#archlinux32 | Logs for 2018-04-19

Back
[00:32:24] -!- tyzoid_ has joined #archlinux32
[02:29:25] -!- tyzoid_ has quit [Quit: ZNC 1.6.3+deb1 - http://znc.in]
[05:44:46] -!- davor has quit [Ping timeout: 264 seconds]
[05:49:49] -!- davor has joined #archlinux32
[07:26:01] -!- eduardoeae has quit [Ping timeout: 256 seconds]
[08:31:55] -!- abaumann has joined #archlinux32
[08:31:55] <buildmaster> Hi abaumann!
[08:42:11] -!- deep42thought has joined #archlinux32
[08:42:12] <buildmaster> Hi deep42thought!
[08:54:02] <abaumann> Just looking at https://packages.archlinux32.org
[08:54:05] <phrik> Title:More and less critical issues with the database (at packages.archlinux32.org)
[08:54:16] <abaumann> clang and llvm issues are listed there.
[08:54:56] <abaumann> I'm currently trying to fix stack smashing and portability issues in libgit2, so I needed a clang vs. gcc countercheck. :-)
[08:55:14] <deep42thought> so we should stabilize llvm, then?
[08:55:43] <abaumann> stabilize is just putting things into tested?
[08:55:56] <deep42thought> no, from testing to stable
[08:56:11] <abaumann> I see clang and llvm-ocaml 6.0.0 in stable, but only llvm and llvm-libs 5.0.1 in stable.
[08:56:19] <abaumann> I don't really understand, why this can happen.
[08:56:21] <deep42thought> [staging] --unstage--> [testing] --stabilize--> [stable]
[08:56:44] <abaumann> I sent stabilize emails, but they didn't work.
[08:56:48] <deep42thought> each binary packages is considered by itself for moving or staying
[08:56:56] <deep42thought> so split packages may get splitted
[08:57:03] <deep42thought> hrmm :-/
[08:57:08] <abaumann> this doesn't make any sense.
[08:57:19] <deep42thought> hmm?
[08:57:24] <abaumann> they are built against the same source, so they must be moved together.
[08:57:47] <abaumann> https://packages.archlinux32.org
[08:57:48] <phrik> Title:email-log (at packages.archlinux32.org)
[08:57:56] <abaumann> I see two stablize with sucess 1 and count 0
[08:58:16] <abaumann> I have to put 'stabilize: llvm-libs-6.0.0-4.0-i686.pkg.tar.xz' into the mail, right?
[08:58:26] <deep42thought> I think so
[08:58:30] <deep42thought> let me re-check
[08:59:09] <abaumann> and the script then says '--tested', so this should move the package to stable.
[08:59:23] <deep42thought> this will mark the package as tested
[08:59:34] <deep42thought> if it is moved depends on the dependent packages and the dependencies
[08:59:50] <abaumann> there is no 'forced move'?
[08:59:56] <deep42thought> not by email
[08:59:59] <abaumann> :-)
[09:00:11] <deep42thought> do you wish for one?
[09:00:21] <abaumann> not really.
[09:00:26] <deep42thought> but in my experience, force-move mostly broke more stuff :-D
[09:00:34] <abaumann> I think, things should work automatically.
[09:00:44] <abaumann> So we should find out, why the thing gets blocked..
[09:01:06] <deep42thought> "why-don't-you" would be a great help here
[09:01:10] <abaumann> And why it thinks clang 6.0 can be moved without breaking a library dependency to llvm-libs
[09:01:21] <deep42thought> but I didn't have a brilliant idea yet how to reimplement this with the db
[09:04:31] <abaumann> the testing llvm and llvm-libs work, no problem, I'll use those for now.
[09:14:13] -!- oaken-source has joined #archlinux32
[09:27:32] * buildmaster resumes sanity.
[10:14:10] -!- oaken-source has quit [Quit: Lost terminal]
[11:24:08] -!- oaken-source has joined #archlinux32
[11:30:22] -!- abaumann has parted #archlinux32
[11:42:48] -!- eduardoeae has joined #archlinux32
[11:42:51] -!- deep42thought has quit [Quit: Leaving.]
[11:57:28] -!- oaken-source has quit [Ping timeout: 240 seconds]
[12:29:56] <buildmaster> btrfs-progs is broken (says buildknecht2).
[12:51:25] <buildmaster> linux is broken (says rechenknecht).
[12:56:52] <buildmaster> linux-zen is broken (says rechenknecht).
[13:00:41] <buildmaster> deepin-daemon is broken (says rechenknecht).
[13:02:46] <buildmaster> virtualbox-modules-arch is broken (says rechenknecht).
[13:11:29] -!- chromicant has joined #archlinux32
[13:29:04] -!- abaumann has joined #archlinux32
[13:29:04] <buildmaster> Hi abaumann!
[13:38:44] <buildmaster> virtualbox is broken (says buildknecht2).
[13:43:57] -!- oaken-source has joined #archlinux32
[13:44:37] -!- deep42thought has joined #archlinux32
[13:44:37] <buildmaster> Hi deep42thought!
[13:56:46] -!- davor has quit [Ping timeout: 264 seconds]
[14:02:49] -!- davor has joined #archlinux32
[14:03:26] <tyzoid> good morning
[14:03:54] <deep42thought> good morning, tyzoid
[14:04:31] <abaumann> morning :-)
[14:05:43] <tyzoid> the reimage successfully completed
[14:05:58] <tyzoid> After several attempts and a faulty kvm switch
[14:09:39] <tyzoid> wtf
[14:09:44] <tyzoid> visudo opens nano??
[14:09:56] <deep42thought> where?
[14:10:06] <tyzoid> on debian
[14:10:06] <deep42thought> I might have exported EDITOR=nano in some of your vms
[14:10:13] <deep42thought> ok, not there
[14:10:15] <tyzoid> no, on my newly created host
[14:10:29] <tyzoid> I don't care about the vms so much
[14:10:42] <deep42thought> ok :-)
[14:13:31] <tyzoid> abaumann: When I spin up your vm, do you need an public ipv4?
[14:14:02] <tyzoid> otherwise, I'll put it behind a nat
[14:26:40] <abaumann> aeh. the buildmaster might need access to it..
[14:26:49] <deep42thought> huh?
[14:26:56] <deep42thought> the other way round, I think
[14:27:02] <abaumann> aeh. yeah.
[14:27:04] <deep42thought> :-D
[14:27:25] <deep42thought> as soon as the buildmaster wants to access some build slave, it went really insane
[14:27:30] <abaumann> mmh. how can I access the VM without a public IP? Do you have some jump station in place?
[14:27:38] <abaumann> :-)
[14:27:48] <deep42thought> forward a port?
[14:27:53] <abaumann> fine for me.
[14:28:29] <abaumann> my question would be.. how can I set it up? Or is this the first test for the i486-ISO of mine? :-)
[14:30:13] <tyzoid> I've got a hypervisor
[14:30:26] <tyzoid> problem is I was having trouble setting up additional users when I last tested it
[14:30:39] <tyzoid> if I can set you up a user account with access to the one vm, I'll get that set up
[14:31:11] <abaumann> ok. I tested lately a lxc-create with archlinux 32, that should also work.
[14:31:40] <tyzoid> if you've got an lxc image, I can import that directly
[14:32:02] <abaumann> or, we can also downgrade a i686 Archlinux to i486. Did that once by accident. :-)
[14:32:10] <tyzoid> lol, nice
[14:35:04] -!- chromicant has quit [Quit: ZNC 1.6.6 - http://znc.in]
[14:38:04] <abaumann> mmh. ok. The lxc template needs a little bit of fiddling, so does the hosts /etc/pacman.conf
[14:38:30] <tyzoid> though the lxc is a container, so that wouldn't really work given an x86_64 host
[14:38:31] <tyzoid> iirc
[14:38:43] <abaumann> I'm on a i486 host. :-)
[14:38:52] <abaumann> i686, with faked Architecture
[14:39:15] <abaumann> I have only a key signing problem at the moment, my 486 repo has no signatures yet..
[14:42:55] <deep42thought> can't you just sign them manually with your regular build key?
[14:43:08] <abaumann> yes. that's what I did just now.
[14:43:12] <deep42thought> :-)
[14:43:17] <tyzoid> :P
[14:43:35] <abaumann> and I had to add the archlinux32 keyring to the lxc-template scripts and populate the keys.
[14:43:45] * tyzoid idiotically tried to connect the new proxmox system to a shared cluster before properly setting up the ip interfaces
[14:45:36] <abaumann> mmh. uname and /proc/cpuinfo faking in a 486 container on a 64-bit host, yes. this is maybe not a good idea..
[14:46:17] <deep42thought> well, if you can fake i686 on x86_64 and fake i486 on i686, I don't see, why i486 on x86_64 should not work
[14:46:28] <tyzoid> risky command of the day: `/etc/init.d/networking restart` over an ssh connection :P
[14:46:36] <deep42thought> :-D
[14:46:44] <deep42thought> !grab tyzoid
[14:46:44] <phrik> deep42thought: Tada!
[14:46:52] <tyzoid> lol
[14:47:00] <abaumann> ui.
[14:47:46] -!- oaken-source has quit [Ping timeout: 256 seconds]
[14:47:48] <abaumann> yeah, but I'll need a utsname patch somewhere in glibc as I cannot use the kernel module uname hack from LFS.
[14:48:06] <deep42thought> ah, right
[14:48:46] <abaumann> I remember oaken-source mentioned some tricks.. I'll try to remember does. Ah, yeah. binfmt.
[14:52:39] <abaumann> ok. Archlinux has no lxd? only in the AUR?
[14:52:40] <abaumann> ok.
[15:03:30] -!- oaken-source has joined #archlinux32
[15:16:22] <abaumann> uff. mixing stat buffer on the stack for stack smashing fun in libgit2. hard to find.
[15:55:00] <abaumann> tyzoid: lxc-create created containers and lxc from lxd don't seem to play well together. I can tar the /var/lib/lxc/486 directory which contains a config and a rootfs..
[16:00:25] -!- oaken-source has quit [Quit: leaving]
[16:16:08] <deep42thought> Does anyone have an idea how to improve the performance of the following command: git log -n 1 --pretty=format:%ct $commit -- $file
[16:18:23] <tyzoid> what are you trying to obtain from it?
[16:18:28] <tyzoid> the commit that last touched a file?
[16:18:29] <deep42thought> the commit-date
[16:18:33] <deep42thought> yes
[16:18:57] <deep42thought> but the issue might be slow file-i/o again
[16:19:08] <deep42thought> the command runs within 1sec on my box over here :-/
[16:19:24] <deep42thought> ... and runs for several minutes now on the buildmaster
[16:19:52] <abaumann> it's fast when I try it.
[16:20:06] <deep42thought> try on community
[16:20:16] <deep42thought> for some package that was last modified in 2015
[16:20:22] <deep42thought> then it gets slower ;-)
[16:20:35] <tyzoid> which repo is it?
[16:20:43] <deep42thought> the community package repository
[16:20:49] <tyzoid> https://github.com ?
[16:20:50] <phrik> Title:GitHub - archlinux32/packages: package customizations and pure-i686 packages (at github.com)
[16:20:54] <deep42thought> git://git.archlinux.org
[16:20:58] <deep42thought> is bigger :-D
[16:21:29] <deep42thought> but still: it's a lot faster on my box than on the buildmaster
[16:40:10] <tyzoid> deep42thought: took 7s on my system
[16:40:33] <deep42thought> yes, that's reasonable and totally ok
[16:40:51] <tyzoid> still slower than I'd expect, though
[16:40:52] <deep42thought> ok, so I'll go looking for the cause elsewhere
[16:41:23] <deep42thought> everything will get faster with eschwartz' new source layout :-)
[16:42:21] <abaumann> yeah. but I really hope we will not loose the git history. because it's sometimes really important to see, what has been done to a package. maybe a read-only historical git repo?
[16:42:54] <deep42thought> oh, I haven't thought of that O.o
[16:43:32] <abaumann> I hope, eschwartz did. :-)
[16:59:21] -!- deep42thought has quit [Quit: Leaving.]
[17:01:46] <tyzoid> abaumann: Are you planning on building this from an iso of some sort?
[17:01:58] <tyzoid> or do you want an iso mounted to help bootstrap?
[17:09:21] <abaumann> I have a lxc container installed, but lxc from lxd doens't allow me to export it.
[17:09:35] <abaumann> yeah. I could bootstrap with the 486 ISO.
[17:10:40] <abaumann> I really don't know proxmox, so I cannot really tell, what's easiest.
[17:10:59] <tyzoid> abaumann: ssh over to abaumann@srv0.tyzoid.com
[17:11:09] <tyzoid> password is password1. It'll ask you to change your password
[17:12:23] <tyzoid> let me know when you've changed it
[17:12:32] <buildmaster> geany-plugins is broken (says buildknecht2).
[17:12:34] <abaumann> I did.
[17:12:35] <abaumann> Could not chdir to home directory /home/abaumann: No such file or directory
[17:12:57] <tyzoid> Yup. It's an ssh-endpoint with no home, set so that only password changes are allowed
[17:13:02] <abaumann> I'm homeless. :-)
[17:13:07] <abaumann> ah.
[17:13:07] <tyzoid> hop on https://srv0.tyzoid.com:8006 with your user/pass
[17:13:09] <phrik> Title:srv0 - Proxmox Virtual Environment (at srv0.tyzoid.com:8006)
[17:13:37] <tyzoid> you should see a vm of id 100, of type (486)
[17:14:01] <abaumann> ever tried that with a seamonkey in 800x400 resolution? ;-)
[17:14:14] <tyzoid> :/
[17:14:16] <tyzoid> that sounds terrible
[17:14:31] <abaumann> ah. sweet. I'm in.
[17:14:53] <tyzoid> Yup. Right now it'll fail to boot, but it gives you a vnc / console view via novmc
[17:14:56] <tyzoid> novnc*
[17:15:13] <abaumann> ah. right.
[17:15:13] <tyzoid> if you send me a link to the iso, I'll mount it for you
[17:16:41] <abaumann> http://archlinux32.andreasbaumann.cc
[17:19:12] <tyzoid> wow, that's one slow server
[17:19:27] <tyzoid> 4mbit down on that connection :/
[17:19:45] <abaumann> yeah. sorry. in theory, it should be 10mbit..
[17:19:51] <tyzoid> no prob
[17:19:59] <abaumann> ..but the machine is a little bit busy with something (have to check)
[17:20:00] <tyzoid> I'm used to having symmetric gigabit on my servers :P
[17:20:18] <tyzoid> no problem, it'll finish in due course. Depends how log you're willing to wait :P
[17:20:22] <abaumann> *10MB/s
[17:20:33] <abaumann> I have time.
[17:20:40] <tyzoid> Well, to be fair, this is a transatlantic transfer
[17:20:50] <abaumann> I recently PXE/TFTP booted a kernel on a 64 MB machine with a SLOW network card.
[17:20:54] <abaumann> took 25 minutes. :-)
[17:21:02] <tyzoid> at least it's only 64mb
[17:22:15] <tyzoid> Do you have an rsync endpoint?
[17:22:20] <abaumann> mmh. nope.
[17:22:35] <tyzoid> If you want, I can mirror your i486 and archi486isos dirs stateside
[17:22:37] <abaumann> but that mirror is anyway not really official. I'm using it for local testing.
[17:22:50] <tyzoid> well "local" being halfway across the world xD
[17:22:56] <abaumann> I would be glad to. But they are still a little bit preliminary.
[17:23:11] <tyzoid> I would add them to a separate domain
[17:23:16] <tyzoid> Mostly just to speed things up for your tesitng
[17:23:26] <tyzoid> so it goes over a local gigabit connection instead of a transatlantic 4mbit one
[17:23:42] <tyzoid> up to you, though
[17:23:47] <abaumann> it's 1.7 GB of data.
[17:23:51] <abaumann> + the ISO
[17:24:01] <abaumann> stage1 to stage4 I should remove..
[17:24:17] <abaumann> ..they are not ment to be used by anybody
[17:24:17] <tyzoid> I've got 1.5tb free storage on the srv1 hypervisor
[17:24:25] <tyzoid> 1.7gigs is nothin
[17:24:25] -!- davor has quit [Ping timeout: 256 seconds]
[17:24:31] <abaumann> cool :-)
[17:24:54] <tyzoid> 8min 20s to go, btw
[17:25:40] <abaumann> I have time. :-)
[17:29:59] -!- davor has joined #archlinux32
[17:35:24] <tyzoid> abaumann: the iso is mounted, want to start it up?
[17:36:20] <abaumann> ok. I give it a try..
[17:37:55] <tyzoid> :/
[17:38:53] <abaumann> ok. I have definitely to try this with a bigger monitor..
[17:39:14] <abaumann> be right back in 1/2 hour. I have to hurry anyway.. battery problems..
[17:39:17] <abaumann> cu
[17:39:19] -!- abaumann has quit [Quit: leaving]
[17:39:19] <tyzoid> k
[18:03:45] -!- abaumann has joined #archlinux32
[18:03:46] <buildmaster> Hi abaumann!
[18:03:57] <tyzoid> wb
[18:04:00] <abaumann> thanks.
[18:04:08] <abaumann> now with a much bigger screen :-)
[18:04:22] <tyzoid> fixed it, apparantly the disk doesn't support raw access, so I set it to have a writethrough cache.
[18:04:24] <abaumann> i like proxmox. nice interface.
[18:04:31] <tyzoid> yup
[18:04:51] <tyzoid> It's annoying that they push you very hard toward getting a license
[18:04:56] <tyzoid> even though it's gpl'd
[18:05:17] <tyzoid> I needed to patch out the 'you have no subscription' warning popup, which normally happens every time you log in
[18:05:33] <abaumann> I see the ISO splash screen. :-)
[18:05:40] <tyzoid> :)
[18:05:54] <tyzoid> ok, so there's no dhcp on the internal network
[18:06:05] <abaumann> aha.
[18:06:12] <tyzoid> so for ipv4, you'll need to configure 10.10.10.2 as your ip, gateway 10.10.10.1
[18:06:24] <tyzoid> ipv6 is also available internally, if you want that
[18:06:37] <abaumann> ok.
[18:08:50] <abaumann> I have a network.
[18:08:56] <tyzoid> sweet
[18:09:14] <tyzoid> lmk if you want any ports forwarded, and I can set that up for you.
[18:09:43] <abaumann> thanks. not at the moment.
[18:09:53] <abaumann> ah /proc/cpuinfo shows 486
[18:10:04] <abaumann> do does uname -a
[18:10:07] <abaumann> this is perfect. :-)
[18:10:18] <tyzoid> :)
[18:10:33] <tyzoid> Glad to help. Proxmox is pretty awesome, imo
[18:11:04] <abaumann> yeah. the fact it works on my eeepc inside seamonkey is a really good sign.
[18:11:14] <tyzoid> When you're done with the set-up, you should be able to unmount the cd yourself if you go to the hardware options
[18:11:22] <tyzoid> but if not, let me know and I can unmount it
[18:11:26] <abaumann> ok
[18:19:50] <tyzoid> abaumann: btw, if you wanted ipv6, fdab:1::0 is the gateway, and you can give yourself fdab:1::1 (netmask 64)
[18:21:43] <abaumann> ipv4 fits well to a 486 VM :-)
[18:21:57] <abaumann> but maybe I'll test just to make sure IPV6 works..
[18:22:00] <tyzoid> yup. Just giving you the details in case you wanted it
[18:22:09] <abaumann> thanks
[18:22:15] <tyzoid> I can optionally route you an entire /64
[18:22:20] <tyzoid> public /64, that is
[18:22:31] <tyzoid> I've got a /48 allocated to my host
[18:22:52] <abaumann> wow.
[18:23:27] <tyzoid> yeah, fun stuff xD
[18:23:54] <abaumann> I'm still jugging 8+4 IPs4 between servers at work..
[18:23:59] <abaumann> ..not that fun, really.
[18:24:28] <tyzoid> ipv4 can get tricky, just by the limited number of 'em
[18:24:48] <tyzoid> I've got a /29 and a /30 both on-link for a total of 6 usable addresses.
[18:25:03] <tyzoid> only really using 2 of 'em right now (one for each host)
[18:33:57] <abaumann> mmh. where is the eject cdrom?
[18:34:12] <tyzoid> should be under hardware
[18:34:19] <tyzoid> if you look at the cd/dvd drive
[18:34:28] <tyzoid> you can click that, then go to 'edit'
[18:34:45] <abaumann> ah. there.
[18:35:52] <abaumann> wheee. it's a booting vm.. :-)
[18:36:27] <abaumann> you have a remote port to ssh to it?
[18:38:52] <abaumann> no worry, no hurry. :-)
[18:38:53] <tyzoid> I can set that up
[18:39:06] <abaumann> don't you get a mess with port allocation?
[18:40:31] <tyzoid> iptables :P
[18:42:48] <tyzoid> alright, srv0.tyzoid.com:2202 is forwarded to your host on both iv4 and v6 (if/when you set that up)
[18:42:53] <tyzoid> abaumann: ^
[18:43:16] <tyzoid> I can remap that to port 22 on your host if you want
[18:43:51] <tyzoid> actually, I already mapped it
[18:43:58] <abaumann> yeah. that would be good.
[18:43:59] <tyzoid> ok so ssh to that port should work
[18:44:05] <tyzoid> assuming you've got an ssh daemon
[18:44:17] <abaumann> just setting it up.
[18:44:24] <abaumann> and I should add a firewall to the VM :-)
[18:44:33] <tyzoid> I've got a firewall on the host
[18:44:39] <tyzoid> it's natted :P
[18:45:05] <abaumann> ssh: connect to host srv0.tyzoid.com port 2202: Network is unreachable
[18:45:14] <tyzoid> is your ssh server running?
[18:45:25] <abaumann> yes.
[18:45:32] <abaumann> listening on port 22
[18:47:30] <tyzoid> hmm
[18:47:39] <tyzoid> it's the same exact setup on the other server :/
[18:47:53] <abaumann> then it must be the vm doing something funny.
[18:48:10] <tyzoid> It's more than likely something I"m doing
[18:48:18] <tyzoid> since iptables is showing 0 packets on that rule
[18:49:51] <tyzoid> -A PREROUTING -d 192.111.148.210/32 -p tcp -m tcp --dport 2202 -j DNAT --to-destination 10.10.10.2:22
[18:50:00] <tyzoid> the rule looks the same to me as it does on my other system, though
[18:50:23] <abaumann> Do I have the right netmask? 10.10.10.2/24
[18:50:35] <tyzoid> netmask should be 16, but that shouldn't be a problem
[18:51:57] <abaumann> an accept missing for port 22 for the VM?
[18:53:26] <tyzoid> not sure, the vm shouldn't have a default deny, though
[18:53:35] <tyzoid> I'm able to hit 22 from the server on 10.10.10.2, though
[18:53:46] <tyzoid> so I highly suspect something off on my side.
[18:54:19] <abaumann> debug1: connect to address 192.111.146.210 port 2202: Connection refused
[18:54:35] <abaumann> ah the network unreachable is because I don't have IPv6 of course.
[18:55:58] -!- davor has quit [Ping timeout: 256 seconds]
[18:56:15] <tyzoid> well everything up to you is dual-stack
[18:56:22] <tyzoid> so both should work
[18:56:30] <tyzoid> I see you're connecting in to the web interface via ipv4
[18:56:46] <abaumann> yep.
[18:58:10] <tyzoid> damn
[18:58:12] <tyzoid> I mistyped it
[18:58:22] <tyzoid> 192.111.146.210, not 192.111.148.210
[18:58:24] <tyzoid> one sec
[18:58:29] <abaumann> oh. :-)
[18:59:00] <tyzoid> alright, should be fixed
[18:59:01] <abaumann> work.
[18:59:04] <abaumann> *works
[18:59:06] <abaumann> :-)
[18:59:18] <tyzoid> as I said, likely something on my side :P
[18:59:56] <tyzoid> btw, the console has mouse/keyboard support, so if you wanted to test a gui, you could
[19:00:19] <abaumann> ok.
[19:01:09] <abaumann> first I have to build 486 packages for X11 :-)
[19:01:16] <tyzoid> yup, lol
[19:01:45] <tyzoid> ping me if you get that rsync endpoint set up. Might make updates/stuff more enjoyable
[19:01:45] <abaumann> thanks for setting up. :-)
[19:01:54] <tyzoid> no prob. Ping me if you need anything else :P
[19:01:56] <abaumann> yes. will do.
[19:02:45] -!- davor has joined #archlinux32
[19:18:40] -!- belanthor has joined #archlinux32
[19:29:17] -!- deep42thought has joined #archlinux32
[19:29:17] <buildmaster> Hi deep42thought!
[20:13:20] <deep42thought> "Could not remove /usr/lib/modules/4.15.15-1.0-ARCH/kernel/drivers/hwmon/pmbus/max31785.ko.xz (operation not permitted)"
[20:13:34] <deep42thought> strange, I have never seen something similar before
[20:43:23] <abaumann> lsattr?
[20:44:12] <abaumann> or try an strace on rm /usr... and check the error codes.
[20:53:54] <deep42thought> I can't
[20:54:00] <deep42thought> the computer crashed in the meantime :-D
[21:01:50] <abaumann> oh. :-)
[21:01:54] <tyzoid> :(
[21:02:07] <abaumann> maybe a corrupt filesystem switched to read-only then?
[21:02:22] <tyzoid> or could be some fuse-mount
[21:02:45] <tyzoid> But yeah, usually there's some extended attributed preventing deletion
[21:03:38] -!- yans has joined #archlinux32
[21:04:09] <tyzoid> deep42thought: new srv0 hypervisor has been set up, btw.
[21:04:14] <tyzoid> abaumann has his i486 vm
[21:04:20] <abaumann> *grin*
[21:04:28] <deep42thought> :-D
[21:04:52] <tyzoid> Are we at the point where we need another build-slave?
[21:06:04] <abaumann> The question is more, can the buildmaster deal with more architectures?
[21:08:07] <deep42thought> well, ...
[21:08:08] <abaumann> and oaken-source mentions ~750 packages, I just have 326 (and I also think I'm covering whole base and base-devel).
[21:08:37] <abaumann> I have a gcc-gnat, vala bootstrapping issue and nss which doesn't compile on i486.
[21:08:39] <deep42thought> I think one build slave more would not be wrong
[21:08:51] <deep42thought> and the database is not yet ready to handle i486, too :-/
[21:09:14] <deep42thought> there are still some "known issues" (known to me), which are no issue if it's single-arch
[21:09:30] <abaumann> I wondered, can the buildmaster be cloned?
[21:09:42] <deep42thought> in principle: yes
[21:09:47] <deep42thought> but I would not want to do that
[21:10:02] <deep42thought> because, we're already duplicating any from upstream
[21:10:02] <abaumann> It would create a mess on the long term, agreed.
[21:10:58] <buildmaster> cinnamon-settings-daemon is broken (says rechenknecht).
[21:11:58] <abaumann> ls -al /etc/ca-certificates/extracted/tls-ca-bundle.pem
[21:11:58] <abaumann> -r--r--r-- 1 root root 0 Apr 19 16:26 /etc/ca-certificates/extracted/tls-ca-bundle.pem
[21:12:01] <abaumann> oups. :-)
[21:12:09] <deep42thought> besides: the principal design allows multiple architectures - it's just, that at some points, it's not yet implemented cleanly
[21:12:17] <abaumann> in the 486 version only,
[21:12:28] <deep42thought> abaumann: who needs that?
[21:12:34] <abaumann> git
[21:12:54] <abaumann> those are the bundles created via nss, which is a *sh* piece of software..
[21:13:03] <deep42thought> :-D
[21:14:00] <abaumann> luckily PEM is ASN.1 :-)
[21:14:13] <abaumann> So I can copy it from another machine.
[21:14:54] <deep42thought> regarding making the buildmaster multi-arch: I'd propose to give repositories an architecture colum, too, then the data should be properly representable in the database
[21:15:02] <deep42thought> https://buildmaster.archlinux32.org
[21:15:25] <abaumann> ah something like multiarch?
[21:15:35] <deep42thought> hmm?
[21:15:36] <abaumann> core-486 or so?
[21:15:44] <deep42thought> yes
[21:15:49] <deep42thought> at least in the database
[21:15:59] <deep42thought> the directory would be i486/core/...
[21:16:05] <deep42thought> as it's i686/core/... now
[21:16:23] <deep42thought> and when we decide to add "pentium3" we'd have pentium3/core/..., too
[21:16:43] <abaumann> dependencies between those repos is not an issue (there should be none)
[21:16:49] <abaumann> no dependencies I mean
[21:17:06] <deep42thought> dependencies are between binary_packages
[21:17:10] <deep42thought> not between repositories
[21:17:25] <abaumann> ah. yep.
[21:17:38] <deep42thought> and as long as we don't want to put i486 packages into a separate table, we could have those dependencies in principle
[21:17:45] <abaumann> binary package also has a reference to architectures..
[21:17:51] <deep42thought> yes
[21:18:02] <abaumann> so they are labelled with an architecture.
[21:18:04] <abaumann> that's good.
[21:18:12] <deep42thought> the idea was, that a "i686" binary_package could be in "pentium3" repository
[21:18:15] <deep42thought> if we'd decided to
[21:18:34] <deep42thought> e.g. if the binaries are identical
[21:18:38] <deep42thought> then this would make sense
[21:19:03] <deep42thought> hmmm
[21:19:17] <deep42thought> the link between binary_packages and repositories would be n:m, then
[21:20:30] <deep42thought> btw: build_assignments has an architecture, too - and it's intentional
[21:20:41] <deep42thought> this marks, which build slave can/should compile the package
[21:21:12] <deep42thought> e.g. you could have a split package: xy i486/i686 and xy-doc any
[21:21:50] <deep42thought> then this would be two build-assignments (i486 and i686) with xy-doc only linked to one of those
[21:21:58] -!- davor has quit [Ping timeout: 264 seconds]
[21:22:02] <abaumann> so, if a slave compiles a 'any' package for 'i486' it would still end up with architecture 'i486'?
[21:22:10] <deep42thought> no
[21:22:24] <abaumann> mmh.
[21:22:31] <deep42thought> only the build_assignment may be marked "i486" indicating, that only i486 slaves should get it
[21:22:48] <abaumann> ah.
[21:23:20] <deep42thought> on the other hand, this could be easily determined by a join on binary_packages<->build_assignments
[21:23:28] <abaumann> how can python-tqdm be architecture any?
[21:23:40] <deep42thought> is it?
[21:23:45] <abaumann> yes.
[21:24:17] <abaumann> ok. if it contains only .py files and the hook creates the architecture specific files?
[21:25:13] <abaumann> I find 'any' superfluos. Most packages are most likely platform-dependend in some way.
[21:25:17] <deep42thought> does it contain ELF?
[21:25:37] <deep42thought> *-doc is not
[21:25:52] <abaumann> yeah. doc packages are sort of a new thing in Arch.
[21:25:56] <deep42thought> but funnily upstream's db-tools does not support different architectures on split packages
[21:25:57] <abaumann> like -lib.
[21:26:24] <abaumann> mmh. only pyo and pyc files.
[21:26:42] <abaumann> and a python script in bin.
[21:28:46] -!- davor has joined #archlinux32
[21:29:25] <abaumann> yeah. bytecode is not platform dependend. fair enough.
[21:29:49] <deep42thought> ok, I think, we really need the n:m mapping binary_packages<->repositories and also the link repositories->architectures
[21:30:01] <tyzoid> I think that's going to get ugly
[21:30:21] <deep42thought> suggestions?
[21:30:26] <abaumann> what I don't like is: it's a little bit risky just to add a funny 486-case.
[21:30:49] <tyzoid> Not sure if this is any better, but have a virtual package table which handles the mapping
[21:30:53] <deep42thought> abaumann: what "funny i486 case" do you have in mind?
[21:31:06] <tyzoid> so you still have one record for every package in the database
[21:31:14] <deep42thought> tyzoid: that's what I mean with n:m mapping
[21:31:16] <tyzoid> since the file itself gets duplicated in the repos
[21:31:18] <deep42thought> how else is it done?
[21:31:35] <abaumann> from the db-model-view I cannot see how you could to it differently.
[21:31:44] <deep42thought> I'd introduce a table similar to "install_target_providers"
[21:31:53] <tyzoid> Ok, that sounds fair
[21:32:11] <deep42thought> "binary_package_repository_symlinks"
[21:32:14] <deep42thought> or something like that
[21:32:15] <abaumann> and linking repositories to architectures also makes sense.
[21:32:54] <abaumann> is install_target_providers not affected too?
[21:33:19] <deep42thought> the plot is a little confusing
[21:33:21] <tyzoid> what do you think about linking package to architecture instead of repo to architecture?
[21:33:37] <deep42thought> they are linked
[21:33:54] <tyzoid> 1:1 link? or 1:n link?
[21:34:31] <deep42thought> I'm not familiar with these termes - what is "1:1"?
[21:34:44] <tyzoid> each package has one and exactly one architecture
[21:34:47] <deep42thought> each binary_package has one architecture
[21:35:04] <deep42thought> yes, only one
[21:35:12] <tyzoid> why not have binary_package specify multiple architectures?
[21:35:29] <deep42thought> I'm just confused by the symmetry of "1:1", but not the symmetry of the meaning of "1:1"
[21:35:30] <abaumann> because binary packages could live in different versions in parallel?
[21:35:44] <deep42thought> yes
[21:36:11] <tyzoid> i.e. an any package
[21:36:26] <tyzoid> or an ('pentium3' 'i686') package
[21:36:46] <tyzoid> It'd require a package_architecture linking table
[21:37:03] <tyzoid> with binary_package_Id in one column, and architecture_id in the other
[21:37:20] <tyzoid> That way, we don't have duplicate records for each repo in multiple architectures
[21:38:30] <deep42thought> I don't see a problem with multiple repos for different archs
[21:38:38] <deep42thought> we have them in the filesystem, too
[21:39:31] <tyzoid> yeah, but I think it'd be nice for us to move to the reposatory pool setup like upstream had
[21:39:53] <tyzoid> then we can just simlink/hardlink as needed
[21:40:08] <tyzoid> to reduce duplication of packages across architectures
[21:40:15] <deep42thought> huh?
[21:40:25] <deep42thought> we can/must introduce pool/ anyway
[21:40:30] <tyzoid> That might be nice when you consider things like flightgear-data or 0ad-data
[21:40:37] <deep42thought> and then the mirror layout makes no difference
[21:41:05] <tyzoid> deep42thought: The idea is that instead of putting all the packages directly in the repo folders, we put them all in a pool folder
[21:41:15] <tyzoid> then link into the pool folder with symlinks
[21:41:29] <deep42thought> yes
[21:41:38] <deep42thought> but that is independent of any other decisions
[21:41:47] <deep42thought> we would do this anyway
[21:41:54] <deep42thought> (because it has no disadvantages)
[21:42:29] <deep42thought> and then a n:m link table binary_packages <-> repositories (with architecture) makes even more sense, because it's closer to what we have on the mirror
[21:42:43] <deep42thought> it would be a listing of all symlinks in the repository folders
[21:43:17] <tyzoid> exactly
[21:44:28] <deep42thought> ah, ok, I think I just misread, what you wrote in the beginning
[21:44:46] <deep42thought> but I'd still assign only a single architecture to a binary_package
[21:44:47] <tyzoid> Yeah, I was confused why you were confused when you seemed to be saying the same thing :P
[21:44:56] <deep42thought> and it may be compatible to other architectures, still
[21:45:25] <tyzoid> I think it makes sense to attach multiple architectures to binary_package, if we are re-using the same package
[21:45:48] <deep42thought> so we'd have some kind of (partial) order: any > i486 > i686 > pentium3
[21:45:50] <tyzoid> the question still is, does 'any' mean we can re-use the binary package? or does 'any' mean it can be compiled on any architecture?
[21:46:05] <deep42thought> the former
[21:46:26] <tyzoid> Isn't it theoretically possible for a package to do feature detection on compilation?
[21:46:34] <deep42thought> yes
[21:46:40] <tyzoid> so if compiled on i686, it might enable sse2, but on i486, it wouldn't?
[21:46:41] <deep42thought> then it's arch=(i686 x86_64)
[21:46:42] <abaumann> even in practive *grrr*
[21:46:46] <deep42thought> and get compiled twice
[21:46:46] <abaumann> *practive
[21:47:05] <deep42thought> we already have that
[21:47:20] <tyzoid> I'm saying not just for array-specifiers, but (any) specifiers.
[21:47:23] <abaumann> there are even the special cases which check what code the compiler can produce without checking the platform.
[21:47:24] <deep42thought> the least packages with arch=(i686 x86_64) have an actual difference in their pkgbuild
[21:47:45] <deep42thought> no, "any" means: "same 'binary' on every architecture"
[21:48:04] <abaumann> yes. because everything can always be compiled on any platform.
[21:48:19] <deep42thought> ... as long as you actually compile :-D
[21:48:27] <abaumann> this is also hardwired in pacman I thing: if no package is found for 'architecture', try 'any'
[21:48:35] <abaumann> *think
[21:48:37] <tyzoid> interesting
[21:49:02] <tyzoid> "If a package is architecture-independent in its compiled state (shell scripts, fonts, themes, many types of extensions, etc.) then use arch=('any'). Please note that, as this is intended for packages that can be built once and used on any architecture, it will cause the package to be labeled -any as opposed to -x86_64, etc."
[21:49:09] <tyzoid> https://wiki.archlinux.org
[21:49:09] <phrik> Title:PKGBUILD - ArchWiki (at wiki.archlinux.org)
[21:49:16] <tyzoid> So you are right there
[21:49:39] <tyzoid> So then we would only have one architecture per binary_package, just that that arch might be 'any'
[21:49:45] <tyzoid> but then the issue is that can mess with selects
[21:49:55] <tyzoid> since then we'd have to account for 'any' as a join condition
[21:50:16] <deep42thought> I'd introduce an architecture_order table
[21:50:45] <deep42thought> e.g. "any" runs on "i686" "i486"; "i486" runs on "i486" "i686"; "i686" runs on "i686"
[21:50:46] <tyzoid> I think that just convolutes the whole thing without adding much value. At least, not from what I can see.
[21:51:02] <abaumann> 'any' would also run on 'armv7'
[21:51:15] <abaumann> that's why I don't like 'any', it just adds another 'if'..
[21:51:29] -!- oaken-source has joined #archlinux32
[21:51:31] <tyzoid> but when are we ever goinc to compile a package for i486, then deploy it to i686 repos?
[21:51:32] <abaumann> ..but you would have to convince upstream. :-)
[21:51:51] <tyzoid> Theoretically, yes, it could work, but I don't think it adds much
[21:51:59] <tyzoid> since the only case we'd need to handle is any
[21:52:19] <deep42thought> I can think of a lot i686 packages running on pentium3
[21:52:24] <abaumann> think syslinux which as a 686-compiled-package is actually a 486 package.
[21:53:14] <abaumann> pacman.conf usually contains 'auto' or for '486', 'pentium3'. You cannot add your picking rule into pacman itself..
[21:53:21] <tyzoid> In that case, we should probably have some sort of binary compatable override flag in the pkgbuild
[21:54:11] <deep42thought> ah, crap, you're right: pacman itself will refuse to install an "-i486" package on "i686"
[21:54:37] <abaumann> I was thinking more along the lines: "every package build on a certain architecture, say 486, get's into the 486 bin'.
[21:54:59] <abaumann> This leads to duplication, but on the other hand you don't want to distribute packages into the correct bins..
[21:55:15] <tyzoid> Yeah, so the only ones we can share between architectures is -any packages
[21:55:22] <abaumann> exactly.
[21:56:01] <deep42thought> for i486 I think, duplication is not a big issue
[21:56:22] <deep42thought> but if we ever want to start pentium3 or other stuff, I'd really like to avoid duplication from the beginning
[21:56:35] <abaumann> ..and maybe it's easier to tell people, if you don't have SSE2, ues the 486 generic architeture binaries..
[21:58:00] <abaumann> hey oaken-source: congrats on the finished stage 4 for RISC-V. :-)
[22:00:17] <abaumann> ok, I'm off. CU.
[22:00:19] -!- abaumann has quit [Quit: leaving]
[22:12:07] -!- abaumann has joined #archlinux32
[22:12:08] <buildmaster> Hi abaumann!
[22:12:34] -!- abaumann has quit [Client Quit]
[22:12:38] -!- AndrevS has joined #archlinux32
[22:30:55] -!- deep42thought has quit [Quit: Leaving.]
[22:55:32] <oaken-source> /usr/bin/oslc: error while loading shared libraries: libImath-2_2.so.12: cannot open shared object file: No such file or directory
[22:55:42] <oaken-source> ^ do you see this too?
[22:55:56] <oaken-source> (part of community/openshadinglanguage)
[22:56:00] <tyzoid> on i686?
[22:56:21] <oaken-source> yes
[22:56:24] <tyzoid> it's possible. Both abaumann and deep42thought have left (for the night, I think)
[22:56:39] <tyzoid> Do you get the same error from testing?
[22:56:42] <tyzoid> or are you on testing?
[22:57:10] <oaken-source> not on testing, no
[22:57:19] <oaken-source> I've run into this while building blender
[22:57:38] <tyzoid> buildmaster: wtf liblmath-2_2.so.12
[22:57:44] <buildmaster> Huh, I don't know that one.
[22:58:19] <oaken-source> oh, wow. irssi didn't ping me on abaumann's message earlier
[22:58:22] <tyzoid> Yeah, I think that's related to an llvm change
[22:58:32] <tyzoid> try the one in community-testing
[22:58:44] <tyzoid> https://packages.archlinux32.org
[22:58:46] <phrik> Title:Arch Linux 32 - openshadinglanguage 1.9.8-1.0 (i686) (at packages.archlinux32.org)
[22:58:48] <tyzoid> looks like the links are in order
[22:58:54] <oaken-source> eh, I'd rather wait until the update hits [community]
[22:59:08] <oaken-source> it's nontrivial to teach our build tools to use [testing] repos :)
[22:59:18] <oaken-source> plus I don't think it's a good idea
[22:59:28] <oaken-source> oh, wait, there might be a quick & dirty fix
[22:59:29] <tyzoid> ah, it's a build issue, not a "I'm trying to run the software" issue
[22:59:45] <tyzoid> I mean, deep42thought's solution would more than likely just be to promote it
[23:00:14] <tyzoid> If you can, you can test a pacman -U of the package
[23:00:41] <oaken-source> dothing that right now.
[23:00:56] <oaken-source> the build tools should pick it up if I install it manually into the chroot
[23:03:27] <oaken-source> Total Installed Size: 6.90 MiB
[23:03:27] <oaken-source> Net Upgrade Size: -23.73 MiB
[23:03:32] <oaken-source> ^ looks a bit fishy to me
[23:04:25] <oaken-source> but I'll start a build anyway.
[23:05:44] -!- AndrevS has quit [Remote host closed the connection]
[23:12:43] <oaken-source> tyzoid: openshadinglanguage from testing needs other unsatisfied libs, probably also packages currently in testing
[23:12:50] <tyzoid> :/
[23:12:58] <oaken-source> I *could* chase that rabbit hole
[23:13:07] <oaken-source> or I just wait for the next release :)
[23:13:13] <tyzoid> Yeah, probably means we need a change to the web ui
[23:13:39] <oaken-source> how so?
[23:13:50] <tyzoid> oaken-source: which libs are it complaining about?
[23:14:20] <oaken-source> the version in [community] or in [community-testing]?
[23:14:46] <tyzoid> The one in community-testing
[23:14:49] <tyzoid> let me guess, libOpenImageIO.so.1.8?
[23:14:55] <oaken-source> sounds about right
[23:15:08] <oaken-source> I think that's right, yes
[23:15:43] <tyzoid> oaken-source https://packages.archlinux32.org
[23:15:45] <phrik> Title:Arch Linux 32 - openimageio 1.8.9-2.0 (i686) (at packages.archlinux32.org)
[23:15:49] <tyzoid> should work if you install that out of community testing
[23:15:55] <tyzoid> the rabbit hole ends with that package :P
[23:18:10] <oaken-source> ah, very good
[23:18:27] * buildmaster failed to execute a mysql query - can you have a look at "tmp.mysql-functions.unimportant_query.stdin.2018-04-19T23:18:26.dmYbq1"?.
[23:18:27] * buildmaster failed to execute a mysql query - can you have a look at "tmp.mysql-functions.unimportant_query.stdin.2018-04-19T23:18:27.tc9arm"?.
[23:24:00] <oaken-source> tyzoid: the rabbit hole goes deeper ;)
[23:24:06] <oaken-source> now we're back to the original error
[23:24:18] <tyzoid> you sure the packages didn't revert?
[23:24:22] <oaken-source> yep
[23:24:26] <oaken-source> checked that
[23:24:49] <tyzoid> what's the error you're getting?
[23:24:55] <tyzoid> And what version of blender are you building?
[23:25:25] <oaken-source> oh, damn
[23:25:33] <oaken-source> it's my fault, the issue is in openexr
[23:25:44] <oaken-source> nevermind o_o
[23:25:53] <tyzoid> no prob :)
[23:33:35] -!- oaken-source has quit [Quit: leaving]