Hello,
There has been quite some churn in Alpine abuild lately and I'd like to
take some time to go through the individual changes and note if they are
something we should cherry-pick or not. I expect most of these changes
are somewhat breaking and therefore should be considered a post-1.0
On Sun Sep 01 04:47 PM, Max Rees wrote:
> As of this writing, there appears to be:
>
> * 24 packages that use the $pkgusers and $pkggroups directives.
> * 3 packages that only use the $pkggroups directive.
> * 0 packages that only use the $pkgusers directive.
> * 12 package
Hello,
As work towards the minimal viable product of APK Foundry nears
completion, I have been thinking of large scale trybuilds that can be
done in order to fully test its functionality. I think one such trybuild
that would also serve a functional purpose would be to begin work on
removing
On Jul 10 02:33 AM, Max Rees wrote:
> Additionally, some mechanism must be employed so that users who:
>
> 1. Currently have a manual grub config
> 2. Do not have a .manual_config file
>
> do not have their configuration file overwritten when this change is
> ma
On Mar 07 04:46 PM, A. Wilcox wrote:
> Hi there,
>
> I have just done an experimental build of system/ without GNU Bison
> available. The only package that uses Bison extensions to Yacc is
> iproute2. There are three ways forward I can determine:
>
> 1) Move iproute2 to user/.
>
> We still
On Sep 06 01:07 AM, Max Rees wrote:
> What if all applicable build servers are unavailable (busy or offline)
> when we want to delegate a new task? For the webhook, this should be
> easy to get around since it's built to be asynchronous, so we can just
> keep polling the list of s
On Sep 05 09:23 PM, A. Wilcox wrote:
> * Missing list
>
> This goes in to the version freeze; are we having a package freeze too?
> If so, our missing list is frozen and we will not ship with any of the
> packages left on it. If not, this can probably be shifted to b2.
We have not previously
On Wed, Sep 5, 2018 at 5:05 PM M. J. Everitt wrote:
> Are you using a custom Message Broker system, or something that would
> integrate with other tools, eg RabbitMQ, etc?
> Might be good for 'portability' and interaction with other tooling perhaps.
The plan is to use MQTT as the communication
Hello all,
During some brief free time today I was thinking about how to go about
implementing some of the upcoming features that I plan to add to abuildd in
the next few weeks. Specifically, I am concerned about the handling of
dependencies.
My current proposal is that each new push to a branch
On May 17 07:47 PM, A. Wilcox wrote:
> Hi all,
>
> I'd like to have a discussion on whether or not it would be worth it to
> invest actual time and resources into the following projects before we
> release 1.0. Perhaps we could even delay 1.0's release slightly, if
> they are deemed critical
On Feb 17 08:49 PM, A. Wilcox wrote:
> I am, however, considering adding cmd:which as a dependency for
> build-tools. I'd like to set debianutils-which as the primary provider
> since their utility is light (just a wrapper for POSIX command(1))
> compared to the full-blown which (~ 100 KB).
>
>
On Feb 11 05:54 PM, A. Wilcox wrote:
> We even still have the archive of Gentoo-based ebuilds, in case we need
> them: https://code.foxkit.us/adelie/packages/tree/ebuild
In my opinion these should be removed from packages.git and put in a
separate archive as well, unless it's something that you
On Feb 11 02:00 PM, A. Wilcox wrote:
> Currently we have a "fork" of aports.git. It's very difficult to rebase
> what we have, so it definitely needs to "restart" imo. We can move
> aports.git to aports-historic.git and then re-clone from Alpine to make
> it cleaner, but I think the better thing
13 matches
Mail list logo
