#archlinux32 | Logs for 2019-01-05

Back
[00:12:15] -!- ubonehas has joined #archlinux32
[00:14:02] -!- dbermondhas has joined #archlinux32
[00:57:06] -!- thePiGrepperhas has joined #archlinux32
[08:36:40] -!- thePiGrepperhas has joined #archlinux32
[09:06:04] -!- woshtyhas has joined #archlinux32
[09:50:15] -!- oaken-sourcehas has joined #archlinux32
[10:16:09] <buildmaster> i686/kimtoy is broken (says buildknecht2).
[11:00:06] <buildmaster> Hi abaumann!
[11:00:06] <buildmaster> !rq abaumann
[11:00:07] <phrik> buildmaster: huh. then I suddenly have to finish and maintain it. ;-)
[11:01:17] <abaumann> deep42thought: the irc logs are not saved anymore..
[12:09:00] -!- z3ntuhas has joined #archlinux32
[12:27:14] -!- titus_livius has joined #archlinux32
[12:27:23] -!- deep42thought has joined #archlinux32
[12:27:24] <buildmaster> Hi deep42thought!
[12:27:24] <buildmaster> !rq deep42thought
[12:27:24] <phrik> buildmaster: <deep42thought> my cluster of 1k 4/86's will be happy to iterate Maxwell-Vlasov-equations :-D
[12:27:32] <deep42thought> thx, abaumann!
[12:27:46] <deep42thought> btw: what are your plans regarding fosdem?
[12:38:53] <deep42thought> logs are restored and titus_livius is logging again
[12:53:41] -!- woshty has quit [Ping timeout: 268 seconds]
[15:18:32] <thePiGrepper> hi everyone
[15:19:34] <thePiGrepper> deep42thought: quick question, is there a json API for the packages in archlinux32.org, as there is in archlinux.org?
[15:19:55] <thePiGrepper> I see the web interface only
[15:40:26] <bill-auger> thePiGrepper: i think archlinux32 stays as close to arch as possible - for most web services, you can just add 32 to the URL
[15:59:11] <deep42thought> the webservices are written from scratch, there we didn't copy from archlinux
[15:59:27] <deep42thought> but you can have a look at pkgapi.archlinux32.org
[16:00:39] <deep42thought> thePiGrepper: If you feel, something is missing, have a look at the source: https://git.archlinux32.org
[16:00:44] <phrik> Title: archlinux32/archweb32: Archlinux32 package and build system information interface - Archlinux32 Gitea (at git.archlinux32.org)
[16:03:23] <thePiGrepper> thx. I was missing the link. I did try with https://www.archlinux32.org but it didnt work.
[16:03:24] <phrik> Title: Arch Linux 32 (at www.archlinux32.org)
[16:03:43] <deep42thought> ah, we don't have a json search
[16:07:01] <deep42thought> hmm, this could be (quite) easily a feature of packages.archlinux32.org
[16:07:31] <deep42thought> in the end it's almost just differently formatted output
[16:08:23] <thePiGrepper> right. It might be useful to some scripts
[16:08:58] -!- abaumann has joined #archlinux32
[16:08:58] <buildmaster> Hi abaumann!
[16:08:58] <buildmaster> !rq abaumann
[16:08:59] <phrik> buildmaster: <abaumann> "anywhere is anywhere for all values of anywhere"
[16:09:01] <abaumann> hi deep42thought
[16:09:02] <deep42thought> Hi abaumann!
[16:09:48] <deep42thought> hmm, I'm not sure about the json api
[16:09:51] <thePiGrepper> do you happen to know if the git server has by default it's json API enabled? or it's something to need to enable manually?
[16:10:03] <deep42thought> it seems, upstream only has the database in form of the *.db and *.files files
[16:10:12] <deep42thought> and is searching / serving that content
[16:10:31] <deep42thought> whereas we have that information (served by pkgapi.archlinux32.org) and the information in the mysql database
[16:10:38] <thePiGrepper> arch does have this: https://www.archlinux.org
[16:10:39] <deep42thought> served by packages.archlinux32.org
[16:11:03] <deep42thought> git server?
[16:11:08] <deep42thought> gitea?
[16:11:22] <thePiGrepper> deep42thought: sorry, yeah, the gitea server. Im looking at some APIs available
[16:11:25] <thePiGrepper> for gitea
[16:11:35] <deep42thought> i don't know
[16:11:35] <thePiGrepper> I was about to test them on git.archlinux32.org
[16:12:35] <thePiGrepper> that'd solve the issue, at least mine for the time being, which is finding is there's a particular patch for a certain package, and also if the package is blacklisted
[16:14:09] <deep42thought> sounds, like you could use a copy of the database
[16:14:30] <deep42thought> I'm afk for some coffe, bbl
[16:37:00] <deep42thought> re
[16:37:28] <thePiGrepper> np. I could, having a 15M+ cache doesnt seem so bad,especially if you compare it to a 1.3G+ repo ;)
[16:38:00] <deep42thought> the repo file is that big?
[16:38:45] <thePiGrepper> nope, the _whole_ arch32 packages repo is 15M. the other one is the arch repo...
[16:39:53] <thePiGrepper> that was actually the original idea, working directly with the git repo locally and updating periodically. I was looking for better alternatives
[16:40:08] <thePiGrepper> but it's too small to matter I think
[16:40:12] <deep42thought> oh, I was talking about our mysql database
[16:40:25] <thePiGrepper> oh, I dont know how big is that..
[16:40:27] <deep42thought> it *should* have all the information, too
[16:40:50] <thePiGrepper> that's right. let me see.
[16:41:05] <deep42thought> /var/lib/mysql is 1.3GB on the buildmaster
[16:41:18] <deep42thought> https://buildmaster.archlinux32.org
[16:42:46] <deep42thought> hmm, the size seems to vary between the different copies
[16:43:19] <deep42thought> I see 1.6GB on packages.archlinux32.org and 2.6GB on my dev copy
[16:50:58] -!- woshty has joined #archlinux32
[16:54:10] <buildmaster> i686/dub is broken (says rechenknecht).
[16:59:50] <thePiGrepper> deep42thought: that's weird. but git does use a gc so you probably have some extra stuff there that should get purged
[17:00:12] <deep42thought> thePiGrepper: that's the working directory of mysql
[17:00:24] <thePiGrepper> hmm..
[17:00:26] <deep42thought> I'm used to extensively growing git repositories ;-)
[17:16:22] -!- abaumann has quit [Quit: leaving]
[18:18:03] -!- ofara__ has joined #archlinux32
[18:20:53] -!- ofara has quit [Ping timeout: 245 seconds]
[18:23:57] -!- NoobAlice has joined #archlinux32
[19:10:18] <finsternis> pacman shows huge upgrade of 1343 packages. Is it normal, I upgraded the whole system just some days ago?
[19:10:26] <finsternis> also: warning: dependency cycle detected:
[19:10:28] <finsternis> warning: harfbuzz will be installed before its freetype2 dependency
[19:12:06] <finsternis> and warning: zeitgeist: local (1.0+1+g1bcc8585-1.1) is newer than extra (1.0.1-1.0)
[19:15:19] <thePiGrepper> disregard the warning. it's actually a more recent package somehow
[19:15:53] <thePiGrepper> and the dependency stuff is not unusual to happen, disregard
[19:20:17] <thePiGrepper> deep42thought: one question, regarding the packages repo. all the patches are on top of <repo>-x86_64 folder right? I know it seems like a silly/obvious question. Im asking because there are still some packages with a i686 folder. or are you using <pkgname>/trunk/ as the base?
[19:20:25] <deep42thought> I moved all packages from testing to stable some days ago
[19:20:56] <deep42thought> thePiGrepper: repos/*-x86_64 or repos/*-any
[19:20:59] <deep42thought> so: yes
[19:21:08] <thePiGrepper> thx
[21:03:06] -!- isacdaavid has joined #archlinux32
[23:17:27] <thePiGrepper> deep42thought: quick question, in the packages repo, there are only 3 under multilib:fasm,wine, and wine staging. why is that?
[23:18:00] <deep42thought> it's because we only have patches for those three packages
[23:18:33] <thePiGrepper> that's because all the others have a patch for the regular 64-bit one?
[23:18:45] <thePiGrepper> otherwise they would be blacklisted right?
[23:19:11] <deep42thought> because the others in multilib don't need patches
[23:19:54] <deep42thought> there are three options: no patch (e.g. nothing in our git repository), a patch (e.g. something in $repo/$pkgbase/) or blacklisted (e.g. an entry in blacklist)
[23:21:32] <thePiGrepper> the only package I detect that starts with lib32 is lib32-harfbuzz, however there are apparently over 200 packages upstream
[23:21:46] <deep42thought> ah, that you mean
[23:22:02] <deep42thought> the build scripts themself ignore lib32-* packges
[23:22:12] <deep42thought> lib32-harfbuzz is probably a mistake :-/
[23:22:55] <thePiGrepper> ignores in what way?we dont build multilib except those 3 for some reason? or what?
[23:23:07] <deep42thought> we don't build lib32-* packages
[23:23:13] <deep42thought> but there are others in multilib
[23:23:46] <deep42thought> lib32-$x is basically the 32-bit version of $x (mostly libraries) for a 64-bit host - so we can simply use $x instead
[23:23:55] -!- miique has joined #archlinux32
[23:24:15] <deep42thought> I think, we have a dependency-rewriting at certain points
[23:24:34] <deep42thought> e.g. depends=(lib32-foo) -> depends=(foo)
[23:24:46] <thePiGrepper> ohh, ok. I see.. I think I understand. because there're many lib32-* packages in 'community'
[23:25:02] <thePiGrepper> those get ignored then
[23:25:07] <deep42thought> yes
[23:27:47] <thePiGrepper> I see. there's something odd(or maybe Im just confused). the fasm package is in community, not in multilib. however, in arch32, the patch is in multilib, not in community. why? the reason I think this might be is because the community repo has both community and multilib, the same as the packages repo has core,and extra. is that somehow correct?
[23:29:45] <deep42thought> probably it was in multilib before, so we added a patch there, but now it was moved to community
[23:30:14] <deep42thought> (I assume by "in arch32, the patch is in multilib" you mean, that it resides in "multilib/fasm/...")
[23:30:41] <thePiGrepper> correct
[23:33:59] <deep42thought> ah, no
[23:34:05] <deep42thought> it _is_ in multilib upstream
[23:34:09] <deep42thought> but we do not have multilib
[23:34:19] <deep42thought> so those packages end up in [community] on archlinux32
[23:35:16] <deep42thought> btw: there was one package in archlinux' [multilib] which was in [extra] on the i686 branch of archlinux - but that package was moved to [community] or dropped (can't remember which), so we do not need to care about community/extra
[23:37:21] <thePiGrepper> one question regarding asp32. the solution I got at the moment, is quite simple. it does basically the same as asp, however it also update a local packages repo, it copies repos/extra-x86_64 as repos/arch32(name-pending), copies all additional files to that new folder, appends the patch to PKGBUILD. is that somehow enough? the difflist and everything else works fine because it doesnt touch
[23:37:27] <thePiGrepper> arch32 history. the main issue is how useful is the arch32 repo history and if it is, how could we merge in a useful way both histories
[23:38:08] <thePiGrepper> I have a different, more complex solution which strips the commit related to the package from the arch32 repo and create that branch in cache
[23:39:16] <deep42thought> I think, the first solution is sufficien
[23:39:17] <deep42thought> t
[23:39:21] <thePiGrepper> however, mainly because there's no way to actually know when a which commit goes from where to which upstream package(date is not really that precise)
[23:39:27] <thePiGrepper> deep42thought: I see.
[23:39:54] <thePiGrepper> disregard the last part then.
[23:39:55] <deep42thought> yeah, I think merging the history is close to impossible
[23:40:14] <thePiGrepper> yeah, maybe with more meta info it could have been
[23:40:44] <thePiGrepper> and that brings me to a topic I thought about some time ago
[23:40:46] <deep42thought> yeah, but it's probably not worth the hassl
[23:40:47] <deep42thought> e
[23:41:01] <thePiGrepper> for someone who want to reproduce the builds
[23:41:11] <thePiGrepper> it's actually quite difficult, right?
[23:41:27] <deep42thought> probably yes :-/
[23:41:32] <thePiGrepper> there's not actual way to do an exact reproduction of a build
[23:41:55] <deep42thought> the tools are all there
[23:42:04] <deep42thought> but you need to puzzle together the right parts
[23:42:05] <thePiGrepper> for small things without too many dependencies maybe.
[23:42:09] <thePiGrepper> not because of that
[23:42:15] <thePiGrepper> what I meant is that
[23:42:34] <thePiGrepper> most of the builds have a list of specific version of packages which are used to build them
[23:42:47] <thePiGrepper> those are not annotated anywhere
[23:42:53] <thePiGrepper> at the time of the build
[23:42:56] <thePiGrepper> or they are?
[23:43:02] <deep42thought> they are
[23:43:07] <deep42thought> it's all in the .BUILDINFO
[23:43:18] <thePiGrepper> ohh :o
[23:43:32] <thePiGrepper> what was that again?
[23:43:45] <deep42thought> inside the package tar ball
[23:45:47] <thePiGrepper> nice! I didnt know about this. silly me
[23:45:52] <deep42thought> np
[23:46:05] <deep42thought> btw: that's no invention of archlinux32, it's also there upstream
[23:46:29] <thePiGrepper> yeah sure, it's part of any pacman-based package I assume
[23:49:49] <thePiGrepper> btw, to close the asp topic, is it good that it creates a copy of the repos/<repo>-x86_64/ file and renames it arch32. I wanted to name it <repo>-<arch> accordingly, however there are still some packages upstream with a i686 folder. what would be the preferred option?
[23:52:08] <deep42thought> is it possible to apply the patches outside of git?
[23:52:14] <thePiGrepper> I can always overwrite any existing library with that name.., after all it can be recovered by a simple git checkout
[23:52:23] <thePiGrepper> how so?
[23:53:20] <thePiGrepper> they are being applied outside of git. in the sense that we are using a git repo, but the applied changes are not necessarily commited
[23:54:23] <deep42thought> ah, ok, right
[23:54:31] <thePiGrepper> for example: after 'asp checkout tmux' it clones a folder named tmux with the known structure. the additional code will create an additional folder under repo/
[23:54:46] <deep42thought> just call the directory repos/$repo-arch32/
[23:55:06] <thePiGrepper> with the old content of repos/<repo>-x86_64/ + the new content plus the appended text to PKGBUILD
[23:55:09] <deep42thought> in the end, it is also used for i486
[23:55:15] <thePiGrepper> right
[23:55:40] <thePiGrepper> what if, eventually(or maybe even now, I havent checked) there are differences between the patches in i486 and i686?
[23:55:51] <deep42thought> checking out a trunk + modifications might also be something of interest
[23:56:01] <deep42thought> there are no differences
[23:56:06] <deep42thought> inside the PKGBUILD
[23:56:11] <thePiGrepper> there wont ever be?
[23:56:16] <deep42thought> eventual differences are managed by $CARCH switches
[23:56:21] <thePiGrepper> ok
[23:56:35] <deep42thought> that's what upstream did for i686/x86_64 before
[23:56:56] <thePiGrepper> I see. "checking out a trunk + modifications might also be something of interest" how so?
[23:57:22] <deep42thought> 'asp export linux' checks out the content of trunk
[23:57:44] <deep42thought> so it would be nice if 'asp32 checkout linux' did so, too, but applied our modifications on top of that
[23:58:03] <deep42thought> (which is an action, that never happens within the build system, because we do not build from trunk)
[23:58:12] <thePiGrepper> oh, right. ofc.
[23:58:42] <thePiGrepper> I always wonder about that. what's the difference between the trunk folder and the repos one?
[23:59:05] <deep42thought> trunk contains some hot-fixes (e.g. for changed source urls) which do not affect the package
[23:59:22] <deep42thought> so the next released package is (often) based on the current trunk
[23:59:48] <deep42thought> e.g.: accumulate fixes in trunk -> increase version -> build -> copy trunk to repos/.../ & release