#archlinux-ports | Logs for 2017-11-28

Back
[01:57:05] -!- because has quit [Ping timeout: 240 seconds]
[01:58:11] -!- because has joined #archlinux-ports
[02:08:23] -!- guys has quit [Ping timeout: 276 seconds]
[02:16:49] -!- Polichronucci has quit [Ping timeout: 248 seconds]
[02:27:59] -!- guys has joined #archlinux-ports
[03:00:18] -!- p71 has quit [Read error: Connection reset by peer]
[03:04:42] -!- isacdaavid has joined #archlinux-ports
[03:07:03] -!- p71 has joined #archlinux-ports
[03:27:09] -!- Polichronucci has joined #archlinux-ports
[05:55:12] -!- hringriin_ has joined #archlinux-ports
[05:58:07] -!- hringriin has quit [Ping timeout: 248 seconds]
[05:58:08] hringriin_ is now known as hringriin
[06:31:07] -!- deep42thought has joined #archlinux-ports
[06:38:13] <deep42thought> tyzoid abaumann: a different api for the buildmaster would be easy and probably the best way to go
[06:43:31] <deep42thought> a different option would be r/o access to the build master's package-states directory
[06:43:46] <deep42thought> which holds the information what's up with what package
[06:44:53] -!- deep42thought has quit [Quit: Leaving.]
[08:17:40] -!- deep42thought has joined #archlinux-ports
[08:21:26] -!- isacdaavid has quit [Quit: Leaving.]
[11:20:25] <deep42thought> The current build master has the following (probably serious) issue: To move a package "a" around (e.g. from [community-testing] to [community]), it requires, that no packages in not-older repositories (e.g. [community-staging] and [community-testing]) are left behind, which depend on "a" or on which "a" depends.
[11:20:38] <deep42thought> (For that it only considers runtime dependencies.)
[11:22:11] <deep42thought> The problem with that is, that as soon as many packages are in testing, none of them will be moveable, because the graph consist only of one connected component and any failing build will be connected to this component too, and block everything
[11:22:50] <deep42thought> also packages which don't get testing _that_fast_ (e.g. within a day) will hold back everything else by a day and then new stuff will appear, which blocks everything again
[11:23:51] <deep42thought> the last point is probably the most serious argument
[11:24:18] <deep42thought> because it is still valid if only packages in [community-testing] are considered (and not also ones in [community-staging] or on the build list)
[13:17:18] -!- jelle has quit [Quit: WeeChat 1.9.1]
[13:54:57] -!- guys has quit [Ping timeout: 240 seconds]
[13:56:31] -!- because has quit [Ping timeout: 248 seconds]
[13:58:19] -!- because has joined #archlinux-ports
[14:23:47] -!- guys has joined #archlinux-ports
[14:27:24] -!- petris has joined #archlinux-ports
[15:04:00] -!- yokel has joined #archlinux-ports
[16:06:26] -!- deep42thought has quit [Quit: Leaving.]
[17:12:45] -!- isacdaavid has joined #archlinux-ports
[17:16:15] -!- abaumann has joined #archlinux-ports
[17:17:08] -!- deep42thought has joined #archlinux-ports
[17:56:38] <abaumann> deep42thought: the dependency issues sound troublesome.
[17:56:44] <deep42thought> yes
[17:56:56] <deep42thought> especially, because we need _less_ dependencies
[17:57:01] <abaumann> so, what can we do? test more and release packages faster to the wild?
[17:57:19] <deep42thought> I would try introducing "ldd-dependencies"
[17:57:26] <abaumann> less dependencies? in a linux system? must be kidding. :-)
[17:57:31] <abaumann> mmh.
[17:57:41] <deep42thought> and at some point only consider ldd-dependencies
[17:57:49] <abaumann> this means: don't trust the package dependencies..
[17:57:54] <deep42thought> and maybe some others (e.g. dependency of python-* on python)
[17:57:59] <deep42thought> right
[17:58:49] <abaumann> well, there are binaries like 'msgfmt' from gettext. you cannot detect those things with ldd.
[17:59:01] <abaumann> this is a makedepend though.
[17:59:08] <abaumann> so you remain with libexec stuff
[17:59:27] <deep42thought> anyway, I wonder how upstream decides what can be moved
[17:59:34] <deep42thought> I guess, it's just "gut feeling"
[17:59:40] <abaumann> should I be frank?
[17:59:41] <abaumann> :-)
[17:59:43] <deep42thought> like with kernel config
[17:59:46] <deep42thought> yes
[17:59:49] <deep42thought> please
[18:00:12] <abaumann> as long as linux, linux-lts look so different you wonder the maintainers talk to each other..
[18:00:44] <deep42thought> lol
[18:01:00] <deep42thought> maybe there's a reason, it's two packages and two maintainers?
[18:01:21] <abaumann> yeah. but that's not the best idea..
[18:01:28] <deep42thought> :-D
[18:01:37] <abaumann> also, gcc, glibc and stuff look really weird.
[18:01:38] <deep42thought> sry, I'll have to leave in a minute
[18:01:39] <brtln> linux-lts gets synced only when it's switched to newer lts branch so I don't know what you're complaining about
[18:01:45] <abaumann> those things should be done by one person IMHO.
[18:01:56] <deep42thought> cu
[18:01:56] -!- deep42thought has quit [Quit: Leaving.]
[18:02:03] <abaumann> brtln: we are just ranting a little bit. :-)
[18:02:16] <abaumann> deep42thought: cu
[18:02:20] <brtln> what makes you think it's not?
[18:02:33] <abaumann> it doesn't look alike..
[18:02:34] <abaumann> in PKGBUILD
[18:03:07] <abaumann> anyway. I'm currently trying to bootstrap an Archlinux on 486.
[18:03:32] <abaumann> this gives me some insight in dependencies and cycles. It's really troublesome.. but nothing Archlinux can do about I'm afraid.
[18:03:44] <brtln> what doesn't look alike?
[18:03:55] <brtln> I'm really curious, because I maintain entire toolchain since a while
[18:04:00] <abaumann> ah. :-)
[18:04:08] <abaumann> hang on.. I have to peek fast..
[18:05:31] <abaumann> cat "${srcdir}/config" > ./.config
[18:05:38] <abaumann> cp -Tf ../config .config
[18:05:39] <abaumann> cp: cannot stat '../config': No such file
[18:05:48] <abaumann> darn..
[18:05:55] <abaumann> cat "${srcdir}/config" > ./.config
[18:06:21] <abaumann> cat "${srcdir}/config" > ./.config
[18:06:26] <abaumann> sorry. :-)
[18:06:29] <brtln> also I suggested you basing on dynamic section of libraries and executables to figure out build order and if things are ready to move some time ago, no idea why you haven't considered it back then
[18:06:56] <abaumann> that's true. was before my time.
[18:07:07] <abaumann> I'm in the Archlinux32 only since a month.
[18:07:28] <brtln> just as it's beyond me why you wrote your own automation instead of using the one from alarm team… but it's different topic
[18:07:48] <abaumann> ask deep42thought
[18:08:18] <abaumann> the problem I also see is a) the effort to maintain it b) the bash nature c) surprising to downstream
[18:09:06] <abaumann> but it is like that now.. what I expect is that those diff seds get more and more complex. and sooner or later we have to keep the whole modified PKGBUILDs anyway
[18:09:36] <brtln> yeah, that's why alarm approach always made more sense in my eyes
[18:09:50] <abaumann> there is another thing: chroots for building software.
[18:09:55] <brtln> just copy entire pkgbuild and call it a day
[18:10:08] <abaumann> I don't like them, and try to come from ARM or SPARC or i486, a chroot is no help then.
[18:11:48] <abaumann> copy the entire PKGBUILD, but if there are simple sed's possible, like the arch=() ones or some others.
[18:11:53] <abaumann> that was actually the idea.
[18:12:51] <abaumann> we'll see. :-)
[18:20:40] <guys> brtln: copying over the entire PKGBUILD should work fine, but if you can do a simple override of select sections that works even better. :)
[18:21:06] <guys> (I would probably skip sed and go straight to defining a custom build() or whatever, myself.)
[18:21:43] <abaumann> that's dangerous if upstream also adds a build() :-)
[18:22:04] <abaumann> had this with prepare(). no prepare upstream, I added mine, suddenly there were two.
[18:22:49] <abaumann> the biggest danger actually is, that sed silently does nothing if nothing matches.. this is not like patch where you get rejects if a patch goes wrong.
[18:23:21] <isacdaavid> there's no need to touch arch=(). makepkg has a flag to ignore it
[18:23:41] <abaumann> true.. bad example..
[18:24:07] <guys> You'd be overwriting the definition of a bash function, possibly silently. So the solution then is to check that none exists yet...
[18:24:46] <abaumann> ..yep. and the big problem is then: how do you present that down downstream distributions?
[18:24:53] <abaumann> isacdaavid: you are the right person to judge (you are downstream)..
[18:24:59] <guys> I think I mentioned some time ago how to append to a function though (hindered by the inability to declare -f only the function body)
[18:25:44] <abaumann> appending is not always the right thing to do, sometimes you have to do something in the right position..
[18:28:19] <abaumann> ok, there are roughlt 60 PKGBILDs right now, with 45 lines the one from gcc is the biggest one.
[18:28:58] <abaumann> not dramatic, I would say.
[18:29:01] <guys> `eval "$(declare -f prepare|sed -n '1s/^/_/;p')"` and then call _prepare for the upstream prepare()
[18:29:36] <guys> Assuming I'm not saying always do this, but it could be handy sometimes...
[18:29:41] <abaumann> ..and you expect downstream to be a sed-wizard. :-)
[18:30:26] <guys> No, that's just the bog-standard utility for redeclaring package() as _package()
[18:31:40] <abaumann> thanks.
[18:33:38] <guys> It' really simple, you declare -f the function definition and sed the first line (the "function() {" part, that is) to start with a _
[18:34:22] <guys> then eval the output, since eval is actually the correct tool for recycling the output of declare and shopt -p and things like that
[18:35:35] <isacdaavid> 60 pkgbuilds sounds manageable. i don't expect that number to increase considerably
[18:35:41] <isacdaavid> alarm has many more and does it manually, afaict
[18:36:17] <isacdaavid> i personally don't care how you modify it, as long as we can reliably get the modified sources
[18:38:00] <abaumann> I'll also make a test: I take upstream with 'asp', then I apply diff PKGBUILDs and the I apply again i486-specific patches. Actually it works fine.. it's just not always that readable.
[18:39:14] <tyzoid> abaumann: `source` in bash and `declare -f`?
[18:39:24] <tyzoid> I imagine I could make a VM to do that
[18:39:31] <abaumann> sure.
[18:39:34] <tyzoid> not sure how I like that idea, though
[18:39:41] <tyzoid> since it's executing arbitrary code
[18:40:01] <abaumann> well: it's in a dispasable vm.. which can be recreated anytime :-)
[18:40:18] <tyzoid> but you also have the issue that any if statements that define functions will be removed/collapsed
[18:40:34] <abaumann> true again.
[18:40:35] <tyzoid> so you still lose information.
[18:40:53] <guys> tyzoid: your current sed implementation suffers the same?
[18:41:15] <tyzoid> guys: Yes, but we're not trying to maintain an illusion of having "proper pkgbuilds"
[18:41:20] <tyzoid> they're transparently generated
[18:41:42] <tyzoid> unlike a published pkgbuild, which is supposed to be 'clean' for some definition of clean.
[18:42:04] <tyzoid> With this discussion, we're trying to see how we can clean up the pkgbuilds to be 'more proper'
[18:42:11] <abaumann> I was thinking if bash can spit out a clean version after patching, but that's maybe wrong thinking from my side..
[18:42:13] <tyzoid> i.e. so downstream can use them.
[18:42:15] <guys> You could provide archives of the generated PKGBUILD you use during a build, I guess.
[18:42:33] <tyzoid> guys: That was the first step, which we're intending to do anyway
[18:42:53] <guys> Which actually makes sense in a way, since in pacman-dev there have been thoughts about providing source tarball repos
[18:42:54] <tyzoid> the problem becomes those may be difficult to work with, seeing as they're computer-generated
[18:43:45] <tyzoid> So basically like the AUR, except with all sources tarred into a package, and official signing?
[18:43:59] <abaumann> SRPMS.
[18:44:00] <tyzoid> i.e. basically nothing like the AUR
[18:44:06] <abaumann> good idea, actually.
[18:45:28] <tyzoid> abaumann: I kinda like the idea of that, not so much for having pacman do the download and compiling on the users' machine (though certainly that'd be a benefit)
[18:45:35] <tyzoid> but for keeping an archive of all our build sources
[18:45:36] <guys> As in, pacman -Sy downloads $repo.db, pacman -Fy downloads $repo.files, pacman --switch-to-be-named would download $repo.src
[18:46:10] <tyzoid> guys: I nominate -O, for originating build material
[18:46:19] <abaumann> :-)
[18:47:02] <tyzoid> but abaumann: What do you think about tweaking the buildmaster so it grabs the source files, tars them up, and versions those as well?
[18:47:33] <tyzoid> that'd also be handy for reproducible builds, no?
[18:48:14] <abaumann> mmh. what about the environment/chroot used at this point in time when the package was build?
[18:48:25] <abaumann> I'm more afraid about influences there..
[18:49:01] <abaumann> SRPMS serve a nice purpose: you can easily rebuild the package later on and you have all things of a package in one place.
[18:49:42] <abaumann> can be done.. but it's not a top priority, I think.
[18:54:38] <guys> abaumann: that is in the .BUILDINFO in the built package
[18:56:20] <abaumann> oh. :-)
[18:56:30] <abaumann> quite.
[18:57:38] <guys> .BUILDINFO + src.tar.gz is everything needed for the reproducible folks to get started
[19:11:26] <tyzoid> abaumann: I'm thinking of adding an API endpoint to make available the BUILDINFO data for a given package.
[19:11:27] <tyzoid> Thoughts?
[19:12:40] <guys> tyzoid: why? The only people who need it will want the whole package anyway.
[19:13:38] <abaumann> yeah: I see buildenv and options from makepkg, and installed the packages installed at this point in time..
[19:13:48] <abaumann> mmh, not terribly interesting.
[19:13:58] <tyzoid> Partially for our own internal purposes, and also for downstream partners. If it's not useful, then I won't add it.
[19:14:24] <guys> tyzoid: as a matter of curiosity, what internal purposes will be aided by this?
[19:14:44] <tyzoid> mostly consistency checking.
[19:15:10] <tyzoid> guys: I'm putting together an API of things anyway, so I'm trying see what information is useful to include.
[19:15:58] <tyzoid> guys: https://pkgapi.arch32.tyzoid.com and https://pkgapi.arch32.tyzoid.com as examples
[19:16:58] <tyzoid> Part of it is that we're planning a web interface to various arch32 processes, and javing JSONAPIs are useful for grabbing data for those interfaces.
[19:20:23] <abaumann> ah: building git needs shadow, which references it's sources as git+https: source. lovely. :-)
[19:22:11] <abaumann> when was the last time anybody tried to bootstrap an Archlinux from sources only?
[19:22:31] <guys> prolly like 2001 or something
[19:22:41] <abaumann> yep. that's what I thought :-)
[19:23:01] <abaumann> to be fair.. Linux userland doens't make it easy for anybode.
[19:23:12] <guys> Well, that's not fair. alarm and the initial 64-bit port did it...
[19:23:19] <abaumann> true.
[19:23:33] <abaumann> I'm really curious how exactly.
[19:23:39] <abaumann> it's quite painful.
[19:24:27] <abaumann> glibc needs gd?
[19:24:32] <abaumann> oh, cool :-)
[19:24:53] <abaumann> sorry.. getting carried away.. on the polemic trail..
[19:25:15] <abaumann> makedepends=(git gd)
[19:25:16] <abaumann> optdepends=('gd: for memusagestat')
[19:25:19] <abaumann> mmh.
[19:25:38] <guys> s/needs/supports/
[19:26:28] <abaumann> the whole source=git+https is really cool, unless you lack git in your chroot environment.
[19:27:46] <abaumann> No comes the crutial point: do I get glibc to run it's test on a i486 without SIGFPE..
[19:28:04] <WarheadsSE> ALARM has actually bootstrapped 4 times.
[19:28:11] <WarheadsSE> 5/6/7/8
[19:28:19] <abaumann> a, cool.
[19:28:32] <abaumann> what was your basis? a raspian or so?
[19:28:32] <WarheadsSE> Just looooots of rebuilding packages
[19:28:42] <WarheadsSE> nope.
[19:28:47] <abaumann> via crosstools-ng
[19:29:29] <WarheadsSE> only for the absolute bare minimum, and raspbian is a _very_ poor example of a ARM targetted distro.
[19:29:37] <abaumann> :-)
[19:30:08] <abaumann> Currently I bootstraped everything via a i486 crosstool-ng toolchain.
[19:30:20] <WarheadsSE> we're slapped around with Debian as needed for aarch64, but mostly because it had needed kernel, userland, nspawn in order to do ours.
[19:30:35] <WarheadsSE> We'd never use raspbian for that.
[19:30:38] <abaumann> ah. ok.
[19:31:01] <guys> abaumann: who is writing PKGBUILDs that makedepends on git without adding the makedepends?
[19:32:25] <abaumann> glibc has a makedepends=git for being able to check out the release version 2.26 from git.
[19:32:38] <abaumann> instead of downloading it.
[19:32:44] <abaumann> IMHO this is overkill.
[19:33:06] <abaumann> it's something different, if the upstream package is badly released and you have to resort to some git version.
[19:33:56] <guys> abaumann: no, glibc builds from snapshots and frequently updates the snapshot used
[19:34:12] <guys> brtln: help explain this
[19:34:31] <abaumann> you cache all git versions localy. yes.
[19:35:20] <guys> Well, I mean there are reasons why historically we've built the toolchain from releases instead of waiting for tagged releases.
[19:35:32] <guys> * built the toolchain from snapshots
[19:35:55] <abaumann> ok, like missing patches and such.. I suppose.
[19:36:16] <abaumann> and instead of doing what other distros: adding tons of patch files to the release tarballs.
[19:36:36] <abaumann> It's just sad to see the art of releasing software disappear in thin air..
[19:36:38] <guys> like there are lots of fixes we want to pull, but cherry-picking and resolving patches just got unmanageable
[19:37:12] <abaumann> I can image security related picks and stuff, yes..
[19:37:17] <guys> abaumann: As in waiting for glibc to release patchlevel releases? Oh lol
[19:37:57] <guys> And when I say lol I mean looooooooooooooooooooooooooooooooooooooooooooooooooooooollllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll
[19:38:13] <abaumann> :-)
[19:38:53] <abaumann> So, I would declare git as part of base-devel and remove it from makedepends?
[19:40:27] <guys> No...
[19:40:36] <abaumann> or use libgit in pacman?
[19:40:51] <guys> I'm not sure what you mean by this at all.
[19:40:59] <guys> Why would pacman itself need git?
[19:41:16] <tyzoid> guys: for packages where the source is a git repo
[19:41:23] <abaumann> as git gets a dominant way to distribute source tarballs.
[19:41:50] <abaumann> and if it gets the only way (as I see it), it's equavalent to get sources via wget/cut/ftp.
[19:41:50] <tyzoid> abaumann: Github provides a way to get a tar/zip from a tag
[19:41:54] <guys> Uhhhhhhhhhhh... that's what a makedepends is, makepkg installs it when you run makepkg on a package that has a makedepends...
[19:42:15] <tyzoid> guys: but does it do the makedepends before trying to download the sources?
[19:42:21] <guys> Yes!
[19:42:27] <abaumann> hope so.
[19:42:29] <abaumann> yes.
[19:42:39] <guys> checking for missing depends/makedepends happens before downloading of sources
[19:42:47] <abaumann> I just meant: using libgit has benefits to calling git as an external process.
[19:43:10] <tyzoid> abaumann: so it looks like your package may have faulty makedepends if they use git sources but don't list git as a makedepend.
[19:43:12] <abaumann> primarily: git has some nasty dependencies when bootstraping.
[19:43:27] <abaumann> nono.
[19:43:29] <tyzoid> unless I'm misunderstanding
[19:43:42] <abaumann> everygthing is correct from the makedepends point of view.
[19:43:51] <tyzoid> ok
[19:44:05] <abaumann> I just wanted to point out that git is sort of a basic requirement today as gcc is.
[19:47:07] <guys> abaumann: bash doesn't have libgit available as an in-process thing
[19:47:44] <guys> Also devtools explicitly depends on git/mercurial/subversion/etc
[19:49:16] <abaumann> ah. ok.
[19:56:45] -!- isacdaavid has quit [Ping timeout: 268 seconds]
[19:59:39] <guys> Actually I am seriously confused, because makepkg --verifysource should warn that git is uninstalled, but it isn't.
[20:06:20] <brtln> abaumann: I'm not going to maintain shitload of patches on top of stable gcc and glibc release because every 5 years someone assumes that arch is meant to be easily bootstrappable
[20:07:23] <brtln> if that hurts, you can replace it with tarball pointing to the same commit, but we have git helpers on our build infra to make bumping snapshots streamlined
[20:07:28] <abaumann> brtln: no problem. it's not easy bootstrappable.. but it is boostrappable. I'm up to a pingable 486 VM which can build packages.
[20:08:05] <abaumann> I resorted to build a non-Arch git temporarily, so I can checkout the artifacts.
[20:08:14] <brtln> glibc really should have bug fix releases, especially for a year since cut-off, but i tdoesn't, and they are unwilling to
[20:08:43] <abaumann> yeah. that's what I meant by the "art of releasing".
[20:08:55] <brtln> gcc does have it and I consider switching back to tarballs every now and then
[20:09:46] <tyzoid> abaumann: Did you see https://github.com ?
[20:09:47] <phrik> Title: GitHub - pikhq/bootstrap-linux: A Linux system which is just barely capable of building itself. (at github.com)
[20:10:44] <abaumann> I'm actually not completly new to that topic: https://github.com
[20:10:46] <phrik> Title: GitHub - andreasbaumann/minilinux: minimalistic linux built from scratch using a Makefile (at github.com)
[20:10:51] <abaumann> :-)
[20:10:55] <tyzoid> huh
[20:10:55] <tyzoid> nice
[20:11:41] <abaumann> yeah. musl and busybox. sort of the real thing.
[20:11:51] <tyzoid> abaumann: So does this mean that we'll need to add an i486 arch to the repo eventually?
[20:12:16] <abaumann> Who would actually use that, I wonder. :)
[20:12:29] <tyzoid> well, those who don't have SSE2 on their systems could benefit
[20:12:50] <abaumann> yeah. I have a AMD K6 of sorts. No SSE2
[20:12:56] <abaumann> and a laptop. same thing there.
[20:13:08] <abaumann> hence my motivation. :-)
[20:13:24] <tyzoid> abaumann: We used to advertise potential upcoming i486/i586 support: https://github.com
[20:13:25] <phrik> Title: index.html: remove i486 and i586 - these won't be built in the near f… · archlinux32/website@4409045 · GitHub (at github.com)
[20:13:54] <abaumann> oh :-)
[20:14:10] <tyzoid> so if we're doing this, I'd like to do it :P
[20:14:31] <tyzoid> ( ͡° ͜ʖ ͡°)
[20:14:33] <abaumann> but then I insist of everybody running an Archlinux i486 to provide a photograph and description of his machine in the forum :-)
[20:14:42] <tyzoid> lol
[20:15:04] <tyzoid> or be evil and bootstrap a phone-home into gcc
[20:15:39] <abaumann> :-)
[20:17:02] <abaumann> brtln: this bootstrap-linux is actually very nice. :-)
[20:18:23] * brtln winks
[20:18:25] <brtln> I know it's not insanely difficult, I've been doing alpine linux for a while
[20:18:56] <abaumann> alpine is musl, right?
[20:19:03] <abaumann> it has a nice package manager.
[20:19:20] <abaumann> actually. runs fine on the very same 196MB K6. :-)
[20:19:59] <brtln> yes, musl these days
[20:20:34] <brtln> I was mostly active around migration from uclibc so that was rather fun with small differences between both
[20:20:35] <abaumann> the sad story is: sooner or later all C-libraries look like glibc.
[20:20:44] <abaumann> otherwise you cannot support all the software on top.
[20:21:07] <abaumann> oh, cool.
[21:09:46] <bill-auger> abaumann: i noticed a few days ago you were in the #parabola channel saying that you wanted to discuss the future of 32bit arch packages - but you did not stay around for anyone to answer - i just wanted to note that parabola is quite aware of archlinux32 and is already using packages from that repo - there are several parabola developers already in this channel also
[21:10:05] <abaumann> hi. yes.
[21:10:39] <abaumann> isacdaavid has contacted us.
[21:10:50] <abaumann> he seems to be the mr 32-bit guy :-)
[21:10:50] <bill-auger> the best way to join the discussion would be the mailing list thread that you mentioned https://lists.parabola.nu - that was the precise purpose for that thread
[21:10:52] <phrik> Title: [Dev] [dbscripts]: Arch Linux 32 support [annoucement]. ABS' future [RFC] (at lists.parabola.nu)
[21:11:18] <bill-auger> yes he handled the migration from the old archlinux repos
[21:11:47] <abaumann> the original problem was that people complained in our IRC about broken libre packages.
[21:12:17] <abaumann> this then made me aware of 'how do acutally other do the 32-bit migration in archlinux derived distros"
[21:12:46] <abaumann> as I understood, all is well. isacdaavid backports from our diffed PKGBUILDs into your repos.
[21:28:28] -!- abaumann has quit [Remote host closed the connection]
[21:56:49] -!- zaungast has joined #archlinux-ports
[22:09:03] -!- deep42thought has joined #archlinux-ports
[22:27:02] -!- isacdaavid has joined #archlinux-ports
[22:31:25] <deep42thought> tyzoid: I think, it could be a nice idea to hand out the git revisions of a package - so one could retrieve the package sources this way.
[22:31:37] <deep42thought> I mean with your package info interface
[22:35:01] -!- isacdaavid has quit [Ping timeout: 240 seconds]
[22:40:00] -!- isacdaavid has joined #archlinux-ports
[22:42:46] <deep42thought> brtln: problem with using dynamic sections of libraries and executables as dependencies is, that you won't catch all dependencies - e.g. of python or perl, which will expect all modules in a different directory for a different version
[22:43:02] <deep42thought> that was my reason, not to implement it immediately
[22:43:46] <deep42thought> and regarding not-using plugbuild from alarm: That was City-busz's idea - so you need to ask him :-)
[22:43:49] -!- zaungast has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
[22:51:20] <tyzoid> deep42thought: "git revisions of a package" not sure what you mean here?
[22:51:43] <deep42thought> well, the revisions of the source directories
[22:51:50] <deep42thought> e.g. what's currently in the build list
[22:51:56] <deep42thought> on the broken packages list
[22:52:07] <deep42thought> and in each and every file name on the build master anyway
[22:52:34] <deep42thought> there is, e.g. a file linux-zen.916a76e18a41e1922c8f64fca836b42d9417c645.fffd6dcc82f431ca4fa6ccd6ee9714bd4995ceb4.extra.testing
[22:52:53] <deep42thought> denoting, that linux-zen built from those two revisions is currently in testing
[22:53:13] <deep42thought> so with these two numbers, you basically can get the source used to build that package
[22:55:53] <isacdaavid> deep42thought: report-installed-packages worked at last, but only after configuring gpg_recipient in sendmailadvanced.conf
[22:56:09] <deep42thought> isacdaavid: strange
[22:56:29] <deep42thought> it _should_ do a "gpg -a -e -r $to-recipient"
[22:56:43] <tyzoid> deep42thought: Does that refer to a commit has in our repo? if not: now is the git repo stored?
[22:56:50] <deep42thought> so if your user sees the key of buildmaster@archlinux32.org, it _should_ work
[22:57:15] <deep42thought> tyzoid: upstreams svn2git repositories and our modification repository on github
[22:57:23] <tyzoid> ah
[22:58:14] -!- mode/#archlinux-ports [+o tyzoid] by ChanServ
[22:58:32] -!- mode/#archlinux-ports [-o tyzoid] by ChanServ
[22:58:35] <deep42thought> If you like, you can also "convert" the git revision to source tarballs, but I think, it's better to not do so, because: a) all the information is there and b) some tar balls will become large
[22:58:58] <tyzoid> yeah, but where's the source of that info?
[22:59:02] <tyzoid> Is it stored for every package?
[22:59:41] <deep42thought> the content of the source array is the weak spot
[22:59:47] <deep42thought> but otherwise, all should be there
[23:00:03] <deep42thought> I mean: the _online_ content of the source array
[23:00:19] <tyzoid> so... the .SRCINFO?
[23:00:45] <deep42thought> no, you have the PKGBUILD
[23:00:52] <deep42thought> isn't that enough?
[23:01:10] <tyzoid> no, I'm saying how would I access the two hashes?
[23:01:27] <tyzoid> if a user calls the API endpoint, where can I grab the data to give back to the user?
[23:01:28] <deep42thought> ah, sry, misunderstood that
[23:01:36] <tyzoid> np
[23:01:49] <deep42thought> we'd need to dump it somewhere
[23:02:11] <deep42thought> if the buildmaster should track stable packages, too, then it could be an api on the buildmaster
[23:02:12] <tyzoid> deep42thought: if that info is in the .SRCINFO or the .BUILDINFO, I can grab that
[23:02:27] <tyzoid> Since the API is on the same server as my mirror
[23:03:01] <deep42thought> we could dump it into the .buildinfo
[23:03:42] * tyzoid never looked into the package structure, so he doesn't know what info they contain
[23:03:49] * tyzoid will investigate later
[23:04:10] <deep42thought> it cannot be in .PKGBUILD currently, because .PKGBUILD does not know, where the source comes from
[23:04:21] <tyzoid> right, that makes sense
[23:05:07] <tyzoid> deep42thought: Given that our forum is running out of github.com/tyzoid/fluxbb, should I move that repo over to archlinux32?
[23:05:27] <deep42thought> feel free to do so
[23:06:06] <deep42thought> hmm, appending information to .BUILDINFO would require a patch to makepkg :-/
[23:06:16] <deep42thought> or we append something to the built package
[23:09:13] <deep42thought> anyway, gotta go to bed - it's late here
[23:09:45] -!- deep42thought has quit [Quit: Leaving.]