#archlinux-ports | Logs for 2017-11-27
Back
[00:29:08] <tyzoid> Okay, so https://pkgapi.arch32.tyzoid.com now works
[00:29:16] <tyzoid> hopefully as expected.
[00:39:29] <tyzoid> XML export is supported
[00:39:31] <tyzoid> https://pkgapi.arch32.tyzoid.com
[00:39:33] <tyzoid> as an example
[00:39:46] <tyzoid> but be wary if you use it: The format is unstable.
[00:43:53] -!- SinusX has joined #archlinux-ports
[00:46:33] -!- SinusX has quit [Client Quit]
[00:53:20] -!- bill-auger_ has quit [Quit: No Ping reply in 180 seconds.]
[00:54:44] -!- bill-auger has joined #archlinux-ports
[01:06:18] -!- bill-auger has quit [Remote host closed the connection]
[01:16:10] <tyzoid> dopsi: Is there a script you use to generate the torrent links?
[03:44:41] -!- bill-auger has joined #archlinux-ports
[03:46:13] <tyzoid> Okay, so I put in a PR for fluxbb: https://github.com
[03:46:14] <phrik> Title: Implement more secure password hashing functionality via password_hash by tyzoid · Pull Request #206 · fluxbb/fluxbb · GitHub (at github.com)
[03:46:31] <tyzoid> and I've already updated the forum with this patch.
[03:47:43] <tyzoid> deep42thought, abaumann: ^ let me know if there's any issues with the forum given that the patch is now live.
[03:50:21] -!- yokel has quit [Ping timeout: 240 seconds]
[03:51:17] -!- yokel has joined #archlinux-ports
[04:34:42] -!- T`aZ has quit [Ping timeout: 260 seconds]
[04:36:12] -!- T`aZ has joined #archlinux-ports
[04:57:01] -!- yokel has quit [Ping timeout: 240 seconds]
[05:37:41] -!- isacdaavid has quit [Quit: Leaving.]
[05:55:57] -!- hringriin_ has joined #archlinux-ports
[05:58:56] -!- hringriin has quit [Ping timeout: 255 seconds]
[05:58:57] hringriin_ is now known as hringriin
[08:40:07] xes__ is now known as xes
[08:50:26] <brtln> FYI, latest gcc add --enable-multilib and has lib32 split package, glibc just the latter, and valgrind depends on lib32-glibc
[08:50:55] <brtln> no idea how you're going to hack it with how your builder works, but I'm open to modifying this upstream
[09:06:00] -!- deep42thought has joined #archlinux-ports
[09:07:41] <deep42thought> brtln: Thanks for the info. I hope, this is not in core, yet?
[09:09:04] <deep42thought> it looks so :-)
[09:10:20] <deep42thought> I think, there is nothing to optimize upstream - we simply need to "revert" all the changes locally
[09:16:27] -!- Vollzornbrot has joined #archlinux-ports
[09:16:40] <Vollzornbrot> hello
[09:16:44] <deep42thought> Hi!
[09:16:53] <Vollzornbrot> all okay?
[09:17:01] <deep42thought> yeah
[09:17:12] <deep42thought> you got my mail regarding the additional dns alias?
[09:17:19] <Vollzornbrot> yes ;)
[09:17:36] <deep42thought> then, all is fine :-)
[09:17:46] <Vollzornbrot> can you check this?
[09:18:43] <deep42thought> ipv4 looks good
[09:19:06] <deep42thought> ah, and I don't have ipv6 on this box here
[09:19:07] <Vollzornbrot> good, god damm! i read anytime your name: deepthroat :P
[09:19:18] <deep42thought> :-D
[09:19:21] <Vollzornbrot> on my root i have no ipv6....
[09:19:39] <deep42thought> right
[09:19:49] <Vollzornbrot> i have an ipv6 but not configured
[09:22:26] -!- abaumann has joined #archlinux-ports
[09:31:55] <abaumann> deep42thought: all ok with the forum :-)
[09:34:39] -!- abaumann has quit [Quit: Page closed]
[09:37:03] <brtln> deep42thought: up to you; I could, for example, move building lib32 to separate function and run it only when $CARCH = x86_64
[09:38:02] <deep42thought> the $CARCH=... logic is not recognized correctly in all cases, anyway
[09:38:08] <deep42thought> so that would not help much :-)
[09:39:36] <brtln> actually it would, because srcinfo doesn't have anything to do with build function, but as I said, your call
[09:40:44] <deep42thought> ah, you mean a _part_ of a function depending on $CARCH?
[09:41:10] <brtln> yes
[09:41:49] <brtln> that would mean you only need to overwrite/modify $pkgname array
[09:42:10] <deep42thought> well, in that case, you could revert the change in line 45,46 -> 38,39 and in @@ -130,16 +121,12 @@
[09:47:48] <deep42thought> but actually, there's still enough, we need to change
[09:47:56] <deep42thought> I'm undecided (as you might notice)
[10:06:42] <deep42thought> brtln: Thanks for your offer, but I think, it's best if we don't rely on upstream providing PKGBUILDs properly building for i686, too - I'll implement all necessary changes in our modifications repository
[10:07:27] <deep42thought> you seem like a nice guy, but who knows, how the next gcc maintainer will treat the i686 specific stuff ;-)
[10:59:39] -!- Vollzornbrot has quit [Remote host closed the connection]
[11:03:07] -!- Vollzornbrot has joined #archlinux-ports
[12:20:56] -!- Vollzornbrot has quit [Quit: Lost terminal]
[12:21:33] <tyzoid> brtln: I'll agree with the above too, it's probably best that we make all our modifications here. The heads up is appreciated, though :)
[13:12:05] <eschwartz[m]> brtln: Speaking of i686 modifications, I cannot help but notice some packages moving towards providing x86_64 binary sources in source=() which is wrong IMHO. This is what source_$CARCH is for and it doesn't matter if the only arch supported is the one being listed, if something is still an architecture-specific source...
[13:39:01] -!- guys has quit [Ping timeout: 240 seconds]
[14:11:44] -!- guys has joined #archlinux-ports
[14:18:58] <fsckd> tyzoid: nice! (re PR). if i read correctly, it rehashes the pwd on successful login? what is the new hash algo?
[14:19:42] <jelle> I believe for php it should be password_hash?
[14:21:29] <fsckd> password_hash seems to use bcrypt by default
[14:21:38] <deep42thought> it does
[15:35:45] <tyzoid> fsckd: yup, rehashes transparently on login
[15:36:36] <brtln> eschwartz[m]: I'm not overlord of arch, you need to report this or tell people they're morons
[15:36:40] <brtln> eschwartz[m]: example package, to satisfy my curiosity who did that?
[15:37:21] <fsckd> tyzoid: nice
[15:37:47] <eschwartz[m]> brtln: example would be flashplugin
[15:38:05] <eschwartz[m]> Granted flashplugin should die in a fery pit, but until then it is still a PKGBUILD...
[15:38:12] <tyzoid> Lol brtln, if only I could grab that
[15:38:13] <eschwartz[m]> So that would be foutrelis
[15:38:39] <brtln> this package is older than source_$CARCH
[15:39:13] <brtln> ah, he changed source_* to source
[15:39:13] <brtln> meh
[15:39:18] <eschwartz[m]> I encourage you to take a look at the last commit to that pkgbase, where it explicitly moved away from source_$CARCH
[15:40:46] <eschwartz[m]> (It was originally migrated to Use architecture-specific sources in Jan 2015 with flashplugin 11.2.202.440-1)
[15:40:57] <brtln> either way, I can't more than poke him (which I did)
[15:41:05] <eschwartz[m]> yeah, that
[15:42:27] <eschwartz[m]> That's good enough, I can't really claim this is like a huge bug anyway, just leaves me feeling vaguely dirty. I could say worse things about the grub PKGBIULD...
[15:42:58] <brtln> make me your new morty, err, friendly president, and I promise i will make arch great again
[15:43:21] <brtln> or I will help get it up off its knees, depending if you prefer polish politics
[15:44:44] * eschwartz[m] votes for brtln
[15:45:42] <brtln> admittedly, gcc now isn't much better than grub now
[15:45:42] * brtln hides
[15:51:44] <eschwartz[m]> gcc is a hundred times better than grub, even considering how much rm's are sprinkled around in aid of split packaging.
[15:52:46] <eschwartz[m]> Though I'm wondering if a few of those rm's should be converted to rm -f's
[15:53:22] <brtln> some have -f, but these are new
[15:53:31] <brtln> I didn't add it everywhere, maybe next time…
[15:54:07] <eschwartz[m]> (That could also make it easier to patch out the x86_64 specific stuff, which is why I mention it. You don't need to patch out a call to rm -f to prevent it from failing to find the files to remove)
[16:03:56] <fsckd> brtln: if you're staging a coup, i will support your bid for power
[16:04:48] <eschwartz[m]> !grab fsckd
[16:04:48] <phrik> eschwartz[m]: Tada!
[16:31:26] -!- deep42thought has quit [Quit: Leaving.]
[17:52:18] -!- deep42thought has joined #archlinux-ports
[17:58:25] -!- abaumann has joined #archlinux-ports
[17:58:27] <tyzoid> Wb
[17:58:37] <abaumann> hi :-)
[17:59:53] <tyzoid> abaumann: do you know of any good irc webchat software?
[18:00:02] <abaumann> *sigh*
[18:00:12] <abaumann> I'm currently using IRC chat in seamonkey.
[18:00:16] <tyzoid> I've got znc, but it doesn't have built-in webchat
[18:00:32] <tyzoid> yeah. The problem is I'm behind a http-proxy
[18:00:33] <abaumann> freenode has an online one, but it's not that good.
[18:00:51] <tyzoid> I usually use the freenode one.
[18:01:09] <abaumann> that's what I'm doing at work - where I have similar constraints proxy-wise. :-)
[18:01:13] <tyzoid> Right now, I'm using the IRC client on my phone,
[18:01:20] <abaumann> *urg*
[18:01:28] <tyzoid> yeah
[18:04:58] <tyzoid> the main issue is I leave my home connection open, so I use a different nick when at work
[18:05:18] <abaumann> In a screen, yeah. that's a way to go.
[18:06:09] <tyzoid> I switched yo ZNC, but can't access it from here yet.
[18:06:13] <tyzoid> to*
[18:20:02] <fsckd> tyzoid: if you use weechat at home, you may consider glowing bear. it is a website which runs as a wecehat relay client.
[18:20:41] <z3ntu> You can also use Matrix which provides an IRC bridge to all channels on Freenode and a bunch of other networks
[18:20:50] <z3ntu> https://about.riot.im
[18:23:09] <fsckd> i would hold back on Matrix for a while. their bridge doesn't play well with freenode (e.g., doesn't notice if a user is quiet, can leak logs, etc.). may be if they fix it...
[18:43:15] -!- deep42thought has quit [Quit: Leaving.]
[18:43:26] -!- deep42thought has joined #archlinux-ports
[18:48:55] <abaumann> deep42thought: how is gcc? :-)
[18:49:18] <deep42thought> I put up a patch, which should preserve the current state when testing becomes stable
[18:49:43] <abaumann> gcc triggers quite a bunch of packages now
[18:49:47] <deep42thought> but unfortunately, this of cours triggered a rebuild of the current gcc (w/o change, hopefully), which just finished a few hours ago
[18:50:06] <abaumann> gcc is a beast. :-)
[18:50:21] <abaumann> luckily we don't have to cross-compile (yet).
[18:50:27] <deep42thought> e.g., we have now "gcc-7.2.0-3.1" which should be identical to "gcc-7.2.0-3.0"
[18:50:48] <abaumann> it passed it's check, so everything should be ok.
[18:51:05] <deep42thought> we'll see :-)
[18:51:26] <abaumann> toolchain-rotting is usually the last thing you do in a distribution.. :->
[18:51:48] <deep42thought> huh, what do you mean by that?
[18:52:00] <deep42thought> outdated/uncompilable toolchain packages?
[18:52:16] <abaumann> a compiler producing slightly broken code.. enough to break all packages above.
[18:52:22] <deep42thought> ah, ok
[18:52:31] <deep42thought> yeah, that would be bad
[18:52:38] <abaumann> In ancient times, me and collegue built an LFS-based RPM-packaged Linux, called Linux47.
[18:52:51] <abaumann> So, I know some traps :-)
[18:52:57] <deep42thought> once reproducible builds become real, we have some serious testing for our toolchain
[18:53:03] <abaumann> true
[18:53:54] <abaumann> I'm currently playing with a Archlinux-i486, but shush.. :-)
[18:54:09] <abaumann> So far I managed to cross-compile the basic stuff via crosstool-ng
[18:54:11] <deep42thought> I'm very keen to see this running :-)
[18:54:15] <abaumann> Me too.
[18:54:33] <abaumann> When you can cross-compile your compiler, you are usually trhough...
[18:54:38] <abaumann> ...then comes glibc. :->
[18:55:04] <abaumann> what I can say, Linux didn't improve from an architectural point of view.. too many circular dependencies and ill-managed packages..
[18:55:22] <deep42thought> what's the planned goal: cross compile all packges in an x86_64 environment? Or compile in an i486 arch vm?
[18:55:22] <abaumann> ..and there is systemd, of couse. :-)
[18:55:32] <deep42thought> :-)
[18:55:51] <abaumann> In several steps: first you build a chroot from 64-bit. In this one you compile the real i486 packages.
[18:55:56] <deep42thought> If I knew more about linux, when arch introduced systemd, I would probably have left it for better
[18:55:57] <deep42thought> ...
[18:56:04] <deep42thought> but now I'm stuck with it (and systemd)
[18:56:11] <abaumann> well. the alternatives are no better.
[18:56:19] <abaumann> systemd vs. tons of unreadable shellish stuff.
[18:56:29] <deep42thought> well "tons" is relative
[18:56:33] <abaumann> I prefer the BSD way: one shell script called 'rc'.
[18:56:41] <deep42thought> it depends on how much stuff you actually need on your system
[18:56:52] <deep42thought> I got an /etc/rc.local
[18:56:53] <abaumann> true.
[18:57:05] <deep42thought> (on crux)
[18:57:12] <abaumann> and the systemd decision in Archlinux is absolutely correct.. keeps it simple for maintainers.
[18:57:24] <abaumann> Crux. Oh memories. :-)
[18:57:28] <abaumann> also did packaging there once.
[18:58:03] <abaumann> shameless plug: http://www.andreasbaumann.cc
[18:58:04] <phrik> Title: OpenBSD firewall applicance - Intro (at www.andreasbaumann.cc)
[18:58:19] <abaumann> OpenBSD with a simple shell script for firewall customization.
[19:01:34] <deep42thought> my alix runs debian
[19:01:44] <deep42thought> it was the only system I was able to boot on it :-/
[19:02:03] <abaumann> what kind of alix? they should run freebsd, openbsd and linux.
[19:02:17] <abaumann> ok. I have quite an old one.
[19:02:25] <abaumann> don't know about newer ones.
[19:02:27] <deep42thought> 2d, I think (is this a valid type?)
[19:02:45] <deep42thought> yes, it should run anything, but I was struggling with the boot loader
[19:02:59] <abaumann> ah. the bios os openbios. quite tricky.
[19:03:31] <abaumann> neat little machines though.
[19:04:54] <deep42thought> might be alix2d13, but I'm really not sure and it's far from new
[19:05:17] <deep42thought> ah, alix2d3 it is
[19:05:28] <tyzoid> test
[19:05:28] <abaumann> That's the same. :-)
[19:06:07] <tyzoid> Alright, got kiwiirc up and running on my server
[19:06:15] <deep42thought> :-)
[19:06:25] <abaumann> finally you can chat. :-)
[19:06:26] <tyzoid> kiwiirc -> znc
[19:07:25] <tyzoid> deep42thought: can you try tagging me?
[19:07:37] <deep42thought> tyzoid: I can
[19:07:46] <tyzoid> alright
[19:07:49] <tyzoid> thanks
[19:08:08] <tyzoid> abaumann: It's actually quite nice, you should check it out sometime.
[19:09:27] <abaumann> ok. will give it a try.
[19:09:43] <abaumann> though: https://tools.suckless.org is more my style.. :-)
[19:09:43] <phrik> Title: ii | suckless.org tools (at tools.suckless.org)
[19:10:22] <abaumann> just update gcc from testing and compiled some stuff with it. looks all well.
[19:10:30] <abaumann> s/update/updated
[19:13:29] <abaumann> oh man: 'linux' kernel dependencies. thanks to however decided to split 'linux' and 'linux-headers' into separate packages. :-)
[19:15:53] <abaumann> argh: and of course. kmod need pkg-config, which needs glib2 which needs the meson build system (and then all is lost)
[19:16:13] <abaumann> so far I can say, whenever gnome-stuff comes into play, things get really urksome.
[19:17:27] <abaumann> so.. no kernel modules for now. who needs them anyway. :-)
[19:23:27] <abaumann> ah: liblzma_CFLAGS and liblzma_LIBS. Ok. we get modules.. :-)
[19:35:36] <tyzoid> lol
[19:36:31] <abaumann> just realized: I only have 196 MB RAM on that old machine I want to try booting.
[19:36:44] <abaumann> ramdisks and ISO images being read into memory from CDROM are a nogo.
[19:37:08] <deep42thought> :-D
[19:38:08] <deep42thought> I wonder if I ever get the build master scripts into a state, where I don't consider them experimental anymore :-/
[19:38:35] <abaumann> ok. I can boot on libvirt with a i486 CP via direct kernel boot. The C compiler works, the C++ compiler has some problems.
[19:38:44] <abaumann> I'm going to rebuilt the toolchain again first..
[19:39:12] <abaumann> ..but I need a i486 master VM and some x86 workers with distcc, in order to finish :-)
[19:39:34] <deep42thought> :-)
[19:39:57] <abaumann> cross-compiling is fine, but can introduce funny bugs into the distro..
[19:40:15] <abaumann> the build scripts are fine.
[19:40:16] <deep42thought> compiling in vms is probably the right way to go
[19:40:27] <abaumann> yeah. not on real hardware. :-)
[19:40:39] <deep42thought> and not in chroots, either
[19:40:41] <abaumann> this one is just for testing.
[19:40:47] <deep42thought> since there is no 'setarch i486'
[19:40:59] <abaumann> chroots are dangerous. linux32 emulates a i686, not a i486.
[19:41:03] <deep42thought> right
[19:41:12] <abaumann> LFS has a uname hack module you can insert into the host.
[19:41:30] <abaumann> but there are still scripts out there trying to get cpu infomration via /proc/cpuinfo or worse..
[19:41:53] <deep42thought> the devtools32 have an i486 branch
[19:41:59] <abaumann> ah, yeah?
[19:42:01] <deep42thought> but it's just a stumb
[19:42:07] <deep42thought> stub
[19:42:29] <deep42thought> I just started it and then stumbled over the setarch issue
[19:42:36] <abaumann> I think doing a linux32 and using the uname hack from LFS is fine for a first chroot.
[19:42:38] <deep42thought> so there is not really much in it
[19:43:18] <abaumann> most packages are most likely find to build in a chroot.
[19:43:35] <abaumann> if the chroot comtains a i486-only compiler.
[19:43:47] <abaumann> but I have to test :-)
[19:44:10] <deep42thought> that would be nice, because this is basically how i686 is compiled in x86_64
[19:45:15] <abaumann> With ARM you cannot do this.
[19:45:20] <deep42thought> right
[19:45:34] <abaumann> I really wonder, how they bootstrapped exactly.. crosstool-ng, master is an ARM, distcc.
[19:45:34] <deep42thought> this is, why they use a build farm AFAIK
[19:45:40] <abaumann> yes.
[19:45:48] <abaumann> but the tricky part is to start.
[19:45:56] <deep42thought> hmm, dunno
[19:46:03] <deep42thought> you can probably start from any linux
[19:46:11] <abaumann> you have to use a Raspbian or similar, and bootstrap the 'base' packages from there.
[19:46:31] <abaumann> That's what I tried in the beginning: an Ubuntu 10 or an lfscript i486 based distro..
[19:46:47] <abaumann> then you just start to compile things till you get pacman (not so nice BTW).
[19:47:00] <tyzoid> sounds like a hell of a lot of work
[19:47:04] <abaumann> from there it's quite easy.. just go up the tree.
[19:47:15] <abaumann> but fun :-)
[19:47:50] <abaumann> glibc went into SIGFPEs and worse.
[19:48:31] <abaumann> the difference is: i486 is long gone. so it's quite likely, there are bugs upstreams (in gcc, glibc). Then it is really almost impossible.
[19:48:44] <tyzoid> they're still bugs, though :)
[19:48:44] <abaumann> for ARM things are better supported, I suppose.
[19:49:10] <tyzoid> would it be possible to shoe-in ulibc for glibc?
[19:49:21] <abaumann> aeh.. yeah.. sort of.
[19:49:21] <tyzoid> or are there things that depend on some of the extensions in glibc?
[19:49:33] <abaumann> I think, thats what alpine linux is doing..
[19:49:49] <abaumann> *sigh* many things depend on glibc-specific stuff..
[19:50:07] <abaumann> that's why the other C libraries have to keep up with new things in glibc
[19:50:17] <tyzoid> I wonder if a polyfill exists to implmenet glibc functions with ulibc?
[19:50:18] <abaumann> the same is somewhat true to gcc, though it's not a drama there.
[19:50:55] <abaumann> JS polyfill?
[19:51:35] <tyzoid> It's just the terminology I'm used to
[19:51:44] <abaumann> ah :-)
[19:51:50] <tyzoid> I meant a library that implements the rest of glibc that ulibc doesn't
[19:52:00] <tyzoid> If that exists, then it should be simpler
[19:52:07] <abaumann> I know about libbsd, shimming BSD things for Linux.
[19:52:27] <tyzoid> Yeah, shim is probably a better term.
[19:52:46] <abaumann> there are tricky parts in a Unix system, where c library, c compiler and the kernel start to depend heavily on each other..
[19:53:24] <abaumann> ..and suddenly it's not a black-and-white decision "what goes where".
[19:53:44] <tyzoid> I don't believe the kernel can even be compiled without gcc, even.
[19:54:20] <abaumann> https://bellard.org
[19:54:21] <phrik> Title: TCCBOOT: TinyCC Boot Loader (at bellard.org)
[19:54:57] <abaumann> it's possible. but don't do it for production systems.
[19:55:26] <abaumann> I though, they tried once clang on Linux.
[19:55:42] <abaumann> Recently other kernels dropped gcc for clang: FreeBSD and most recently OpenBSD
[19:55:43] <tyzoid> https://lwn.net
[19:55:45] <phrik> Title: Building the kernel with clang [LWN.net] (at lwn.net)
[19:56:12] <abaumann> yeah. the kernel is C and a little bit assembly in the end. :-)
[19:56:58] <tyzoid> Which relies on some gnu extensions
[19:57:02] <abaumann> my experience is: compile with at least compilers, then your code base is really robust. :-)
[19:57:31] <tyzoid> I think you missed the number there. 3?
[19:57:39] <abaumann> yes. :-)
[19:57:57] <tyzoid> what's another alternative to gcc and clang?
[19:58:05] <abaumann> Visual Studio
[19:58:16] <abaumann> For C: pcc and tcc
[19:59:47] <tyzoid> huh, does pcc support full c99?
[19:59:58] <abaumann> no.
[20:00:10] <abaumann> do gcc and clang?
[20:00:25] <abaumann> there are corner cases of the standards which are not implemented everywhere.
[20:00:35] <abaumann> in practice: not relevant.
[20:09:26] <eschwartz[m]> abaumann: actually I quite like Thunderbird (so same as seamonkey IIRC), what do you dislike about it? :p
[20:09:56] <abaumann> Seamonkey is a little bit lighter on the memory, my feeling.
[20:10:33] <tyzoid> Haven't used seamonkey in years, but can confirm Thunderbird is memory hog.
[20:10:37] <abaumann> I'm a mutt guy :-)
[20:11:38] <eschwartz[m]> !mutt
[20:11:39] <phrik> https://lists.debian.org
[20:12:16] <abaumann> ok. trojita is quite promising.
[20:12:22] <abaumann> still a little bit buggy. but fast.
[20:34:20] <abaumann> question: should https://buildmaster.archlinux32.org be more public? So if people can peek there before they complain something is not working.
[20:34:21] <phrik> Title: Blacklisted packages (at buildmaster.archlinux32.org)
[20:34:39] <jelle> that's not a lot of packages :p
[20:34:56] <jelle> oh that's not of which build failed :D
[20:35:07] <abaumann> well, there quite some we don't know yet about.. the first time they get used, we see. :-)
[20:35:22] <abaumann> no. those are "known-not-to-work on i686"
[20:35:29] <abaumann> and are also not easy fixable..
[20:35:49] * jelle expected more 404s :D
[20:35:56] <abaumann> yeah :-)
[20:36:05] <deep42thought> of sources?
[20:36:40] <abaumann> indeed. all those packages repackaging a i386.deb package for instance.
[20:37:55] <abaumann> yeah. I can ping my i486 VM :-)
[20:38:00] <deep42thought> :-)
[20:38:11] <jelle> really doing this i486 now :O
[20:38:19] <abaumann> yep. just as a test.
[20:46:51] <deep42thought> abaumann: we could duplicate or link the list (and the one with broken packages) on our main site
[20:47:34] <abaumann> sort of a status page. I like that.
[20:47:51] <abaumann> Though me must be careful with our language then. :->
[20:48:00] <deep42thought> but I'd recommend, someone except me does the coding - my layouts are horrible
[20:48:20] <abaumann> I just know the guy.. :-)
[20:48:32] <abaumann> tyzoid?
[20:48:41] <deep42thought> :-D
[20:50:39] <tyzoid> I'm sorry, what/
[20:50:58] <abaumann> we got you a job. ;-)
[20:51:02] <tyzoid> uh...
[20:51:07] * tyzoid hides
[20:51:33] <tyzoid> You're saying to fix up buildmaster to look nicer?
[20:51:38] <abaumann> no.. I just asked for your opinions to present some stuff from the buildmaster.
[20:51:40] <tyzoid> or am I completely misunderstanding
[20:51:41] <abaumann> yep.
[20:51:54] <tyzoid> yes I'm completely misunderstanding?
[20:51:55] <abaumann> and maybe draw a link from the main page.
[20:53:20] <tyzoid> abaumann or deep42though: What do you mean by "link the list"?
[20:53:39] <abaumann> the list of blacklisted and blocked packages would be nice to see somewhere.
[20:53:41] <deep42thought> we currently have no links from archlinux32.org to buildmaster.archlinxu32.org
[20:54:05] <deep42thought> and we should point people to those lists either by duplicating them on archlinux32.org or by linking to them
[20:54:44] <abaumann> duplicating would mean another web api of some sort?
[20:54:50] <deep42thought> yes
[20:55:11] <deep42thought> this could be part of the archweb32
[20:55:19] <abaumann> indeed. good idea.
[20:55:30] <deep42thought> like part of the "track package states" part
[20:56:52] <deep42thought> I added it to the requiremendts
[20:57:13] <deep42thought> https://github.com
[20:57:15] <phrik> Title: Requirements · archlinux32/archweb32 Wiki · GitHub (at github.com)
[20:57:58] <abaumann> "solve halting problem" :-)
[20:58:25] <deep42thought> I thought, I'd put an ambitious goal there, too
[20:58:41] <abaumann> :)
[20:59:28] <tyzoid> yeah, I had a haughty chuckle when I read that
[20:59:42] <deep42thought> anyway, feel free to add some (serious) items to the wish list, I'll go to bed now
[20:59:43] <tyzoid> abaumann: did you see my package API?
[20:59:56] <tyzoid> deep42thought: rest up
[21:00:05] <abaumann> deep42thought: ok, good night
[21:00:19] <abaumann> tyzoid: I saw your message, but I couldn't test it yet..
[21:00:35] <abaumann> .. but I will. :-)
[21:00:59] <tyzoid> abaumann: Well, I'm thinking if we want to extend it into an arch32 general rest API
[21:01:00] -!- deep42thought has quit [Quit: Leaving.]
[21:02:30] <tyzoid> abaumann: here's the link, for ease of reference: https://pkgapi.arch32.tyzoid.com
[21:02:37] <tyzoid> It's basically a jsonapi
[21:02:44] <abaumann> ah.. that's the thing I missed. :-)
[21:03:01] <tyzoid> has rudimentary xml support, but that API is shaky
[21:03:09] <abaumann> yeah.. but that's a start.
[21:03:30] <abaumann> and you can add all kind of information afterwards.. for instance the build status, block status, blacklist status, etc.
[21:03:55] <abaumann> the only question is then, how to get this information from the buildmaster.
[21:03:59] <tyzoid> Yeah. It uses PHP in the backend, with a MVC like framework (Where the V is just 'json_export')
[21:04:05] <abaumann> the blacklist is in git.. but blocked is trickier.
[21:04:14] <tyzoid> There's always scraping
[21:04:21] <abaumann> *urg*
[21:04:24] <tyzoid> the package API is coming via pacman -Sy in a cronjob
[21:04:26] <abaumann> :-)
[21:04:42] <abaumann> ah. period updates. git can be done the same way.
[21:05:02] <abaumann> just the list of currently blocked (or currently building packages) is something we must discuss.
[21:05:11] <tyzoid> I mean the buildmaster scripts basically generate static output anyway
[21:05:19] <abaumann> that's true.
[21:05:21] <tyzoid> so I could probably write them in such a way that they also build out static json responses
[21:05:41] <abaumann> you only need a way, to get them. similar how the slaves get their job assignments maybe.
[21:06:04] <tyzoid> The question is if I want to have a cache of this, or if I want to act as a proxy to get the info.
[21:06:25] <tyzoid> Or we could just create a sub-api on the buildmaster
[21:06:29] <tyzoid> with a /api directory
[21:06:36] <abaumann> also an option.
[21:06:43] <tyzoid> and create a psuedo-rest api consisting of GET requests on static objects
[21:07:03] <abaumann> what's pseudo-rest about that? :-)
[21:07:22] <tyzoid> It's tecnhically rest, but has no support for other HTTP modes
[21:07:32] <tyzoid> If we want to be able to query information other than what's generated, it's not possible
[21:07:40] <abaumann> readonly static object, static web pages, REST. :-)
[21:07:50] <tyzoid> or if we want to be able to modify behavior of the buildmaster via the API.
[21:07:53] <abaumann> it's a subcase of the bigger case.
[21:08:23] <abaumann> Well, this would have to be as secure as the current signed/encrypted email way then.
[21:09:00] <abaumann> but nice idea. :-)
[21:09:24] <tyzoid> abaumann: You can do API Authentication via RSA keys, using the JWT request standard
[21:09:37] <tyzoid> OpenSSL is usually used to handle that
[21:09:42] <tyzoid> but it's actually pretty nifty
[21:09:43] <abaumann> ah.. ok.
[21:10:05] <tyzoid> I've been meaning to implement it for a while, never had a chane
[21:10:07] <tyzoid> chance*
[21:10:19] <tyzoid> It's basically the cloud-to-cloud component of OAuth.
[21:10:28] <tyzoid> abaumann: https://pkgapi.arch32.tyzoid.com
[21:10:43] <tyzoid> ^ That's the other piece that I implemented
[21:11:02] <tyzoid> and https://pkgapi.arch32.tyzoid.com enumerates the repos
[21:11:30] <abaumann> pretty fast, given 6000 packages.
[21:12:03] <tyzoid> It's basically putting each line from pacman -Sql <repo> into an array and json_encoding it
[21:13:01] <abaumann> are there php/python bindings to libalpm?
[21:13:17] <tyzoid> python I believe so. I don't think there's php bindings.
[21:13:33] <tyzoid> but not sure on both counts
[21:14:46] <tyzoid> So this is a thing: https://wiki.archlinux.org
[21:14:47] <phrik> Title: Unified Extensible Firmware Interface - ArchWiki (at wiki.archlinux.org)
[21:15:06] <tyzoid> The default iso uses systemd-boot, but grub apparently has support for 32bit efi
[21:15:41] <abaumann> Ah. I saw the topic with Mr Green
[21:16:00] <abaumann> yeah. I'm also no expert in that and I lack the hardware to test it.
[21:16:15] <tyzoid> I usually just throw virtualbox in 32bit mode with efi and watch it fail
[21:16:59] <abaumann> But you were right to ask: was it ever there in Archlinux?
[21:17:16] <abaumann> We might have to ask the ISO-wizard. :-)
[21:33:13] <abaumann> ok. bye. I'm way tired..
[21:35:14] -!- abaumann has quit [Quit: ChatZilla 0.9.92 [SeaMonkey 2.49.1/20171107234153]]
[22:05:51] -!- wyre has joined #archlinux-ports
[23:57:17] -!- T`aZ has quit [Ping timeout: 260 seconds]