#archlinux32 | Logs for 2019-06-20

Back
[00:32:33] -!- eschwartz has quit [Ping timeout: 245 seconds]
[00:37:32] -!- thePiGrepper has quit [Ping timeout: 245 seconds]
[00:41:33] <marc2377> elibrokeit: Is there an option similar to pacstrap's '-M' for arch-nspawn?
[00:41:43] <marc2377> to prevent copying the host's mirrorlist to the chroot
[00:43:02] <marc2377> (nvm; it's a bash script I can check myself)
[00:53:47] -!- MrBIOS has quit [Read error: Connection reset by peer]
[00:54:56] <elibrokeit> marc2377: it makes much more sense to use mirrorlist32 which should already be the case ;)
[01:03:24] <marc2377> I guess it does
[01:03:31] <marc2377> xD
[01:05:17] -!- samantaz_ has joined #archlinux32
[01:07:57] -!- samantaz has quit [Ping timeout: 245 seconds]
[01:09:56] -!- jamincollins has joined #archlinux32
[01:11:47] <jamincollins> booting to the latest ISO (archlinux-2019.03.07-i686.iso) installing python3, and attempting to use it results in: python3: /usr/lib/libm.so.6: version `GLIBC_2.29' not found (required by /usr/lib/libpython3.7m.so.1.0)
[01:13:57] <elibrokeit> jamincollins: don't do partial updates
[01:14:08] <jamincollins> this is the ISO
[01:14:18] <jamincollins> I haven't installed anything
[01:14:26] <jamincollins> other than python3
[01:14:30] <elibrokeit> You did, you installed python3
[01:14:40] <jamincollins> it should have installed what it needed, no?
[01:14:47] <elibrokeit> And that is the whole problem, now isnt it?
[01:14:50] <elibrokeit> Uh, no
[01:15:00] <elibrokeit> You did Pacman -Sy
[01:15:29] <elibrokeit> This is not supported on arch32 any more than it ever was on archlinux
[01:15:50] <jamincollins> news to me, what should I be doing instead?
[01:20:00] <elibrokeit> What are you trying to do with python? Generally you'd want to do a full -Syu but for a live ISO that will update a lot of files in a ramfs
[01:21:16] <jamincollins> I want to install python so I can use it to install Arch.. I do this routinely with upstream Arch, and `pacman -Sy python` works there
[01:23:23] <jamincollins> updating glibc fixes it
[01:25:41] <marc2377> jamincollins: See https://wiki.archlinux.org
[01:25:41] <phrik> Title: System maintenance - ArchWiki (at wiki.archlinux.org)
[01:26:16] <jamincollins> it's not a partial upgrade, it's a missing dependency
[01:27:34] <jamincollins> python does *not* declare a dependency on glibc, let alone a specific version of it
[01:27:43] <jamincollins> https://wiki.archlinux.org
[01:27:43] <phrik> Title: PKGBUILD - ArchWiki (at wiki.archlinux.org)
[01:31:03] <elibrokeit> jamincollins: if python did declare a dependency on glibc, then it would, based on long-standing principle, refuse to use a specific version
[01:32:10] <elibrokeit> But as it happens, python depends on a whole lot of things, many of which in turn depend on glibc
[01:32:20] <jamincollins> "An array of packages that must be installed for the software to build and run." <-- the fact that Python does not run without the specific version, would seem to indicate by that statement that a specific version should be listed :shrug:
[01:32:26] <elibrokeit> It's actually entirely impossible to ever have a system without glibc
[01:32:56] <jamincollins> yes, but python requires a specific version, and based on the PKGBUILD page, /should/ list it
[01:33:04] <elibrokeit> jamincollins: if you want to argue that archlinux should use versioned dependencies you will get nowhere
[01:33:23] <elibrokeit> Don't quote the PKGBUILD manage at me -- I helped write it
[01:33:26] <jamincollins> I'm stating what the page states
[01:33:29] <elibrokeit> *manpage
[01:33:46] <elibrokeit> You are attempting to be a rules lawyer
[01:33:56] <elibrokeit> I don't like rules lawyers
[01:34:14] <jamincollins> and you've resorted to name calling, cute
[01:37:15] <elibrokeit> You have been authoritatively informed that our philosophical policy is to not support partial updates. The depends field is perfectly capable of describing package *names*, but you are insisting that our decades-old policy is wrong, not because you think there is merit to using versioned dependencies, but because we're not "allowed" to leave them out because you read the depends definition as requiring it?
[01:38:32] <elibrokeit> For your information, the depends field is whatever the packager wants it to be. It is "the mechanism by which the PKGBUILD describes which dependencies it insists it needs"
[01:38:40] <jamincollins> the depends field is capable of declaring a package by name, and if required version, but since you helped author the page you already know this
[01:38:57] <elibrokeit> And this package only insists it needs openssl, which needs Perl, which needs glibc
[01:39:21] <marc2377> Reminds me of the time I thought it was so - https://bugs.archlinux.org
[01:39:21] <phrik> Title: FS#58212 : The glibmm package should specify versions of its dependencies (at bugs.archlinux.org)
[01:39:38] <elibrokeit> And packages do not go around insisting they need specific versions of glibc -- it is assumed that you will have it, because we don't support partial updates
[01:39:59] <jamincollins> you call the situation a "partial upgrade", but the fact remains that the state would not exist if the python package listed the packages it needs (and specific version if a specific version is needed)
[01:40:28] <jamincollins> which is an insufficient dependency declaration
[01:40:31] <elibrokeit> No one cares if the state would exist...
[01:41:01] <elibrokeit> The state is a sign of user error, per policy. I can help you fix that, or you could attempt to change policy
[01:41:32] <jamincollins> I can fix it, I already did, and I can work around your unwillingness to correct the actual issue
[01:41:46] <elibrokeit> Or you could argue that our policy is forbidden by the manpage and wiki page, and I can stop caring about anything you ever say.
[01:41:55] <rcf> jamincollins: it's only an issue if you want to support partial upgrades. If the people in charge don't, then... not much to do.
[01:42:51] <jamincollins> :shrug: I came to report a bug, that the people in charge want to call the bug a "partial upgrade" is their choice
[01:43:20] <rcf> If it's a bug, you should not be using this distribution.
[01:43:51] <jamincollins> if that's a true statement no one should use any Linux distro, they all have bugs
[01:43:54] <elibrokeit> I would also like to point out that versioned dependencies make no sense here anyway, because the PKGBUILD does not care what version of glibc you have. The compiler will use the most recent symbol compat from glibc that is installed -- it is backwards compatible but not forwards compatible
[01:44:28] <elibrokeit> jamincollins: if you consider something to be a bug, and we consider it to be a distro feature, then it is the work g distro for you
[01:44:33] <elibrokeit> *wrong
[01:44:51] <jamincollins> only if I can't work around your stubbornness, which I can
[01:44:56] <elibrokeit> You should use a distro that agrees on what the ideal distro is
[01:46:11] <rcf> jamincollins: it's a *fundamental design choice*. It's not a mistake. Whether it's right or wrong is immaterial to the fact that you so fundamentally disagree with the maintainers, and your efforts will be entirely wasted when they could be productive when dealing with different people.
[01:46:26] <elibrokeit> Debian, Fedora, Gentoo, all would allow you to do a partial update, because they have "versioned dependencies are a feature" or because they build from source
[01:47:20] <jamincollins> my efforts aren't wasted, I have a working installer and I can ignore elibrokeit from this point forward
[01:48:16] <elibrokeit> But can you ignire the other dozens of developers of archlinux, every last one of whom agrees with me and most of whom did so a decade before I even heard of Linux?
[01:50:16] <elibrokeit> I mean, if you just want to say "python works right here and now and that is all I care about", then okay... But if you ever expect to get support for other similar issues then it would be deeply unwise to try getting support from an entire culture that doesn't agree on fundamental design principles
[01:50:32] <jamincollins> it's worked fine for years, I only encounter this issue during the ISO installer, simple enough to ignore... once the system is installed it's a non-issue
[01:50:35] <marc2377> yes, dare I say @jamincollins, no messing around with dependency versions on the core packages is by-design on Arch Linux. And you have it on good authority here (Eli is one of the main-tainers - pun intended)
[01:51:13] <marc2377> I guess this design decision is because maintainance would be a nightmare otherwise (am I correct @Eli, or are there other reasons?)
[01:52:16] <elibrokeit> jamincollins: good luck doing a partial update of pacman -Syu pacman, the next time libarchive or curl have a soname update. Then you won't even be able to use Pacman to recover.
[01:52:19] <marc2377> but in any case, being by-design if you expect to change this policy you try making a case in the mailing lists - but I assume some have already tried that - or making an Arch fork
[01:52:42] <marc2377> I'm afraid
[01:53:15] <rcf> marc2377: indirectly. It's a rolling-release distribution, targeting people who want the latest version of everything installed anyway, so the extra maintenance burden would not be worthwhile.
[01:53:56] <elibrokeit> marc2377: yes, doing version pinning is awkward to maintain -- not least because any compiled binary or library depends on >= the version of glibc that it was built with, and that changes depending on which chroot you built it in.
[01:54:00] <marc2377> I figured, just another way of KISS'ing
[01:54:18] <jamincollins> I also notice that http booting consumes much more RAM than needed (2x the size of the SFS) due to copying the SFS first to /run/archiso/httpspace and then to /run/archiso/copytoram without freeing/removing the httpspace instance
[01:54:19] <elibrokeit> And since we are rolling anyway...
[01:54:57] <elibrokeit> jamincollins: you could discuss that with djgera on the arch-releng mailing list, where archiso is developed
[01:55:10] <jamincollins> will do
[01:55:48] <jamincollins> moving the sfs, then umounting the httpspace allows for systems with far less memory to succesfully install Arch
[01:56:48] <marc2377> what does sfs stand for? (sorry I'm still pretty much a noob)
[01:57:00] <jamincollins> squash filesystem
[01:57:04] <marc2377> ah
[01:59:21] <marc2377> another newbie question incoming
[01:59:38] <marc2377> I had done 'linux32 makechrootpkg -c -r /media/Fast/Dev/chroot32/ -- -s' on the arch32 kernel dir
[02:00:11] <marc2377> build took a long while, and during packaging it failed with "/usr/share/makepkg/util/compress.sh: line 41: lzop: command not found"
[02:00:26] <marc2377> I then installed lzop on the chroot
[02:00:33] <elibrokeit> On the glibc front... You'd need to scan every binary in a package and see what symbols it calls, then tag the package as depending on the symbol. And likewise, have glibc provide thousands of symbols. Otherwise you couldn't know when you have the right glibc
[02:00:45] <marc2377> and then did the makechrootpkg again
[02:00:57] <marc2377> but it looks like it's building everything again from source
[02:01:21] <jamincollins> marc2377: unless you have ccache installed and configured I believe it will, nature of the beast
[02:01:37] <jamincollins> even with ccache it'll only save _some_ time
[02:01:43] <elibrokeit> Debian etc. basically work around this by never updating gli c, only providing security fixes, and then updating glibc itself when you reinstall the next major Debian release
[02:01:51] <marc2377> if I don't pass the '-c' argument, that won't happen?
[02:02:20] <jamincollins> it won't clean it, no
[02:02:22] <elibrokeit> Makechrootpkg does support passing options to makepkg like --repackage
[02:02:23] <jamincollins> but that could et messy
[02:02:33] <jamincollins> *get
[02:02:37] <elibrokeit> If you do that, then makechrootpkg will preserve the builddir
[02:02:49] <marc2377> great
[02:02:56] <marc2377> its too late now but thats good
[02:02:57] <elibrokeit> The -c option is about recreating the chroot, not about preserving the builddir
[02:03:13] <marc2377> oh, alright
[02:03:16] <elibrokeit> The builddir is just one part of the chroot ;)
[02:04:55] <marc2377> I have ccache set up on my system but not on the chroot - it won't work without special setup, right?
[02:05:31] <marc2377> I have 'watch -n 1 ccache -s' and it's not updating at all
[02:07:54] <elibrokeit> You need to configure ccache in makepkg.conf
[02:08:13] <elibrokeit> Which is awkward because the chroot uses its own
[02:08:44] <elibrokeit> And also because you'd need to bind mount the ccache cache somewhere so it doesn't get deleted every time makechrootpkg runs
[02:09:01] <marc2377> thanks
[02:10:35] <marc2377> does it make sense to bind my existing cache dir even though the chroot is i686?
[02:10:39] <elibrokeit> You can set up the chroot with a good makepkg.conf using mkarchroot or arch-nspawn, then run makechrootpkg
[02:11:10] <elibrokeit> Your existing ccache cachedir is full of x86_64 objects
[02:11:24] <marc2377> yeah, no good then
[02:11:29] <elibrokeit> But I expect ccache can figure out how to save both together ;)
[02:11:49] <elibrokeit> You will need to rebuild all objects as i686 before you can cache and reuse them...
[02:15:50] <marc2377> yes indeed
[02:15:59] <marc2377> I stopped the compilation while I figure that out
[02:49:13] -!- guys has joined #archlinux32
[03:01:55] <marc2377> instead of using the '-d' option for makechrootpkg, is it possible to permanently set up the cache dir binding?
[03:02:38] -!- guys has quit [Read error: Connection reset by peer]
[03:03:25] -!- guys has joined #archlinux32
[03:03:38] <marc2377> I guess it would be 'mount --bind /path/to/chroot/root /path/to/ccache/" but not sure if that'll work afterwards
[03:03:57] <marc2377> because 'chroot/root' is synced to 'chroot/myuser'
[03:06:29] <elibrokeit> marc2377: --bind=$PWD/ccache:/build/.ccache
[03:06:49] <elibrokeit> would be the systemd-nspawn / arch-nspawn arg
[03:07:08] <elibrokeit> uh
[03:07:27] <elibrokeit> wouldn't make sense to persist the bind mount, since nspawn likes to do its own accounting.
[03:07:48] <elibrokeit> There have been ponderings, regarding the idea of letting *.nspawn conf things
[03:11:09] <marc2377> right
[03:21:01] <marc2377> I'm getting access denied during the build, can't write to the cache dir
[03:21:31] <marc2377> any bind switch for that?
[03:31:42] <elibrokeit> makechrootpkg should use the same uid for "builduser" as the user invoking makechrootpkg
[03:32:09] <elibrokeit> so, can your current user write to the cache dir?
[03:41:18] -!- samantaz_ has quit [Ping timeout: 245 seconds]
[03:46:38] <marc2377> yes, I could
[03:46:44] <marc2377> but not after mounting
[03:46:52] <marc2377> fixed not
[03:46:54] <marc2377> now*
[03:49:15] <elibrokeit> how?
[03:50:23] -!- guys has quit [Read error: Connection reset by peer]
[03:51:35] -!- guys has joined #archlinux32
[03:52:03] <marc2377> I had previously set the cache dir in the chroot for the root user, but not for the builduser
[03:52:21] <marc2377> so in fact it ccache was attempting to write to the wrong dir
[03:56:00] <elibrokeit> aha :)
[04:01:17] <marc2377> I actually copied 'makechrootpkg' to /usr/local/bin and edited it to call my own version of arch-spawn (renamed, of course) in which I commented out the call to 'copy_hostconf'
[04:01:41] <marc2377> since I intend to use the same chroot for a long time
[04:02:57] <marc2377> I also manually mounted (bound?) the cache dir to the chroot/<user>
[04:03:29] <marc2377> and finally I can monitor the cache performance with 'CCACHE_DIR=/media/Fast/ccache-chroot32/ watch -n 1 ccache -s'
[04:12:52] -!- guys has quit [Read error: Connection reset by peer]
[04:13:47] -!- guys has joined #archlinux32
[04:37:51] -!- guys has quit [Read error: Connection reset by peer]
[04:38:59] -!- guys has joined #archlinux32
[04:59:10] -!- guys has quit [Read error: Connection reset by peer]
[05:00:11] -!- guys has joined #archlinux32
[05:06:10] -!- guys has quit [Ping timeout: 268 seconds]
[05:12:53] -!- thePiGrepper has joined #archlinux32
[05:27:57] -!- MrBIOS has joined #archlinux32
[05:49:52] -!- MrBIOS has quit [Quit: MrBIOS]
[06:17:42] -!- jamincollins has quit [Ping timeout: 268 seconds]
[06:17:56] <marc2377> well, now that I have the "build-in-chroot" process sorted out, i'm a bit overwhelmed by the ammount of diverging config settings between the two kernel architectures (x86_64 and i686)
[06:18:29] <marc2377> what I did:
[06:21:16] <marc2377> 1. took the HEAD config.i686 from the archlinux32 git - which is for kernel 5.1.9
[06:22:28] <marc2377> 2. took the last config that had specified kernel 5.1.8 from the archlinux packages.git
[06:23:08] <marc2377> 3. copied this config from step 2 to to the kernel source dir and did 'make olddefconfig'
[06:23:33] <marc2377> (where I had checked out kernel 5.1.9 from arch)
[06:24:01] <marc2377> and 4. diff the configs from step 1 and the resulting .config generated from step 3
[06:24:24] <marc2377> there are just too many of them - how did they diverge so much?
[06:35:05] -!- MrBIOS has joined #archlinux32
[06:57:25] -!- MrBIOS has quit [Quit: MrBIOS]
[06:58:05] -!- marc2377 has quit [Remote host closed the connection]
[07:08:39] -!- marc2377 has joined #archlinux32
[07:09:05] <marc2377> test
[07:09:20] <rcf> marc2377: it failed
[07:09:49] <marc2377> uh, lets try again
[07:09:50] <marc2377> life
[07:10:14] <marc2377> hm, life did not fail, good
[07:10:15] <marc2377> not yet
[07:10:22] <marc2377> xD
[07:29:44] -!- abaumann has joined #archlinux32
[07:29:45] <buildmaster> Hi abaumann!
[07:29:45] <buildmaster> !rq abaumann
[07:29:46] <phrik> buildmaster: <abaumann> they should have called it 'features: side-channel'
[07:32:07] <abaumann> marc2377: the config files for 32-bit kernels are for instance in https://git.archlinux32.org (config.i486, config.i686, config.pentium4)
[07:32:08] <phrik> Title: archlinux32/packages: Package customizations and pure-i686 packages - Archlinux32 Gitea (at git.archlinux32.org)
[07:33:03] <marc2377> Hey abaumann
[07:34:02] <marc2377> yes, I can see that, but when I compare the config.i686 file with the arch native (x86_64) in a diff viewer, there are so many different options
[07:34:10] <marc2377> even for the same kernel version
[07:34:23] <marc2377> much more than the usual architecture-specific options
[07:34:34] <marc2377> I wanted to know why is that the case
[07:34:38] <abaumann> jamincollins: everything depends on glibc, but glibc is a special beast providing backwards compatibility. What you did is installing a new python3 on a ISO with an older glibc, as elibrokeit pointed out, this is not supported. The ISO is there for rescuing and installing systems, not to test whether something works with 'pacman -S python' inside the ISO system (so the ISO is _not_ a life system in
[07:34:44] <abaumann> the usual way)
[07:35:03] <abaumann> marc2377: let me check..
[07:39:22] <abaumann> things like CONFIG_64BIT=y should be diff, but you are right, there are far too many differences
[07:39:49] <abaumann> some things might simply not be supported on 32-bit
[07:40:32] <abaumann> important point: we did _not_ copy the 64-bit config to 32-bit when forking Archlinux32, we took the version from the then active i686 version
[07:40:46] <marc2377> that was what I was going to ask just now
[07:40:48] <abaumann> reason: there must be reasons why they differ..
[07:40:52] <abaumann> :-)
[07:41:00] <marc2377> makes sense
[07:41:04] <abaumann> it's an intersting topic
[07:41:18] <abaumann> the question is: is/was that the right thing to do?
[07:41:32] <abaumann> is it better to take the 64-bit config from now and switch it to 32-bit?
[07:41:55] <marc2377> It almost certainly needs a review at this point - I surely saw a couple of settings that should be the same on 32bit
[07:41:56] <abaumann> for i486 and so most likely not, there are deprecated modules, which are very important to get a i486 machine to run :-)
[07:42:23] <abaumann> yeah. for instance Xen is enable on 64-bit, 32-bit not
[07:42:35] <marc2377> yeah
[07:42:55] <abaumann> another source of problems is, that upstream has different maintainers for linux, linux-lts, linux-zen.
[07:43:00] <abaumann> so things differ also there..
[07:43:58] <marc2377> good point
[07:47:50] <abaumann> jamincollins: depending on specific versions of glibc doesn't make sense, as it required building 10'000 packages on every change of the glibc. That's why glibc is a multi-version symbol thingy being backwards compatible for almost 20 years.
[07:48:20] <abaumann> jamincollins: there is a point I take here, the ISO should be done again on a monthly basis and be more up to date than it sometimes is.
[07:48:35] <marc2377> the reason I'm messing with this is I'm creating an AUR package for drm-openchrome (https://cgit.freedesktop.org/openchrome/drm-openchrome) and now I'm at the stage of adding i686 (and pentium4) support to the PKGBUILD
[07:48:37] <phrik> Title: openchrome/drm-openchrome - DRM driver for VIA IGPs (at cgit.freedesktop.org)
[07:48:52] <abaumann> marc2377: that's cool
[07:49:10] <abaumann> so, there are modules missing in 'linux'? I had the same issue with some of my old machines.
[07:49:26] <abaumann> The kernel supports a deprecated DRI now, but mesa/xorg dropped support for it. :-)
[07:49:37] <marc2377> nowadays, yes - by default the old dri1 drivers are disabled
[07:49:42] <marc2377> exactly
[07:49:50] <marc2377> the old drm driver is called via
[07:50:07] <abaumann> I'm on VESA for most of the old machines
[07:50:09] <marc2377> but openchrome is newer and should be a replacement
[07:50:26] <abaumann> mainly because after Xorg 1.20 you have to basically adapt and support old Xorg modules yourself.
[07:50:34] <marc2377> me too :/
[07:51:27] <abaumann> as this needs real hardware to test, it's something Archlinux32 devs push to the users of Archlinux32 :-)
[07:51:37] <marc2377> Kevin Brace (the openchrome dev) told me on an email earlier this month that the very latest version of the openchrome ddx should work without any drm module (I haven't tested)
[07:52:05] <abaumann> that's actually good news.
[07:52:07] <marc2377> but vesafb and another couple of kernel modules must be blacklisted
[07:52:27] <marc2377> hah, sure thing
[07:52:43] <abaumann> I remember some problems on Geode LX AMD, which go into the same direction
[07:53:06] <marc2377> in fact I came to use archlinux32 in an old laptop (it has a Via Unichrome Pro chip) without x86_64 support
[07:53:32] <marc2377> oh, glad I didn't come across those
[07:53:44] <abaumann> fun fact: end of 2017 my Alix with Geode LX was running perfectly with dedicated driver and Xorg. Then came the CET protection thing breaking the toolchain for those machines and the Xorg update, breaking the graphical interface. So now the box is basically text only. :-)
[07:55:08] <marc2377> damn
[07:55:12] <abaumann> some Linux project are run by the moto: "break things and support only newest stuff", they don't let old code in to rot and for somebody else to fix it. There is a tradeoff here between security, featuritis and maintainance
[07:56:16] <marc2377> quite. I usually see reason on both sides
[07:56:51] <marc2377> at least if the old code is removed you can ressurrect them from version control
[07:56:58] <marc2377> that's a start
[07:57:12] <marc2377> (shudders)
[07:59:16] <marc2377> I think I'll rebase my current drm-openchrome config on top of the archlinux32's config.i686 file for the time being
[07:59:41] <marc2377> (or maybe the opposite?)
[07:59:57] <marc2377> well, thats a decision for later
[08:00:07] <marc2377> gotta go.. cya
[08:00:12] <abaumann> ok. cu
[08:01:38] <marc2377> do we receive messages sent when we were offline in this server/channel?
[08:02:13] <abaumann> I'm not aware of, but there is a chat log on https://mirror.archlinux32.org
[08:02:15] <phrik> Title: #archlinux32 | Logs (at mirror.archlinux32.org)
[08:02:58] <marc2377> ty
[08:11:05] -!- deep42thought has joined #archlinux32
[08:11:21] <deep42thought> hey buildmaster, what's up?
[08:11:21] <buildmaster> Hi deep42thought!
[08:11:21] <buildmaster> !rq deep42thought
[08:11:21] <buildmaster> up? I'm up for 1 day, 12 hours, 7 minutes, load average: 0.56, 0.61, 0.78
[08:11:22] <phrik> buildmaster: <deep42thought> I have the impression, their main operating area is television via cable
[08:12:01] <deep42thought> hehe: https://github.com
[08:12:02] <phrik> Title: GitHub - shapr/markovkeyboard: keyboard layout that changes by markov frequency (at github.com)
[08:16:21] <abaumann> hi deep42thought
[08:16:26] <deep42thought> Hi abaumann!
[08:17:22] <abaumann> markov optimized keyboard - sounds like another smart idea like "pick Linux commits for stable with artifical intelligence algorithms" :-)
[08:18:08] <abaumann> chroots='/var/lib/archbuild'
[08:18:13] <abaumann> archbuild.in
[08:18:35] <abaumann> you were right. might be the easiest idea to split those per build slave on eurobuild6
[08:25:17] <deep42thought> "easy" in terms of how much we need to hack
[08:25:28] <deep42thought> but it would be cleaner if all root/ are the same
[08:25:37] <deep42thought> and we had proper locking ...
[08:25:41] <abaumann> true.
[08:25:45] <abaumann> same as for the git repos..
[08:25:47] <abaumann> mmh.
[08:25:50] <deep42thought> yup
[08:27:45] <deep42thought> I'll ad a TODO :-)
[08:37:55] <deep42thought> do you have multiple "builder" repos? or are you running all build slaves from within one?
[08:38:06] <abaumann> multiple
[08:38:17] <deep42thought> this would be also nice to reduce ...
[08:38:19] <deep42thought> hmmm
[08:38:39] <abaumann> yeah. but for now I'm really just aiming for the "works in parallel, though ugly"
[08:38:46] <deep42thought> :-)
[08:38:57] <abaumann> make it work now, optimize later
[08:39:04] <deep42thought> "ein gutes Provisorium hält am längsten"
[08:39:22] <deep42thought> not sure what that's in english ...
[08:39:43] <abaumann> :-)
[08:48:12] -!- charims has quit [Read error: Connection reset by peer]
[08:59:40] <deep42thought> archbuild's locking is already sufficient - it blocks when it cannot get a lock
[09:00:04] <abaumann> yeah, but the recursively_delete thingy is a problem
[09:00:22] <abaumann> I have a patch now for '-r /var/lib/archbuild/slave1' now in 'builder'
[09:00:25] <abaumann> just testing
[09:01:59] <deep42thought> you mean recursively_umount_and_rm() ?
[09:02:13] <abaumann> oh.
[09:02:14] <abaumann> shit
[09:02:18] <abaumann> parallel updates.
[09:02:19] <abaumann> yes.
[09:02:31] <deep42thought> I removed the recursive umount on -c (that's now in devtools32's archbuild)
[09:02:40] <abaumann> ah. ok
[09:02:51] <deep42thought> recursively_umount_and_rm now only gets invoked on $tmp_dir
[09:02:55] <deep42thought> which is fine imho
[09:04:01] <abaumann> yeah. but are you respecting the '-r chroot' flag?
[09:04:04] <abaumann> in devtools32
[09:04:15] <deep42thought> I did not change anything about that
[09:04:24] <deep42thought> at least I'm not aware of it ;-)
[09:04:25] <abaumann> so, it's /var/lib/archbuild hardcoded?
[09:04:54] <deep42thought> r) chroots="$OPTARG" ;;
[09:04:58] <deep42thought> it's all there
[09:05:49] <abaumann> is it run as root? otherwise it has little effect.
[09:05:50] <deep42thought> though, you need it in the first parameter group ("$outerParameters")
[09:06:05] <deep42thought> why should it need to be run as root?
[09:06:19] <abaumann> because all files belong to root inside the chroot
[09:06:26] <abaumann> at least all packages being installed with pacman
[09:06:58] <deep42thought> archbuild itself invokes sudo
[09:07:03] <abaumann> ah. ok then.
[09:07:22] <abaumann> the we should no longer have messages like 'rm: permission denied' anywhere
[09:07:28] <abaumann> *then
[09:07:29] <deep42thought> yes
[09:07:40] <abaumann> ok, I'll update, merge and test again.. :-)
[09:07:42] <deep42thought> that was the idea behind moving that code into archbuild and friends
[09:07:48] <abaumann> ah. :-)
[09:08:06] <abaumann> did you check in devtools32 already?
[09:08:07] <deep42thought> also it's cleaner in the sense, that whoever messes up should clean up, too
[09:08:14] <deep42thought> yes
[09:08:25] <deep42thought> 20190616-1
[09:08:42] <abaumann> ah, yep. seen it.
[09:08:52] <deep42thought> though, it's not yet build on archlinux32 :-(
[09:09:23] <abaumann> doesn't matter
[09:09:34] <abaumann> I'm using devtools32 usually directly from git on the build slaves
[09:09:50] <deep42thought> ah, ok :-)
[09:10:07] <abaumann> reminds me to adapt tyzoids 18 point list of "how to set up a slave'
[09:13:47] <buildmaster> pentium4/acpi_call-lts are broken (says rechenknecht).
[09:14:09] <buildmaster> pentium4/r8168-lts are broken (says rechenknecht).
[09:26:29] <abaumann> seems to work nicely. :-)
[09:27:29] <abaumann> kworker/u64:4+flush 99% I/O
[09:27:37] <abaumann> now, there is some room for optimization..
[09:27:52] <abaumann> all slaves are currently installing chroots, so I hope, this doesn't happen in normal builds.
[09:28:32] <deep42thought> abaumann: your "test ..." addition belongs into lib/load-configuration
[09:28:33] <abaumann> all my build slaves build some things, which break due to a broken rust..
[09:28:41] <deep42thought> :-D
[09:28:47] <abaumann> ah.
[09:28:51] <abaumann> I'll move it.
[09:28:55] <deep42thought> wait
[09:29:01] <abaumann> ah. you are too fast..
[09:29:08] <abaumann> ..as usual. :-)
[09:29:20] <deep42thought> you can skip the conditional if you just assign the variable before sourcing conf/*
[09:30:08] <abaumann> but this is before lib/load-configuration
[09:30:11] <abaumann> kinda ugly
[09:30:15] <deep42thought> no
[09:30:23] <deep42thought> what is before lib/load-configuration?
[09:30:56] <abaumann> *abaumann is confused
[09:31:16] <abaumann> ah qtwebengine-everywhere
[09:31:19] <abaumann> better
[09:33:16] <deep42thought> like so: a20502b
[09:34:54] <abaumann> ah. ok.
[09:34:55] <abaumann> thanks.
[09:35:06] <deep42thought> np
[09:36:35] <abaumann> mmh. is the default MAKEFLAGS now '-j' or is qt5 just not respecting any settings?
[09:36:51] <deep42thought> I think, it depends on your /etc/makepkg.conf
[09:37:06] <abaumann> MAKEFLAGS="-j1"
[09:37:08] <abaumann> on the host
[09:37:21] <abaumann> but the chroot ones I have to check
[09:38:45] <abaumann> ninja: build stopped: subcommand failed.
[09:38:55] <abaumann> yeah. parallel builds don't really work for qt5-webengine
[09:41:02] <abaumann> a qmake, then a make without makeflags in the PKGBUILD, weird.
[09:41:24] <abaumann> and a ninja is failing
[09:42:04] <abaumann> I wonder: MAKEFLAGS is for 'make', less and less packages use make and have different flags. How does upstream address that?
[09:42:19] <deep42thought> MESONFLAGS
[09:42:26] <deep42thought> NINJAFLAGS
[09:42:28] <deep42thought> ...
[09:42:43] <deep42thought> soon there will be *FLAGS
[09:42:45] <abaumann> I think, there should be a PARALLEL_BUILDS flags which then gets translated to all kind of local flags
[09:42:55] <deep42thought> sounds reasonable
[09:42:57] <abaumann> let me check what arch-meson is doing
[09:43:28] <abaumann> that's another approach: have wrappers for meson, ninja, etc.
[09:44:40] <abaumann> no parallilty thing in arch-meson
[09:44:41] <abaumann>
[09:46:01] <abaumann> MAKEFLAGS='-j1'
[09:46:04] <abaumann> no effect
[09:46:17] <abaumann> this makes running parallel chroots not so nice.
[09:46:34] <abaumann> so back to the idea of limit number of cpus in a systemd-nspawn
[09:46:47] <deep42thought> I would consider this a bug of the PKGBUILD
[09:47:59] <abaumann> yep, all 'make' directly in PKGBUILD are wrong. All build tools should always set the parallelity.
[09:48:11] <abaumann> I'm just afraid, this is never done.
[09:48:32] <deep42thought> does make read MAKEFLAGS from env?
[09:48:37] -!- thePiGrepper has quit [Ping timeout: 246 seconds]
[09:48:46] <abaumann> good point
[09:48:52] <abaumann> ah.
[09:48:53] <abaumann> yes
[09:48:58] <abaumann> it does :-)
[09:49:25] <abaumann> so most like make calls some ninja stuff (chromium) inside qt5-webengine, and that one doesn't respect any flags.
[09:49:44] <deep42thought> yes, _that_'s an issue ...
[09:49:46] <deep42thought> or a bug
[09:50:23] <abaumann> the problem is: I want to protect the slaves against misbehaving builds..
[09:50:31] <deep42thought> yes
[09:50:33] <abaumann> so resource limitation has to happen outside
[09:50:38] <deep42thought> limiting cpus is a good idea either way
[09:50:43] <abaumann> yep
[10:14:16] -!- charims has joined #archlinux32
[10:21:18] <abaumann> now I have parallel running 'js' from the test environemnt *sigh*
[10:21:39] <abaumann> this is really b*it what developers are doing..
[10:21:52] <deep42thought> the problem will be, that nproc still reports all cpus
[10:21:53] <abaumann> "works on my laptop and I buy a laptop every year"
[10:21:59] <deep42thought> !grab abaumann
[10:21:59] <phrik> deep42thought: Tada!
[10:22:47] <abaumann> I think, I just let it run. Then I get some 100% peaks on the machine, let's see how often.
[10:23:51] <abaumann> CPUQuota=20%
[10:24:00] <abaumann> but systemd limits on a CPU rlimit level.
[10:24:10] <abaumann> there is CPU affinity I could play with, but..
[10:25:11] <abaumann> what I want to see: are additional build slaves bringing down the "to be built' packages in the graphs or not.
[10:25:24] <abaumann> if not, then scheduling is not optimal
[10:25:41] <deep42thought> yeah, I'm also trying to optimize the build-packages script to require less trials on failing builds :-)
[10:25:41] <abaumann> or too many makedepends like npm, yarn, rust, java are currently broken..
[10:25:56] <abaumann> or too many packages are broken..
[10:26:12] <abaumann> it's important information in order to know where to put in effort..
[10:26:20] <deep42thought> yeah
[10:27:00] <abaumann> and I used now almost 4 days with hardware, setup build slaves etc.
[10:27:06] <abaumann> I have to focus again on packages. :-)
[10:42:28] <deep42thought> I changed the repair-failing-build logic: it now separately tries to fix the sources (e.g. download missing keys, download source from source tarball, download source by hash) and then tries to fix broken builds (e.g. clean chroot, build with build-support)
[10:42:54] <deep42thought> there is still room for optimization: e.g. if it fails due to missing dependencies, then cleaning the chroot will not fix that ...
[10:45:00] <abaumann> of course. but that sounds good.
[10:45:33] <abaumann> btw: is there something like negative priorities?
[10:45:33] <deep42thought> my problem with moving the error-detection logic into build-packages is, that this is currently managed by regexes in the database - which resides on the buildmaster
[10:45:42] <abaumann> oh.
[10:45:50] <deep42thought> no, there are no neg. priorities
[10:46:00] <deep42thought> but once a package gets built, its priority is set to 0
[10:46:08] <deep42thought> (independend of the success)
[10:46:13] <abaumann> blacklist is sort of -inf priority :-)
[10:46:19] <deep42thought> !grab abaumann
[10:46:19] <phrik> deep42thought: Tada!
[11:09:55] <abaumann> mmh. why is gqrx looping endlessly, not executing any straws?
[11:10:12] <deep42thought> maybe I created new bugs :-)
[11:10:33] <abaumann> do i have to update the slaves?
[11:10:44] <deep42thought> if you want to have the new bugs: yes
[11:11:37] <abaumann> gprx is a package which is failing, then it just terminates build-packages and gets the same build-assignment again
[11:11:49] <deep42thought> "sed: can't read ;: No such file or directory"
[11:11:50] <deep42thought> hmmm
[11:12:30] <deep42thought> oops
[11:13:22] <deep42thought> I copied that from within a "find" ...
[11:14:36] <deep42thought> should be fixed now
[11:15:31] <abaumann> ok
[11:20:43] <deep42thought> damn, another bug ...
[11:21:14] <abaumann> "another day, another bug" :-)
[11:34:18] <deep42thought> looks good so far ...
[11:37:18] <deep42thought> ok, failing a build works - looks ok :-)
[11:37:57] <deep42thought> cu later
[11:37:59] -!- deep42thought has quit [Quit: Leaving.]
[11:39:03] <abaumann> ok, cu.
[11:39:07] <abaumann> thanks for the fix
[11:41:38] <abaumann> *abaumann thinks you didn't git push :-)
[13:26:03] <abaumann> Fun fact of the day: rust calls i686 cpus with SSE2 and i586 without SSE.
[13:26:25] <abaumann> That miss-naming just caused my headaches and debugging sessions
[13:30:52] <abaumann> python ./x.py build -j"$(nproc)"
[13:30:57] <abaumann> yeah. nicely done.
[13:31:00] <abaumann> in rust PKGBUILD
[13:33:55] <abaumann> I'll report that one upstream..makeing eli happy :-)
[13:36:26] <abaumann> Mmh. Maybe I should have bothere eli with that first.. a well.
[13:36:27] <abaumann> https://bugs.archlinux.org
[13:36:27] <phrik> Title: FS#62952 : [rust] build doesn't respect MAKEFLAGS (at bugs.archlinux.org)
[13:36:44] <abaumann> I'm used to getting bugs closed because I'm discussing philosophical issues. :-)
[13:38:39] <elibrokeit> Nproc in a PKGBUILD is ugly
[13:38:59] <abaumann> He has been summoned.. ;-)
[13:39:11] <elibrokeit> The whole point of MAKEFLAGS is that you're supposed to, well, use them :(
[13:39:27] <abaumann> But MAKEFLAGS has an effect on make only
[13:39:31] <abaumann> as environment variable
[13:40:05] <elibrokeit> Actually I am tracking an upstream ticket for samurai (ninja-compatible build system) to support SAMUFLAGS
[13:40:11] <abaumann> another idea is to have a MAX_CPUS=n setting and then set some build-tool specific variables users of PKGBUILD can use, NINJA_FLAGS, MAKE_FLAGS.
[13:40:24] <abaumann> SAMUFLAGS *abaumann grins at the name
[13:40:35] <elibrokeit> And once it does, I will add that to makepkg.conf integration
[13:40:49] <abaumann> qt5-webkit had also a killing-the-machine-behaviour in ninja :->
[13:40:55] <abaumann> sounds good.
[13:41:09] <abaumann> MESONFLAGS?
[13:41:14] <elibrokeit> https://github.com
[13:41:15] <phrik> Title: Consider supporting a SAMUFLAGS environment · Issue #15 · michaelforney/samurai · GitHub (at github.com)
[13:41:24] <elibrokeit> Samu replaces ninja
[13:41:42] <abaumann> there are more open source projects than names in an English dictionary.
[13:41:50] <elibrokeit> Meson just generates build.ninja files, it is like cmake or configure
[13:41:53] <abaumann> yeah, hence the naming gets.. well.. strange :-)
[13:42:08] <elibrokeit> So you don't need MESONFLAGS I guess
[13:42:17] <abaumann> I was also trying to limit systemd-nspawn for ill-behaving packages..
[13:42:18] <elibrokeit> Would you like to implement SAMUFLAGS?
[13:42:53] <elibrokeit> If so I will package samu to the official repos and submit Pacman patches to define SAMUFLAGS right below MAKEFLAGS in makepkg.conf
[13:43:35] <abaumann> samu is like ninja written in C?
[13:43:41] <elibrokeit> Yes
[13:43:57] <elibrokeit> Also yes, I am tricking you into doing my OSS work for me. :P
[13:44:14] <abaumann> that's why there was an akward silence.. :-)
[13:44:35] <abaumann> what about ninja? there too? or is samurai a drop-in replacement for ninja
[13:45:27] <elibrokeit> Samurai is a drop-in replacement, and the Ninja developers are absolutely refusing to implement it because "environment variables are stupid, use command line flags because those work on wjndows6
[13:45:32] <elibrokeit> *Windows
[13:45:48] <abaumann> mmh.
[13:46:00] <abaumann> samurai is in the AUR
[13:46:06] <elibrokeit> That's why I gave up on ninja in disgust and wish to replace it everywhere with samurai
[13:46:15] <abaumann> ah. :-)
[13:46:15] <elibrokeit> By packaging it ;)
[13:47:31] <abaumann> I have now a faster build machine, but this doesn't mean I can do more work..
[13:47:41] <abaumann> let me make a diff between ninja and samurai
[13:51:23] <abaumann> hah: "Ninja supports one environment variable to control its behavior:
[13:51:23] <abaumann> `NINJA_STATUS`, the progress status printed before the rule being run.
[13:51:54] <abaumann> one environment variable is already there, so they cannot argue that adding more is a bad idea :-)
[13:52:11] <elibrokeit> And yet they do
[13:52:23] <abaumann> Well, fight them with logic..
[13:52:55] <elibrokeit> A dozen people have been doing that for several years now.
[13:53:13] <abaumann> typical google sponsored project, I'm afraid to say so..
[13:53:23] <abaumann> ..I'm trying to get native Windows support for leveldb..
[13:53:28] <abaumann> ..they simply ignore it.
[13:53:39] <elibrokeit> The Ninja developers closed all the feature requests and told them to use downstream wrapper scripts in /usr/local/bin
[13:54:46] <elibrokeit> Just to give you an idea of what we are fighting
[13:54:49] <elibrokeit> ...
[13:55:42] <elibrokeit> This was while simultaneously arguing that it's unjustified to add environment parsing because that requires ninja to do more work and more work is slow
[13:55:57] <elibrokeit> Slower than shell scripts apparently
[13:56:20] <abaumann> yeah, sure. getting a variable from the operating system _once_ is slowing down the program..
[13:56:23] <abaumann> ..sure :-)
[13:56:33] <abaumann> maybe they forgot how 'getenv' works.. ;-)
[13:56:34] <elibrokeit> Slower than python scripts too, since python is their preferred cross-platform script interpreter
[13:57:00] <elibrokeit> At that point, most people assumed this ninja dev was arguing purely for the sake of arguing
[13:57:10] <abaumann> lol, yep :-)
[13:57:44] <elibrokeit> Tl;dr it's easier to work with the samurai dev
[13:58:16] <elibrokeit> Also samurai is C, not C++ ;)
[13:58:23] <abaumann> samurai has a man page, 'man ninja' gives me nothing, but there is raw ascii doc in /usr/share
[13:58:32] <elibrokeit> Yep
[13:58:50] <elibrokeit> Let's keep counting the reasons I prefer samurai ;)
[13:59:13] <abaumann> The only problem will be: is everything buildable with samurai? and are the ninja people going to add a lot more features, so that samurai gets into a catchup game?
[13:59:32] <abaumann> I prefer C :-)
[14:00:18] <abaumann> bootstrapping is another argument
[14:00:37] <abaumann> ninja builds itself with ninja where a simple make or shell script would have been sufficient.
[14:00:46] <abaumann> ok, eat-our-own-dog-food, I assume..
[14:01:51] <elibrokeit> The Ninja build specification is versioned and build.ninja declares its feature requirements. Samurai should always build the project, and it continues to add new compatibility levels as ninja progresses
[14:02:32] <abaumann> mmh. no automated tests in samurai
[14:02:34] <elibrokeit> Not that there is huge churn
[14:05:10] <abaumann> " -j N run N jobs in parallel (0 means infinity) [default=18 on this system]
[14:05:20] <abaumann> my machines has 8 cores and 16 threads.
[14:05:30] <abaumann> thats a funny default=18 there of ninja :-)
[14:10:50] <abaumann> sysconf(_SC_NPROCESSORS_ONLN) gives 16, so maybe ninja adds to additional ninjas, a manager and a trainer ;-)
[14:10:56] <abaumann> *two
[14:14:09] <abaumann> *abaumann: AFK (gonne shoppinge)
[14:54:55] -!- thePiGrepper has joined #archlinux32
[15:16:29] -!- MrBIOS has joined #archlinux32
[15:47:41] -!- eschwartz has joined #archlinux32
[16:27:44] -!- thePiGrepper has quit [Ping timeout: 248 seconds]
[16:48:51] <buildmaster> pentium4/virtualbox-modules-arch is broken (says eurobuild3).
[17:50:04] <buildmaster> pentium4/broadcom-wl is broken (says rechenknecht).
[18:06:20] -!- titus_livius has quit [Ping timeout: 272 seconds]
[18:07:41] -!- titus_livius has joined #archlinux32
[18:10:49] <buildmaster> pentium4/nvidia-390xx is broken (says buildknecht).
[18:11:32] <buildmaster> i686/trojan is broken (says buildknecht).
[18:12:13] <buildmaster> pentium4/wireguard-arch is broken (says rechenknecht).
[18:12:34] <buildmaster> pentium4/trojan is broken (says eurobuild3).
[18:20:03] -!- eschwartz has quit [Ping timeout: 245 seconds]
[18:38:27] -!- eschwartz has joined #archlinux32
[18:38:48] -!- samantaz_ has joined #archlinux32
[19:16:34] -!- AndrevS has joined #archlinux32
[19:25:21] -!- thePiGrepper has joined #archlinux32
[19:43:04] <buildmaster> i686/nvidia-390xx is broken (says eurobuild6-1).
[19:47:02] -!- thePiGrepper has quit [Ping timeout: 258 seconds]
[19:51:28] -!- eschwartz has quit [Ping timeout: 272 seconds]
[20:00:36] -!- eschwartz has joined #archlinux32
[20:18:48] -!- thePiGrepper has joined #archlinux32
[20:25:14] -!- abaumann has quit [Quit: leaving]
[20:32:22] -!- buildmaster has quit [Remote host closed the connection]
[20:33:01] -!- buildmaster has joined #archlinux32
[20:33:01] <buildmaster> !rq buildmaster
[20:33:02] <phrik> buildmaster: <buildmaster> I might be insane, but never confused ... ;-)
[20:36:26] <buildmaster> pentium4/swi-prolog is broken (says eurobuild6-4).
[21:47:41] -!- thePiGrepper has quit [Read error: Connection reset by peer]
[21:53:27] -!- thePiGrepper has joined #archlinux32
[21:59:12] -!- thePiGrepper has quit [Ping timeout: 245 seconds]
[22:12:29] <buildmaster> pentium4/js60 is broken (says eurobuild6-3).
[22:13:40] <buildmaster> i686/js60 is broken (says eurobuild6-3).
[22:32:41] -!- MrBIOS has quit [Quit: MrBIOS]
[22:39:27] -!- thePiGrepper has joined #archlinux32
[23:06:18] <marc2377> Hello
[23:10:01] -!- djmoch has quit [Quit: ZNC 1.7.3 - https://znc.in]
[23:10:22] -!- djmoch has joined #archlinux32