Re: [arch-ports] {i686, pentium4}/core: linux-lts &
linux-lts-headers out of sync Reply-To: Andreas Baumann mail@andreasbaumann.cc In-Reply-To: 5f289c0b-4f33-77c3-2a47-3ebacf5e734a@gmail.com
On Fri, Aug 23, 2019 at 05:43:40PM +0200, Markus Schaaf wrote:
Since this seems to be a recurring theme lately, I'm asking straightly: Is someone over-worked? Is there any help needed? Also borg for pentium4 is lagging behind. What's the problem?
Borg had a relative simple problem in 'check()' it was using $CARCH directly for results of testing (which go into i686 for pentium4).
Cheers
Andreas
Regards _______________________________________________ arch-ports mailing list arch-ports@archlinux.org https://lists.archlinux.org/listinfo/arch-ports
-- Andreas Baumann Trottenstrasse 20 CH-8037 Zuerich Telefon: +41(0)76/373 01 29 E-mail: mail@andreasbaumann.cc Homepage: www.andreasbaumann.cc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Sat, 24 Aug 2019, Andreas Baumann wrote:
On Fri, Aug 23, 2019 at 05:43:40PM +0200, Markus Schaaf wrote:
Since this seems to be a recurring theme lately, I'm asking straightly: Is someone over-worked? Is there any help needed? Also borg for pentium4 is lagging behind. What's the problem?
Borg had a relative simple problem in 'check()' it was using $CARCH directly for results of testing (which go into i686 for pentium4).
Cheers
Andreas
Regards
Hi Markus, hi list,
let me answer the questions left open by Andreas:
Yes, there is (currently) always help needed (as you can see, the fix is sometimes pretty trivial). We're not really overworked, but there is also not much head room ;-) You can head over to the irc channel (#archlinux32 on freenode) to get in touch or register to git.archlinux32.org or bugs.archlinux32.org and open pull requests / bug reports directly there (the bug tracker needs manual approval from one of us to get you started - and it seems to be temporarily down, currently).
Regarding the already-answered questions, I can give some more details to Andreas' (correct answers):
lagging of package versions: Other, more important packages eat up our time. And since we don't have a one-maintainer-per-package segmentation, other packages can (and will) fall behind.
breaking dependencies: Due to the low number of devs, almost everything is automatized. This should not break dependencies when moving stuff around (but sometimes it does, because there are bugs in the logic, which we then fix). But more importantly, as Andreas pointed out, this assumes a perfectly stable distribution (e.g. no package ever gets broken by upgrading a library it depends on, but not upgrading the package itself) - which is nice, but unfortunately not true (some packages fail to recompile, so we cannot link them against the new library). Thus, we sometimes have to do things manually which *must* ignore these dependencies and thus can break stuff.
regards, Erich
participants (2)
-
Andreas Baumann
-
Erich Eckner