#archlinux32 | Logs for 2018-10-11

Back
[02:11:54] -!- woshty has quit [Ping timeout: 252 seconds]
[02:29:06] -!- ofara_ has joined #archlinux32
[03:01:21] -!- jarshvor has quit [Ping timeout: 244 seconds]
[03:07:01] -!- buildmaster has quit [Ping timeout: 260 seconds]
[03:07:15] -!- z3ntu has quit [Ping timeout: 250 seconds]
[03:09:07] -!- jarshvor has joined #archlinux32
[03:10:13] -!- z3ntu has joined #archlinux32
[04:04:32] -!- buildmaster has joined #archlinux32
[05:57:30] -!- NoobAlice has quit [Quit: Leaving.]
[06:17:51] -!- deep42thought has joined #archlinux32
[06:17:55] <buildmaster> Hi deep42thought!
[06:17:55] <buildmaster> !rq deep42thought
[06:17:55] <phrik> buildmaster: <deep42thought> arch32 is on the bleeding edge of arch, which is on the bleeding edge of software?
[06:18:23] <deep42thought> Hi buildmaster, what's up?
[06:18:26] <buildmaster> up? I'm up for 4 days, 21 hours, 41 minutes, load average: 6.84, 4.49, 3.27
[07:05:19] -!- deep42thought has quit [Quit: Leaving.]
[08:13:56] -!- deep42thought has joined #archlinux32
[08:13:56] <buildmaster> Hi deep42thought!
[08:13:56] <buildmaster> !rq deep42thought
[08:13:57] <phrik> buildmaster: <deep42thought> arch32 is on the bleeding edge of arch, which is on the bleeding edge of software?
[08:14:39] <deep42thought> the problem I see with the welcome-cite-feature is, that some of us (e.g. I) have considerably few quotes
[08:16:40] -!- abaumann has joined #archlinux32
[08:16:40] <buildmaster> Hi abaumann!
[08:16:40] <buildmaster> !rq abaumann
[08:16:41] <phrik> buildmaster: <abaumann> I remember the old saying in archlinux: "core" is for the things we need to boot the system and build the system. So meson is now part of core?
[08:16:45] <deep42thought> Hi abaumann!
[08:16:51] <abaumann> hi deep42thought
[08:17:13] <abaumann> well.. also my fault.. I'm not grabbing quotes..
[08:17:32] <deep42thought> ... that's what I wanted to say "through the flower"
[08:17:38] <abaumann> :-)
[08:17:47] <deep42thought> (how do you phrase that in english?)=
[08:17:59] <abaumann> mmh...
[08:20:48] <abaumann> 'say somthing in a roundabout' (at least following PONS: https://de.pons.comübersetzung/deutsch-englisch/Durch+die+blume+sagen)
[08:21:42] <abaumann> We need mesa and librsvg, it creates some knots on i486, now building rust is maybe doable, the mesa bug is hard to solve..
[08:22:28] <deep42thought> yeah, I already commented upstream
[08:22:30] <abaumann> I'm currently solving some remaining knots in 'base' 'base-devel' and dependencies of them.
[08:22:35] <deep42thought> ... on a 2 year old thread :-/
[08:22:35] <abaumann> ah. good.
[08:22:43] <abaumann> ah.. not good. :-(
[08:24:02] <deep42thought> https://bugs.freedesktop.org
[08:24:06] <phrik> Title:93089 – mesa fails to check for gcc atomic primitives before using them (at bugs.freedesktop.org)
[08:24:14] <abaumann> I still have to revive my test environment.. I simply don't know what happened in Archlinux upstream, the kernel/libvirt/qemu-combo is simply not working anymore for my setup.. 100% CPU freezes, broken network bridges..
[08:25:10] <abaumann> ah. so we have to disable vulkan for mesa..
[08:25:22] <deep42thought> yeah, I haven't seen the answer yet
[08:25:32] <abaumann> ..which then breaks other things again..
[08:25:33] <deep42thought> I thought, I'd get an email, but apparently I did not
[08:26:11] <deep42thought> actually, the answer is inaccurate, because you _can_ run a i486 kernel on i686 hardware ...
[08:26:30] <deep42thought> s/kernel/software/
[08:26:51] <abaumann> .. I think what he means is, that an i486 cannot possibly have an embedded GPU or so. so the whole vulkan framework makes little sense to build.
[08:27:33] <abaumann> would all be fine, if the rest still works in an unaccelerated, pure-C version.
[08:27:56] <abaumann> but I need my VMs to test it..
[08:28:38] <abaumann> openmpi is a similar thing, makes little sense for i486, but software depends on it, e.g. boost. So my plan is to build it nonetheless to satisfy the dependencies..
[08:28:57] <abaumann> mmh.. I'll try rust now, seems feasable..
[08:29:00] <deep42thought> or we could kick out the dependencies for i486
[08:29:23] <abaumann> that's what currentl is in the CARCH=i486 section, just dropping openmpi
[08:29:34] <abaumann> *currently
[08:29:45] <abaumann> actually: might be better in order not to trigger funny behaviour?
[08:29:52] <deep42thought> yeah
[08:30:00] <deep42thought> but it might become a maintenance nightmare
[08:30:13] <deep42thought> because we might need to kick out openmpi at many places
[08:30:20] <deep42thought> a dummy-package for i486 would be easier
[08:30:24] <abaumann> blacklisting for i486 is no option..
[08:30:28] <abaumann> a dummy package.
[08:30:41] <abaumann> let's see what happens, if openmpi is built on a i486 :-)
[08:30:46] <abaumann> so far it builds..
[08:30:46] <deep42thought> :-D
[08:31:30] <deep42thought> my cluster of 1k 4/86's will be happy to iterate Maxwell-Vlasov-equations :-D
[08:31:31] <abaumann> for boost for instance it's only there to make Boost.MPI work..
[08:31:42] <abaumann> !grab deep42thought
[08:31:42] <phrik> abaumann: Tada!
[08:31:49] <abaumann> there you go. lol/.
[08:31:55] <deep42thought> see - it's easy ;-P
[08:34:50] <abaumann> AFK: "Gonne Shoppinge"
[08:36:36] -!- woshty has joined #archlinux32
[09:42:43] -!- thePiGre1per has joined #archlinux32
[09:44:28] -!- thePiGrepper has quit [Ping timeout: 268 seconds]
[10:42:49] -!- noctambulo has quit [Remote host closed the connection]
[10:52:23] <deep42thought> abaumann: I think, I made mesa compile on i486 :-)
[10:54:40] <abaumann> I saw your commit. :-)
[10:54:44] <abaumann> Cool :-)
[10:55:00] <deep42thought> it's w/o lm_sensors, for now (not in the commit - I'll fix this manually)
[10:55:49] <abaumann> lm_sensors is a dependency of mesa?
[10:55:53] <deep42thought> yes
[10:56:00] <deep42thought> some feature requires it
[10:56:09] <abaumann> So, when the gpu gets too hot, then at least you can monitor it and disable some gpu features?
[10:56:16] <deep42thought> dunno
[10:56:37] <deep42thought> -D lmsensors=true
[10:56:43] <abaumann> does it include a dependency to a mailer, so it can send emails about temperature and usage too? ;-)
[10:56:54] <deep42thought> !grab abaumann
[10:56:56] <phrik> deep42thought: 🎉
[10:57:06] <deep42thought> my software usually depends on a mailer
[10:57:17] <abaumann> you know the saying: sooner or later every software contains a feature to send email.
[10:57:31] <abaumann> was it applied for emacs first?
[10:57:31] <deep42thought> I didn't know that one
[10:57:48] <abaumann> I have to hunt the citation. :-)
[10:58:09] <deep42thought> nah, I never ran emacs - it's a nice os, but I couldn't find a suitable editor for it
[10:58:21] <abaumann> !grab deep42thought
[10:58:21] <phrik> abaumann: Tada!
[10:58:32] <abaumann> lol
[10:58:50] <deep42thought> the quote is a stolen one, though
[10:59:15] <deep42thought> yet another nice one for bootstrappers: http://bash.org
[10:59:16] <phrik> Title:QDB: Quote #891175 (at bash.org)
[10:59:49] <abaumann> :-)
[11:06:33] <deep42thought> abaumann: you broke nasm's pkgbuild
[11:07:22] <abaumann> actually twice. now it should be ok.
[11:11:37] <abaumann> just tested on i686, now it builds. on i486 I lack the documentation manual, but otherwise the software builds too.
[11:12:01] <deep42thought> rust or nasm?
[11:12:21] <abaumann> nasm
[11:12:26] <abaumann> rust comes now :-)
[11:15:23] <abaumann> error: target not found: rust
[11:15:30] <deep42thought> yeah
[11:15:35] <abaumann> don't tell me rust boostrapps itself with an existing rust
[11:15:37] <deep42thought> you need to cross compile it from somewhere :-/
[11:15:39] <abaumann> *sigh*
[11:16:50] <deep42thought> why can't those self-hosted compilers come with a minimal compiler version (which is capable of compiling the real compiler) written in a _common_ language like brainfuck?
[11:16:54] <abaumann> yeah. or use a trustworthy i486 rust blob.
[11:17:08] <abaumann> because that's old school compiler building. :-)
[11:17:12] <deep42thought> lol
[11:17:22] <abaumann> easiest is usually to write a new-language-to-C translator.
[11:17:37] <abaumann> Then you can write your compiler in your new language.
[11:17:52] <deep42thought> the translator should be written in C, too ;-P
[11:17:59] <abaumann> actually: there is a tradeoff between boostrappability and minimizing duplication of compiler code.
[11:18:14] <abaumann> yes. that's exactly the point.
[11:18:20] <deep42thought> well, then don't write the compiler in its own language ...
[11:18:30] <abaumann> use an existing wide-spread and portable language for your first translator or/and compiler
[11:18:51] <abaumann> .. definitely write your compiler in your own language. You want to be able to maintain it afterwards.
[11:19:19] <abaumann> unless your new language is not suited to write compilers in.. which would raise some question marks about your new funky language. :-)
[11:19:51] <abaumann> urust2c?
[11:19:51] <deep42thought> :-) mabye it's not turing complete?
[11:20:33] <abaumann> https://internals.rust-lang.org
[11:20:34] <phrik> Title:Solving the bootstrap problem - tools and infrastructure - Rust Internals (at internals.rust-lang.org)
[11:21:17] <abaumann> https://github.com
[11:21:19] <phrik> Title:GitHub - thepowersgang/mrustc: Alternative rust compiler (re-implementation) (at github.com)
[11:21:25] <abaumann> but I doubt they are production ready.
[11:21:44] <abaumann> then the next question is: can rust crosscompile itself?
[11:22:23] <abaumann> https://github.com
[11:22:24] <phrik> Title:GitHub - japaric/rust-cross: Everything you need to know about cross compiling Rust programs! (at github.com)
[11:24:00] <abaumann> aha. so if use by i486 crosstool chain for building rust, it should work.
[11:24:04] <abaumann> *my
[11:39:44] <buildmaster> i686/jsonrpc-glib is broken (says buildknecht2).
[11:41:09] <deep42thought> abaumann: fyi, there is now a feature to force a build of a specific build-assignment on a specific build slave the next time that build slave requests an assignment
[11:41:52] <deep42thought> just put a line "$arch $pkgbase" into ~/builder/work/forced-package-builds.$slave on the buildmaster
[11:42:27] <deep42thought> note, that this skips all dependency checks
[11:42:29] <abaumann> ah. very good. So I we don't build always on all architectures..
[11:42:33] <abaumann> ok.
[11:42:40] <deep42thought> no
[11:42:49] <deep42thought> this only _prioritizes_ the build assignment
[11:42:54] <abaumann> ah. ok.
[11:42:55] <deep42thought> it needs to be in the build-list already
[11:43:04] <abaumann> I used priorize.. so far.
[11:43:14] <deep42thought> but you can force to build stuff on i486 where the buildmaster thinks the dependencies are not yet met
[11:43:31] <deep42thought> prioritize-build-list only works if the dependencies are available
[11:43:42] <abaumann> the buildmaster doesn't work for packages only available in bootstrap, aha.
[11:43:43] <deep42thought> otherwise the build assignment is not considered for handing out
[11:43:49] <deep42thought> exactly
[11:43:53] <abaumann> that explains a lot :-)
[11:44:14] <abaumann> ok. will try, I have fixed some 20 packages in core which need a reubuild against bootstrapped packages.
[11:44:18] <deep42thought> I just got tired of manipulating the database directly, so I wrote some lines to accomplish that (also somewhat cleaner)
[11:44:43] <abaumann> definitely :-)
[11:44:47] <deep42thought> well, for a rebuild you'll need to put the packages on the build-list first
[11:44:47] <buildmaster> i686/qmidiroute is broken (says tyzoid-srv0-bs0).
[11:45:13] <abaumann> AFK: "Gonne Cokkinge"
[11:45:16] <deep42thought> :-D
[11:45:21] <deep42thought> Guten Appetit!
[11:45:28] <abaumann> Dankeschoen. :-)
[11:52:02] <deep42thought> lol: namcap complains _after_ the successful build of mesa: "Error: /startdir/PKGBUILD is not a valid PKGBUILD"
[12:01:17] <buildmaster> i686/kde-cli-tools is broken (says buildknecht2).
[12:07:37] <buildmaster> i686/systemsettings is broken (says rechenknecht).
[12:08:59] <buildmaster> i686/powerdevil is broken (says buildknecht2).
[14:03:58] <buildmaster> i686/python-dbus-client-gen is broken (says eurobuild3).
[14:21:33] <buildmaster> i686/krita is broken (says buildknecht2).
[14:42:45] <abaumann> chmod: changing permissions of '/data/arch32/builder/bin/../work/tmp.build-packages.4YWJAB/package-content.pkoJtC/mesa-18.2.2-1.1-i686.pkg.tar.xz/usr/lib/libGLX_indirect.so.0': Operation not permitted
[14:42:58] <abaumann> mmh. maybe harmless.. maybe not..
[14:43:15] <deep42thought> harmless
[14:43:26] <abaumann> ah.. ok..
[14:43:27] <deep42thought> it tries to chmod 777 or something before deleting
[14:43:34] <abaumann> ah.
[14:43:43] <abaumann> the force-onto-slave-feature works fine. :-)
[14:43:57] <deep42thought> I saw, you were using it :-)
[14:44:09] <abaumann> I can make good use of it. :-)
[15:41:45] -!- NoobAlice has joined #archlinux32
[15:51:14] <abaumann> hurrey: radeon backlight=1 and brightd to the rescue of "my mac display going black on arch" problem. Now the machine is pretty usable. :-)
[16:01:18] <deep42thought> abaumann: your fix for gpgme confuses the buildmaster
[16:01:27] <deep42thought> just setting "pkgname=(gpgme)" is not enough
[16:01:47] <deep42thought> you need to also explicitely declaring "arch=" in all other package functions
[16:02:00] <deep42thought> otherwise "makepkg --printsrcinfo" gives wrong information
[16:05:33] <abaumann> ui.. this look complicated now..
[16:05:39] -!- woshty has quit [Ping timeout: 244 seconds]
[16:05:52] <abaumann> ..I have a template to copy from from now on. :-)
[16:05:54] <abaumann> thanks.
[16:05:56] <deep42thought> problem is, that the buildmaster calls "makepkg --printsrcinfo" to extract which part is built for which arch
[16:06:12] <deep42thought> there was a template already: extra/mesa
[16:06:17] <abaumann> ah.
[16:06:22] <deep42thought> ;-)=
[16:07:53] <deep42thought> maybe there is an easier solution
[16:08:09] <deep42thought> "makepkg --printsrcinfo" needs to give correct information
[16:08:16] <deep42thought> because that is, what the buildmaster relies on
[16:08:31] <abaumann> yeah definitely. this is important. I was not aware of it..
[16:09:08] <abaumann> disabling subpackages for a package is a rare thing, I think.
[16:09:22] <deep42thought> hopefully :-)
[16:09:23] <abaumann> I only used it for things currently not building, but they will build in the future.
[16:09:29] <abaumann> mesa is a real case :-)
[16:11:04] <deep42thought> if it's only temporary, you can also create empty packages by leaving early
[16:11:24] <abaumann> true. I was so happy today: "pacman -S xorg-server"..
[16:11:32] <abaumann> ..just to find out, that this is an empty packgae :-)
[16:11:33] <deep42thought> declare -f package x-doc | sed '/\s*{\s*$/ a return'
[16:11:41] <deep42thought> sry
[16:11:48] <deep42thought> that was I :-/
[16:11:49] <abaumann> no, that's good
[16:11:53] <abaumann> as it makes things compile.
[16:11:58] <deep42thought> but the package is called xorg-server-dummy!
[16:12:24] <abaumann> That's what gave it away :-)
[16:13:37] <deep42thought> we're only one libepoxy away from compiling a real xorg-server ...
[16:13:55] <deep42thought> which requires graphviz
[16:14:00] <abaumann> *argh*
[16:14:10] <deep42thought> which pulls in low-level dependencies like qt4 and gtk2
[16:14:20] <abaumann> and librsvg/rust :-)
[16:14:38] <deep42thought> ah, I commented them out :-)
[16:14:42] <abaumann> that's why graphiz is out of makedepends in a lot of packages in core currently.
[16:14:57] <abaumann> glib2: meson.build:1986:2: ERROR: Program(s) ['xsltproc'] not found or not executable
[16:15:09] <abaumann> I'm really puzzled. libxslt is not a makedepend?
[16:15:15] <deep42thought> yes
[16:15:19] <deep42thought> I've seen this before
[16:15:22] <deep42thought> no clue, why
[16:15:26] <deep42thought> I just added it as makedepends
[16:15:37] <deep42thought> but that was not necessary on x86_64 or i686 IIRC
[16:15:49] <abaumann> that's exactly what I tried too.
[16:15:54] <abaumann> There it builds.
[16:16:17] <abaumann> maybe some auto-guessing in meson triggers something which needs libxslt on i486 only..
[16:16:39] <deep42thought> or some dependency we cut off which would pull in libxslt otherwise
[16:16:47] <abaumann> ah.
[16:16:57] <abaumann> like gtk-doc :-)
[16:17:11] <abaumann> did you check in already?
[16:17:16] <deep42thought> nope
[16:17:33] <abaumann> you could add a libxslt after th removal of gtk-doc in CARCH=i486
[16:17:41] <deep42thought> I'm on the hunt for xorg-server, currently
[16:17:58] <abaumann> Xindiana Xones ;-)
[16:18:04] <deep42thought> lol
[16:18:47] <deep42thought> btw: we do have gtk-doc now on i486
[16:18:55] <abaumann> a real one?
[16:19:02] <deep42thought> a "any" one, I think
[16:19:23] <deep42thought> gtk-doc-1.29-1.0-any.pkg.tar.xz
[16:19:24] <deep42thought> yep
[16:19:34] <abaumann> that's something I noted: there are 'any' packages which where built, but then when installing, they have unfullfilled dependencies..
[16:19:44] <deep42thought> yes
[16:19:51] <deep42thought> this can happen in [staging]
[16:20:00] <abaumann> for instance: shadow: warning: cannot resolve "rarian", a dependency of "gnome-doc-utils"
[16:20:09] <deep42thought> because they're moved to staging on all architectures even if they were built on i686
[16:20:16] <abaumann> ah
[16:20:50] <deep42thought> we could introduce a [backstage] which is _not_ used on build slaves, but it would make things even messier
[16:21:10] <abaumann> backstage packages. lol.
[16:21:48] <abaumann> I'll remove all gtk-doc patching on i486..
[16:21:54] <deep42thought> ok
[16:25:18] -!- rcf has quit [Ping timeout: 268 seconds]
[16:26:49] <deep42thought> abaumann: when/how should we start removing obsolete packages from your bootstrap mirror?
[16:27:14] <abaumann> yes, confirmed. glib2 with libxslt in makepends works, so it was gtk-doc drawing in libxslt
[16:27:17] <abaumann> oeh...
[16:27:39] <abaumann> ..do we have to remove them?
[16:27:51] <deep42thought> no, not really
[16:27:53] <abaumann> I thought, if a package exists in the other repos, it overwrites the bootstrap one.
[16:28:38] <deep42thought> I just thought, we might want to clean things up at some point
[16:28:57] <abaumann> as this is my mirror (and in double), let me draft a script. :-)
[16:29:11] <deep42thought> there is already a script to find duplicates
[16:29:13] <deep42thought> in devops
[16:29:29] <abaumann> ah. this might come in handy. :-)
[16:31:13] <abaumann> meson test -t2 sounds like two threads, right?
[16:31:34] <deep42thought> or test of type 2
[16:31:37] <deep42thought> ;-)
[16:31:41] <abaumann> mmh..
[16:33:30] <deep42thought> looks like xorg-server built successfully
[16:33:46] <abaumann> hurray :-)
[16:33:48] <deep42thought> now it just needs to fetch a free upload-slot at the build master :-D
[16:34:03] <deep42thought> I have to go
[16:34:10] <deep42thought> cu
[16:34:12] <abaumann> ok. I check in the gtk-doc changes now.
[16:34:13] <abaumann> cu.
[16:34:17] -!- deep42thought has quit [Quit: Leaving.]
[16:50:47] -!- isacdaavid has joined #archlinux32
[17:06:06] thePiGre1per is now known as thePiGrepper
[17:09:42] <thePiGrepper> abaumann: hi, I have a question regarding package testing, do you have one min?
[17:11:40] <abaumann> hi thePiGrepper.
[17:11:47] <abaumann> yes. sorry. was still answering the forum..
[17:11:51] <abaumann> ..now I'm here. :-)
[17:12:13] -!- jarshvor has quit [Quit: leaving]
[17:12:42] <abaumann> There is a topic on testing at https://bbs.archlinux32.org
[17:12:43] <phrik> Title:automatic testing via manual installation(s) / Testing / Arch Linux 32 Forums (at bbs.archlinux32.org)
[17:13:02] <abaumann> What we would need from you is a gpg key, so you can be identified as trusted tester.
[17:13:09] <thePiGrepper> dont worry. look, I already added my gpg, and all that.
[17:13:16] <abaumann> ah. cool.
[17:14:02] <abaumann> so, what's you question?
[17:14:05] <abaumann> *your
[17:14:38] <thePiGrepper> yeah, my question was regarding the actual testing. after installing some packages in testing, I've run report-installed-packages... and the server successfully marked them as being tested
[17:14:52] <thePiGrepper> that's ok I guess, my question was regarding the next step
[17:15:15] <abaumann> well. you get absolutely no feedback and the buildmaster marks the package as tested in the database.
[17:15:16] <thePiGrepper> what do I need to do if I find something not working, and otherwise
[17:15:35] <thePiGrepper> right, I saw that at the log, that's fine
[17:15:35] <abaumann> ah. you can write a bug report, or post it in the forum or directly here.
[17:16:06] <thePiGrepper> I see. so the report-installed-packages is basically just a counting system
[17:16:12] <abaumann> exactly
[17:16:36] <thePiGrepper> so that, if after a certain amount of time, and being the count !=0, it can be said that the package has been tested, right?
[17:16:43] <abaumann> and you we get nice graphs about the status of the builds at https://buildmaster.archlinux32.org
[17:16:46] <phrik> Title:Buildmaster for Archlinux32 packages (at buildmaster.archlinux32.org)
[17:16:55] <abaumann> yep. that's the idea.
[17:17:17] <abaumann> the problem of course is, that not everything can be tested and sometimes we have to move packages from testing to stable in the brutal way.
[17:17:35] <abaumann> especially if some dependency slipped through unnoticed.
[17:17:58] <thePiGrepper> hehe, yeah, deep42thought told me about that
[17:18:15] <abaumann> well. nothing is perfect (yet).
[17:18:30] <thePiGrepper> I think that's understood then. now, I might have another question
[17:18:37] <abaumann> shoot. :-)
[17:18:38] <thePiGrepper> regarding building packages in general
[17:19:04] <thePiGrepper> I dont know how many ppl actually are doing this job and fixing things in the repo
[17:19:17] <thePiGrepper> but by the irc activity
[17:19:22] <abaumann> :-)
[17:19:23] <thePiGrepper> I think its mainly you and him right?
[17:19:49] <abaumann> yes. but we also get hints from upstream (elibrokeit) or from people in the forums.
[17:19:56] <thePiGrepper> deep42thought explained to me how the 'merge' system works
[17:20:19] <thePiGrepper> so now that I cloned the repo, I actually understand how you do the porting
[17:21:30] <abaumann> ..and I almost forgot: there is Debian, Fedora, Gentoo mainly which also have i686 branches, so patches go all ways..
[17:21:33] <thePiGrepper> but that brought up some questions regarding this process. for example, this build slaves are installed by each of you locally or there's like a public one and you send the job to it?
[17:21:52] <abaumann> there is a buildmaster sitting on a VM.
[17:22:24] <abaumann> then we have slaves distributed all around the world.
[17:22:51] <abaumann> the slaves have a build script (basically build-pakckages in the 'builder' repo) which talks to the buildmaster and asks for jobs to do.
[17:23:00] <thePiGrepper> also, there are this kind of messages that appear sometimes in the irc
[17:23:02] <thePiGrepper> buildmaster> i686/kde-cli-tools is broken (says buildknecht2).
[17:23:06] <abaumann> the buildmaster keeps track, sends out the jobs, collects back the results, and so on.
[17:23:31] <abaumann> there is a chat robot called 'buildmaster', it is a script sitting on the buildmaster.
[17:23:38] <abaumann> the buildmaster can write stuff this way.
[17:24:03] <thePiGrepper> I see, and that name after 'says' is the person who sent the job?
[17:24:26] <abaumann> it's the name of the slave, see https://packages.archlinux32.org
[17:24:28] <phrik> Title:Arch Linux 32 - List of Build Slaves (at packages.archlinux32.org)
[17:24:39] <abaumann> there you see the names, the operators and what they are doing.
[17:24:51] <abaumann> so, if things break or get stuck we know who to contact..
[17:25:25] <abaumann> mind you, that operator != donator of the resource
[17:25:58] <abaumann> I should mention tyzoid doing the admin work providing services and vms.
[17:26:38] <abaumann> there are people doing ISOs, torrent seeding, forum work (thanks levi) and now..
[17:26:50] <abaumann> .. everybody I forgot to mention, gets angry ;-)
[17:27:08] <thePiGrepper> what's the 'builder' repo?
[17:27:28] <abaumann> the git repository containg the shell scripts implementing the 'master' and the 'slave'
[17:27:33] <abaumann> *containing
[17:28:04] <thePiGrepper> so the buildmaster is the one who actually distributes the jobs, and avoid redoing the same job, right?
[17:28:05] <abaumann> https://git.archlinux32.org
[17:28:06] <phrik> Title:archlinux32/builder: Tools for building 32-bit archlinux packages from archlinux.org's official, 64-bit tested PKGBUILDs et al. - Archlinux32 Gitea (at git.archlinux32.org)
[17:28:12] <abaumann> exactly.
[17:29:52] <abaumann> see also the forum, there are some nice explanations there: https://bbs.archlinux32.org
[17:29:53] <phrik> Title:build system / Building / Arch Linux 32 Forums (at bbs.archlinux32.org)
[17:37:47] <thePiGrepper> I see. I think I understand most of it. the package starts being build at one of the slaves, sent by the master, and when(if) it succeeds, it goes to the staging repo, then it goes to the testing repos, and after a while it goes to the actual 'normal' repos.
[17:37:51] <thePiGrepper> right?
[17:38:05] <abaumann> yep. :-)
[17:38:16] <thePiGrepper> then, when or by which criteria the package goes from staging to testing?
[17:38:50] <abaumann> buildmaster: why don't you stabilize glib2
[17:40:21] <abaumann> I thought it's staging to testing after some time, from testing to stable if tested and after some time and if dependencies are fullfilled. roughly. deep42thought can tell you exactly how.
[17:40:35] <abaumann> I'm more on the PKGBUILD package fixing side than on the build system side :-)
[17:41:01] <abaumann> buildmaster: why don't you talk to me?
[17:41:18] <thePiGrepper> I see. that's probably the case
[17:41:56] <buildmaster> abaumann: glib2 cannot be moved:
[17:41:57] <buildmaster> (and) i686/testing/glib2-2.58.1-1.0-i686.pkg.tar.xz 0 --> zlib 0
[17:41:57] <buildmaster> (and) i686/testing/glib2-2.58.1-1.0-i686.pkg.tar.xz 0 --> libffi 0
[17:41:57] <buildmaster> (and) i686/testing/glib2-2.58.1-1.0-i686.pkg.tar.xz 0 --> libz.so.1 0
[17:41:57] <buildmaster> (and) i686/testing/glib2-2.58.1-1.0-i686.pkg.tar.xz 0 --> libelf.so.1 0
[17:42:06] <abaumann> aha.
[17:42:09] <thePiGrepper> one more question. why are you talking to the bot? is it a bot? wasnt?(I might be getting confused, if it's an actual person, sorry ;) )
[17:42:22] <thePiGrepper> ok, it's not. good
[17:42:35] <abaumann> buildmaster: are you a bot?
[17:43:12] <abaumann> have a look at ii-connect, it's a chat bot you can ask questions about the status of packages.
[17:43:23] <abaumann> and sometimes it even makes funny remarks. :-)
[17:43:49] <abaumann> actually, all ii-* scripts
[17:44:46] <abaumann> buildmaster: What's up?
[17:44:47] <buildmaster> up? I'm up for 5 days, 9 hours, 8 minutes, load average: 2.90, 3.10, 2.78
[17:45:06] * buildmaster goes insane.
[17:45:26] <thePiGrepper> haha, I see what you mean
[17:45:48] <abaumann> and insanity means: the buildmaster is in a troubled state and cannot do it's work.
[17:45:55] <abaumann> so, this means fixing :-)
[17:46:23] <thePiGrepper> does it have some useful questions for debugging packaging? is there a manual for that? or a git repo?
[17:46:40] <abaumann> it's a big switch in ii-answer
[17:46:49] <abaumann> no docu I'm aware of.
[17:47:15] <thePiGrepper> that's the irc client in the arch32 repositories right?
[17:47:34] <abaumann> yes. in 'builder'
[17:47:39] <thePiGrepper> logbot?
[17:48:39] <thePiGrepper> nope, sorry
[17:48:40] <abaumann> https://git.archlinux32.org
[17:48:42] <phrik> Title:archlinux32/builder: Tools for building 32-bit archlinux packages from archlinux.org's official, 64-bit tested PKGBUILDs et al. - Archlinux32 Gitea (at git.archlinux32.org)
[17:48:48] <thePiGrepper> I was looking at the wrong repo. right
[17:49:07] <thePiGrepper> I just saw the ii dependency of master
[17:50:56] <abaumann> deep42thought: that might have been me: "CALL `find_the_culprit`(138332);"
[17:51:03] <abaumann> >> Ctrl-C -- query killed. Continuing normally.
[17:51:03] <abaumann> >> Ctrl-C -- query killed. Continuing normally.
[17:51:03] <abaumann> >> Ctrl-C -- exit!
[17:59:55] <thePiGrepper> well, I think I understand the basics of it at least, I'd like to ask though, how do you troubleshoot when some build fails? like, do you access the slave itself to test something, what's your workflow? and who tells the buildmaster what to build and how? (sorry for all these questions..)
[18:08:02] -!- noctambulo has joined #archlinux32
[18:13:33] <abaumann> You can arch-chroot into the build chroot on the slave (the modified Archlinux build scripts) and debug in this virtual enviroment. That's what I am usually doing. We can also tell the buildmaster to build certain packages on certain slaves forcefully or we can play with the priority in which packages are being built.
[18:13:47] <abaumann> there is no problem asking questions. :-)
[18:14:54] <abaumann> you can also have a virtual machine, asp export <package>, attach the PKGBUILD snippet from Archlinux32 and do a local build.
[18:16:30] -!- noctambulo has quit [Remote host closed the connection]
[18:16:50] -!- noctambulo has joined #archlinux32
[18:18:13] <thePiGrepper> ofc, that last one is the one I usually use when some package doesnt work on my system, ie xorg-server. It's either this or arch-chroot into an arch32 base system.
[18:21:13] <thePiGrepper> if you force the buildmaster into building a specific package with a specific slave, the slave will pick the PKGBUILD currently having issues right? the one 'merged' from the packages repo and the upstream one. if you'd like the buildmaster to build a modified PKGBUILD, just for testing, you couldnt do that, right?
[18:21:44] <abaumann> yes, correct.
[18:22:14] <abaumann> I have a test script in a local branch which is not talking to the buildmaster, also build-packages as a local build mode.
[18:22:21] <abaumann> this emulates more or less a test build.
[18:22:44] <abaumann> so you can run it locally without checking in first your package changes.
[18:30:07] -!- woshty has joined #archlinux32
[18:30:34] <thePiGrepper> hm, when you say that it emulates more or less a test build, you mean that what you do is create a local branch in the 'merge' repo(I dont know the used name for this one, the one with the appended lines) and just make your modifications there? after that, do you just run makepkg and test if it works locally? that's basically the same as running asp,modifying the PKGBUILD and runnning makepkg,
[18:30:40] <thePiGrepper> isnt it?
[18:31:00] <thePiGrepper> or you are doing this *in the slave*?
[18:32:09] <abaumann> you don't run makepkg, but staging-i686-build, staging-i484-build, which is the same the slaves are doing. You can also do makepkg directly (in order to angry elibrokeit) and run into errors, because your host enviroment leaks into the build environment.
[18:33:14] <abaumann> I can only debug something on the slave which are under my control, otherwise I have to force the build to that slave or just do it locally on a test machine.
[18:38:27] <thePiGrepper> staging-i*86-build is a command/script? where is it?
[18:39:26] <abaumann> https://git.archlinux32.org
[18:39:27] <phrik> Title:archlinux32/devtools32: Fork of devtools from archlinux.org with small modifications to compile i486 and i686 from our repositories - Archlinux32 Gitea (at git.archlinux32.org)
[18:40:46] <abaumann> They get generated and installed with make.
[18:52:50] -!- slacka123 has quit [Remote host closed the connection]
[18:53:32] -!- slacka123 has joined #archlinux32
[19:10:34] -!- abaumann has quit [Quit: leaving]
[19:14:53] -!- noctambulo has quit [Remote host closed the connection]
[19:15:34] -!- AndrevS has joined #archlinux32
[20:13:53] -!- abaumann has joined #archlinux32
[20:13:54] <buildmaster> Hi abaumann!
[20:13:54] <buildmaster> !rq abaumann
[20:13:55] <phrik> buildmaster: <abaumann> very soon only a machine learning algorithm will be able to devise a build plan for a Linux distribution..
[20:18:24] <abaumann> This remark definitely applies for rust cross-compilation. :->
[20:18:25] -!- abaumann has quit [Quit: leaving]
[21:02:56] -!- noctambulo has joined #archlinux32
[21:26:08] -!- AndrevS has quit [Quit: umount /dev/irc]
[21:36:15] -!- noctambulo has quit [Ping timeout: 252 seconds]
[22:08:37] -!- isacdaavid has quit [Ping timeout: 250 seconds]
[23:02:27] -!- deep42thought has joined #archlinux32
[23:02:28] <buildmaster> Hi deep42thought!
[23:02:28] <buildmaster> !rq deep42thought
[23:02:28] <phrik> buildmaster: <deep42thought> my cluster of 1k 4/86's will be happy to iterate Maxwell-Vlasov-equations :-D
[23:03:53] <deep42thought> thePiGrepper: packages are moved as soon as possible. For staging -> testing the criteria are, that it can be installed in testing (e.g. does not depend on something which is still in staging) and that all other packages in testing stay installable (e.g. it does not replace a dependency of another package which stays in testing)
[23:04:27] <deep42thought> for testing->stable, the same applies, but additionally, the package must be marked as "tested" or have been at least 7 days in testing
[23:05:10] <deep42thought> abaumann: the why-don't-you stuff is still broken - I didn't have time and muse to fix it, sry :-/
[23:07:36] <thePiGrepper> deep42thought: I see, so the only restriction is that it doesnt break something in testing or itself by being moved.
[23:07:46] <deep42thought> exactly
[23:08:17] <deep42thought> but this is quite tricky, because upstream archlinux does not track _all_ dependencies in the package meta data
[23:08:33] <deep42thought> so we need to add some "virtual" dependencies - and sometimes, we miss some
[23:08:53] <thePiGrepper> deep42thought: I see, Ive been reading some of those lately here, is for example that systemd one such a case?
[23:09:43] <deep42thought> I don't know, what you refer to.
[23:10:01] <thePiGrepper> I think not, because the latest from upstream did have it as a dependency, but I get what you mean. sometimes you run ldd and it contains some additional dependency not stated in the PKGBUILD. is that what you mean?
[23:10:14] <deep42thought> yes
[23:10:29] <deep42thought> we do not add this to the package either, but we track it in the database
[23:10:48] <deep42thought> https://packages.archlinux32.org
[23:10:49] <phrik> Title:Arch Linux 32 - systemd 239.2-1.0 (i686) (at packages.archlinux32.org)
[23:10:54] <deep42thought> have a look at the "link" dependencies
[23:11:11] <deep42thought> these are dependencies which we added after building and inspecting the package
[23:11:58] * deep42thought spotted some redundancy in the output of this website ... hrmmm
[23:13:42] <deep42thought> regarding troubleshooting: I usually use staging-i686-build on one of my boxes directly (not in a vm) or I use the arch32-test vagrant image provided by tyzoid if I need to take a deeper look
[23:13:44] <thePiGrepper> I never realized that this page has a complete 'required by' field. very useful. is there a way to do this in pacman without having to install all the packages?
[23:14:11] <deep42thought> pacman shows which _installed_ packages require the given package
[23:14:23] <deep42thought> but I don't know of any feature which shows _all_ packages depending on it
[23:14:44] <thePiGrepper> right, that's why I found this quite surprising
[23:14:49] <deep42thought> but OTOH I'm not a pacman expert, maybe the manpage knows more :-)
[23:15:55] <thePiGrepper> back to the link dependencies, did you(archlinux32) add _all_ of those, or some of those come from upstream?
[23:16:20] <deep42thought> we added all of them
[23:16:34] <deep42thought> some / most of them might be given as depends already
[23:16:36] <deep42thought> though
[23:16:46] <thePiGrepper> deep42thought: all this comes from a database right? but that's a different database than the pacman one.
[23:16:54] <deep42thought> yes
[23:17:05] <deep42thought> (to both questions)
[23:18:11] <thePiGrepper> the 'redundancy' you referred to before was related to having a link dependency _and_ a package dependency which includes that same link dependency, right?
[23:18:21] <deep42thought> no
[23:18:39] <deep42thought> it referred to multiple links to identical packages under "link" dependencies
[23:18:40] <thePiGrepper> oh, an actual repeated line then?
[23:18:48] <thePiGrepper> I see
[23:19:01] <deep42thought> check out the libaudit line in the systemd pkginfo I linked
[23:19:38] <thePiGrepper> yeah,I just did, there are more than a few like that
[23:19:58] <deep42thought> yes, probably some missing "distinct" in a mysql query somewhere :-/
[23:23:57] <thePiGrepper> deep42thought: I see. regarding troubleshooting, a couple questions. what's the purpose exactly of staging-i686-build, is it mainly a makepkg with environment flags included? or is something more complex than that? sadly there's not a manual for that package..
[23:24:48] <deep42thought> it sets up a systemd-nspawn container in which the packages are then built (with "setarch i686")
[23:24:58] <deep42thought> it's a clone of upstream's devtools
[23:25:06] <deep42thought> which had it until they dropped i686 support
[23:25:30] <deep42thought> staging-i486-build is similar, but uses different mirrors and compiler options
[23:27:11] <thePiGrepper> deep42thought: the other question is basically, if I wanted to help with the build process (patching PKGBUILDs and the like) , how could I help with that? abaumann told me about the way the buildmaster and the slaves work, and how each slave has an operator, ofc I could still help by doing the work locally and sending a patch. I dont know if I would have a way to send a command to the
[23:27:17] <thePiGrepper> buildmaster though.(many questions here, sorry...)
[23:28:16] <deep42thought> you can help even if (or better: independently of wether) you don't run a build slave
[23:28:20] <deep42thought> https://packages.archlinux32.org
[23:28:21] <phrik> Title:Arch Linux 32 - List of Package Builds (at packages.archlinux32.org)
[23:28:27] <deep42thought> there is the list of currently failing builds
[23:29:02] <deep42thought> in the "Failures" column, there is linked the latest log for each package and failure type
[23:29:23] <deep42thought> (ignore the i486 packages for now - they fail mostly due to uninstallable dependencies)
[23:29:36] <deep42thought> you can filter on top
[23:29:41] <deep42thought> https://packages.archlinux32.org
[23:29:42] <phrik> Title:Arch Linux 32 - List of Package Builds (at packages.archlinux32.org)
[23:30:23] <deep42thought> and if you see a package which you like / know, you can check out the log of the failing build (it's gzipped) and see if you find the cause of it
[23:30:26] <deep42thought> (locally)
[23:30:49] <thePiGrepper> 'it sets up a systemd-nspawn container(...)' I see, that makes sense, and all those .conf files enable different environments.
[23:30:59] <deep42thought> depending on the cause, you can then either report to upstream (archlinux) or try to provide a patch for our package modification repository
[23:31:42] <deep42thought> devtools32 is really just a fork of https://git.archlinux.org - maybe you find some useful documentation there
[23:31:43] <phrik> Title:devtools.git - The official devtools repository (at git.archlinux.org)
[23:32:01] * buildmaster resumes sanity.
[23:32:11] <deep42thought> buildmaster: that was about time ...
[23:37:32] <thePiGrepper> I'll take a look later, maybe there's some documentation after all. for now at least, I think I understand how staging-i686-build works.
[23:38:03] <deep42thought> then you understand more than I - I just try to abuse it for our case ;-)
[23:38:48] -!- rcf has joined #archlinux32
[23:39:09] <thePiGrepper> deep42thought: one the main things I wanted to know was where was the list of broken packages, so Im close to clear my main questions hehe
[23:39:30] <deep42thought> :-)
[23:40:31] <thePiGrepper> deep42thought: that list contains a lot of fields though, can you explain some of them?
[23:40:44] <deep42thought> sure
[23:40:51] <thePiGrepper> deep42thought: priority and deps for instance
[23:41:10] <deep42thought> we can increase the priority of packages so they will get handed out before other packages
[23:41:26] <deep42thought> deps is the number of _pending_ dependencies
[23:41:57] <deep42thought> arch,package,git revision, mod. git revision,repository should be clear
[23:42:06] <thePiGrepper> 'handed out' == processed by the buildmaster/fetched to the slaves?
[23:42:07] <deep42thought> commit time is the source commit time (from upstream)
[23:42:41] <deep42thought> by "hand out" I mean give an assignment to a build slave (by the build master)
[23:42:56] <thePiGrepper> _pending_ dependencies for ...? building the package?
[23:43:21] <deep42thought> yes
[23:43:27] <thePiGrepper> ok, I think I get the priority part then.
[23:43:29] <deep42thought> run-dependencies must be built before the package
[23:43:52] <deep42thought> and makedependencies must be available in _any_ version (e.g. not necessarily the newest one)
[23:44:14] <deep42thought> we don't care about checkdependencies (this creates too many cycles)
[23:44:29] <thePiGrepper> I see for example that there are _more than one line_ per package sometimes, this is because the list identifies builds, not packages right?
[23:44:29] <deep42thought> and "link" dependencies are added after the package was built, so we don't care about them either
[23:44:41] <deep42thought> yes
[23:44:58] <deep42thought> it should be maximally two lines: one for i686 and one for i486
[23:46:07] <thePiGrepper> one question, inside the nspawn 'container', all the requirements are built as well, or anything besides the package is only downloaded from stable repos?
[23:46:23] <thePiGrepper> probably the latter
[23:46:29] <deep42thought> almost
[23:46:39] <deep42thought> it's downloaded/installed from stable+testing+staging
[23:46:51] <thePiGrepper> giving priority to which?
[23:46:57] <deep42thought> staging
[23:47:17] <deep42thought> staging > community-staging > testing > community-testing > core > extra > community
[23:48:32] <thePiGrepper> I see, if for example the PKGBUILD requires dbus>1.12.10 and it doesnt exist in staging yet, what happens?
[23:48:49] <deep42thought> the buildmaster won't hand it out
[23:49:00] <deep42thought> at least not, if dbus is also scheduled
[23:49:41] <thePiGrepper> I see, that queue of build requests is visible as well?
[23:49:56] <deep42thought> yeah, if you remove the "broken" filter
[23:50:17] <thePiGrepper> ohh, haha, right..
[23:55:30] -!- prstoetzer has joined #archlinux32
[23:55:37] <deep42thought> so, it's late here, I'll go to bed
[23:55:41] <deep42thought> good night!
[23:56:05] <thePiGrepper> deep42thought: ok, thanks for everything.
[23:56:19] <deep42thought> np, I like explaining ;-)
[23:56:21] -!- noctambulo has joined #archlinux32
[23:56:34] -!- deep42thought has quit [Quit: Leaving.]