#archlinux32 | Logs for 2019-05-03

Back
[00:02:05] -!- beano66 has quit [Remote host closed the connection]
[00:28:48] -!- samantaz_ has quit [Ping timeout: 245 seconds]
[01:00:53] <buildmaster> pentium4/radamsa is broken (says buildknecht).
[01:30:11] <buildmaster> pentium4/bchunk is broken (says nlopc43).
[01:47:19] <elibrokeit> Why is radamsa being built -- it is not touched in scn and x86_64 last built it in 2016. It doesn't currently build because the current list compiler no longer accepts that syntax...
[01:50:30] -!- yans has quit [Quit: chaos is the only true answer]
[02:18:28] -!- yans has joined #archlinux32
[02:33:00] <buildmaster> pentium4/lsof is broken (says rechenknecht).
[02:36:31] <buildmaster> pentium4/tcp-wrappers are broken (says rechenknecht).
[02:47:51] -!- isacdaavid has quit [Quit: Leaving.]
[02:48:05] -!- ubuntuxp has quit [Quit: ERC (IRC client for Emacs 26.2)]
[03:35:22] -!- guys has quit [Ping timeout: 258 seconds]
[03:36:16] <buildmaster> pentium4/dsniff is broken (says nlopc43).
[03:41:15] -!- guys has joined #archlinux32
[03:41:59] <buildmaster> pentium4/pdflib-lite is broken (says nlopc43).
[03:47:03] <buildmaster> pentium4/dmapi is broken (says nlopc43).
[03:54:05] <buildmaster> pentium4/nss_ldap is broken (says nlopc43).
[03:56:06] <buildmaster> pentium4/hardlink is broken (says buildknecht).
[03:58:44] -!- yans has quit [Quit: chaos is the only true answer]
[04:03:30] <buildmaster> pentium4/linux-atm is broken (says nlopc43).
[04:17:47] <buildmaster> pentium4/evemu is broken (says nlopc43).
[04:31:50] <buildmaster> pentium4/jxrlib is broken (says buildknecht).
[04:32:04] -!- yans has joined #archlinux32
[05:05:27] <buildmaster> pentium4/libbloom is broken (says nlopc43).
[05:19:22] <buildmaster> pentium4/python-kivy is broken (says rechenknecht).
[05:37:33] <buildmaster> pentium4/valgrind is broken (says rechenknecht).
[05:54:45] <buildmaster> pentium4/cmucl is broken (says rechenknecht).
[06:18:22] -!- deep42thought has joined #archlinux32
[06:18:22] <buildmaster> Hi deep42thought!
[06:18:22] <buildmaster> !rq deep42thought
[06:18:23] <phrik> buildmaster: <deep42thought> please don't go insane - I think I can't fix you like I can fix the buildmaster
[06:18:42] <deep42thought> elibrokeit: I rescheduled all packages that had broken dependencies - radamsa is most probably one of them
[06:19:06] <deep42thought> but considering what you said, I think, there is some flaw in the rescheduling logic and/or the recorded dependencies in the database ...
[06:19:38] <elibrokeit> I remember radamsa because it is outstanding on a TODO for rebuilding old packages with PIE
[06:28:32] -!- MrBIOS has joined #archlinux32
[06:51:25] -!- yans has quit [Ping timeout: 246 seconds]
[07:17:47] -!- deep42thought has quit [Quit: Leaving.]
[07:22:11] <buildmaster> pentium4/link-grammar is broken (says rechenknecht).
[07:45:12] -!- thePiGrepper has quit [Ping timeout: 252 seconds]
[08:12:34] -!- abaumann has joined #archlinux32
[08:12:34] <buildmaster> Hi abaumann!
[08:12:34] <buildmaster> !rq abaumann
[08:12:35] <phrik> buildmaster: <abaumann> wasn't I saying something lately about setarch being broken? ;-)
[08:13:45] -!- thePiGrepper has joined #archlinux32
[08:14:29] <abaumann> morning everybody.. including disasters.. :-)
[08:15:38] <abaumann> Updateing non-graphical servers seems to be fine ATM (my NAS is alive and kicking), but some desktop things seems broken around icu 63/64 and the miriads of ffmpeg dependencies..
[08:16:11] <abaumann> I see a pattern here: all libraries bumping major releases too fast (having instable ABIs) having build cycles cause major issues.
[08:16:45] <abaumann> assuming same dependencies and being able to device an automatic build order, seems to be a wrong assumption.
[08:18:12] -!- deep42thought has joined #archlinux32
[08:18:12] <buildmaster> Hi deep42thought!
[08:18:12] <buildmaster> !rq deep42thought
[08:18:12] <phrik> buildmaster: <deep42thought> ahm, what is actually in the package "vulkan-headers" on i486? I thought, we disabled all vulcans?
[08:18:37] <deep42thought> good morning
[08:18:45] <abaumann> hi deep42thought
[08:18:47] <deep42thought> abaumann: there must be some way to "bootstrap" from one major version to the next
[08:18:56] <deep42thought> whatever that way is, we should automate it ;-)
[08:19:08] <abaumann> yes. It's called a manual update procesure in the head of some upstream maintainer..
[08:19:23] <deep42thought> btw: according to xkcd "automate" comes from "auto" meaning "self" and "mate" meaning "screwing up"
[08:20:22] <deep42thought> btw: my i686/pentium4/i486 machines/chroots were updated fine, too
[08:20:25] <abaumann> lol
[08:20:27] <deep42thought> but I'm running on testing
[08:20:34] <deep42thought> and they don't have desktops ...
[08:20:42] <abaumann> testing is very ok for me too.
[08:21:02] <abaumann> stable has no problems for non-graphical stuff (as far as I can see)
[08:21:13] <deep42thought> here it is: https://xkcd.com
[08:21:14] <phrik> Title: xkcd: Automation (at xkcd.com)
[08:21:39] <abaumann> sad.. but true..
[08:22:20] <abaumann> well. let's fix bugs. :-)
[08:23:00] <abaumann> I don't like how package counts plateau in the buildmaster graph..
[08:23:22] <abaumann> I remember the past where major rebuilds happened and the curves where less flat.
[08:23:23] <deep42thought> yes, fixing bugs and/or blacklisting unbuildable packages should circumvent that
[08:24:21] <abaumann> broken packages are rebuilt constantly as long as they are broken?
[08:24:32] <deep42thought> well, after each major rebuild, some packages remained, slowly increasing this level ...
[08:24:33] <deep42thought> yes
[08:24:42] <deep42thought> https://archlinux32.org
[08:24:45] <abaumann> this makes sense for something like glibc, where a lot of packages depend on it. but not for some high-level community packages.
[08:25:03] <deep42thought> I disagree
[08:25:19] <deep42thought> however, I think, we should give packages that failed often a very low priority
[08:25:26] <abaumann> that's an option.
[08:25:37] <deep42thought> if the build slaves idle, they should build /any/ package
[08:25:48] <deep42thought> no matter how low the probability is, that it succeeds this time
[08:26:04] <abaumann> I'm more thinking, what helps more currently: 1) fix outstanding bugs, 2) add more build slaves, 3) tweak some build order logic
[08:26:10] <abaumann> I'm also all in for 1)
[08:26:25] <deep42thought> you do 1, I do 3
[08:26:29] <abaumann> :-)
[08:26:37] <deep42thought> ah, and probably 4
[08:26:39] <abaumann> 2) we did yesterday, at least one more build slave :-)
[08:26:44] <deep42thought> 4) remove unnecessary build order
[08:26:44] <deep42thought> s
[08:26:56] <abaumann> * abaumann thinks this sounds like the Spanish inquisition.. ;-)
[08:27:22] * deep42thought ponders removing /all/ pending builds
[08:27:37] <abaumann> mmh that stats graph looks good actually, a steep slope down in the blue line is a good thing..
[08:27:58] <deep42thought> yes
[08:28:16] <deep42thought> but I have the feeling, that after each major rebuild, we are left with a few additional packages that won't build
[08:28:36] <abaumann> exactly, they need manual treatment.
[08:28:56] <abaumann> I'm pretty sure ICU and ffmpeg are two of them.. I never saw them recover on their own..
[08:29:09] <deep42thought> well
[08:29:15] <abaumann> a good indicator is, that I have to change PKGBUILD temporary to remove a dependency
[08:29:20] <deep42thought> but we had running icu and ffmpeg in the past (also after the rebuilds)
[08:29:43] <abaumann> the strict library x264=x264-127.so dependencies maybe?
[08:29:59] <abaumann> they create a much tighter build cyrcle, so to speak.
[08:30:08] <deep42thought> yes
[08:30:20] <abaumann> OTOH they also ensure that library ABI mismatches don't go undetected to stable.
[08:30:51] <abaumann> If one removes them for rebuilding, then one may build illegal ABI dependencies into the package, also not ideal
[08:31:33] <deep42thought> the mysql database /should/ still detect the linking ...
[08:32:03] <buildmaster> pentium4/shaderc is broken (says eurobuild3).
[08:32:27] <abaumann> is there a sanity check for that, comparing the mysql dependencies to the dependencies in the packages?
[08:33:27] <deep42thought> no
[08:33:33] <deep42thought> but it should not get moved
[08:33:46] <deep42thought> because db-update only cares/knows about dependencies in the database
[08:38:06] <abaumann> :: unable to satisfy dependency 'device-mapper>=2.02.184' required by lvm2
[08:38:09] <abaumann> on i486
[08:40:56] <abaumann> => forced move
[08:41:01] <abaumann> now ok. :-)
[08:41:10] <deep42thought> oh, I think, I just killed the webserver by requesting the statistics graph for the last 1000 days :-/
[08:41:19] <abaumann> oups.
[08:50:07] <abaumann> yeah. systemd-login is officially borked on i486 too, it just fails and makes ssh go WAY SLOW..
[08:50:13] <abaumann> or all logins that is.
[08:50:32] <abaumann> and as this happens on ARM and on i486 I doubt this is a packager problem. :->
[08:53:35] <buildmaster> pentium4/glew1.10 is broken (says eurobuild3).
[08:53:50] <deep42thought> hmm? my ssh connections (on arm) work fine
[08:54:22] -!- thePiGrepper has quit [Ping timeout: 244 seconds]
[08:54:49] <abaumann> if I use ssh -v, it's fast, if I use just ssh, then it hangs for 30 seconds and I see journal error about systemd-login on the box.
[08:54:55] <abaumann> seems to be a race..
[08:55:16] <abaumann> it's rather random, it seems
[08:55:38] <abaumann> one ARM works for me too, the other has the same stupid behaviour with postfix/cyrus and SASL authentication
[08:56:28] <abaumann> it's a random glitch, happens, happens not, happens...
[08:57:10] <abaumann> ok.. I'm downgrading..
[08:57:48] <abaumann> systemd 242.19-1.0
[08:57:50] <abaumann> systemd-libs 240.95-2.2
[08:57:54] <abaumann> mmh. this sounds nice.
[08:57:55] <deep42thought> O.o
[08:57:57] <deep42thought> on arm?
[08:58:00] <abaumann> yep.
[08:58:05] <abaumann> armv6
[08:58:09] <abaumann> not armv7, aarch64
[08:58:27] <abaumann> maybe just a mismatch of libraries..
[08:58:58] <abaumann> so, systemd-libs 240.95-2.2 has been removed, and is still installed after an update?
[08:59:15] <abaumann> libsystemd 240.93-1.0/systemd 240.93-1.0
[08:59:17] <abaumann> fits
[09:00:08] <abaumann> systemd 242.19-1/systemd-libs 242.19-1 is upstream
[09:00:20] <abaumann> yeah. i486 moved just half of systemd..
[09:00:26] <abaumann> => moved by hand.
[09:00:52] <deep42thought> local/systemd 242.19-1 (base-devel)
[09:00:52] <deep42thought> local/systemd-libs 242.19-1
[09:00:55] <deep42thought> over here
[09:01:02] <abaumann> this is i686?
[09:01:28] <abaumann> it's only a problem on i486..
[09:01:37] <deep42thought> armv6
[09:02:25] <abaumann> ah.
[09:02:44] <deep42thought> we should use different nicks, one for each architecture
[09:02:51] <abaumann> agree :-)
[09:02:54] deep42thought is now known as deep42thought_of
[09:02:58] <deep42thought_of> I will be talking most
[09:03:11] deep42thought_of is now known as deep42thought_ot
[09:03:31] deep42thought_ot is now known as deep42thought_i6
[09:03:36] deep42thought_i6 is now known as deep42thought
[09:03:48] <deep42thought> hmm, there seems to be a limit to the length :-(
[09:03:56] <abaumann> lol
[09:04:22] <abaumann> systemd 242.19-1, systemd-libs 242.19-1, on my ARMv6. Seems ok now after the last update.
[09:04:24] <bill-auger> you would need to type - if you only talk, the IRC wont hear you
[09:04:32] -!- thePiGrepper has joined #archlinux32
[09:04:43] <bill-auger> yes freenode nicknames are capped at 16 characters
[09:05:06] <deep42thought> bill-auger: I'm always talking simultanously to my typing
[09:05:32] <deep42thought> it took me long to keep the volume down to not disturb others ;-)
[09:06:13] <buildmaster> pentium4/libsodium is broken (says eurobuild1).
[09:08:04] <abaumann> warning: cannot resolve "boost-libs=1.69.0", a dependency of "boost"
[09:08:05] <abaumann> warning: cannot resolve "gcc-libs=8.3.0-1.0", a dependency of "gcc"
[09:08:07] <abaumann> *grmpf*
[09:08:17] <abaumann> i486
[09:08:49] <deep42thought> btw: the ordering of build assignments is now changed
[09:08:57] <abaumann> ok.
[09:09:12] <abaumann> In the move I spot an error: the master package is moved, the dependent package *-libs not
[09:09:36] <deep42thought> that's not a problem
[09:09:57] <deep42thought> only if the dependent package was already available and /its/ dependency gets replaced by the moved master
[09:10:05] <deep42thought> (which usually should be the case)
[09:10:22] <abaumann> => just moved gcc-libs and boost-libs on i486 by hand
[09:10:32] <abaumann> mmh.
[09:10:43] <deep42thought> but I/we should fix the auto-mover, too ...
[09:11:49] <abaumann> one of the yous.. ;-)
[09:12:06] <deep42thought> either my left or my right arm
[09:12:40] <abaumann> or one of the additional ones you will have to grow.. ;-)
[09:14:08] <deep42thought> otoh it might be, that the "db-update -p" broke some dependencies while believing to repair others
[09:14:43] <abaumann> yeah. The normal move algorithm seems to work fine.
[09:15:04] <abaumann> You are called "Mr. P" :-)
[09:15:17] <deep42thought> Who's that?
[09:15:22] <abaumann> "Mr. -p"
[09:15:31] <deep42thought> ah, ok
[09:15:41] <abaumann> ..nothing can go wrong.. I'm so happy, I didn't use the -p option yesterday to move clang :-)
[09:15:41] <deep42thought> I thought, I run in polynomial time or something ;-)
[09:16:01] <abaumann> i486 test machine is up again. :-)
[09:26:21] <deep42thought> hmm, the i686 glibc claims (in the database) to not provide glibc :-/
[09:26:51] <deep42thought> thus everything depending (according to the database) on glibc (which is almost everything) was rescheduled
[09:31:29] <abaumann> ouch.
[09:31:51] <deep42thought> the good news is, that this seems to be the case only for three packages
[09:32:10] <deep42thought> the bad news is, that the three packages are i686/glibc, i686/binutils and i486/binutils
[09:32:26] <abaumann> binutils is not a problem
[09:32:37] <abaumann> nothing, or almost nothing depends on binutils directly
[09:32:44] <deep42thought> ok
[09:32:47] <abaumann> ok. the toolchain.
[09:33:04] <abaumann> didn't you say something, that you stopped gcc to be built after binutils?
[09:33:18] <abaumann> so this might have been related to that..
[09:33:20] <deep42thought> I aborted some builds and removed it from the build list
[09:33:30] <deep42thought> no, the whole row was removed from the database
[09:33:35] <abaumann> ah.
[09:34:04] <abaumann> again. I'm in favour of a database which is not dropping its pants..
[09:34:15] <deep42thought> !grab abaumann
[09:34:16] <phrik> deep42thought: Tada!
[09:34:27] <deep42thought> I'm not familiar with databases
[09:34:35] <deep42thought> so it's mainly your decision ;-)
[09:34:51] <deep42thought> e.g. I have no idea what syntax changes are necessary, etc.
[09:35:00] <abaumann> well. it's mysql now and remains mysql. mysql has some unique features for vendor lockins :->
[09:36:20] <abaumann> libsodium-1.0.17.tar.gz.minisig ... FAILED
[09:36:35] <abaumann> this retriggering of a complete rebuild is also positive.. we find bugs upstream..
[09:38:11] <deep42thought> we are the ci for archlinux :-)
[09:38:18] <abaumann> :-)
[09:38:21] <abaumann> "504 Gateway Time-out"?
[09:38:44] <deep42thought> 392 mysql 20 0 1268576 392492 20008 S 198.3 19.2 451:20.83 mysqld
[09:38:53] <deep42thought> besides _that_ I cannot see something faulty ...
[09:38:53] <buildmaster> pentium4/libvterm is broken (says eurobuild3).
[09:39:08] <abaumann> urgh.
[09:41:00] <deep42thought> mysql is _still_ processing the statistics query
[09:41:05] <abaumann> ah. :-)
[09:41:05] <deep42thought> is there no timeout for such stuff??
[09:41:15] <deep42thought> 25423 webserve localhost buildmast 4630 0.0 Query Removing duplic SELECT DISTINCT UNIX_TIMESTAMP(`statistics`.`date`) AS `date`,SUM(`statistics`.
[09:43:47] <abaumann> https://scaledynamix.com
[09:43:48] <phrik> Title: How to Kill MySQL Queries - Scale Dynamix (at scaledynamix.com)
[09:44:05] <deep42thought> I restarted the mysql server
[09:44:12] <deep42thought> but thx for the link, I'll read ...
[09:44:25] <abaumann> show processlist; kill, seems easy enough :-)
[09:45:02] <deep42thought> mytop shows the processid, too, I think
[09:49:32] <abaumann> rm: cannot remove '/build/pam/pkg/pam/usr/share/doc/Linux-PAM/sag-pam_userdb.html': No such file or directory
[09:49:48] <abaumann> mmh. nice. fatal documentation building error for pam.
[09:50:29] <abaumann> I'm all for an docdepends upstreams and a doc hook, in order to reduce all those silly dependencies just to get documentation nobody reads afterwards, because they don't know about the 'man' command.. (rant of the day)
[09:50:48] <deep42thought> !grab abaumann
[09:50:48] <phrik> deep42thought: Bazinga!
[09:52:20] <abaumann> aha: the ffmpeg problem was easy, I just had to force move x264 and x265 from testing to stable (in i686)
[09:56:07] <abaumann> *abaumann just realized he has to clone his i686 virtual machines and migrate those to pentium4 in order to test the pentium4 architecture
[10:01:27] <deep42thought> on archlinux32.org mysqld is back on 200% cpu load again ...
[10:06:36] -!- T`aZ has joined #archlinux32
[10:08:23] <abaumann> mmh. I wonder what happens if we push icu 64 to stable..
[10:08:33] <deep42thought> we break a lot of stuff?
[10:08:48] <abaumann> yeah. libxapp.so.1' referenced by the typelib: libicuuc.so.64: cannot open shared object file: No such file or directory
[10:09:02] <deep42thought> and we simultanously fix a lot of stuff
[10:09:03] <abaumann> otoh some things seem to be pushed to stable which require icu64
[10:09:08] <deep42thought> yes
[10:10:52] <abaumann> I can try to selectively push some things to stable..
[10:11:53] <deep42thought> nah
[10:11:57] <deep42thought> just move icu64
[10:12:05] <deep42thought> and then use db-update -p to repair
[10:12:19] <abaumann> ok
[10:12:31] <deep42thought> otoh, db-update -p might/should move icu to stable anyways
[10:12:41] <deep42thought> ah, no, that is not right
[10:12:52] <abaumann> too late :-)
[10:12:55] <deep42thought> np
[10:13:13] <deep42thought> I meant, icu will not be moved by "db-update -p" - because icu is not broken in stable
[10:13:20] <deep42thought> only the packages depending on icu are broken
[10:13:26] <deep42thought> s/are/might be/
[10:14:40] <abaumann> actually with slim/xfce things look much better now with icu64 :-)
[10:16:58] <abaumann> no to heavy weight display managers, of course.. no sddm. no lightdm.. *sigh*
[10:17:27] <abaumann> lightdm works
[10:17:47] <deep42thought> and heavydm does not?
[10:18:32] <abaumann> cinammon: "We failed, but the fail whale is dead. Sorry...."
[10:20:25] <abaumann> gnome: "Oh no! Something has gone wrong."
[10:20:39] <abaumann> they could really try to write error messages which are actually helpful..
[10:21:45] <abaumann> kde5init fails.
[10:21:57] <deep42thought> at least they try to hold your hand
[10:22:01] <abaumann> so. short: MY window managers (XFCE and Notion) work. The glossy ones don't
[10:22:08] <deep42thought> :-D
[10:22:12] <abaumann> that's sweet. :-)
[10:23:05] <abaumann> KDE: "Could not start kdeinit5. Check your installation."
[10:23:23] <deep42thought> `check installation`
[10:23:49] <abaumann> soffice has an icu63 dependency.
[10:26:00] <abaumann> ok. libreoffice needs a rebuild..
[10:26:56] <abaumann> trojita
[10:28:21] <deep42thought> libreoffice is already on the build list
[10:30:09] <abaumann> ah. good.
[10:30:20] <abaumann> trojita I have to check, it may be enough to move it..
[10:30:48] <abaumann> as everything having glibc dependency is on the build list? ;-)
[10:31:27] <deep42thought> I think, I should really clear out the build list and repopulate it
[10:31:31] <deep42thought> give me a second
[10:32:51] <deep42thought> 7940 build assignments, building 9882 packages
[10:32:57] <abaumann> oups.
[10:33:24] <deep42thought> ... removing ...
[10:33:25] <abaumann> as eli pointed out: we build things which are known not to build upstream..
[10:33:31] <deep42thought> yeah
[10:33:55] <abaumann> then we can priorize broken packages more easily
[10:34:03] <deep42thought> fortunately, we had enough trouble in the past, so there is a nice script now which is able to repopulate the build list quite conveniently
[10:34:11] <abaumann> :-)
[10:34:21] <deep42thought> damn, the query timed out
[10:35:58] <deep42thought> ... refilling build-list ...
[10:41:37] <deep42thought> oh, fun approaching: lots of haskell packages are being scheduled!
[10:43:03] -!- deep42thought has quit [Remote host closed the connection]
[10:43:18] <abaumann> thanks.
[10:43:20] <abaumann> :-)
[10:43:24] -!- deep42thought has joined #archlinux32
[10:43:24] <buildmaster> Hi deep42thought!
[10:43:24] <buildmaster> !rq deep42thought
[10:43:26] <phrik> buildmaster: <deep42thought> "und wieder ist ein Tag vollbracht und wieder ist nur Murks gemacht"
[11:06:34] <deep42thought> ... now inserting all packages, that are older on archlinux32 than archlinux ...
[11:13:39] <abaumann> .. increasing 2113 packages.. :-)
[11:14:22] <deep42thought> yeah, it pretty much looks like it is rescheduling everything ...
[11:14:42] <deep42thought> ah, wait, it temporarily also adds blacklisted packages, so this might be misleading
[11:14:48] <abaumann> ah.
[11:15:11] <deep42thought> the blacklisted packages never end up on the buildlist, though, but it needs to add them, so the blacklisting logic has all the dependency links available
[11:31:48] <deep42thought> I aborted that, it really inserted all packages
[11:31:56] <deep42thought> ... I'm looking for the bug now
[11:50:39] <T`aZ> meh, "installing clang (8.0.0-4.0) breaks dependency 'clang=7.0.1' required by qtcreator"
[11:59:23] <abaumann> T`aZ: yep, same as for kdevelop
[11:59:27] <abaumann> sorry
[11:59:42] <abaumann> they both need a reschedule.
[12:00:03] <abaumann> OTOH, clang 7 was happilly broken in stable anyway.
[12:00:46] <abaumann> binutils on eurobuild1, that'll be a while..
[12:00:48] <deep42thought> abaumann: feel free to manually reschedule the packages you think need to be rescheduled - I'm still hunting the schedules-almost-everything-bug
[12:01:00] <abaumann> ok.
[12:07:04] <deep42thought> oh - it considers i486, too ... that might cause many packages to be scheduled, too
[12:07:23] <deep42thought> and then the blacklisting will only remove them for i486, but not the other architectures
[12:11:00] <deep42thought> w/o i486, 1145 packages will be rescheduled, with i486 it's 2229
[12:25:20] <T`aZ> sure, no problem :p
[12:33:51] <abaumann> deep42thought: sounds about right.
[12:34:33] -!- abaumann has quit [Quit: leaving]
[12:53:01] -!- abaumann has joined #archlinux32
[12:53:02] <buildmaster> Hi abaumann!
[12:53:02] <buildmaster> !rq abaumann
[12:53:03] <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?
[12:54:53] <abaumann> I don't complain to have no broken packages, but https://archlinux32.org should not be empty, I guess.. ;-)
[12:54:55] <phrik> Title: Arch Linux 32 - List of Package Builds (at archlinux32.org)
[12:55:10] <deep42thought> abaumann: why not?
[12:55:14] <deep42thought> I emptied the build list
[12:55:20] <deep42thought> and rescheduled everything in need
[12:55:25] <deep42thought> and nothing has failed so far
[12:55:30] <abaumann> aha. good.
[12:55:49] <deep42thought> I'm now rescheduling the delta between archlinux32 (i686 and pentium4 only) and archlinux
[12:55:54] <abaumann> ok.
[12:56:09] <abaumann> I just reinstalled my eeepc and things are still working.. :-)
[12:56:52] -!- AndrevS has joined #archlinux32
[13:20:52] <buildmaster> pentium4/python-sphinx is broken (says nlopc43).
[13:21:08] <deep42thought> aha!
[13:21:23] <deep42thought> now your linked overview isn't empty anymore :-)
[13:23:02] <buildmaster> pentium4/python-sphinxcontrib-applehelp is broken (says nlopc43).
[13:24:14] <buildmaster> pentium4/python-sphinxcontrib-qthelp is broken (says nlopc43).
[13:24:21] <deep42thought> they all fail in check()
[13:30:18] <abaumann> wget: error while loading shared libraries: libidn2.so.0: cannot open shared object file: No such file or directory
[13:30:55] <abaumann> yeah. I'm so happy. wget failed when I wanted to download the first broken package log. :-)
[13:31:19] <deep42thought> oh
[13:39:31] <abaumann> oh. the bugs disappeared again from the list :-)
[13:39:40] <deep42thought> I cleaned up python
[13:39:48] <deep42thought> there was still something wrong with the dependencies
[13:40:02] <deep42thought> rescheduling is in progress
[13:41:10] <abaumann> pacman
[13:41:10] <abaumann> pacman: error while loading shared libraries: libidn2.so.4: cannot open shared object file: No such file or directory
[13:41:17] <abaumann> ok. good I installed pacman-static
[13:41:57] <abaumann> ah, this libidn2.so.4, libidn2.so.0 flippers again. This is pretty annoying..
[13:42:13] <abaumann> what a stupid library.
[13:42:22] <deep42thought> on which arch is this?
[13:42:29] <abaumann> i686
[13:43:09] <abaumann> binutils is in a loop, it seems..
[13:43:17] <abaumann> ah
[13:43:21] <abaumann> no i686, the pentiuim4..
[13:43:25] <abaumann> on the same machine
[13:44:11] <deep42thought> yes, I have not yet removed the extra logic for the toolchain
[13:44:19] <deep42thought> my hope was that I would find the error and correct it
[13:44:37] <deep42thought> should I simply remove binutils from the buildlist? Or does it actually need to be built?
[13:50:18] -!- MrBIOS has quit [Quit: MrBIOS]
[13:52:01] <abaumann> mmh. no clue.
[13:52:07] <abaumann> it's half way through.. so..
[13:52:19] <deep42thought> ah, I thought it was stuck in a cycle
[13:52:28] <deep42thought> well, just let it finish
[13:52:35] <abaumann> no, I can hardly distinguish between i686 and pentium4 :-)
[13:52:51] <abaumann> it's just quite coincidence it happened up on the same build slave.
[13:52:59] <abaumann> *ended
[13:55:41] <deep42thought> the first build of pentium4/binutils failed on your build slave?
[13:56:55] <abaumann> seems so. it had to recreate the chroot.
[13:57:45] <abaumann> argh. pushing libidn2 was a _really_ bad idea..
[13:57:58] <abaumann> now pacman, mutt, wget all broke.
[13:57:59] <deep42thought> you broke more stuff in the wake?
[13:58:02] <deep42thought> oh
[13:58:04] <abaumann> yeah.
[13:58:12] <deep42thought> on i686?
[13:58:15] <abaumann> yep
[13:58:25] -!- MrBIOS has joined #archlinux32
[13:58:49] <deep42thought> there is only one version of pacman available ...
[13:58:57] <abaumann> yeah. exactly.
[13:59:10] <abaumann> so, a forced rebuild is at hand. I rescheduled libidn2 and pacman
[13:59:19] <abaumann> prioritize-build-list always returns 0.. ?
[13:59:46] <abaumann> 5636 packages to be built..
[13:59:48] <deep42thought> what did you run?
[13:59:56] <abaumann> ./prioritize-build-list -w <(echo '^libidn2$' '^pacman$')
[14:00:08] <deep42thought> it needs \n between the items
[14:00:15] <abaumann> argh
[14:00:16] <deep42thought> but I can change that
[14:00:32] <abaumann> ./prioritize-build-list -w <(printf '^libidn2$\n^pacman$\n')
[14:00:35] <abaumann> => 6
[14:00:37] <abaumann> better :-)
[14:00:53] <deep42thought> there is no real reason to not break at any spaces ...
[14:03:01] <abaumann> ah. eurobuild1 buildmaster passed the tests.. :-)
[14:03:09] <abaumann> aeh binutils, I meant
[14:03:21] <deep42thought> :-)
[14:04:40] <deep42thought> prioritize-build-list now separates at any white space
[14:07:44] <abaumann> thanks :-)
[14:08:56] <abaumann> Yeah. I start to realize something. db-update works on all architectures, so, if the builds are not in sync, bad things happen.
[14:09:19] <deep42thought> what options do you use?
[14:09:25] <deep42thought> -f takes an architecture, too
[14:09:33] <deep42thought> w/o options should be fine at any time
[14:09:43] <deep42thought> and -p, well ... umm ...
[14:10:04] <abaumann> ah. I use the right architectures, but then I do it also for other architectures.
[14:10:11] <deep42thought> :-D
[14:10:24] <abaumann> so, if pushing a package on i486, this doesn't mean I have to push it on the other architectures too.
[14:10:28] <deep42thought> pacman-5.1.3-1.3-i686.pkg.tar.xz is now in staging
[14:10:32] <abaumann> cool
[14:10:32] <deep42thought> should I move it?
[14:10:44] <abaumann> let me check on staging/test first
[14:10:49] <deep42thought> ok
[14:11:45] <abaumann> mmh. should I have installed pacman-static first...
[14:14:35] <abaumann> yeah. looks good.
[14:14:42] <abaumann> pacman works on staging
[14:14:44] <abaumann> i686
[14:14:48] <deep42thought> ... moving pacman to testing and then to stable
[14:17:32] <deep42thought> ok, done
[14:17:43] <abaumann> yeah. there is also something fishy with libidn2
[14:17:53] <abaumann> worked on testing and staging, not anymore on stable
[14:18:47] <deep42thought> you're sure, you're not using [build-support]?
[14:18:48] <abaumann> sometimes I get the feeling, whenever you build libidn2 you get different ABI version numbers in the so files..
[14:18:56] <abaumann> I never use build-support
[14:19:01] <deep42thought> ok
[14:20:24] <abaumann> sorry, but I also had to push libidn2 to stable
[14:21:11] <abaumann> still.. I'm close to declare pacman-static the official pacman :->
[14:21:18] <deep42thought> !grab abaumann
[14:21:19] <phrik> deep42thought: Tada!
[14:21:47] <abaumann> stable: libidn2 2.1.1-2.5
[14:21:57] <abaumann> testing: libidn2 2.1.1-2.5
[14:22:10] <abaumann> staging: libidn2 2.1.1-2.5
[14:22:16] <deep42thought> $ ls /mnt/archlinux32/i686/*/libidn*.xz
[14:22:16] <deep42thought> /mnt/archlinux32/i686/build-support/libidn2-shim-2.1.0-1.1-i686.pkg.tar.xz
[14:22:16] <deep42thought> /mnt/archlinux32/i686/community/libidn11-1.33-1.0-i686.pkg.tar.xz
[14:22:16] <deep42thought> /mnt/archlinux32/i686/core/libidn-1.35-1.0-i686.pkg.tar.xz
[14:22:16] <deep42thought> /mnt/archlinux32/i686/core/libidn2-2.1.1-2.5-i686.pkg.tar.xz
[14:22:29] <deep42thought> you must have fetched some intermediate state
[14:22:47] <abaumann> stable: /usr/lib/libidn2.so.0 -> libidn2.so.0.3.5
[14:23:05] <abaumann> testing: /usr/lib/libidn2.so.0 -> libidn2.so.0.3.5
[14:23:09] <abaumann> staging: /usr/lib/libidn2.so.0 -> libidn2.so.0.3.5
[14:23:15] <deep42thought> several i686 packages link to libidn2.so.4
[14:23:52] <abaumann> pacman-static -S pacman
[14:23:57] <abaumann> forced reinstallation of pacman.
[14:24:10] <abaumann> Don't tell me, this is the symlink issue in pacman again..
[14:24:17] <deep42thought> pacman over here works fine
[14:24:23] <deep42thought> (on staging)
[14:24:27] <abaumann> yeah.
[14:24:30] <abaumann> stable is the problem
[14:24:47] <deep42thought> I have no stable box ...
[14:25:16] <abaumann> ah. not pacman, some other library has a stupid dependency on libidn2.so.4
[14:25:35] <abaumann> libcurl.so.4 => libidn2.so.4
[14:25:45] <abaumann> cool. I force rebuilding libcurl
[14:25:55] <deep42thought> no
[14:25:59] <deep42thought> it's already in testing
[14:26:03] <deep42thought> (and working there)
[14:26:05] <abaumann> ah, right.
[14:26:07] <abaumann> db-update then
[14:26:10] <deep42thought> so force moving should be enough
[14:26:11] <deep42thought> exactly
[14:27:01] <abaumann> nope
[14:27:32] <deep42thought> maybe the version in staging works?
[14:27:33] <elibrokeit> abaumann: you moved libidn2, huh? :p
[14:27:41] <abaumann> yeah. bad decision.
[14:27:45] <abaumann> a. there is a curl in staging.
[14:27:46] <elibrokeit> the problem with libidn2 is that curl, not pacman, depends on it
[14:27:50] <elibrokeit> so curl is broken
[14:28:00] <abaumann> yep. I moved testing instead of staging :-)
[14:28:02] <elibrokeit> I know this much without checking, past experience :p
[14:28:18] <elibrokeit> no need to schedule pacman though!
[14:28:18] <deep42thought> abaumann: wait a sec, then I can try with my testing machine if it is really the issue
[14:28:41] <deep42thought> elibrokeit: pacman is already rebuilt - that one at least does not throw strange build errors ;-)
[14:28:42] -!- MrBIOS has quit [Quit: MrBIOS]
[14:28:49] <abaumann> we have to rebuild libcurl.
[14:28:53] <deep42thought> no
[14:28:56] <abaumann> why?
[14:29:00] <deep42thought> we have to move it from staging to stable
[14:29:06] <abaumann> that's what I did.
[14:29:08] <abaumann> no effect.
[14:29:09] <deep42thought> no
[14:29:14] <deep42thought> you moved it from testing to stable
[14:29:21] <deep42thought> there was/is yet another version in staging
[14:29:26] <deep42thought> ah
[14:29:28] <deep42thought> wait
[14:29:33] <deep42thought> you moved that, too
[14:29:49] <abaumann> yeah. after the first failed update :-)
[14:29:53] <deep42thought> so how does it come, that staging works?
[14:30:07] <abaumann> mmh.
[14:30:12] <deep42thought> doesn't this mean, we just need to identify the package that needs to be moved from staging?
[14:30:37] <abaumann> yep.
[14:30:47] <deep42thought> so: no need to reschedule anything
[14:30:50] <abaumann> preetty sure, there is another one. :-)
[14:31:06] <abaumann> libpsl.so.5
[14:31:52] <deep42thought> [testing] looks fine, too, so the problematic package is in testing
[14:31:55] <abaumann> tada
[14:31:56] <abaumann> :-)
[14:31:58] <deep42thought> :-)
[14:32:07] <abaumann> I really hope, nobody updated in the last hour or so in stable.
[14:32:25] <deep42thought> db-update --fuck-up
[14:32:25] <abaumann> and this just because I wanted to wget a logfile. :-)
[14:32:36] <abaumann> !grab deep42thought
[14:32:36] <phrik> abaumann: Tada!
[14:32:54] <deep42thought> and the logfile is gone by now ;-)
[14:33:01] <abaumann> phrik: where is you swear-word safe-gueard?
[14:33:02] <phrik> abaumann: Error: You must be registered to use this command. If you are already registered, you must either identify (using the identify command) or add a hostmask matching your current hostmask (using the "hostmask add" command).
[14:33:16] <deep42thought> lol
[14:33:17] <abaumann> lol, exactly.
[14:33:24] <abaumann> phrik: whut?
[14:33:25] <phrik> abaumann: You might be able to bribe me for an answer…
[14:33:33] <deep42thought> phrik: how much?
[14:33:33] <phrik> deep42thought: Eh?
[14:33:40] <abaumann> * abaumann send 10$ to phrik
[14:35:07] <deep42thought> I'll move some more libidn2-broken packages
[14:35:15] <abaumann> gnutls I just moved..
[14:35:25] <abaumann> now finally wget works again.
[14:35:27] <deep42thought> gnurl getdns
[14:35:35] <deep42thought> knot
[14:35:39] <deep42thought> ... there are more :-)
[14:35:45] <abaumann> I'm pretty sure.
[14:36:43] <deep42thought> just to be sure: you only broke i686, not pentium4, right?
[14:37:10] <abaumann> yep.
[14:37:50] <abaumann> all domain resultion happens nowaday in glibc, libidn2 is outside. The situation might get better, if libidn2 is integrated in glibc (as many other libraries were before)
[14:39:26] <buildmaster> pentium4/gnome-shell is broken (says rechenknecht).
[14:39:29] <buildmaster> pentium4/virtualbox is broken (says buildknecht).
[14:40:32] <deep42thought> "i686/core/systemd-240.93-1.0-i686 depends on libidn2.so.4 which is not provided by any package"
[14:40:44] * deep42thought coughes nervously
[14:40:46] <abaumann> ah, no
[14:41:01] <abaumann> don't reboot any machines for the next hour.
[14:41:20] <abaumann> systemctl
[14:41:20] <abaumann> systemctl: error while loading shared libraries: libidn2.so.4: cannot open shared object file: No such file or directory
[14:41:25] <deep42thought> at least not if you're on our unstable stable branch ...
[14:41:35] <deep42thought> haha, you _cannot_ reboot :-D
[14:42:01] <abaumann> safety feature :-)
[14:42:48] <deep42thought> ok, systemd is moved
[14:42:52] <abaumann> db-moving systemd and friends might be enough.
[14:42:53] <deep42thought> others still have to be moved ...
[14:42:55] <abaumann> ah. exactly. :-)
[14:44:18] <abaumann> systemd-sysvcompat
[14:44:33] <abaumann> because its 240.93 in stable (still)
[14:44:55] <deep42thought> the db shows no systemd-related issues anymore
[14:45:06] <abaumann> systemd-sysvcompat is a logical dependency more
[14:45:20] <abaumann> I moved.
[14:46:22] <abaumann> * abaumann bravely reboots a stable test machine..
[14:46:30] <deep42thought> good luck
[14:46:46] <abaumann> no problems. it has libvirt snapshots.. :-)
[14:46:54] <abaumann> looking good. :-)
[14:46:57] <deep42thought> :-)
[14:47:24] <abaumann> I think, I fucked up enough for one afternoon :-)
[14:47:34] <deep42thought> :-D
[14:48:48] <deep42thought> mpd is broken
[14:48:53] <deep42thought> IIRC you're using that
[14:49:09] <abaumann> Do I?
[14:49:15] <abaumann> * abaumann wonders on which machine..
[14:49:41] <deep42thought> qt5-base is broken ... this will be fun :-)
[14:49:47] <abaumann> yeah. seen that.
[14:50:09] <abaumann> isn't that an icu issue
[14:50:16] <deep42thought> yes
[14:50:30] <deep42thought> I'm going through the list of icu issues, currently
[14:50:41] <abaumann> so, one half of qt used icu 63 before, and after my move it's broken on the other side. nice.
[14:56:37] <deep42thought> yes, but it's still an improvement if now the packages using the old version are the ones being broken
[15:00:59] <abaumann> Failed to connect to bus: Connection refused
[15:01:08] <abaumann> lxc/system issues in i686
[15:01:13] <abaumann> with networking
[15:01:21] <abaumann> poweroff: Failed to connect to bus: Connection refused
[15:01:26] <abaumann> *sigh*
[15:01:39] <deep42thought> more moving packages are on their way
[15:01:48] <deep42thought> ... I got lazy and ran 'db-update -p' again
[15:01:49] <abaumann> good packages? ;-)
[15:01:52] <buildmaster> pentium4/perl-dbd-mysql is broken (says rechenknecht).
[15:01:52] <abaumann> lol
[15:02:51] <abaumann> mmh 'poweroff --force' solved the problem. I think dbus got stuck somehow..
[15:05:35] <abaumann> pdftex: error while loading shared libraries: libpoppler.so.85: cannot open shared object file: No such file or directory
[15:05:38] <abaumann> luatex.
[15:05:40] <abaumann> yep.
[15:05:43] <abaumann> been there.
[15:06:12] <deep42thought> texlive-bin was moved, because it had other linking issues
[15:06:41] <deep42thought> should I move poppler, too?
[15:06:47] <abaumann> yeah, why not.
[15:06:53] <deep42thought> why not: this will most probably also break other stuff
[15:06:58] <abaumann> ah.
[15:06:59] <deep42thought> but I will happily move it :-D
[15:07:11] <abaumann> :-)
[15:07:53] -!- AndrevS has quit [Read error: Connection reset by peer]
[15:15:24] <abaumann> oh. you pushed openttd, so I can game this evening, thanks :-)
[15:15:36] <deep42thought> you play openttd?
[15:15:53] <abaumann> yep. sometimes.
[15:15:56] <deep42thought> I'm maintaining a few patches for that :-)
[15:16:00] <abaumann> oh. :-)
[15:16:49] <abaumann> I usually construct big networks till my eeepc stops rendering the network properly. then I start a new one.. :-)
[15:16:57] <deep42thought> yeah
[15:17:04] <deep42thought> that's my algorithm, too
[15:17:13] <deep42thought> except, that I exhaust a pentium i7
[15:17:17] <abaumann> lol
[15:19:27] <deep42thought> and when I play over network with my wife, the game ends much earlier due to frequent de-syncs
[15:20:58] <buildmaster> pentium4/virtualbox-modules-arch is broken (says buildknecht).
[15:56:07] -!- deep42thought has quit [Quit: Leaving.]
[15:57:34] <buildmaster> i686/gnome-shell is broken (says buildknecht).
[16:10:43] -!- ubuntuxp has joined #archlinux32
[16:26:07] <slacka123> warning: cannot resolve "gvfs=1.38.2", a dependency of "gvfs-nfs"
[16:26:33] <abaumann> DNSSEC is default yes in systemd-resolved, this caused my downgrade, first lookup trouble with OpenBSD unbound..
[16:26:49] <abaumann> really, in a local network forcing people to use DNSSEC?
[16:35:07] <slacka123> looks like gvfs-nfs has to be bumped from testing
[16:35:15] <abaumann> oh. yep.
[16:35:52] <abaumann> might be not enough.. hang on.
[16:37:58] <abaumann> ah. gvfs is the problem.
[16:38:20] <abaumann> the submodules have been pushed to stable, gvfs not. So I'll move gvfs (what can possibly go wrong?)
[16:39:04] <abaumann> installing gvfs (1.38.2-1.0) breaks dependency 'gvfs=1.38.1+8+ge4eec2bc' required by gvfs-afc
[16:39:11] <abaumann> aha. now the other submodules croak.
[16:44:08] <abaumann> ok. I moved gvfs and most modules, as well as gvfs-google.
[16:44:37] <abaumann> * abaumann will remember this day as the day of (too many) manual db-updates
[16:48:12] <abaumann> /usr/bin/xsltproc: error while loading shared libraries: libicuuc.so.63: cannot open shared object file: No such file or directory
[16:48:15] <abaumann> yep.
[16:48:41] <abaumann> this is i486..
[16:59:29] <slacka123> "gvfs-nfs" is still complaining it can't find gvfs=1.38.2
[16:59:39] <abaumann> which mirror are you using?
[16:59:52] <abaumann> they might still be out of date.
[16:59:59] <abaumann> mirror.archlinux32.org
[17:09:27] <slacka123> I switched mirrors from Canada to US, that did it
[17:09:36] <slacka123> no more dependency errors
[17:12:05] <abaumann> good :-)
[17:30:12] <abaumann> openttd
[17:30:12] <abaumann> openttd: error while loading shared libraries: libfluidsynth.so.2: cannot open shared object file:
[17:30:20] <abaumann> I cannot play (yet) ;-(
[17:33:33] <abaumann> ah. it works. :-)
[17:37:04] * buildmaster goes insane.
[17:37:24] -!- abaumann has quit [Quit: leaving]
[18:52:43] -!- slacka123 has quit [Remote host closed the connection]
[18:55:18] -!- slacka123 has joined #archlinux32
[18:57:19] <slacka123> Good news, everyone! My GNOME, i686 desktop survived a reboot after the update storm. All major apps are loading.
[19:05:19] <slacka123> so systemd is fixed on i686 but pentium4 still is broken with libicuuc issues
[19:24:30] <slacka123> not sure if this is important, but WARNING: accountsservice: directory permissing differ /var/lib/AccountSerive/icons -> 775 755
[19:26:34] <slacka123> Should I chmod /var/lib/AccountsService/icons
[20:29:38] <finsternis> I get this trying to update the system: https://pastebin.com
[20:29:47] <finsternis> installing x264 (2:157.r72db4377-1.4) breaks dependency 'libx264.so=155-32' required by libquicktime
[20:32:35] <slacka123> finsternis: pacman -Syyu or change mirror
[20:32:46] <slacka123> that dependency issue was fixed on i686 and pentium4
[20:34:19] -!- samantaz_ has joined #archlinux32
[20:34:59] <slacka123> Good news, everyone! My GNOME, pentium4 desktop by upgrading to the testing repo
[20:35:41] <slacka123> Can any admins here push the systemd /icu libs in testing into stable so that pentium4 can boot again?
[20:39:39] -!- deep42thought has joined #archlinux32
[20:39:40] <buildmaster> Hi deep42thought!
[20:39:40] <buildmaster> !rq deep42thought
[20:39:40] <phrik> buildmaster: <deep42thought> golang-asvnp-acwduac-sefc-evfsx-vb4fs-sefvcy is broken (says me)
[20:43:51] <deep42thought> systemd is moved
[20:49:14] <slacka123> icu libs were also breaking boot. going to testing solved all the issues
[20:49:52] <slacka123> so both i686 stable and pentium4 desktops are now booting and seem 100%
[20:50:02] <slacka123> pentium4 (testing)
[20:51:06] <slacka123> oh testing also fixed the clang / llvm issue I was having yesterday
[20:51:26] <deep42thought> yes, for some reason testing is more stable than stable :-/
[20:51:52] <slacka123> yeah and the icons were broken in stable. they are fixed in testing
[20:52:36] <slacka123> can you just mass move testing -> stable?
[20:52:58] -!- abaumann has joined #archlinux32
[20:52:58] <buildmaster> Hi abaumann!
[20:52:58] <buildmaster> !rq abaumann
[20:52:59] <phrik> buildmaster: <abaumann> "Santa Claus brings you bells and presents.. and bugs"
[20:53:04] <deep42thought> yes, I'm on it, but currently my internet connection is saturated with backups
[20:53:26] <deep42thought> plus the buildmaster is insane ...
[20:53:35] <deep42thought> buildmaster: what's up?
[20:53:35] <buildmaster> up? I'm up for 3 days, 3 hours, 39 minutes, load average: 1.61, 1.19, 0.80 ... and I'm insane :-D
[20:54:59] <slacka123> no rush, testing pentium4 is good for now, GNOME, clang, firefox, libreoffice are all working
[20:55:24] <slacka123> just let us know when your done so I can switch back to stable to test that
[21:00:11] -!- abaumann has quit [Quit: leaving]
[21:00:45] * buildmaster resumes sanity.
[21:06:40] <buildmaster> pentium4/aarch64-linux-gnu-gcc is broken (says eurobuild3).
[21:13:29] <slacka123> deep42thought: can your router do QoS to throttle your backups?
[21:13:40] <deep42thought> sure, it could
[21:13:46] <deep42thought> but I would need to configure it :-/
[21:15:08] <slacka123> might be worth it, with buffer bloat today's routers make things unusable without QoS
[21:15:12] <deep42thought> in the end, it's a alix running debian
[21:16:17] <deep42thought> the blocker is, that I would need to think about how I identify the backups and/or if those are the only thing that I want to throttle
[21:16:25] <slacka123> oh, that will take some work...I'm spoiled with OpenWRT / dd-WRT
[21:16:38] <slacka123> point and click :)
[21:16:55] <deep42thought> I do not consider point-and-click easy
[21:16:57] <T`aZ> net.ipv4.tcp_congestion_control = bbr
[21:17:04] <deep42thought> I consider 'nano /etc/qos.conf' easy
[21:17:10] <T`aZ> enjoy way less buffer bloat without adding qos to your router
[21:17:58] <deep42thought> as I said: the main problem here is, that I have not made up my mind, what I actually want/expect from qos
[21:19:34] <slacka123> I like the power of config files to fix. But if lets say I want to setup a VPN, 1 wizard with correct defaults is better than 4 config files where 1 typo can mean VPN not working
[21:20:14] <buildmaster> pentium4/wlc is broken (says eurobuild3).
[21:20:23] <deep42thought> that's also a good and valid point, yes
[21:21:17] <slacka123> and I wish all config files worked like visudo, so 1 little typo wont' waste hours tracking down
[21:22:02] <slacka123> I have wasted too many hours tracking down a stray ;
[21:29:27] <deep42thought> i686/testing does not need to be emptied into stable, right?
[21:30:17] <slacka123> Not for me. I'm talking to you on it now.
[21:33:44] <deep42thought> ok, pentium4/testing is now empty
[21:34:36] <slacka123> thanks!
[21:35:15] <slacka123> eurobuild3 out of space again?
[21:35:17] -!- samantaz__ has joined #archlinux32
[21:35:41] <deep42thought> that's abauman's machine
[21:37:38] -!- samantaz_ has quit [Ping timeout: 255 seconds]
[21:37:54] <buildmaster> pentium4/fcitx-unikey is broken (says nlopc43).
[21:39:59] <slacka123> https://archlinux32.org works but not https://archlinux32.org ... just have to wait for your changes to propogate?
[21:40:01] <phrik> Title: Arch Linux 32 - icu 64.2-1.0 (i686) (at archlinux32.org)
[21:40:18] <deep42thought> I think so, yes
[21:41:41] <buildmaster> pentium4/pyrit is broken (says nlopc43).
[21:43:57] <deep42thought> I think net.ipv4.tcp_congestion_control will not solve my problem, because: a) the backups run over vpn, which uses udp IIRC, and b) the vpn connects via ipv6 most probably - but anyways thanks for the hint
[21:46:16] <buildmaster> pentium4/bigloo is broken (says nlopc43).
[21:48:23] -!- MrBIOS has joined #archlinux32
[21:51:55] <buildmaster> pentium4/brise is broken (says eurobuild3).
[21:54:37] <buildmaster> pentium4/gens-gs are broken (says rechenknecht).
[22:01:24] <buildmaster> pentium4/dvd+rw-tools are broken (says nlopc43).
[22:01:48] <buildmaster> pentium4/ckermit is broken (says rechenknecht).
[22:05:40] <buildmaster> pentium4/dmapi is broken (says nlopc43).
[22:08:02] <buildmaster> pentium4/hardlink is broken (says nlopc43).
[22:08:19] <deep42thought> I thought, hardlinks cannot be broken ;-)
[22:11:31] <T`aZ> deep42thought: indeed wont help in that case
[22:12:22] <buildmaster> pentium4/agg is broken (says nlopc43).
[22:12:23] <girls> I activated it anyways, and it looks like it realy improved something - my dns queries are not timing out so often - but maybe it looks just that way
[22:15:13] <deep42thought> ah, wrong tab :-/
[22:16:41] <buildmaster> pentium4/apitrace is broken (says rechenknecht).
[22:22:50] <T`aZ> irls: just to be sure, this only affects your own computer, for tcp connections, while doing uploads, indeed if you had your upload bandwidth being full with tcp uuploads, using bbr will reduce latencies also for non bandwidth hungry protocol
[22:22:58] <T`aZ> girls: ^ :p
[22:24:15] <deep42thought> I had my uplink bandwidth full - I'm just not sure whether it's tcp and whether it's ipv4
[22:26:36] <T`aZ> it applies to ipv6 also, iirc
[22:27:00] <deep42thought> ah, ok, then maybe openvpn uses udp and tcp ...
[22:28:06] <T`aZ> depends on how it's configured :p
[22:30:26] <slacka123> 32.arlm.tyzoid.com/ from https://archlinux32.org has an expired CERT
[22:30:27] <phrik> Title: Arch Linux 32 - Mirror Overview (at archlinux32.org)
[22:30:44] <deep42thought> tyzoid has a hand for expired certs ;-)
[22:33:14] <slacka123> deep42thought: if it's 1 process that is killing your upstream, you can use iptables tc command to limit the bandwidth
[22:33:37] <slacka123> deep42thought: sid-owner can be used for threads and their children
[22:35:17] <slacka123> Or you can do it on the application level: OpenVPN allows limits with the "shaper" parameter
[22:39:34] <buildmaster> pentium4/refind-efi is broken (says rechenknecht).
[22:41:29] <buildmaster> pentium4/badtouch is broken (says nlopc43).
[22:44:13] <buildmaster> pentium4/asciiportal is broken (says nlopc43).
[22:44:48] <buildmaster> pentium4/tdlib is broken (says eurobuild3).
[22:49:40] <buildmaster> pentium4/luasec is broken (says eurobuild3).
[23:00:47] <buildmaster> pentium4/libstdc++5 is broken (says rechenknecht).
[23:11:22] <buildmaster> pentium4/cmucl is broken (says eurobuild3).
[23:23:14] -!- deep42thought has quit [Quit: Leaving.]
[23:26:17] <buildmaster> pentium4/csfml is broken (says nlopc43).
[23:31:53] <buildmaster> pentium4/avogadrolibs are broken (says nlopc43).
[23:34:28] <buildmaster> pentium4/link-grammar is broken (says eurobuild3).
[23:42:39] <buildmaster> pentium4/gwenhywfar is broken (says rechenknecht).
[23:44:37] <buildmaster> pentium4/graphite is broken (says nlopc43).
[23:46:46] <buildmaster> pentium4/borg is broken (says nlopc43).