#archlinux32 | Logs for 2018-12-06

Back
[00:19:00] -!- guys has quit [Ping timeout: 252 seconds]
[00:25:12] -!- thePiGrepper has joined #archlinux32
[00:26:11] -!- MrBIOS has quit [Quit: MrBIOS]
[01:32:36] -!- isacdaavid has quit [Quit: Leaving.]
[02:43:27] -!- woshty has quit [Ping timeout: 240 seconds]
[02:50:53] -!- guys has joined #archlinux32
[03:17:04] -!- dbermond has quit [Quit: gn]
[03:53:20] <thePiGrepper> elibrokeit: sorry for replying one day later. with that, you mean the issue when using Arch-x64 as host and pacstraping using a mirrorlist from arch32, it requires you to ignore signature checking to avoid the warning/abort message?
[03:54:09] <thePiGrepper> that's normal right? because a typical arch x64 system doesnt have the keyring from arch32
[04:34:27] <elibrokeit> Sort of yes and sort of no.
[04:34:50] <elibrokeit> It breaks on every arch-nspawn
[04:36:05] -!- guys has quit [Ping timeout: 268 seconds]
[04:50:06] -!- guys has joined #archlinux32
[04:50:35] <buildmaster> i686/grafana is broken (says rechenknecht).
[04:59:21] -!- comrumino has quit [Quit: ZNC 1.7.1 - https://znc.in]
[05:23:22] <thePiGrepper> elibrokeit: oh, I see. I dont have much experience with systemd-nspawn. what's the difference between regular chroot and it? and then, what exactly do you mean with 'break'? it doesnt enter into the chroot? or something like that? or pacman doesnt work once inside the jail?
[05:24:56] <elibrokeit> the problem is that arch-nspawn is a wrapper script that among other things deletes the chroot's pacman-key keyring and replaces it with the one from the host system
[05:27:10] <thePiGrepper> oh, ok, I get it. once you do that, obviously an arch32's pacman wouldnt work. does arch-nspawn creates(calls pacstrap) the basesystem as well, or only uses a previously created one?
[05:28:18] <thePiGrepper> and that point you made yesterday that pacman had as a dependency archlinux-keyring and not the other way around, what was that about?
[05:29:59] <elibrokeit> it uses previous ones
[05:30:36] <elibrokeit> and the dependency ordering just means that when first installing the chroot, it does not actually populate the keyring
[05:31:01] <elibrokeit> it's an unrelated bug which means that people pacstrapping from the ISO, will hit a couple odd potential issues.
[05:32:12] <thePiGrepper> once inside it, that also means you wouldnt be able to solve it by using pacman-key --init because the keyring was swapped, right?
[05:33:46] <thePiGrepper> I dont really understand why would the script delete the chroot's pacman-key keyring and replace it. what's the purpose in doing that?
[05:34:32] <thePiGrepper> in order to have an updated one, instead of probably one from an old iso?
[05:35:58] <elibrokeit> well, the idea is that your chroot might be old, so get the updated keys from the host system
[05:36:09] <elibrokeit> but weirdly, it deletes the existing ones...
[05:36:50] <thePiGrepper> I see. it should copy the inside the package, chroot into it, and update them from inside...
[05:37:03] <thePiGrepper> instead of merely replacing it?
[05:37:28] <thePiGrepper> or even easier, wouldnt there be an option to avoid doing this?
[05:37:50] <thePiGrepper> or another one to point to a directory where the keys are located?
[05:39:20] <elibrokeit> thePiGrepper: I already solved the problem so now it works
[05:39:57] <thePiGrepper> I see. what was the solution at the end?
[05:40:10] <elibrokeit> https://github.com
[05:40:11] <phrik> Title: arch-nspawn: don't delete the guest gpg configuration · eli-schwartz/devtools@7b90ea9 · GitHub (at github.com)
[05:40:30] <elibrokeit> You can read my extremely verbose commit message :)
[05:40:35] <elibrokeit> I like verbose commit messages
[05:43:03] <thePiGrepper> haha, well that certainly beats me asking you 1000 questions that can be answered by reading that extremely verbose commit message. ;)
[05:44:37] <thePiGrepper> sorry again for the ton of questions. hehe
[05:45:55] <elibrokeit> questions are fine
[05:46:12] <elibrokeit> I like people who are curious about how things work and interested in learning
[05:52:59] <thePiGrepper> that's good. at the end of the day, software is of many levels of quality, but the real advantage of open source is *this*. a community of people eager to share knowledge :)
[05:53:20] <thePiGrepper> btw, I just read your commit
[05:54:34] <thePiGrepper> that fix made me think. in the (unlikely) case, I'd like to create this chroot as a way of installing a new arch32 full system.
[05:55:13] <thePiGrepper> wouldnt the gpg be different from one using the 'normal' installation ISO method?
[05:55:30] <thePiGrepper> or this would eventually get overwritten when the archlinux-keyring gets installed/updated?
[05:58:22] <thePiGrepper> just curious. I know it wouldnt make any difference functionally
[06:10:16] <buildmaster> i686/llvm is broken (says eurobuild3).
[06:11:56] <elibrokeit> the gpg would be the one from the machine you ran mkarchroot on
[06:12:14] <elibrokeit> which might be an i686 host, or might be an x86_64 host
[06:12:48] <elibrokeit> for example, this does not fix pacstrapping an i686 chroot (which I still need the host keys for), but it does let me maintain an existing chroot
[06:23:44] -!- deep42thought has joined #archlinux32
[06:23:44] <buildmaster> Hi deep42thought!
[06:23:44] <buildmaster> !rq deep42thought
[06:23:45] <phrik> buildmaster: <deep42thought> ahm, what is actually in the package "vulkan-headers" on i486? I thought, we disabled all vulcans?
[06:24:00] <deep42thought> thx, eli for reminding me, what the goal of this commit was
[06:24:30] <deep42thought> btw: I think, copying should happen, but in mkarchroot and not in arch-chroot
[06:25:32] <elibrokeit> no, arch-chroot is supposed to refresh it each time
[06:25:46] <elibrokeit> mkarchroot should also copy it though
[06:25:59] <deep42thought> that's what I meant
[06:26:02] <elibrokeit> hence https://github.com
[06:26:03] <phrik> Title: mkarchroot: don't create a broken chroot by default · eli-schwartz/devtools@f22c473 · GitHub (at github.com)
[06:26:24] <elibrokeit> I've force-pushed the whole branch
[06:26:25] <deep42thought> oh, there is an option for pacstrap for that :-o
[06:26:39] <elibrokeit> pacstrap even does it by default...
[06:26:49] <deep42thought> yeah, I just noticed as I read it
[06:26:58] <elibrokeit> (you still need pacstrap to have access to the archlinux32 keys)
[06:27:06] <deep42thought> yeah, that's ok
[06:27:30] <elibrokeit> but I had an existing chroot which should not be clobbered by repeated arch-nspawn, which is its own issue
[06:27:45] <deep42thought> ack
[06:29:46] -!- davor_ has joined #archlinux32
[06:30:09] <elibrokeit> in fact, pacstrap --gpgdir /etc/pacman.d/gnupg-i686
[06:30:36] -!- davor has quit [Ping timeout: 246 seconds]
[06:30:36] davor_ is now known as davor
[06:32:40] <deep42thought> you have a separate archlinux32 gpgdir on your host?
[06:32:54] <deep42thought> I think, that's no option on our build slaves
[06:33:13] <deep42thought> because we need my key for our [releng] packages
[06:35:51] -!- guys has quit [Ping timeout: 246 seconds]
[06:37:52] <elibrokeit> deep42thought: yeah
[06:38:14] <elibrokeit> I'll never use it natively for the host, so why have keys I don't use?
[06:50:28] -!- guys has joined #archlinux32
[06:57:41] -!- NoobAlice has quit [Quit: Leaving.]
[07:11:32] -!- deep42thought has quit [Quit: Leaving.]
[07:13:51] <thePiGrepper> elibrokeit: I just read this patch https://github.com and wondered. why is the -d option still there? for compatibility reasons?
[07:13:52] <phrik> Title: mkarchroot: don't create a broken chroot by default · eli-schwartz/devtools@f22c473 · GitHub (at github.com)
[07:14:06] <elibrokeit> oh hehe
[07:14:22] <elibrokeit> pacstrap still supports it by doing nothing, yeah
[07:14:43] <thePiGrepper> yeah, I had to check pacstrap code to figure that one out, lol
[07:17:26] <thePiGrepper> what's the purpose in keeping -d on pacstrap, and here? it's clearly on purpose right? is there a usecase for this?
[07:27:35] <elibrokeit> the code is old and never received the patches to drop deprecated sutff
[07:32:49] <thePiGrepper> and also I assume, the first step would be to drop that option on all the packages that use pacstrap first...
[07:46:17] -!- abaumann has joined #archlinux32
[07:46:17] <buildmaster> Hi abaumann!
[07:46:17] <buildmaster> !rq abaumann
[07:46:19] <phrik> buildmaster: <abaumann> classic approach then.. add more resources to the problem :-)
[07:46:58] <abaumann> deep42thought: buildmaster.archlinux32.org redirects now to https://packages.archlinux32.org which is quite slow ATM?
[07:47:47] <abaumann> ah. now it's faster.. :-)
[07:48:46] <abaumann> https://status.archlinux32.org ah, the check might need some fixing there..
[08:00:56] <abaumann> I'm trying to solve the LLVM/Ocaml knot and the node-gyp segfault (which now also starts to block some packages)..
[08:06:56] -!- abaumann has quit [Quit: leaving]
[08:36:22] -!- guys has quit [Ping timeout: 246 seconds]
[08:41:52] -!- deep42thought has joined #archlinux32
[08:41:52] <buildmaster> Hi deep42thought!
[08:41:52] <buildmaster> !rq deep42thought
[08:41:54] <phrik> buildmaster: <deep42thought> my cluster of 1k 4/86's will be happy to iterate Maxwell-Vlasov-equations :-D
[08:42:29] <deep42thought> abaumann: packages.archlinux32.org being slow is mainly due to (inefficient ?) mysql queries
[08:42:51] <deep42thought> the reason for being fast sometimes is, that the http content is cached
[08:43:32] <deep42thought> the webserver is running on my not-that-big vps which I primarily rented for my own (static) webpages, email and similar leightweight tasks
[09:56:20] -!- thePiGrepper has quit [Ping timeout: 250 seconds]
[09:58:14] -!- thePiGrepper has joined #archlinux32
[10:23:37] -!- abaumann has joined #archlinux32
[10:23:37] <buildmaster> Hi abaumann!
[10:23:37] <buildmaster> !rq abaumann
[10:23:38] <phrik> buildmaster: <abaumann> ok. it fails, but it works..
[10:24:07] <abaumann> deep42thought: how much space is it using? Is the machine the buildmaster is currently running on an option?
[10:24:27] <deep42thought> I'd rather keep the web frontend and the buildmaster separated
[10:24:38] <deep42thought> for that very reason that some operations block the mysql database
[10:25:06] <abaumann> ah. that's true.
[10:25:49] <deep42thought> honestly, looking at the specs of my vps, it's very similar to yours: 8GB ram, 2 cores, 300GB hdd (probably not ssd)
[10:26:16] <deep42thought> I'm currently logging the duration of all mysql queries to find the slow ones :-)(
[10:26:21] <deep42thought> s/($//
[10:26:23] <abaumann> I just have a small 10GB ssd, the costs for more are quite high. hence good old platter. :-)
[10:26:43] <abaumann> lol, a smiley sed.
[10:26:43] <deep42thought> I think, this system has no ssd at all
[10:27:04] <deep42thought> sad smiley removal sed
[11:10:07] -!- thePiGrepper has quit [Ping timeout: 240 seconds]
[11:14:08] -!- woshty has joined #archlinux32
[11:14:53] -!- DepositePirate_ has quit [Ping timeout: 256 seconds]
[11:16:41] -!- DepositePirate_ has joined #archlinux32
[11:23:41] -!- woshty has quit [Ping timeout: 268 seconds]
[11:26:43] -!- abaumann has quit [Quit: leaving]
[12:13:50] <buildmaster> i686/jupyter-notebook is broken (says nlopc46).
[13:26:44] -!- dopsi has quit [Quit: ZNC - https://znc.in]
[13:27:33] -!- dopsi has joined #archlinux32
[14:13:12] <buildmaster> i686/freeradius are broken (says rechenknecht).
[14:17:48] -!- guys has joined #archlinux32
[14:38:42] -!- thePiGrepper has joined #archlinux32
[14:40:39] -!- guys has quit [Ping timeout: 250 seconds]
[14:45:49] -!- woshty has joined #archlinux32
[14:55:23] -!- guys has joined #archlinux32
[15:58:51] -!- deep42thought has quit [Quit: Leaving.]
[16:04:13] <buildmaster> i686/nginx-mod-modsecurity is broken (says rechenknecht).
[16:04:14] -!- thePiGrepper has quit [Ping timeout: 250 seconds]
[16:06:08] -!- thePiGrepper has joined #archlinux32
[16:41:04] -!- guys has quit [Ping timeout: 250 seconds]
[16:55:20] -!- guys has joined #archlinux32
[18:26:42] -!- NoobAlice has joined #archlinux32
[18:42:45] -!- guys has quit [Ping timeout: 268 seconds]
[18:51:20] -!- abaumann has joined #archlinux32
[18:51:20] <buildmaster> Hi abaumann!
[18:51:20] <buildmaster> !rq abaumann
[18:51:21] <phrik> buildmaster: <abaumann> a babe is a checksum error
[18:54:22] <abaumann> I start to see GPG errors in some packages, for instance nginx-mod-modsecurity.
[18:56:27] -!- guys has joined #archlinux32
[18:57:23] <abaumann> If the PGP keys are nuked inside the chroot, does this mean, that the machines running the build slaves now how to make sure the keyrings are kept up-to-date?
[19:01:43] <elibrokeit> abaumann: no, they're replaced by the host pgp keys
[19:02:19] <abaumann> ah. ok. so then the first makepkg outside the build slave has to make sure to check and eventually download the proper keys..
[19:02:46] <abaumann> ..anyway better, because then they are shared between builds..
[19:04:30] <elibrokeit> abaumann: that's why I want these to be cached between builds as well as adding the host keys
[19:39:03] -!- abaumann has quit [Remote host closed the connection]
[19:54:25] -!- MrBIOS has joined #archlinux32
[20:27:33] -!- isacdaavid has joined #archlinux32
[20:43:23] -!- guys has quit [Ping timeout: 245 seconds]
[20:58:10] -!- guys has joined #archlinux32
[21:49:18] -!- deep42thought has joined #archlinux32
[21:49:19] <buildmaster> Hi deep42thought!
[21:49:19] <buildmaster> !rq deep42thought
[21:49:19] <phrik> buildmaster: <deep42thought> brtln: you're "the arch linux", we're "the other arch linux" and alarm is "arches linux", then?
[21:49:41] <deep42thought> abaumann: installing archlinux32-keyring on the host (it's in [releng] and a dependency of devtools32) should be enough
[22:20:28] <deep42thought> abaumann: the mysql query times look somewhat high but non-alarming to me (at least if we don't want to serve too many queries) https://szilassi.eckner.net
[22:21:14] <deep42thought> however, these are only the php runs where the script did not time out during the query
[22:21:40] <deep42thought> so my guess is, that sometimes the query takes _a_lot_ longer than what is in that graph
[22:43:12] -!- guys has quit [Ping timeout: 244 seconds]
[22:43:36] -!- deep42thought has quit [Quit: Leaving.]
[22:48:11] -!- thePiGrepper has quit [Ping timeout: 268 seconds]
[22:56:56] -!- guys has joined #archlinux32
[22:58:03] -!- isacdaavid has quit [Read error: Connection reset by peer]
[23:13:10] -!- woshty has quit [Ping timeout: 244 seconds]
[23:14:01] -!- woshty has joined #archlinux32