#archlinux32 | Logs for 2018-08-26

[00:10:06] -!- MrBIOS has quit [Quit: MrBIOS]
[00:42:22] -!- MrBIOS has joined #archlinux32
[00:45:13] -!- MrBIOS has quit [Client Quit]
[00:45:26] -!- MrBIOS has joined #archlinux32
[00:46:09] -!- MrBIOS has quit [Client Quit]
[00:46:22] -!- MrBIOS has joined #archlinux32
[00:51:50] -!- eduardoeae_ has quit [Ping timeout: 272 seconds]
[00:53:16] -!- eduardoeae_ has joined #archlinux32
[01:00:26] -!- eduardoeae__ has joined #archlinux32
[01:02:45] -!- eduardoeae_ has quit [Ping timeout: 244 seconds]
[01:47:53] -!- MrBIOS has quit [Quit: MrBIOS]
[02:20:05] -!- rcf has joined #archlinux32
[03:14:56] -!- davascript has quit [Remote host closed the connection]
[07:16:02] <girls> davascript: what do you mean by "mask"? You can simply edit the PKGBUILD and build it yourself
[07:16:50] <girls> abaumann: if db-update takes long to run (it really takes long and produces much load on the database), this simply means, many packages may be moved, but probably won't be moved due to dependencies
[07:21:51] <girls> abaumann: if you want to trigger db-update either start db-uppdate.service or start db-update itself manually
[07:22:18] <girls> but I can tell you what takes so long: `calculate_maximal_moveable_set` is quite complex and needs much time
[07:46:01] -!- abaumann has joined #archlinux32
[07:46:01] <buildmaster> Hi abaumann!
[07:46:25] <girls> hi abaumann
[07:46:39] <abaumann> davascript: the AUR is architecture agnostic, just because the arch states 64-bit this doesn't mean the package doesn't build on i686 or ARM.
[07:47:16] <abaumann> just change arch=(i686) and see if the package builds and runs.
[07:48:14] <abaumann> mmh. perl-date-manip builds since 13 days: https://packages.archlinux32.org
[07:49:44] <girls> probably stuck
[07:49:53] <abaumann> hi. yeah. :-)
[07:58:57] <girls> it hangs during check()
[07:59:04] <girls> I'll skip it ...
[08:02:16] <girls> abaumann: also the replacing is correct "0" means, it prioritized zero packages
[08:02:40] <girls> usually, I run 'prioritize-build-list <(echo 'regex')
[08:02:44] <girls> '
[08:03:38] <abaumann> ok.
[08:04:13] <abaumann> my current problem is mysqld eating up all CPU resources doing more or less nothing.
[08:04:29] <girls> db-update needs much resources
[08:04:32] <girls> from mysqld
[08:04:59] <abaumann> it looks like it blocks more or less all other operations..
[08:05:25] <girls> it does :-(
[08:05:58] <girls> I'll try to force-move all the python packages which replace python3.6 packages, maybe this solves some problems
[08:06:06] <abaumann> good idea.
[08:06:16] <abaumann> I tried to move gdb and gdb-common, but it didn't work
[08:06:59] <girls> you need to specify binary_packages_in_repositories.id
[08:07:02] <girls> did you do that?
[08:07:09] <girls> e.g. db-update -f 12345
[08:07:41] <abaumann> ah, I uesd modify-package-state, that's the mistake. :-)
[08:07:54] <girls> well, this only sets the "is_tested" bit
[08:08:04] <girls> then the move will be done automatically by db-update
[08:08:14] <girls> iff it can be moved (dependencies, etc.)
[08:08:16] <abaumann> ah. and db-update didn't get there.
[08:08:21] <girls> probably
[08:08:26] <girls> or some dependency blocked it
[08:08:40] <abaumann> I hade two sanity checks which reported running queries from db-update
[08:08:44] <abaumann> *had
[08:09:09] <girls> ususally, the check should be blocked if the queries are running
[08:09:32] <girls> but sometimes the files are still seen by the check running _after_ the query
[08:09:39] <abaumann> that's what I meant with the flocking system. without a fifo with a priority queue this is hard to achieve.
[08:10:04] <girls> hmm? where do you suggest a fifo?
[08:10:19] <girls> you mean a fifo of planned tasks?
[08:10:22] <abaumann> -w, flock. at the moment the first just wins.
[08:10:34] <abaumann> more a fifo of PIDs, roles of processes waiting.
[08:10:41] <abaumann> otherwise you risk starvation on the lock
[08:10:56] <girls> good point
[08:11:09] <girls> I'll think about it, shouldn't be too hard to implement
[08:12:22] <girls> my current thought was that more important and/or simpler tasks are scheduled more often and thus have higher probability of getting the lock
[08:12:35] <abaumann> that's actually correct
[08:12:43] <girls> and -w is only a manual switch saying "i don't have the time to wait for my luck"
[08:12:50] <abaumann> only if the runtime behaviour of a job changes, you could get into trouble
[08:13:12] <abaumann> well.. this means, maybe we should search for root causes instead?
[08:13:23] <abaumann> like: why are certain queries so slow?
[08:13:25] <girls> probably the locks are too restrictive
[08:13:31] <girls> that, too
[08:13:55] <girls> calculate_maximal_moveable_set is slow as hell, but I can't think of a way to implement the complex task faster
[08:14:13] <abaumann> classic approach then.. add more resources to the problem :-)
[08:14:32] <girls> !grab abaumann
[08:14:32] <phrik> girls: Tada!
[08:14:55] <girls> we could split some locks, I think
[08:15:01] <abaumann> https://hackthology.com
[08:15:03] <phrik> Title:A Job Queue in BASH (at hackthology.com)
[08:15:06] <girls> some tasks do not really need to lock out all others
[08:15:24] <abaumann> the blocking is not so bad, especially being low on resources.
[08:16:35] <girls> hmm, ok
[08:16:40] <girls> anyway: breakfast!
[08:16:47] <abaumann> enjoy! :-)
[08:30:22] -!- abaumann has quit [Quit: leaving]
[09:31:02] -!- abaumann has joined #archlinux32
[09:31:02] <buildmaster> Hi abaumann!
[09:31:12] <abaumann> buildmaster: why don't you stabilize gdb-common
[09:31:19] <abaumann> buildmaster: why don't you stabilize gdb
[09:32:45] <buildmaster> graphviz is broken (says buildknecht).
[09:32:54] <buildmaster> abaumann: I cannot decide whether gdb-common can be moved or not.
[09:34:11] * buildmaster failed to execute a mysql query - can you have a look at "tmp.mysql-functions.query.stdin.2018-08-26T09:32:59.2TSuPv"?.
[09:34:11] <buildmaster> abaumann: I could not complete a mysql query!
[09:34:14] <abaumann> buildmaster: make up your mind. :-)
[09:34:55] <abaumann> mmh. tmp.mysql-functions.query.stdin.2018-08-26T09:32:59.2TSuPv looks like a query on a graph :-)
[09:36:49] <abaumann> ah a failed db-update
[09:49:06] <abaumann> rsync: write failed on "/tmp/tmp.sanity-check.wFaMbfYV6A/community.db.tar.gz": No space left on device (28)
[09:55:17] * buildmaster resumes sanity.
[09:59:16] <abaumann> db-update -w -f 66989 -f 92340
[09:59:16] <abaumann> Nothing to move here (2).
[09:59:16] <abaumann> Nothing to move here (3).
[09:59:20] <abaumann> mmh. *puzzle*
[10:03:10] -!- dopsi has quit [Quit: ZNC - https://znc.in]
[10:05:50] -!- dopsi has joined #archlinux32
[10:09:20] <buildmaster> gcr is broken (says rechenknecht).
[10:22:20] <abaumann> so. gdb and gdb-common hopped into stable, this ends the python3.6 problem there..
[10:22:59] <abaumann> now, I'm trying to force rebuilds of things like imagemagick, blocking upgrades after perl upgrade to 5.28
[10:28:04] <buildmaster> skk-jisyo is broken (says buildknecht).
[10:39:36] <buildmaster> hugin is broken (says buildknecht2).
[10:42:16] <buildmaster> weston is broken (says buildknecht).
[11:07:51] -!- eduardoeae has quit [Ping timeout: 268 seconds]
[12:16:48] <buildmaster> avogadrolibs is broken (says rechenknecht).
[12:50:24] <buildmaster> virtualbox-modules-arch is broken (says rechenknecht).
[12:52:44] -!- eduardoeae has joined #archlinux32
[13:04:28] -!- abaumann has quit [Quit: leaving]
[13:09:32] <buildmaster> giac is broken (says eurobuild3).
[13:32:10] <buildmaster> meson is broken (says rechenknecht).
[14:04:02] <buildmaster> qt5-base is broken (says rechenknecht).
[16:07:29] <buildmaster> qt5-declarative is broken (says rechenknecht).
[19:36:01] -!- eduardoeae__ has quit [Quit: eduardoeae__]
[19:37:35] -!- eduardoeae_ has joined #archlinux32
[19:37:48] -!- abaumann has joined #archlinux32
[19:37:49] <buildmaster> Hi abaumann!
[19:38:17] <abaumann> so, llvm rebuild needs ocaml, ocaml is broken in the middle (again, because of the lto/gold/bintuils/llvm linking bug)
[19:38:38] <abaumann> I'm trying to break the knot by building a non-ocaml llvm and adding it to the build-support.
[19:39:06] <abaumann> this is no most dangerous bug currently: linking failing because of LTO instrumentation.
[19:39:46] <abaumann> on a personal note: it might not be a very clever idea to join the two toolchains llvm and binutils and end in feature creep..
[19:45:34] <abaumann> So, llvm cannot be rebuilt because of : CommandLine Error: Option 'asm-instrumentation' registered more than once!
[19:45:54] <abaumann> Now comes the final straw: remove LLVM/gold/LTO support from binutils.
[19:46:40] <abaumann> ...and disable all plugins.. while being at it.
[19:53:06] <abaumann> libiberty: : CommandLine Error: Option 'asm-instrumentation' registered more than once!
[19:53:24] <abaumann> nice. so, now we have to dowgrade the toolchain and build us a new one..
[19:53:46] <elibrokeit> https://bugs.archlinux.org
[19:53:47] <phrik> Title:FS#59631 : [binutils] CommandLine Error: Option 'asm-instrumentation' registered more than once! (at bugs.archlinux.org)
[19:54:36] <abaumann> yep, have seen that.
[19:55:03] <abaumann> the problem is, that I cannot link anything currently, so I have to downgrade at least binutils..
[19:55:39] <abaumann> all this LLVM stuff is just there for LTO linking and some programmer instrumentation tools, I suppose.
[19:56:12] <abaumann> using LLVM to instrument libraries, isn't that what libbfd is for?
[20:01:15] <elibrokeit> Muh alternative impl
[20:01:43] <elibrokeit> You cannot even build llvm without an existing llvm install?
[20:02:16] <abaumann> when I build llvm it uses ar to link a library, that's when the broken LLVM plugin kicks in. :-)
[20:02:45] <abaumann> so, my plan is now to go back to an unbroken bintutils, build me a new version of LLVM (whith the bug fixed) and adding that one to the build-support.
[20:02:56] <elibrokeit> Why is llvm installed in the build chroot
[20:03:17] <elibrokeit> We built it okay, apparently...
[20:03:30] <abaumann> good question..
[20:04:25] <abaumann> everthing using some graphical stuff, qt4/qt5. llvm is in there because of mesa/nvidia or so.
[20:04:38] <abaumann> that's why lower level packages build fine.
[20:04:46] <abaumann> this means, binutils and llvm should NOT have a llvm in them.
[20:05:09] <abaumann> maybe another mess on one of my build slaves.. let me rebuild it. :-)
[20:07:26] -!- Alina-malina has quit [Ping timeout: 268 seconds]
[20:20:59] * buildmaster goes insane.
[20:58:33] -!- abaumann has quit [Quit: Lost terminal]
[21:49:14] -!- Alina-malina has joined #archlinux32
[21:49:40] -!- eduardoeae has quit [Read error: Connection reset by peer]
[21:50:15] -!- eduardoeae has joined #archlinux32
[22:02:45] -!- eduardoeae has quit [Read error: Connection reset by peer]
[22:03:42] -!- eduardoeae has joined #archlinux32
[23:19:58] -!- minted has joined #archlinux32
[23:20:40] <minted> anyone know if the 32bit will continue to be supported long term???
[23:25:44] <bill-auger> minted: that is the one and only stated purpose of archlinux32
[23:27:03] <bill-auger> the archlinux32 project is only about one year old - it was created specifically to support archlinux on 32bit x86 for the long term
[23:27:37] <minted> bill-auger: yes...clearly... but WE all know how THAT has gone with distros in the past :-((
[23:27:55] <bill-auger> it has gone from wrch in the past - about a year ago
[23:29:02] <bill-auger> that is the bery reason archlinux32 was created
[23:29:46] <bill-auger> so if anything, what you are really asking is if this projecr intends to continue for the long term
[23:31:14] <minted> bill-auger: indeed... as recently manjaro openrc death was a 'betrayal' as they had said it was there for the 'long term'
[23:32:13] <minted> bill-auger: first they killed 32 >>> then ended the whole thing with artix the spinoff
[23:32:14] <bill-auger> it seems like you may be wondering if archlinux will drop 32bit support - but that already happened a year ago - this project is not archlinux - it is a separate project created for that one and only reason
[23:33:05] <minted> bill-auger: yes. before i commit to put it on some hardware
[23:33:16] <bill-auger> ok minted but manjaro and arch had other priorities in mind - this project has only one purpose - to contonue a 32biut archlinux OS
[23:33:50] <minted> bill-auger: are you one of the dev.s?
[23:34:53] <bill-auger> not exactly - i am one of the parabola devs - parabola inherits much of its 32bit packages from archlinux32
[23:35:37] <minted> ty for the info and the confirm
[23:35:57] <bill-auger> the ugly truth is that there promises are meaningless in any area where everyone is a volunteer
[23:36:20] <bill-auger> any opensource project that makes promises is full of crap
[23:36:46] <minted> bill-auger: indeed... does this channel stay pretty well populated?
[23:37:10] <bill-auger> when everyone is a volunteer , the only way to keep it going is to have people who want to help keep it going
[23:37:44] <minted> bill-auger: try not. DO or do not.
[23:37:49] <bill-auger> a nusiness like redhat or microsoft can make promises and their customers can sue them if they break their promises
[23:38:17] <bill-auger> but nothing like that is applicable to open source projects
[23:38:46] <bill-auger> yes, for now i would say that archlinux32 is quite healthy
[23:39:48] <minted> bill-auger: will go play with it most likely come back and check in ty
[23:39:56] -!- minted has parted #archlinux32
[23:50:06] -!- eduardoeae has quit [Ping timeout: 252 seconds]