-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi there Alpinists,
This is a sort of status update and wish list after near two months of
attempting to base Adélie on Alpine Linux.
1. scripts/bootstrap.sh cannot "fake" cross. Since Adélie uses a
slightly different GCC configuration from Alpine, I attempted to run
bootstrap.sh on x86_64, from my x86_64 system:
ERROR: unsatisfiable constraints:
gcc-6.3.0-r4:
conflicts: gcc-x86_64-6.3.0-r4[so:libcilkrts.so.5=5.0.0]
satisfies: world[gcc] g++-6.3.0-r4[gcc=6.3.0-r4]
gcc-gnat-6.3.0-r4[gcc=6.3.0-r4] build-base-0.5-r0[gcc]
gcc-x86_64-6.3.0-r4:
conflicts: gcc-6.3.0-r4[so:libcilkrts.so.5=5.0.0]
satisfies: world[gcc-x86_64]
Since we have other CPU types that we wish to support, I went ahead
and simply bootstrapped PowerPC. This is therefore not a fatal error,
but one that has caused a lot of time to burn; a lot of packages are
just not ready for ppc and needed some fixing. Specifically, GCC and
OpenSSL needed to be made aware of the PowerPC architecture.
2. The virtual system is pathetic. One of the very core tenets of
Adélie is giving the user power through choice. That choice is almost
impossible to provide using the current abuild/apk framework. I keep
hearing of a Debian-style alternatives system, and supposedly it was
specified somewhere, but I cannot find the specification nor an
implementation. If I could read the specification I would be highly
motivated to write an implementation.
Red Hat has `alternatives`, Debian has `update-alternatives`, and
Gentoo has `eselect`. The Alpine system desperately needs something
like this and I would love to contribute to such.
Consider a few different use cases:
mta: any package that needs `sendmail` has to either hard-depend on
postfix, or disable mail services. This is unacceptable in my
opinion. Other distros let you select what package you want to
provide `sendmail`.
awk: mawk vs gawk vs busybox awk. All have benefits and drawbacks and
the user should be able to choose which provides /usr/bin/awk.
shell: /bin/sh as busybox is of course default, but some users may
want bash or another shell. I don't see any reason that can't be
supported.
vi: busybox, vim, neovim, elvis, ... There are almost a dozen
providers of `vi` in Debian and more than a dozen on Gentoo. I
believe Alpine itself packages four of them.
I started to try and make 'v:mta' but I'm very concerned about
diverging so much from the Alpine aports tree. Also, apk doesn't
support an automatic choice for a virtual if the user hasn't already
installed one (something like replaces_priority but for virtuals would
be good here imo). That means that when I *do* manage to get packages
to depend on v:mta, the user now has to read through an 'unsatisfiable
constraints' error and pick a package out of the list of providers.
3. It is very hard to know where to send some things. For example,
the GCC APKBUILD does not function properly right now: it does not
declare a makedepends on gcc-gnat, and the GCC configure process bails
out when it does not find it because LANG_ADA is true whenever CBUILD
== CHOST == CTARGET. I am not 100% confident in my ability to edit
the APKBUILD for GCC considering how finicky it is, so I would like
help. I posted on the IRC channel but I mainly only have the weekends
to work on Adélie, and most of the channel is away on weekends. This
really isn't a distro topic, so it doesn't belong on alpine-devel from
what I have been able to gather about this list. The aports list
seems to be for patches only, from what I have gathered about that
list. Maybe this belongs on the bug tracker, but there really isn't a
bug category for build failures that I could find.
Additionally, changes made to abuild or apk-tools are currently being
sent via GitHub pull requests. However, none of us in Adélie really
want to use GitHub as it is a closed platform. The aports mailing
list exists for aports, but where could we send abuild or apk-tools
changes if we wanted an alternative to GitHub?
4. We have managed to make a split function 'openrc' that takes
/etc/init.d and /etc/conf.d directories. It has install_if="$pkgname
openrc" so it is transparent when you have OpenRC installed, and
allows future migrations to a different init system. I don't know if
this is of any interest to Alpine.
5. After being annoyed by bugs in the PowerPC build of GNU tar, we
managed to swap out /usr/bin/tar for bsdtar provided by libarchive in
abuild. It needed a patch to output the format apk expects by
default, but otherwise it seems to work quite well. This may be of
interest to those who want to do a GNU-free Alpine spin.
Best,
- --arw
- --
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJZdeC9AAoJEMspy1GSK50U5GsQAIusnvqVkHgQ0IdvRuTngbMD
65j0VAdqSeC0+iuK/yKxkHv9YeBTa6OEPbZwCxzoilYaPem3G7GjFc6WaTwSwGaz
G1XJGEYj7XIA8LQZ2cSKwM+O8FfByXIKxaOLv47hm59hiC3mFXLP0Zl7N2QXF9Nk
eM0YH8DbnFiyz0oanUS9OFOYS96nYEGog9qjGqdHX1w3ENpagWU/FRbaRCDZQSzz
NNbhX+yHYUrFLG/D1zeYadHqwstCcuAv9MgWY8Dd2fMKMdIrAWYzhj8y1f4Du215
kUVmX+4URUfSUGVLdeyw8mm49WMgK0Xivdr6phEfa498xfQrYaW30JQXo3puzWZc
5tabfDxmolM9xNKEA9K/wecguSnphkdz11YMe8DCF9KPiDabbpAdhWdckmZANgxm
7vzAftquJKwnN2rW2oKfuVFX65XKxXIFEJ82ByE52BnVRX5/DhUKDn3up+yXbOYl
IhHfTlyAbaxTi5ovShPb4MKgO8gdsDMyryj/GVQyoivsHp5zNF5ghHCOxAj4N+k1
FAinIVJFRIhRrmv5fHPcvhetUzQdd+RoVYNSJ0QC3Ah38yqZFwnkxEZz0Ce06AZT
h9pjzXSsogN0UBiSdqustxvaCgYlmLod9XQemaqEOKt+7Nn6AfZ5HW0ftVy8GWg7
AC1Na1rqIck0HGUqUYkN
=KGH8
-----END PGP SIGNATURE-----
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello there,
On 24/07/17 09:53, Shiz wrote:
> Hi,> > Thanks for sharing your experiences! I’ll comment on the specific > cases below.> >> 1. scripts/bootstrap.sh cannot "fake" cross. Since Adélie uses >> a slightly different GCC configuration from Alpine, I attempted >> to run bootstrap.sh on x86_64, from my x86_64 system:> > I’m in general not a huge fan of how bootstrapping works at the > moment, but I don’t see a direct way to improve it without > rewriting it entirely and adding significant new functionality > (like proper multiline) to APK.
APK already knows about architectures. And that won't really help the
fake cross: x86_64 == x86_64. Maybe a hack would be to do something
like replaces="gcc" in gcc-$arch packages? Theoretically they should
be in separate directories anyway, but I am not sure if that would be
safe.
>> 2. The virtual system is pathetic. One of the very core tenets >> of Adélie is giving the user power through choice. That choice >> is almost impossible to provide using the current abuild/apk >> framework. I keep hearing of a Debian-style alternatives>> system, and supposedly it was specified somewhere, but I cannot>> find the specification nor an implementation. If I could read>> the specification I would be highly motivated to write an >> implementation.> > This is correct and something that has been bothering us for a > while. A while back I wrote up a rough sketch of how such a system > would function in APK, which is likely what you are referring to. > It can be found here: https://txt.shiz.me/ZDNkNTY3MD.txt
This seems like a decent start. I like how you can select all
provided paths from a package or just a subset. This was actually
requested by one of our early alpha testers.
Would the relocations database have *every* file, or only those in
conflict? I can see the argument either way.
> I have no specific experience with apk-tools’s internals, but> would be open to looking into them to see what’s needed, > possibly/preferably with kaniini and fabled’s assistance and > insights as well.
I have some experience with the internals of apk-tools, but not so
much the database portion. Perhaps that is a task for this weekend :)
> Something I’d like to see is file: dependencies (in the same vein > as so:, but for full file paths), but that’d require encoding the > entire file listing of a package in its `provides` metadata, which > I’m not sure we want due to APKINDEX file size bloat.
I know that both Debian and Red Hat based systems have something like
this stored in another index; `apt-file` and `yum provides`. The
databases are somewhere around 100 MB compressed, so they obviously
are not a part of the standard installation of apt/yum, but they are
available to enable at any time for the users. I'm not sure if Alpine
would want to do something similar. One method would be to have some
sort of 'simplification' step when generating APKINDEX: only include
file: from the master file database when a package references it. For
example:
depends="file:/usr/bin/awk"
would cause every `awk` provider to have a provides: line in APKINDEX
for file:/usr/bin/awk. They wouldn't need to have a provides: for
every file, only the ones that other packages reference.
>> I started to try and make 'v:mta' but I'm very concerned about >> diverging so much from the Alpine aports tree. Also, apk doesn't>> support an automatic choice for a virtual if the user hasn't>> already installed one (something like replaces_priority but for>> virtuals would be good here imo). That means that when I *do*>> manage to get packages to depend on v:mta, the user now has to>> read through an 'unsatisfiable constraints' error and pick a >> package out of the list of providers.> > I’m not sure what the best way to approach this would be in the > system sketch I laid out above.
The above-linked specification doesn't resolve this in any way.
That's fine because it doesn't need to. That can be a separate
discussion / specification. (APK is already deficient in that regard,
so it should be fixed independently of adding an alternatives system,
IMO.)
>> 3. It is very hard to know where to send some things. For >> example, the GCC APKBUILD does not function properly right now: >> it does not declare a makedepends on gcc-gnat, and the GCC >> configure process bails out when it does not find it because >> LANG_ADA is true whenever CBUILD == CHOST == CTARGET.> > This would be a bug against aports in the bug tracker. Generally > most of us are somewhat busy, especially considering the time of > the year. Pinging specific people can work however — don’t take> our lack of response as lack of interest. :)
I never took it as a lack of interest. I know that people are busy
and have jobs and families and lives; for most of us, Alpine and
related open-source projects are things we do because we like doing
them, as a hobby. I will go ahead and file the bug in that section
and keep that in mind if I come across any in the future.
>> Additionally, changes made to abuild or apk-tools are currently >> being sent via GitHub pull requests. However, none of us in >> Adélie really want to use GitHub as it is a closed platform.>> The aports mailing list exists for aports, but where could we>> send abuild or apk-tools changes if we wanted an alternative to >> GitHub?> > These kind of changes should be sent to alpine-devel if you do not > wish to use GitHub.
Duly noted. I would ask if there are any plans to install something
like GitLab, Pagure, or Phabricator for Alpine at some point, but I
don't really want to open such a can of worms :)
>> 4. We have managed to make a split function 'openrc' that takes >> /etc/init.d and /etc/conf.d directories. It has >> install_if="$pkgname openrc" so it is transparent when you have >> OpenRC installed, and allows future migrations to a different >> init system. I don't know if this is of any interest to Alpine.> > I’d like to see this, yes. It seems like a good addition in light > of the things discussed at FOSDEM with regards to init systems.
I will send the patch to this list later today. It is very similar to
the doc split function, so hopefully it is acceptable. If it is
accepted, I will gladly forward on the packages that I have already
split out -openrc for Adélie.
>> 5. After being annoyed by bugs in the PowerPC build of GNU tar, >> we managed to swap out /usr/bin/tar for bsdtar provided by >> libarchive in abuild. It needed a patch to output the format>> apk expects by default, but otherwise it seems to work quite>> well. This may be of interest to those who want to do a GNU-free>> Alpine spin.> > I’m not personally interested in bsdtar as I consider libarchive > fairly bloated, but if the patch is backwards-compatible with GNU > tar I would see no issue with including it at all.
The patch is not for abuild. It is for libarchive itself. Renaming
bsdtar to tar is sufficient for abuild to use it.
> Hope this helped a bit, - Shiz>
It did indeed. Thank you very much!
All the best,
- --arw
- --
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJZdhAxAAoJEMspy1GSK50UYs8P/3KsddJbDb1G+9vfKvsUptyp
+SgzsxMKMfqvZG4mBrgFxUN61rybT0voFcLCZrUGveoxHiib/IUBrHwgPlvDCIVQ
jikunPucpWOfISFdCWE/tphZCZfrWXkfPAGtE7YZlYV6gVu/UkfxmCbSx3JzXAng
sqIuguP5SmBNj7RWFU9qZnLhT3cw6EMDJwEz36tfcvhkGHTwxr4rCtWvbtGkTQBM
IEGK/VWA4MauB3p6vgeAPRZTOXuKRBK/kOt4eGQUh4vNZp55EsSiaRhcrhZKExZ7
DvF66AftUWUJ9VE7qpdm1dYBYuSqD21ooXzeKWiAfcYgmmsUqQ2u+bJ8FwHcOkFV
QwTRmft4khJlQGLL9eOtvL78zmMKXbnj9WC3TNvg7wkTDegSD5uMoRtB9js4Zkq5
TMHMM2xvBHppunIvf8ThlKkCjfEYlyOR3FbCwW4fDcV5Eh+Sefv1FE+2FJfPIu90
ToyGFHa6KmWY+rgP4G8ea2PVi50Sc6e/I+DecA35M/+ZTXzgu+wpFDJW2FOggrYl
2VRaB3xhvwbCqbFXLkw+HdFMZhne5I/P9h+nndKutWBTNx/wFaP1pPQqrN2T2Ay+
oD8tnUXXkhpmx1V4Fv8KYDmn/YJRkFcbdv1UC23bLUDRNscmbhL6dkzRH1eGMRZx
j+aYo+uKKFJ771rknGWF
=F67k
-----END PGP SIGNATURE-----
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Hi,
Thanks for sharing your experiences! I’ll comment on the specific cases
below.
> 1. scripts/bootstrap.sh cannot "fake" cross. Since Adélie uses a> slightly different GCC configuration from Alpine, I attempted to run> bootstrap.sh on x86_64, from my x86_64 system:> > > ERROR: unsatisfiable constraints:> gcc-6.3.0-r4:> conflicts: gcc-x86_64-6.3.0-r4[so:libcilkrts.so.5=5.0.0]> satisfies: world[gcc] g++-6.3.0-r4[gcc=6.3.0-r4]> gcc-gnat-6.3.0-r4[gcc=6.3.0-r4] build-base-0.5-r0[gcc]> gcc-x86_64-6.3.0-r4:> conflicts: gcc-6.3.0-r4[so:libcilkrts.so.5=5.0.0]> satisfies: world[gcc-x86_64]> > > Since we have other CPU types that we wish to support, I went ahead> and simply bootstrapped PowerPC. This is therefore not a fatal error,> but one that has caused a lot of time to burn; a lot of packages are> just not ready for ppc and needed some fixing. Specifically, GCC and> OpenSSL needed to be made aware of the PowerPC architecture.
I’m in general not a huge fan of how bootstrapping works at the moment,
but I don’t see a direct way to improve it without rewriting it entirely
and adding significant new functionality (like proper multiline) to APK.
> 2. The virtual system is pathetic. One of the very core tenets of> Adélie is giving the user power through choice. That choice is almost> impossible to provide using the current abuild/apk framework. I keep> hearing of a Debian-style alternatives system, and supposedly it was> specified somewhere, but I cannot find the specification nor an> implementation. If I could read the specification I would be highly> motivated to write an implementation.
This is correct and something that has been bothering us for a while.
A while back I wrote up a rough sketch of how such a system would function
in APK, which is likely what you are referring to. It can be found here:
https://txt.shiz.me/ZDNkNTY3MD.txt
I have no specific experience with apk-tools’s internals, but would be open
to looking into them to see what’s needed, possibly/preferably with kaniini
and fabled’s assistance and insights as well.
> Red Hat has `alternatives`, Debian has `update-alternatives`, and> Gentoo has `eselect`. The Alpine system desperately needs something> like this and I would love to contribute to such.> > Consider a few different use cases:> > mta: any package that needs `sendmail` has to either hard-depend on> postfix, or disable mail services. This is unacceptable in my> opinion. Other distros let you select what package you want to> provide `sendmail`.> > awk: mawk vs gawk vs busybox awk. All have benefits and drawbacks and> the user should be able to choose which provides /usr/bin/awk.> > shell: /bin/sh as busybox is of course default, but some users may> want bash or another shell. I don't see any reason that can't be> supported.> > vi: busybox, vim, neovim, elvis, ... There are almost a dozen> providers of `vi` in Debian and more than a dozen on Gentoo. I> believe Alpine itself packages four of them.
Something I’d like to see is file: dependencies (in the same vein
as so:, but for full file paths), but that’d require encoding the
entire file listing of a package in its `provides` metadata, which I’m
not sure we want due to APKINDEX file size bloat.
> I started to try and make 'v:mta' but I'm very concerned about> diverging so much from the Alpine aports tree. Also, apk doesn't> support an automatic choice for a virtual if the user hasn't already> installed one (something like replaces_priority but for virtuals would> be good here imo). That means that when I *do* manage to get packages> to depend on v:mta, the user now has to read through an 'unsatisfiable> constraints' error and pick a package out of the list of providers.
I’m not sure what the best way to approach this would be in the system
sketch I laid out above.
> 3. It is very hard to know where to send some things. For example,> the GCC APKBUILD does not function properly right now: it does not> declare a makedepends on gcc-gnat, and the GCC configure process bails> out when it does not find it because LANG_ADA is true whenever CBUILD> == CHOST == CTARGET. I am not 100% confident in my ability to edit> the APKBUILD for GCC considering how finicky it is, so I would like> help. I posted on the IRC channel but I mainly only have the weekends> to work on Adélie, and most of the channel is away on weekends. This> really isn't a distro topic, so it doesn't belong on alpine-devel from> what I have been able to gather about this list. The aports list> seems to be for patches only, from what I have gathered about that> list. Maybe this belongs on the bug tracker, but there really isn't a> bug category for build failures that I could find.
This would be a bug against aports in the bug tracker. Generally most of
us are somewhat busy, especially considering the time of the year.
Pinging specific people can work however — don’t take our lack of response
as lack of interest. :)
> Additionally, changes made to abuild or apk-tools are currently being> sent via GitHub pull requests. However, none of us in Adélie really> want to use GitHub as it is a closed platform. The aports mailing> list exists for aports, but where could we send abuild or apk-tools> changes if we wanted an alternative to GitHub?
These kind of changes should be sent to alpine-devel if you do not wish
to use GitHub.
> 4. We have managed to make a split function 'openrc' that takes> /etc/init.d and /etc/conf.d directories. It has install_if="$pkgname> openrc" so it is transparent when you have OpenRC installed, and> allows future migrations to a different init system. I don't know if> this is of any interest to Alpine.
I’d like to see this, yes. It seems like a good addition in light of the
things discussed at FOSDEM with regards to init systems.
> 5. After being annoyed by bugs in the PowerPC build of GNU tar, we> managed to swap out /usr/bin/tar for bsdtar provided by libarchive in> abuild. It needed a patch to output the format apk expects by> default, but otherwise it seems to work quite well. This may be of> interest to those who want to do a GNU-free Alpine spin.
I’m not personally interested in bsdtar as I consider libarchive fairly
bloated, but if the patch is backwards-compatible with GNU tar I would
see no issue with including it at all.
> Best,> --arw
Hope this helped a bit,
- Shiz
Hi
On Mon, Jul 24, 2017 at 10:20:17AM -0500, A. Wilcox wrote:
> Duly noted. I would ask if there are any plans to install something> like GitLab, Pagure, or Phabricator for Alpine at some point, but I> don't really want to open such a can of worms :)http://patchwork.alpinelinux.org/project/aports/list/
Alpine uses patchwork, which is a great tool developed at ozlabs.
Patchwork 2.0 will support RESTAPI events, so you can plugin almost
anything into patchwork (Jenkins for example). I love the
mailinglist/patchwork approach, because I am a hopeless minimalist
(using only terminal programs and a browser). I hope Alpine will
continue into build into that direction.
I have use GitHub a lot, while disliking it for various reasons.
Best,
Jean-Louis
HI,
I strongly disagree that Patchwork is a great tool, at least the current version we have.
I can’t imagine something that can be worse, less productive than Patchwork. It’s more or less just bad a web UI for mailbox. There’s no clear relation between related patches, ’cause it’s just nearly impossible to reconstruct such information from separated patches in mail. It’s simply not possible to set any reasonable integration with CI on top of this. Not even talking about its “support” for code-reviews, that is more or less non-existing.
Patchwork is based on ancient workflow from CVS era. Pull/Merge request, the feature in GitHub, GitLab and other git-based tools, is proper git-way. It starts and ends with git. You create new branch in your clone of the repository, push some commits and opens a pull request (this can be done from CLI ofc, but well only via vendor-specific API). On git level, pull request is a reference in the target git repository. Maintainer can work with it directly via git (see https://gist.github.com/piscisaureus/3342247), without leaving terminal. When the contributor push new changes to the pull request, maintainer can simply pull them via git and view in context, it’s just a branch.
Comments on pull requests are unfortunately not stored in git (they can be, but GH/GL don’t do that), so this happens outside of git (yet still can work with it from CLI).
I’m one of the Alpine devs who interacts with user contributions the most. I don’t use our Patchwork at all, because it’s unreasonable waste of my time to work with such bad tool. Mostly for lack of CI integration, but not just that. It’s really horrible for reviews. I understand that it may be quite comfortable for contributors (that don’t know git), but I believe that only to the moment when changes are requested.
I understand why some ppl don’t like GitHub (it’s third-party commercial service after all), but what I really don’t understand is how can anyone say minimalism and Mailing-List/Patchwork in one sentence. Have you ever considered the “mail” part of it? Mails are insanely complex nowadays.
Sorry for grammar, I wrote it in hurry.
Jakub
> On 24. Jul 2017, at 21:50, Jean-Louis Fuchs <ganwell@fangorn.ch> wrote:> > Hi> > On Mon, Jul 24, 2017 at 10:20:17AM -0500, A. Wilcox wrote:>> Duly noted. I would ask if there are any plans to install something>> like GitLab, Pagure, or Phabricator for Alpine at some point, but I>> don't really want to open such a can of worms :)> > http://patchwork.alpinelinux.org/project/aports/list/> > Alpine uses patchwork, which is a great tool developed at ozlabs.> Patchwork 2.0 will support RESTAPI events, so you can plugin almost> anything into patchwork (Jenkins for example). I love the> mailinglist/patchwork approach, because I am a hopeless minimalist> (using only terminal programs and a browser). I hope Alpine will> continue into build into that direction.> > I have use GitHub a lot, while disliking it for various reasons.> > Best,> Jean-Louis
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Hi Jakub
On Mon, Jul 24, 2017 at 10:46:44PM +0200, Jakub Jirutka wrote:
> I strongly disagree that Patchwork is a great tool, at least the> current version we have.
In the end the process/tools has to fit the most active commiters, not
non-commiters like me.
Since you are a power-user, know better then I. I am someone
who likes "git send-email" and mailinglists. For me patchwork is more
or less the tool that creates RESTAPI events from a patch-mailinglist
(not in alpine though). I also use GitLab a lot and like it a lot.
I just wanted to say that a minimalistic approach (meaning simple
tools like git send-email + a mailinglist), is liked by a non-commiter
like me and I know commiters in other projects who like it too.
But as I said, the process has to be optimized for the active
commiters. And I guess I am strange and a exception, since I prefer
TUIs to GUIs.
Best,
Jean
Hello,
On Mon, Jul 24, 2017 at 10:20 AM, A. Wilcox <awilfox@adelielinux.org> wrote:
>>> 2. The virtual system is pathetic. One of the very core tenets>>> of Adélie is giving the user power through choice. That choice>>> is almost impossible to provide using the current abuild/apk>>> framework. I keep hearing of a Debian-style alternatives>>> system, and supposedly it was specified somewhere, but I cannot>>> find the specification nor an implementation. If I could read>>> the specification I would be highly motivated to write an>>> implementation.>>>> This is correct and something that has been bothering us for a>> while. A while back I wrote up a rough sketch of how such a system>> would function in APK, which is likely what you are referring to.>> It can be found here: https://txt.shiz.me/ZDNkNTY3MD.txt>>> This seems like a decent start. I like how you can select all> provided paths from a package or just a subset. This was actually> requested by one of our early alpha testers.>> Would the relocations database have *every* file, or only those in> conflict? I can see the argument either way.
APK already stores all files available to it in the installed-db.
Thusly, we would only need to store the redirections.
I think this should be a component of apk-tools.
>> I have no specific experience with apk-tools’s internals, but>> would be open to looking into them to see what’s needed,>> possibly/preferably with kaniini and fabled’s assistance and>> insights as well.>>> I have some experience with the internals of apk-tools, but not so> much the database portion. Perhaps that is a task for this weekend :)>>>> Something I’d like to see is file: dependencies (in the same vein>> as so:, but for full file paths), but that’d require encoding the>> entire file listing of a package in its `provides` metadata, which>> I’m not sure we want due to APKINDEX file size bloat.>>> I know that both Debian and Red Hat based systems have something like> this stored in another index; `apt-file` and `yum provides`. The> databases are somewhere around 100 MB compressed, so they obviously> are not a part of the standard installation of apt/yum, but they are> available to enable at any time for the users. I'm not sure if Alpine> would want to do something similar. One method would be to have some> sort of 'simplification' step when generating APKINDEX: only include> file: from the master file database when a package references it. For> example:>> depends="file:/usr/bin/awk">> would cause every `awk` provider to have a provides: line in APKINDEX> for file:/usr/bin/awk. They wouldn't need to have a provides: for> every file, only the ones that other packages reference.
This would severely bloat the APKINDEX. We should probably not do this.
>>> I started to try and make 'v:mta' but I'm very concerned about>>> diverging so much from the Alpine aports tree. Also, apk doesn't>>> support an automatic choice for a virtual if the user hasn't>>> already installed one (something like replaces_priority but for>>> virtuals would be good here imo). That means that when I *do*>>> manage to get packages to depend on v:mta, the user now has to>>> read through an 'unsatisfiable constraints' error and pick a>>> package out of the list of providers.>>>> I’m not sure what the best way to approach this would be in the>> system sketch I laid out above.>>> The above-linked specification doesn't resolve this in any way.> That's fine because it doesn't need to. That can be a separate> discussion / specification. (APK is already deficient in that regard,> so it should be fixed independently of adding an alternatives system,> IMO.)
This could probably be solved by 'preference levels'.
The package with the highest preference level and lowest depgraph
solution cost would be selected.
>>> 3. It is very hard to know where to send some things. For>>> example, the GCC APKBUILD does not function properly right now:>>> it does not declare a makedepends on gcc-gnat, and the GCC>>> configure process bails out when it does not find it because>>> LANG_ADA is true whenever CBUILD == CHOST == CTARGET.>>>> This would be a bug against aports in the bug tracker. Generally>> most of us are somewhat busy, especially considering the time of>> the year. Pinging specific people can work however — don’t take>> our lack of response as lack of interest. :)>>> I never took it as a lack of interest. I know that people are busy> and have jobs and families and lives; for most of us, Alpine and> related open-source projects are things we do because we like doing> them, as a hobby. I will go ahead and file the bug in that section> and keep that in mind if I come across any in the future.>>>>> Additionally, changes made to abuild or apk-tools are currently>>> being sent via GitHub pull requests. However, none of us in>>> Adélie really want to use GitHub as it is a closed platform.>>> The aports mailing list exists for aports, but where could we>>> send abuild or apk-tools changes if we wanted an alternative to>>> GitHub?>>>> These kind of changes should be sent to alpine-devel if you do not>> wish to use GitHub.>>> Duly noted. I would ask if there are any plans to install something> like GitLab, Pagure, or Phabricator for Alpine at some point, but I> don't really want to open such a can of worms :)>>>>> 4. We have managed to make a split function 'openrc' that takes>>> /etc/init.d and /etc/conf.d directories. It has>>> install_if="$pkgname openrc" so it is transparent when you have>>> OpenRC installed, and allows future migrations to a different>>> init system. I don't know if this is of any interest to Alpine.>>>> I’d like to see this, yes. It seems like a good addition in light>> of the things discussed at FOSDEM with regards to init systems.>>> I will send the patch to this list later today. It is very similar to> the doc split function, so hopefully it is acceptable. If it is> accepted, I will gladly forward on the packages that I have already> split out -openrc for Adélie.
Once sent over, I see no reason why it wouldn't be accepted.
>>> 5. After being annoyed by bugs in the PowerPC build of GNU tar,>>> we managed to swap out /usr/bin/tar for bsdtar provided by>>> libarchive in abuild. It needed a patch to output the format>>> apk expects by default, but otherwise it seems to work quite>>> well. This may be of interest to those who want to do a GNU-free>>> Alpine spin.>>>> I’m not personally interested in bsdtar as I consider libarchive>> fairly bloated, but if the patch is backwards-compatible with GNU>> tar I would see no issue with including it at all.>>> The patch is not for abuild. It is for libarchive itself. Renaming> bsdtar to tar is sufficient for abuild to use it.
Lets go ahead and integrate this patch, I suppose.
William
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Hello,
On Mon, Jul 24, 2017 at 5:31 PM, Jakub Jirutka <jakub@jirutka.cz> wrote:
> Hi Jean,>>> I just wanted to say that a minimalistic approach (meaning simple tools like git send-email + a mailinglist)…>> git send-email is indeed minimalistic, but mailing-list is really not.>>> And I guess I am strange and a exception, since I prefer TUIs to GUIs.>> Actually you’re not, many Alpinists prefer TUIs to GUIs, including myself. What I wanted to say is that pull requests workflow is even more suitable for TUIs than ML. You can use tools like https://hub.github.com/ + plain git or build your own tools suitable for your workflow, without need to deal with bunch of unstructured information in emails.>>> …is liked by a non-commiter like meand I know commiters in other projects who like it too. …the process has to be optimized for the active commiters…>> Well, we need to optimize the process for maintainers, active contributors and even less active / new contributors like you. That’s one of the reasons why we still support both GitHub and Patchwork.>> I admit that I’d personally love to get rid of Patchwork, but 1st others don’t allow me to do that, 2st no one, including myself, wants to depend on third-party service as the only option. Currently we don’t have any sane alternative (simple, lightweight yet powerful). We know that the current process is not ideal, but there are too many issues and too little time…
I think our requirements are more specialised and I am wondering if it
would be possible to build a simple application which merges the
github PRs and patchwork patches in such a way that they can be
tested.
Once we have a solution to the CI problems, building such a site seems
trivial to me.
Debian has a similar website: mentors.debian.org, which does some
checks on incoming contributions. Building something like that seems
like something that would give us the best of all worlds, really.
William
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Hi Jean,
> I just wanted to say that a minimalistic approach (meaning simple tools like git send-email + a mailinglist)…
git send-email is indeed minimalistic, but mailing-list is really not.
> And I guess I am strange and a exception, since I prefer TUIs to GUIs.
Actually you’re not, many Alpinists prefer TUIs to GUIs, including myself. What I wanted to say is that pull requests workflow is even more suitable for TUIs than ML. You can use tools like https://hub.github.com/ + plain git or build your own tools suitable for your workflow, without need to deal with bunch of unstructured information in emails.
> …is liked by a non-commiter like meand I know commiters in other projects who like it too. …the process has to be optimized for the active commiters…
Well, we need to optimize the process for maintainers, active contributors and even less active / new contributors like you. That’s one of the reasons why we still support both GitHub and Patchwork.
I admit that I’d personally love to get rid of Patchwork, but 1st others don’t allow me to do that, 2st no one, including myself, wants to depend on third-party service as the only option. Currently we don’t have any sane alternative (simple, lightweight yet powerful). We know that the current process is not ideal, but there are too many issues and too little time…
About GitLab, I know it very well and it makes me very sad what insane bloatware it became after years. Complex beasts rules the world, not many people value simplicity.
Best regards,
Jakub
> On 24. Jul 2017, at 23:46, Jean-Louis Fuchs <ganwell@fangorn.ch> wrote:> > Hi Jakub> > In the end the process/tools has to fit the most active commiters, not> non-commiters like me.> > Since you are a power-user, know better then I. I am someone> who likes "git send-email" and mailinglists. For me patchwork is more> or less the tool that creates RESTAPI events from a patch-mailinglist> (not in alpine though). I also use GitLab a lot and like it a lot.> > I just wanted to say that a minimalistic approach (meaning simple> tools like git send-email + a mailinglist), is liked by a non-commiter> like me and I know commiters in other projects who like it too.> > But as I said, the process has to be optimized for the active> commiters. And I guess I am strange and a exception, since I prefer> TUIs to GUIs.> > Best,> Jean
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Perfect example of a post hoc ergo propter hoc fallacy. I am orders of
magnitude more active on github than on patchwork, because it really,
really sucks. I'm pretty sure that I'm not the only one.
You can say whatever you want about the next version of patchwork, as
it's not yet there, and therefore might very well suck less; but please
do not infer that the not-so-active contributors wouldn't be more active
under different (in the case of patchwork - less painful) conditions.
HTH,
7heo.
On 7/24/2017 11:46 PM, Jean-Louis Fuchs wrote:
> Hi Jakub>> On Mon, Jul 24, 2017 at 10:46:44PM +0200, Jakub Jirutka wrote:>>> I strongly disagree that Patchwork is a great tool, at least the>> current version we have.>> In the end the process/tools has to fit the most active commiters, not> non-commiters like me.>> Since you are a power-user, know better then I. I am someone> who likes "git send-email" and mailinglists. For me patchwork is more> or less the tool that creates RESTAPI events from a patch-mailinglist> (not in alpine though). I also use GitLab a lot and like it a lot.>> I just wanted to say that a minimalistic approach (meaning simple> tools like git send-email + a mailinglist), is liked by a non-commiter> like me and I know commiters in other projects who like it too.>> But as I said, the process has to be optimized for the active> commiters. And I guess I am strange and a exception, since I prefer> TUIs to GUIs.>> Best,> Jean>
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 24/07/17 17:31, Jakub Jirutka wrote:
> Currently we don’t have any sane alternative (simple, lightweight> yet powerful). We know that the current process is not ideal, but> there are too many issues and too little time…> > About GitLab, I know it very well and it makes me very sad what> insane bloatware it became after years. Complex beasts rules the> world, not many people value simplicity.> > Best regards, Jakub>
Have you looked in to Pagure? It is designed to be a lightweight Git
forge, made by the Fedora people. Right now it still has some
Fedora-specific stuff, but Debian has a testing package for it and I'm
hoping to try and make an Alpine port for it once I manage to have a
desktop going.
It is written in Python but has very few dependencies; just flask
(lightweight Web framework), redis, and libgit2. I am very hopeful to
have it running as a replacement for our (Adélie) GitLab instance some
time in Q4 17 or Q1 18.
All the best,
- --arw
- --
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJZdzXRAAoJEMspy1GSK50UZacP/2i8S96HuuqpcJsQIpA9AhB3
7ERdY8QabGZgQqWZJkbE84cjP9DmJf500YsoQoNRUN4p729YizRb8ODH9sVBbeTf
DjHTuXV/V7v0yKIVkNrBUqP2ceSsxZ+L7j3uMS9Sv0L3+i7bSNQj+M3AYTtiO5Lb
1iZZxpVhqeIBsMhL4Kcku1weURHyLSHsLkqngZ1t5W5z26c2xUlBY76QCbViYWYv
Vsws3TxvjViEv4SM8+jaF/xD5/W9Qn95qiU1tW4eNjmwcwjXeHTbRRSpLbkAJCZa
JEWCVZ98CopuItuTTkMCpa4W/Xuu9y0OsbCKPyu3YjCFbsLF4jrnWcX6gK20on8L
R25/Vc/TAQ6qfpONivr7mdwh20g1oPu0JBa+6vuVQpravDEJQMlI92w8A8ow/7Xb
MRVaUb6+B6kuoYYguFQJj1NF/Mnu/58w0q1rYE96uufkACM9/WZiRf4Fx0r1eAFW
uFr0l1h80TE0Qps9KU+QmMoOe2cjCsw44P6rP1beCivn8837puBDsJZQ4s0lU7H/
9NauXAuyP8JT6q0PIfp3X9GhADyPxV9/MO4/wVE66jzRUIy/BTw81f0X4qR676RK
8u0saJmKVfrmqrloEOSyZCDHUrnQv00tUW3ESxfcQOP2VZC0Nlr/ts+9ucsHIYXC
0Oo7Yt00sqSXQB9OcLTB
=46D3
-----END PGP SIGNATURE-----
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 25/07/17 01:07, Timo Teras wrote:
> On Mon, 24 Jul 2017 16:53:50 +0200 Shiz <hi@shiz.me> wrote:> >>> 1. scripts/bootstrap.sh cannot "fake" cross. Since Adélie>>> uses a slightly different GCC configuration from Alpine, I>>> attempted to run bootstrap.sh on x86_64, from my x86_64>>> system:>>> > > The above error is mostly due to GCC having strict versioned > dependencies for the exact pkgversion + pkgrel. And probably the > gcc APKBUILD you tried to use to bootstrap did not match the gcc > installed on your system. I am not entirely sure how the> dependencies should be fixed.> > Additionally the crossbuild mechanism is triggered by build arch> being different from host arch. So bootstrapping same architecture> is not so trivial. This is also how it works on gcc, though it's> using the arch triplets. As such the bootstrap script is currently> really intended for bootstrapping new architectures only.
How does one bootstrap a new distro? Especially one with a slightly
different triplet (i486-*, powerpc64-*, etc) than Alpine's, not to
mention different configuration options? Should I just build a new
GCC and install it over the current one?
I figured running bootstrap.sh would be the quickest / easiest way to
do that. But maybe I was wrong.
>> A while back I wrote up a rough sketch of how such a system>> would function in APK, which is likely what you are referring to.>> It can be found here: https://txt.shiz.me/ZDNkNTY3MD.txt> > Yes, this has been discussed couple of times. I've been designing> apk v3 with different implementation for resolving file conflicts.> The basic idea being as described in Shiz's note (though this is> the first time I see it). The plan was to resolve conflicts first> based on the 'replaces priority' but have some sort of manual> override.
Would there still be a way to choose a different provider later?
>> This would be a bug against aports in the bug tracker. Generally>> most of us are somewhat busy, especially considering the time of>> the year. Pinging specific people can work however — don’t take>> our lack of response as lack of interest. :)> > Agreed. Alpine-devel mailing list like you did now is also good :)> > Toolchain assumes to have toolchain on builders. gcc-gnat is> somehow nasty, it should be in build-base *or* in makedepends> explicitly. But IIRC, the build scripts had some limitations on> this originally. Perhaps this is fixed now.> > @ncopa Could we just add gcc-gnat to gcc's makedepends, or> build-base?
I know that build-base is probably already a bit larger than it needs
to be... but how many Ada packages are on Alpine to justify the
additional size in build-base? AFAIK no other distro has Ada support
in the base build package. It probably belongs in makedepends.
>>> Additionally, changes made to abuild or apk-tools are>>> currently being sent via GitHub pull requests. However, none>>> of us in Adélie really want to use GitHub as it is a closed>>> platform. The aports mailing list exists for aports, but where>>> could we send abuild or apk-tools changes if we wanted an>>> alternative to GitHub?>> >> These kind of changes should be sent to alpine-devel if you do>> not wish to use GitHub.> > We've picked up patches to abuild and apk-tools from alpine-devel> and alpine-aports mailing lists. Perhaps we should have> alpine-patches or similar for non-aports patches.
+1 for alpine-patches, but alpine-devel works just as well and already
has the subscribers so it is probably fine.
> > Thanks! Timo>
Best,
- --arw
- --
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJZdznlAAoJEMspy1GSK50U0WQQAKNd+rUmMUZMnXySJj1w2J7t
xeFxm/8KFv/gN9Rnq7GNdZ1O6qvsHbnNGtdMKHq39yhXJe2jPRPugp+5Z+n+IHSt
TDqMYy9ENUd+MAmJIKZcJ5Qs7vC9vknMJtoPL674A0VVsIhjfjQ2FSOU5KrFX3yQ
MjS7+1/LqqDPnINgWfsWUwvSnzBPd2qWfDWbslDtBB/uk13juHzgVOmmE/Fjn9Uj
mAu6ohMv9UkBrTS4ixhvk2butMdZ8MrllDUewfLFfivlWGSfff2pOOMkQ1E1gFPW
R0nfqWL8Gh6mJ37UJbunXm/I0U0acw1vXDE3jqpfGIXu1R9x4K6EuFv4aeyXyf9o
9WnFLr1d0hwNfexWqYFrkANkOleS+q2tRDE0S/zYG2ayMxVa/bbwhQOdIMxSUzkT
fXirftOEFzmrqWJ/hUimRwLg9sOcU6GzIwJ6RZJD9EmHE/kP+nx9Owt90N/B5kQy
3Ls5/j+e3g7C1LpHkH3B+38NABBBcoNtB3ZqR9YeV223m5XQmN6n8ijNNp80nVTi
M/S+jDzBGwba7rARcgEabvr9mr86sBRuA4Xpt9J/VUk49LrdVWEzLEl+zbTYsIYX
PIJ59gzAZIqpk/YEcXnFfVv0wmfgPEzdFB5Wzt2y0jNbtpINWbKzssmWSsn2t04X
gC59KcuEXiSvDgobv+7t
=cBY6
-----END PGP SIGNATURE-----
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Mon, 24 Jul 2017 16:53:50 +0200
Shiz <hi@shiz.me> wrote:
> > 1. scripts/bootstrap.sh cannot "fake" cross. Since Adélie uses a> > slightly different GCC configuration from Alpine, I attempted to run> > bootstrap.sh on x86_64, from my x86_64 system:> > > > > > ERROR: unsatisfiable constraints:> > gcc-6.3.0-r4:> > conflicts: gcc-x86_64-6.3.0-r4[so:libcilkrts.so.5=5.0.0]> > satisfies: world[gcc] g++-6.3.0-r4[gcc=6.3.0-r4]> > gcc-gnat-6.3.0-r4[gcc=6.3.0-r4] build-base-0.5-r0[gcc]> > gcc-x86_64-6.3.0-r4:> > conflicts: gcc-6.3.0-r4[so:libcilkrts.so.5=5.0.0]> > satisfies: world[gcc-x86_64]> > > > Since we have other CPU types that we wish to support, I went ahead> > and simply bootstrapped PowerPC. This is therefore not a fatal> > error, but one that has caused a lot of time to burn; a lot of> > packages are just not ready for ppc and needed some fixing.> > Specifically, GCC and OpenSSL needed to be made aware of the> > PowerPC architecture.
The above error is mostly due to GCC having strict versioned
dependencies for the exact pkgversion + pkgrel. And probably the
gcc APKBUILD you tried to use to bootstrap did not match the gcc
installed on your system. I am not entirely sure how the dependencies
should be fixed.
Additionally the crossbuild mechanism is triggered by build arch being
different from host arch. So bootstrapping same architecture is not so
trivial. This is also how it works on gcc, though it's using the arch
triplets. As such the bootstrap script is currently really intended for
bootstrapping new architectures only.
> I’m in general not a huge fan of how bootstrapping works at the> moment, but I don’t see a direct way to improve it without rewriting> it entirely and adding significant new functionality (like proper> multiline) to APK.
Could you elaborate this a bit? We actually now properly cross-build
and package .apk package at each step. While it's not polished,
it does actually technically the correct thing in most cases.
> > 2. The virtual system is pathetic. One of the very core tenets of> > Adélie is giving the user power through choice. That choice is> > almost impossible to provide using the current abuild/apk> > framework. I keep hearing of a Debian-style alternatives system,> > and supposedly it was specified somewhere, but I cannot find the> > specification nor an implementation. If I could read the> > specification I would be highly motivated to write an> > implementation. > > This is correct and something that has been bothering us for a while.> A while back I wrote up a rough sketch of how such a system would> function in APK, which is likely what you are referring to. It can be> found here: https://txt.shiz.me/ZDNkNTY3MD.txt> > I have no specific experience with apk-tools’s internals, but would> be open to looking into them to see what’s needed,> possibly/preferably with kaniini and fabled’s assistance and insights> as well.
Yes, this has been discussed couple of times. I've been designing apk
v3 with different implementation for resolving file conflicts. The
basic idea being as described in Shiz's note (though this is the first
time I see it). The plan was to resolve conflicts first based on the
'replaces priority' but have some sort of manual override.
> > Red Hat has `alternatives`, Debian has `update-alternatives`, and> > Gentoo has `eselect`. The Alpine system desperately needs something> > like this and I would love to contribute to such.> > > > Consider a few different use cases:> > > > mta: any package that needs `sendmail` has to either hard-depend on> > postfix, or disable mail services. This is unacceptable in my> > opinion. Other distros let you select what package you want to> > provide `sendmail`.> > > > awk: mawk vs gawk vs busybox awk. All have benefits and drawbacks> > and the user should be able to choose which provides /usr/bin/awk.> > > > shell: /bin/sh as busybox is of course default, but some users may> > want bash or another shell. I don't see any reason that can't be> > supported.> > > > vi: busybox, vim, neovim, elvis, ... There are almost a dozen> > providers of `vi` in Debian and more than a dozen on Gentoo. I> > believe Alpine itself packages four of them.
Yes. Currently the way it works busybox is a hack. I'd love to get this
fixed too.
> Something I’d like to see is file: dependencies (in the same vein> as so:, but for full file paths), but that’d require encoding the> entire file listing of a package in its `provides` metadata, which I’m> not sure we want due to APKINDEX file size bloat.
We have some intent to add full DB of files, as separate index files.
I'd rather not depend file directly. But nothing prevents adding
"provides=file:/bin/foo" from multiple packages and have packages
depend on it.
In fact this is how the automatic dso dependencies work; they scan for
the .so files, and create provides for it, and depends on them.
> > I started to try and make 'v:mta' but I'm very concerned about> > diverging so much from the Alpine aports tree. Also, apk doesn't> > support an automatic choice for a virtual if the user hasn't already> > installed one (something like replaces_priority but for virtuals> > would be good here imo). That means that when I *do* manage to get> > packages to depend on v:mta, the user now has to read through an> > 'unsatisfiable constraints' error and pick a package out of the> > list of providers.
Correct. The automatic choice is done only if the provided dependency
is versioned, but that also automatically conflicts with other
providers of the same dependency.
It was intentional design choice to not do automatic choice for the
versionless provided names. Replaces priority or similar work here. But
I would like to give a bit more thought to this.
> I’m not sure what the best way to approach this would be in the system> sketch I laid out above.> > > 3. It is very hard to know where to send some things. For example,> > the GCC APKBUILD does not function properly right now: it does not> > declare a makedepends on gcc-gnat, and the GCC configure process> > bails out when it does not find it because LANG_ADA is true> > whenever CBUILD == CHOST == CTARGET. I am not 100% confident in my> > ability to edit the APKBUILD for GCC considering how finicky it is,> > so I would like help. I posted on the IRC channel but I mainly> > only have the weekends to work on Adélie, and most of the channel> > is away on weekends. This really isn't a distro topic, so it> > doesn't belong on alpine-devel from what I have been able to gather> > about this list. The aports list seems to be for patches only,> > from what I have gathered about that list. Maybe this belongs on> > the bug tracker, but there really isn't a bug category for build> > failures that I could find. > > This would be a bug against aports in the bug tracker. Generally most> of us are somewhat busy, especially considering the time of the year.> Pinging specific people can work however — don’t take our lack of> response as lack of interest. :)
Agreed. Alpine-devel mailing list like you did now is also good :)
Toolchain assumes to have toolchain on builders. gcc-gnat is somehow
nasty, it should be in build-base *or* in makedepends explicitly. But
IIRC, the build scripts had some limitations on this originally.
Perhaps this is fixed now.
@ncopa Could we just add gcc-gnat to gcc's makedepends, or build-base?
> > Additionally, changes made to abuild or apk-tools are currently> > being sent via GitHub pull requests. However, none of us in Adélie> > really want to use GitHub as it is a closed platform. The aports> > mailing list exists for aports, but where could we send abuild or> > apk-tools changes if we wanted an alternative to GitHub? > > These kind of changes should be sent to alpine-devel if you do not> wish to use GitHub.
We've picked up patches to abuild and apk-tools from alpine-devel and
alpine-aports mailing lists. Perhaps we should have alpine-patches or
similar for non-aports patches.
Thanks!
Timo
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Hello,
On 07/25/2017 09:30 AM, A. Wilcox wrote:
> How does one bootstrap a new distro? Especially one with a slightly> different triplet (i486-*, powerpc64-*, etc) than Alpine's, not to> mention different configuration options? Should I just build a new> GCC and install it over the current one?> > I figured running bootstrap.sh would be the quickest / easiest way to> do that. But maybe I was wrong.
That is what I found during the ppc64le bootstrap.
During the ppc64le bootstrap time, I tried two different strategies:
1) Cross-distro compile Alpine packages from Debian/ppc64le. This strategy
seemed better at that time, because I could have delayed or even avoid GCC
bootstrap. I.e, I was using Debian's GCC to compile Alpine's package, and I
would like to have compiled GCC from the inside an already created Alpine
rootfs, without doing the GCC bootstrap process.
Since Debian had Musl, it would not be a problem, I thought.
2) Use the bootstrap script and start on Alpine/x86 and starting build from
the begining, i.e, doing GCC bootstrap and moving up.
What I found later is that it was quite hard to avoid GLIBC contamination
during the cross-distro compilation process. I was never able to get rid of
the GLIBC symbols using the first strategy.
When I switched to the second strategy, it was much easier to find the
problem and solve them, seeing progress at every new bug.
Anyway, this was my personal experience, and, as you should expect, your
mileage may vary.
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi,
On 27/07/17 04:46, Natanael Copa wrote:
> On Mon, 24 Jul 2017 06:57:52 -0500 "A. Wilcox" > <awilfox@adelielinux.org> wrote:>> This is a sort of status update and wish list after near two >> months of attempting to base Adélie on Alpine Linux.> > Thank you for sharing your experiences.
I am glad to be a part of a community where sharing is acceptable. :)
>> 1. scripts/bootstrap.sh cannot "fake" cross. Since Adélie uses >> a slightly different GCC configuration from Alpine, I attempted >> to run bootstrap.sh on x86_64, from my x86_64 system:>> >> >> ERROR: unsatisfiable constraints: gcc-6.3.0-r4: conflicts: >> gcc-x86_64-6.3.0-r4[so:libcilkrts.so.5=5.0.0]> > I wonder if it would make sense to add provides="$pkgname-$arch" to> gcc. That way "gcc-x86_64" would be provided from "gcc" on x86_64.
That might be an interesting way around it. I will play with that
over this weekend and see how that works.
>> 2. The virtual system is pathetic. One of the very core tenets >> of Adélie is giving the user power through choice. That choice >> is almost impossible to provide using the current abuild/apk >> framework. I keep hearing of a Debian-style alternatives>> system, and supposedly it was specified somewhere, but I cannot>> find the specification nor an implementation. If I could read>> the specification I would be highly motivated to write an >> implementation.>> >> Red Hat has `alternatives`, Debian has `update-alternatives`, and>> Gentoo has `eselect`. The Alpine system desperately needs >> something like this and I would love to contribute to such.> > I think something like update-alternatives or eselect makes sense. > For example, you may want select which java implementation you > should use as the "system" java.> > But I think we can divide it in 2 different cases:> > 1) symlinks (eg /usr/bin/lua -> /usr/bin/lua$version and > /usr/bin/php -> /usr/bin/php$version). Selecting system java also > goes here.> > 2) provides and dependencies in apk> > I am not convinced we should let apk handle the> select/alternatives and mix that into the dependency calculation.
apk doesn't necessarily need to be the tool used to select the
alternative, but I'm not sure how packages that depend on something
like PHP or Java or Lua would work if apk wasn't somewhat aware.
Something like Gentoo's slots may work for some of them but I don't
think that's something that needs to be added to the APK format.
There needs to be a way to depend on "php" and have apk accept that
there are multiple PHP interpreters (such as a virtual or file path).
>> Consider a few different use cases:>> >> mta: any package that needs `sendmail` has to either hard-depend >> on postfix, or disable mail services. This is unacceptable in my>> opinion. Other distros let you select what package you want to>> provide `sendmail`.> > It has been mentioned already, but I think for sendmail we want > provides=/usr/sbin/sendmail in the different providers and the > packages that needs it should do depends=/usr/sbin/sendmail. (we > could do provides=file:/usr/sbin/sendmail too but i think that a > leading '/' is enought to indicate that its a file)
So would that be manual (you put in the package provides= line that it
provides sendmail)? That would probably be fine.
>> awk: mawk vs gawk vs busybox awk. All have benefits and >> drawbacks and the user should be able to choose which provides >> /usr/bin/awk.> > Also mentioned before that awk is a part of the base system and is> expected to be there. So adding depends=/usr/bin/awk to all > packages needing it would be cumbersome. However, we could maybe> do symlinks trick using alternatives/select functionality.
But then how would the dependency be satisfied? If a package requires
'awk', then how would APK know that 'mawk' or 'busybox' satisfies it?
I have noticed that in general there is a deep expectation in aports
that BusyBox will always be present. This really does not work too
well for Adélie, but I'm willing to take on the additional work of
fixing up aports if that work would be welcome.
If it wouldn't be welcome, the trees will likely diverge much more.
As I said in my opening email, Adélie wants the user to have the
maximum amount of freedom, and that includes the ability to choose
whether or not to use BusyBox.
[I will note here that "awk" in some form is required by POSIX; since
virtuals don't exist right now, 'mawk' is pulled in by adelie-base and
therefore the lack of explicit awk dependency does not break building
packages on Adélie. Still, implicit dependencies are always a bad
thing IMO.]
>> shell: /bin/sh as busybox is of course default, but some users >> may want bash or another shell. I don't see any reason that >> can't be supported.> > Same as awk.
My concern is for people to be able to choose what works for them.
Maybe they want to use sash+toybox+ubase or bash+coreutils or such,
instead of BusyBox. All packages with shell scripts have an explicit
dependency to BusyBox[1] so that package effectively cannot be
uninstalled on an Alpine system.
If there was a 'shell' provider in the index, this could be solved
quite easily.
[1]: https://git.alpinelinux.org/cgit/abuild/tree/abuild.in#n897
Consider also a very very tiny run-from-RAM instance that only needed
an emergency shell and no other user interaction. If sash could
replace busybox there could be a size benefit as well. BusyBox is 900
kB installed and sash is 280 kB installed.
>> vi: busybox, vim, neovim, elvis, ... There are almost a dozen >> providers of `vi` in Debian and more than a dozen on Gentoo. I >> believe Alpine itself packages four of them.> > I don't know if I see the problem here. You can use the EDITOR env > var to select any editor, even non-vi like nano.
Some programs do not obey EDITOR, but that is a good point. Still,
most distros do allow you to choose the provider of `vi` and if
everything else is being fixed up I don't see any reason to ignore vi.
>> I started to try and make 'v:mta' but I'm very concerned about >> diverging so much from the Alpine aports tree. Also, apk doesn't>> support an automatic choice for a virtual if the user hasn't>> already installed one (something like replaces_priority but for>> virtuals would be good here imo). That means that when I *do*>> manage to get packages to depend on v:mta, the user now has to>> read through an 'unsatisfiable constraints' error and pick a >> package out of the list of providers.> > I don't think 'v:mta' makes much sense (mta with tcp port 25 does > not even need to run on local host), but I think > provides=/usr/sbin/sendmail makes sense.
Yes, if such a format is allowed, that would be the ideal solution.
> Currently you can have unversioned provides and have them> installed in parallel, but then apk will not autoselect anything> for you or you can have the provides versioned and apk will select> one for you. But then you will not be able to have both installed> at the same time.> > Maybe apk could, when the provides is unversioned and no provides > installed, auto-select the provides with smallest size?
I feel like it could still output a message such as:
apk: selecting 'ssmtp' for provider of '/usr/sbin/sendmail'
That way the user knows what is happening and that they can select
another provider if they want.
> Then you atleast get something installed (for example ssmtp),> which you can manually replace if you want.
Yes, that is the goal.
>> Additionally, changes made to abuild or apk-tools are currently >> being sent via GitHub pull requests. However, none of us in >> Adélie really want to use GitHub as it is a closed platform.>> The aports mailing list exists for aports, but where could we>> send abuild or apk-tools changes if we wanted an alternative to >> GitHub?> > It is mentioned before that you can use alpine-devel for that. I'd > also suggest that you use --subject-prefix="PATCH apk-tools" or > "PATCH abuild" so its clear what project it belongs to.
Okay. I will do that in the future. Thanks for the guidance.
>> 4. We have managed to make a split function 'openrc' that takes >> /etc/init.d and /etc/conf.d directories. It has >> install_if="$pkgname openrc" so it is transparent when you have >> OpenRC installed, and allows future migrations to a different >> init system. I don't know if this is of any interest to Alpine.> > I like this. Just make sure that the pkgname is versioned. eg> > install_if="$pkgname-$pkgver-r$pkgrel openrc"> > Otherwise interesting things will happen if you have older> versions of $pkgname in you local build repository. (older versions> will see it and, "hey openrc and $pkgname is installed. i want be> installed too!")
Yes, I did the same as the doc function which does the same :)
>> 5. After being annoyed by bugs in the PowerPC build of GNU tar, >> we managed to swap out /usr/bin/tar for bsdtar provided by >> libarchive in abuild. It needed a patch to output the format>> apk expects by default, but otherwise it seems to work quite>> well. This may be of interest to those who want to do a GNU-free>> Alpine spin.> > libarchive seems a bit bigger that gnu tar, otherwise I don't have> strong opinions. I would prefer to get the needed functionality > added to busybox tar if possible.
That is understandable. I took a look at the BusyBox tar code and it
was a bit over my head. Perhaps someone else can add the requisite
functionality to it. As far as I can tell, that would be:
* write pax format
* full xattr support
Everything else seems to be supported.
Best,
- --arw
> > -nc>
- --
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJZeegTAAoJEMspy1GSK50UBl4P/11U24hRv++2Ye8bl/KRAw8G
bTZ6gNF5Olcr8QQPonEnCxooV7FhNp+toaDuyNV+a8vMWkRohf/Yv3iSoIForpX4
EQCqn4YM+1lR2MK98peqg7R7sMhRCK/QL1r2+lSoARQTWn0c8T/c3Umee9HsrTUJ
pDTISw93hL1p+2YTxtGy3SH3/Ck6bTPnuU3YnD1VIYtb9MQlurojuUeaEVapSvdw
Mipaf2stmbqvq4xz6tj5uW3Ke/Kv76syv4bt00ruhE9Yit3O9QxTRdjtP+zxkmJ7
clZd0YPoK4y3kKZX7+j1oRGpDWANrPUmwMfQjh3FhENuf3rhxHrCxfpWHFzM0TbA
FfsoEDuHLN7pGksTXLlC4FZh32863KFxZs+GCWmhudTLk8BQXcFEZbEeHplZB8rF
FNGYAHotPU4L4+sl5Et4v/u1U87A3fC/bdsNagDhr+SykldhH7MA0qrOMtjUJsJg
YfHR8jD4Ef09BvHsiXUt9ocHTWpaAy6fG2lD5Zd7j+rihVwSV1/Ze8/uQGgEI098
q3dYva9G8dIj3tzE9/bJX/J9QvAnxVXNJ7WiU7qxYBcq7ewF+Zdxxq9jtIl9Ohdb
Xsx1RO2No+LJED9nsydEGgWJ6kf44dgcQ+5tGc6HwfKIHTTmyawk4NAso92NYOY9
QSVE4RF1RRvL1AhBtann
=BBov
-----END PGP SIGNATURE-----
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Mon, 24 Jul 2017 06:57:52 -0500
"A. Wilcox" <awilfox@adelielinux.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----> Hash: SHA256> > Hi there Alpinists,> > This is a sort of status update and wish list after near two months of> attempting to base Adélie on Alpine Linux.
Thank you for sharing your experiences.
> > 1. scripts/bootstrap.sh cannot "fake" cross. Since Adélie uses a> slightly different GCC configuration from Alpine, I attempted to run> bootstrap.sh on x86_64, from my x86_64 system:> > > ERROR: unsatisfiable constraints:> gcc-6.3.0-r4:> conflicts: gcc-x86_64-6.3.0-r4[so:libcilkrts.so.5=5.0.0]
I wonder if it would make sense to add provides="$pkgname-$arch" to
gcc. That way "gcc-x86_64" would be provided from "gcc" on x86_64.
> 2. The virtual system is pathetic. One of the very core tenets of> Adélie is giving the user power through choice. That choice is almost> impossible to provide using the current abuild/apk framework. I keep> hearing of a Debian-style alternatives system, and supposedly it was> specified somewhere, but I cannot find the specification nor an> implementation. If I could read the specification I would be highly> motivated to write an implementation.> > Red Hat has `alternatives`, Debian has `update-alternatives`, and> Gentoo has `eselect`. The Alpine system desperately needs something> like this and I would love to contribute to such.
I think something like update-alternatives or eselect makes sense. For
example, you may want select which java implementation you should use
as the "system" java.
But I think we can divide it in 2 different cases:
1) symlinks (eg /usr/bin/lua -> /usr/bin/lua$version and /usr/bin/php
-> /usr/bin/php$version). Selecting system java also goes here.
2) provides and dependencies in apk
I am not convinced we should let apk handle the select/alternatives and
mix that into the dependency calculation.
> Consider a few different use cases:> > mta: any package that needs `sendmail` has to either hard-depend on> postfix, or disable mail services. This is unacceptable in my> opinion. Other distros let you select what package you want to> provide `sendmail`.
It has been mentioned already, but I think for sendmail we want
provides=/usr/sbin/sendmail in the different providers and the packages
that needs it should do depends=/usr/sbin/sendmail. (we could do
provides=file:/usr/sbin/sendmail too but i think that a leading '/'
is enought to indicate that its a file)
> awk: mawk vs gawk vs busybox awk. All have benefits and drawbacks and> the user should be able to choose which provides /usr/bin/awk.
Also mentioned before that awk is a part of the base system and is
expected to be there. So adding depends=/usr/bin/awk to all packages
needing it would be cumbersome. However, we could maybe do symlinks
trick using alternatives/select functionality.
> shell: /bin/sh as busybox is of course default, but some users may> want bash or another shell. I don't see any reason that can't be> supported.
Same as awk.
> vi: busybox, vim, neovim, elvis, ... There are almost a dozen> providers of `vi` in Debian and more than a dozen on Gentoo. I> believe Alpine itself packages four of them.
I don't know if I see the problem here. You can use the EDITOR env var
to select any editor, even non-vi like nano.
> I started to try and make 'v:mta' but I'm very concerned about> diverging so much from the Alpine aports tree. Also, apk doesn't> support an automatic choice for a virtual if the user hasn't already> installed one (something like replaces_priority but for virtuals would> be good here imo). That means that when I *do* manage to get packages> to depend on v:mta, the user now has to read through an 'unsatisfiable> constraints' error and pick a package out of the list of providers.
I don't think 'v:mta' makes much sense (mta with tcp port 25 does not
even need to run on local host), but I think provides=/usr/sbin/sendmail
makes sense.
Currently you can have unversioned provides and have them installed in
parallel, but then apk will not autoselect anything for you or you can
have the provides versioned and apk will select one for you. But then
you will not be able to have both installed at the same time.
Maybe apk could, when the provides is unversioned and no provides
installed, auto-select the provides with smallest size?
Then you atleast get something installed (for example ssmtp), which you
can manually replace if you want.
> 3. It is very hard to know where to send some things. For example,> the GCC APKBUILD does not function properly right now: it does not> declare a makedepends on gcc-gnat, and the GCC configure process bails> out when it does not find it because LANG_ADA is true whenever CBUILD> == CHOST == CTARGET. I am not 100% confident in my ability to edit> the APKBUILD for GCC considering how finicky it is, so I would like> help. I posted on the IRC channel but I mainly only have the weekends> to work on Adélie, and most of the channel is away on weekends. This> really isn't a distro topic, so it doesn't belong on alpine-devel from> what I have been able to gather about this list. The aports list> seems to be for patches only, from what I have gathered about that> list. Maybe this belongs on the bug tracker, but there really isn't a> bug category for build failures that I could find.> > Additionally, changes made to abuild or apk-tools are currently being> sent via GitHub pull requests. However, none of us in Adélie really> want to use GitHub as it is a closed platform. The aports mailing> list exists for aports, but where could we send abuild or apk-tools> changes if we wanted an alternative to GitHub?
It is mentioned before that you can use alpine-devel for that. I'd also
suggest that you use --subject-prefix="PATCH apk-tools" or "PATCH
abuild" so its clear what project it belongs to.
> 4. We have managed to make a split function 'openrc' that takes> /etc/init.d and /etc/conf.d directories. It has install_if="$pkgname> openrc" so it is transparent when you have OpenRC installed, and> allows future migrations to a different init system. I don't know if> this is of any interest to Alpine.
I like this. Just make sure that the pkgname is versioned. eg
install_if="$pkgname-$pkgver-r$pkgrel openrc"
Otherwise interesting things will happen if you have older versions of
$pkgname in you local build repository. (older versions will see it
and, "hey openrc and $pkgname is installed. i want be installed too!")
> 5. After being annoyed by bugs in the PowerPC build of GNU tar, we> managed to swap out /usr/bin/tar for bsdtar provided by libarchive in> abuild. It needed a patch to output the format apk expects by> default, but otherwise it seems to work quite well. This may be of> interest to those who want to do a GNU-free Alpine spin.
libarchive seems a bit bigger that gnu tar, otherwise I don't have
strong opinions. I would prefer to get the needed functionality added
to busybox tar if possible.
-nc
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Mon, 24 Jul 2017 22:46:44 +0200
Jakub Jirutka <jakub@jirutka.cz> wrote:
> There*s no clear relation between related patches, *cause it*s just> nearly impossible to reconstruct such information from separated> patches in mail.
That depends on how you send them. Use --in-reply-to=<message-id> to
send the patch to a previous email thread.
> Patchwork is based on ancient workflow from CVS era.
No. It's based on the linux kernel development workflow, the people who
invented git in the first place.
> Maintainer can work with it directly via git (see> https://gist.github.com/piscisaureus/3342247), without leaving> terminal. When the contributor push new changes to the pull request,> maintainer can simply pull them via git and view in context, it*s> just a branch.
This was great news for me. I have looked for something like that,
without installing hub to provide github specific functionality to the
cli.
> It*s really horrible for reviews.
Then you are using it wrong. Patchwork is not designed to make reviews.
It is designed to help maintainer to keep track of the state of the
patch, and to make sure that patches are not forgotten.
You do the review, commenting and interaction via email, using your
favorite email client.
Using emails has some benefits. For example, you can read and write
reviews while you are offline (on an airplane for example). You don't
need sign up to any service. (github has critical mass now days so you
cannot really be involved in open source without having github account
anyway - I'm not convinced that is a good thing)
> I understand why some ppl don*t like GitHub (it*s third-party> commercial service after all)
Yes. I don't want be locked in to a service provider. I don't want make
it a requirement that you sell your soul to github (or facebook or
twitter or whatever) to be able to contribute to alpine.
I also find the github web interface sluggish at times. Some pages can
take various seconds to load. And if content or directory is to bit it
will simply not show anything at all.
The major problem with supporting both github and email submissions is
that different people may send same patch. It is inconvenient for users
that they need to check patchwork before making a github PR and it is
inconventient that you need to search github PRs before you `git
send-email`. I suppose that is the price we pay.
I cannot claim that I love patchwork, but I want make it possible for
people to `git send-email` patches.
-nc
PS. interestingly patchwork itself is hosted on github.
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Tue, 25 Jul 2017 07:13:12 -0500
"A. Wilcox" <awilfox@adelielinux.org> wrote:
> Have you looked in to Pagure? It is designed to be a lightweight Git> forge, made by the Fedora people. Right now it still has some> Fedora-specific stuff, but Debian has a testing package for it and I'm> hoping to try and make an Alpine port for it once I manage to have a> desktop going.> > It is written in Python but has very few dependencies; just flask> (lightweight Web framework), redis, and libgit2.
I sort of knew that they were replacing whatever they used before for
hosted projects, but I had not looked to close to it.
It does look pretty nice. python is nice (or at lease acceptable).
A few comments on first impression:
- Docs section is sluggish and I don't like that the scrollbar inside
the page (iframe?) (https://pagure.io/docs/pagure/)
- Releases says: "If the developers have upload one or more tarball(s),
you will be able to find them in the release folder."
I would like to automatically create the tarballs when you push a new
git tag.
I would likely switch right away if it had support for multi-gitbranch
tickets. That is, you file a ticket, lets say a CVE, and mark off which
git branches that needs to be fixed. When you git push a commit with
"fixes issue #X" the marked branch will get "checked" or hooked off.
Once all affected branches are fixed, the ticket is autoclosed.
That would be the killer feature.
-nc
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---