2020-10-01 06:31:31 <indy> hi all, i'm getting on 3.12.0 message apk-tools are old when running abuild, but apk upgrade has nothing new
2020-10-01 06:53:14 <indy> and few of "fatal: not a git repository (or any of the parent directories): .git"
2020-10-01 06:56:39 <mps> indy: you run abuild in directory which don't have .git
2020-10-01 06:57:15 <afontain_> to get aports, you should git clone, then go in the directory of your chosen package
2020-10-01 06:59:22 <indy> i'm polishing package before i'll put it in customer's git
2020-10-01 07:00:01 <indy> trying to fix issue with cmake and rpath "WARNING: somepackage: Redundant /usr/lib in rpath found"
2020-10-01 07:02:42 <indy> tried several combinations of https://dpaste.org/uoHX
2020-10-01 07:06:07 <afontain_> that's probably more suited for #alpine-linux
2020-10-01 07:09:47 <Cogitri> I think you can specify -DCMAKE_SKIP_INSTALL_RPATH=TRUE to CMake, indy
2020-10-01 07:10:05 <Cogitri> But if they doesn't work it's fine to leave the rpath in
2020-10-01 07:10:38 <mps> good morning
2020-10-01 07:10:47 <mps> ncopa: !12185
2020-10-01 07:11:17 <mps> I think this should be merged. any objection?
2020-10-01 07:12:03 <mps> ncopa: I assigned MR to you and forgot about it, sorry
2020-10-01 07:19:03 <indy> Cogitri, already tried, still redundant /usr/lib in rpath, i think i can live with warning as there is no more scanelf red alert regarding rpath :)
2020-10-01 07:21:04 <indy> Cogitri, thanks
2020-10-01 07:28:10 <Cogitri> 👍
2020-10-01 08:57:38 <craftyguy> is this waiting for the maintainer to approve? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/13056
2020-10-01 10:15:35 <ikke> mps: how did you fix that naming conflict with par?
2020-10-01 10:17:15 <mps> ikke: for now by 'depends="!rancid"'
2020-10-01 10:18:03 <ikke> ok
2020-10-01 10:18:50 <mps> when I found time (this means 'never' :) ) I will look at rancid and does it make sense to move its executables in /usr/lib{exec}/rancid dir
2020-10-01 12:55:40 <minimal> Hi folks. The Edge armv7 and armhf builders have been failing on testing/mpdecimal for several days now and its clogging up the queues - I've got a package merged on 26th and another merged on 28th that are still affected by this
2020-10-01 12:56:28 <ikke> Ariadne said she would look at it. I wanted to disable this specific test, but could not find how.
2020-10-01 12:56:38 <ikke> Otherwise, i'll disable the entire package for those arches + dependencies)
2020-10-01 12:56:53 <Ariadne> haven't gotten to it yet sorry
2020-10-01 12:58:37 <minimal> Ariadne: no problem, just wanted to check it was on peoples' radar
2020-10-01 13:04:05 <ikke> minimal: I have #alpine-commits open continue, so I see it constantly failing to build :)
2020-10-01 13:04:48 <minimal> ikke: staring into the abyss? ;-)
2020-10-01 13:04:53 <ikke> heh
2020-10-01 13:17:20 <mps> is the BSD_PROCESS_ACCT useful nowadays on linux?
2020-10-01 13:21:09 <minimal> Ariadne: see you kicked armhf and armv7, unfortunately the 1st testing package they both picked to build is.....mpdecimal :-(
2020-10-01 13:21:29 <Ariadne> that's not wht
2020-10-01 13:21:37 <Ariadne> I want to keep the mips builder busy
2020-10-01 13:21:56 <minimal> I asked on here a couple of days ago whether the builders could be changed (even temporarily) to upload each *individual* package when built, at present it appear to want to built all pending testing packages before uploading them all in one go - so if it hangs (like with mpdecimal) then each time its kicked it builds a lot of the same package all over again before hanging
2020-10-01 13:24:02 <Cogitri> That can be done but we usually don't have the builders in that mode because that masks build failures from maintainers and causes problems for users on those arches (due to missing packages)
2020-10-01 13:24:58 <Cogitri> And the repo might get inconsistent when a package breaks soname, fails to build on that arch but then the builder goes on rebuilding the packages that depend on it
2020-10-01 13:25:11 <ikke> And we want to keep things green as much as possible
2020-10-01 13:25:15 <ikke> this kind of stimulates that
2020-10-01 13:25:48 <minimal> just seems like the testing backlog on the hanging builders archs is getting larger and larger as a result...
2020-10-01 13:26:52 <Cogitri> Yup, but the fix to that is to fix the failing package and not to let the builders wave the failure
2020-10-01 13:29:28 <minimal> didn't mean to wave any failure. I've seen (on build.alpinelinux.org) one of my pending testing packages (unconnected to mpdecimal) build successfully at least once but because that builder then hung on mpdecimal my built package was never uploaded and so continues to be built and thrown away when the builder hangs
2020-10-01 13:30:13 <ikke> Problem is that you then easily run into dependency issues
2020-10-01 13:30:55 <minimal> right, am not familiar with how the builders work exactly.
2020-10-01 13:31:44 <minimal> just seems at the very least very wasteful of resources to keep building and throwing away stuff repeatedly
2020-10-01 13:31:50 <ikke> They get notified of new commits, start building each repo in build order, after each repo is built, it syncs the repo with the master
2020-10-01 13:31:56 <ncopa> minimal: i dont think we want upload individual built packages. It will cause a mess when bumping ABI breaking updates
2020-10-01 13:32:43 <minimal> ncopa: was only a temporary suggestion to be over the ever-increasing backlog for some archs
2020-10-01 13:33:08 <minimal> ncopa: BTW dropped you an email earlier in the week with some cloud-init backgrounder notes
2020-10-01 13:33:47 <ncopa> oh, right sorry, i have been distracted with other stuff this week. sorry
2020-10-01 13:34:04 <ikke> minimal: typically failing packages are fixed sooner (in some way or another)
2020-10-01 13:35:11 <ikke> Ariadne, ncopa: should I just disable the package for now?
2020-10-01 13:35:22 <minimal> just had a look at the mpdecimal log, seg fault during tests. Maybe just disable tests?
2020-10-01 13:35:23 <ikke> It's in testing anyway
2020-10-01 13:35:27 <Ariadne> yes
2020-10-01 13:35:39 <ikke> minimal: We prefer not to
2020-10-01 13:36:06 <ikke> minimal: unless we have verified it's the actual test that is the issue, and not something in the program / library itself
2020-10-01 13:36:26 <ikke> Just disabling tests can mask potential real issues
2020-10-01 13:38:17 <minimal> then temporarily disabling the package as you suggested at least for a short time would let the builders catch up on their backlog
2020-10-01 13:40:55 <mps> why not contact maintainer
2020-10-01 13:41:50 <mps> php7-pecl-decimal and py3-pylint deps on it
2020-10-01 13:43:41 <ncopa> i think we can temp disable it and ping the maintainer
2020-10-01 13:48:00 <Ariadne> controversial opinion: next alpine release should be alpine 13 instead of alpine 3.13
2020-10-01 13:48:48 <mps> :)
2020-10-01 13:49:18 <Ariadne> the 3. part has basically lost any useful meaning at this point
2020-10-01 13:49:33 <mps> 4.1
2020-10-01 13:49:42 <dne> doomsday release
2020-10-01 13:50:07 <insep_> 1.3
2020-10-01 13:50:48 <mps> 2020.12.{day_of_month}
2020-10-01 13:51:19 <mps> but for me 3.13 is quite ok
2020-10-01 13:51:52 <Ariadne> 13 is also ok though :)
2020-10-01 13:53:06 <mps> I'm much too accustomed to dots in release numbers
2020-10-01 13:53:44 <mps> when I see something without at least one dot it looks strange to me
2020-10-01 13:55:11 <Ariadne> you'll adapt
2020-10-01 13:55:16 <ikke> mdec was already disabled on ppc64le and x86, but not yet on armv7 and armhf
2020-10-01 13:55:42 <ikke> Ariadne: I want to see at least Alpine 3.14, after that, I don't care :P
2020-10-01 14:05:06 <minimal> ikke: Alpine 3.151492 ?
2020-10-01 14:05:28 <ikke> 3.14.1592
2020-10-01 14:05:30 <minimal> the "Piece of pie" release :-)
2020-10-01 14:10:12 <maxice8> Alpine $(busybox date -Isec)
2020-10-01 14:12:41 <mps> wouldn't it be better to make rust program which do same ^
2020-10-01 14:12:59 <maxice8> do what ?
2020-10-01 14:13:14 <mps> $(busybox date -Isec)
2020-10-01 14:13:45 <mps> we are becoming real hipsters :)
2020-10-01 14:22:22 <ikke> minimal: armhf/v7 are now up-to-date
2020-10-01 14:24:11 <mps> I expect kernel 5.8.13 release in few hours, hm 13 ;)
2020-10-01 14:24:39 <mps> 5.4.69 is just released
2020-10-01 14:38:38 <minimal> ikke: Thanks
2020-10-01 16:27:46 <andypost[m]> Ariadne: is mips64 builder gone because of build php? or other reason?
2020-10-01 18:31:28 <Ariadne> [10:27] <f44336andypost[m]> Ariadne: is mips64 builder gone because of build php? or other reason?
2020-10-01 18:31:33 <Ariadne> it's catching up
2020-10-01 18:35:43 <Ariadne> [07:55] <@da8e00ikke> Ariadne: I want to see at least Alpine 3.14, after that, I don't care :P
2020-10-01 18:36:01 <Ariadne> ok 3.13, 3.14, 15? :)
2020-10-01 18:42:33 <mps> I don't understand. is the 3.13 wrong or bad and why
2020-10-01 18:48:45 <Cogitri> mps: I think the argument is that the 3.x doesnt really make sense when we don't bump to 4.x at some point
2020-10-01 18:49:13 <Cogitri> Unless we want to jump to 4.x for apk-tools v3
2020-10-01 18:53:02 <mps> Cogitri: big jump is for big changes, imo. when we switch to glibc or systemd :D
2020-10-01 19:00:22 <dalias> lol
2020-10-01 19:01:32 <wsinatra> mps: you can label that one "Alpine: Malware Edition"
2020-10-01 19:03:00 <mps> :)
2020-10-01 19:11:45 <ikke> Having a stable major version is a feature ;-)
2020-10-01 20:03:33 <mps> ikke: in consumer cultures (all world nowadays) people want 'new' and not 'stable'
2020-10-01 20:15:14 <ikke> mps: People want both at the same time
2020-10-01 20:16:48 <dalias> :)
2020-10-01 20:17:03 <Cogitri> Yup, but I think it's mostly new and stable (as in works, not unchanging)
2020-10-01 20:27:59 <mps> which usually doesn't go together, and there are still some people survived which are not 'consumers' by their personality
2020-10-01 20:29:03 <mps> maxice8: just pushed linux-edge with task and io accounting enabled. you can test iotop-c if you want, when builders finish
2020-10-01 20:43:50 <maxice8> ty
2020-10-02 06:01:33 <mps> >>> WARNING: fsverity-utils-dev*: Found static archive on usr/lib/libfsverity.a but name doesn't end with -static
2020-10-02 06:01:56 <mps> this warning should be removed from abuild
2020-10-02 06:02:17 <mps> and good morning
2020-10-02 06:20:04 <ncopa> morning
2020-10-02 06:31:10 <maxice8> morning
2020-10-02 07:00:03 <maxice8> mps: so it has been decided that static libs will be in -dev ?
2020-10-02 07:13:03 <mps> maxice8: to my disappointment (and our new users) no, else I would write 'MUST' instead of 'should'
2020-10-02 07:14:42 <mps> but I do 'change' (i.e. not making -static libs subpkgs) for pkgs I maintain. we have to start somewhere, I think
2020-10-02 07:15:44 <mps> and we are discussing this nearly about two years without any action, it is time to decide about that
2020-10-02 11:36:51 <ikke> mps: so far, I have only seen you bring it up each time :)
2020-10-02 11:40:18 <mps> ikke: yes, because I want to improve alpine
2020-10-02 11:40:57 <mps> and because I'm annoying sometimes ;)
2020-10-02 11:47:59 <mps> started to work on fakeroot upgrade, but want to know does anyone else working on it, to not waste time and work on other things which needs 'care'
2020-10-02 11:48:30 <Cogitri> I don't think anyone else works on it yet
2020-10-02 11:48:46 <Cogitri> mps: Maybe it'd be best to make a vote or something on it on the MR
2020-10-02 11:48:50 <Cogitri> s/R/L/
2020-10-02 11:48:50 <alpine-meetbot> Cogitri meant to say: mps: Maybe it'd be best to make a vote or something on it on the ML
2020-10-02 11:49:25 <Cogitri> I also think that the split doesn't make a ton of sense, I don't see when I'd need the static lib and not the other development files
2020-10-02 11:52:32 <mps> Cogitri: i agree with you but using our ML is hmm.... cumbersome to me
2020-10-02 11:53:01 <tehcloud> lol, mailing list
2020-10-02 11:53:41 <Cogitri> mps: Hm fair, but I doubt that saying it on IRC will lead to anything
2020-10-02 11:53:49 <Cogitri> So the ML is still the best way to reach all devs
2020-10-02 11:54:03 <Cogitri> Since many Devs don't check their gitlab pings
2020-10-02 11:54:40 <mps> ikke: Cogitri: from time to time we got questions on #alpine-linux related to -static libs. new users/developers can't find static libs by installing just -dev and they are surprised about -static
2020-10-02 11:55:12 <ikke> mps: isn't that an issue with subpackages in general?
2020-10-02 11:55:19 <mps> Cogitri: I think we can make decision on IRC also, most of us are here
2020-10-02 11:55:28 <mps> ikke: no
2020-10-02 11:56:35 <mps> most new users understand our subpackages, i.e. -dev, -doc etc., but not -static libs
2020-10-02 11:57:00 <mps> and most of them think that -static is static binaries of pkgs
2020-10-02 11:57:31 <ikke> we regularly get questions about missing man-pages
2020-10-02 11:57:51 <ikke> -dev is less of an issue because it's similar to what ubuntu does I guess
2020-10-02 11:58:08 <ikke> ubuntu/debian
2020-10-02 11:58:21 <Cogitri> Yup
2020-10-02 11:59:50 <Cogitri> But right now we have a somewhat confusing mix of packages having -static for binaries, having -static for libs or nothing having -static at all and instead having the static libs in -dev
2020-10-02 12:00:04 <ikke> yes, that's true
2020-10-02 12:00:05 <mps> yes, man pages (-doc) questions are what keeps repeating mostly
2020-10-02 12:00:24 <Cogitri> So imho we either have to get rid of -static for libs or add it everywhere
2020-10-02 12:00:39 <mps> Cogitri: +1
2020-10-02 12:00:40 <ikke> -staticlibs :P
2020-10-02 12:00:53 <mps> s/+1/+100/
2020-10-02 12:00:53 <alpine-meetbot> mps meant to say: Cogitri: +100
2020-10-02 12:01:27 <mps> ikke: I like your sense of humor ;)
2020-10-02 12:01:40 <mps> -static-dev or -dev-static :D
2020-10-02 12:03:19 <mps> seriously, we should start removal of  -static libs, for start no new libs should have -static subpackage
2020-10-02 12:04:08 <mps> removal can't be done for all in one release cycle but we have to start
2020-10-02 12:06:52 <ikke> We would need proper replace/provides as well
2020-10-02 12:08:39 <mps> I think it would be better to fix every dependant pkg when we change/remove -static from one of them
2020-10-02 12:09:13 <mps> fix in batches TM
2020-10-02 12:12:02 <mps> and some of -static libs subpkgs are not used in any other packages
2020-10-02 12:12:23 <insep_> ikke: `provides="$pkgname-static"; replaces="$pkgname-static"` should be enough?
2020-10-02 12:12:27 <mps> they are made just because of inertia
2020-10-02 12:13:12 <mps> insep_: I dislike this idea with provided/replaces
2020-10-02 12:13:36 <mps> we need to clean this and not complicate it
2020-10-02 12:15:31 <mps> grep -r mbedtls-static . => nothing
2020-10-02 12:15:52 <mps> grep -r libx11-static . => nothing
2020-10-02 12:16:34 <mps> so why add `provides="$pkgname-static"; replaces="$pkgname-static"` to them and a lot of other
2020-10-02 12:16:58 <ikke> Only in case the -static package exists and is later removed
2020-10-02 12:17:20 <insep_> mps: but then we might break setups of people who have just $pkgname-static installed and not $pkgname-dev for some reason
2020-10-02 12:17:34 <ikke> Or we get the same issues as with python, where things break on upgrade because people have -static in world
2020-10-02 12:17:38 <insep_> agreed that it should be done only in already eхisting packages
2020-10-02 12:18:12 <maxice8> when will we be able to remove the py-<module> ?
2020-10-02 12:18:18 <maxice8> from provides= and replaces= ?
2020-10-02 12:19:06 <mps> <harsh hat on> users have to adapt to changes </harsh hat on>
2020-10-02 12:20:02 <mps> if we try to keep expectations of all users we should stop any working on alpine, to have it 'set in stone' as it is
2020-10-02 12:20:19 <ikke> mps: we need to provide a clean upgrade path
2020-10-02 12:20:27 <ikke> the situation with alpine 3.12 was painful
2020-10-02 12:21:04 <mps> heh, I can't even imagine what will be with 3.13
2020-10-02 12:21:51 <mps> how many pkgs will break because of AS-unsafe
2020-10-02 12:28:32 <ikke> good question
2020-10-02 12:28:40 <ikke> I hope we have a good solution before 3.13 is released
2020-10-02 12:28:51 <mps> before leaving to meeting, have to add that I'm not strongly against `provides="$pkgname-static"; replaces="$pkgname-static"`
2020-10-02 12:56:05 <skarnet> this is how, as a developer, I try to organize things when I have to dispatch stuff into several packages (and how I do it on Adélie):
2020-10-02 12:57:53 <skarnet> $pkgname has the binaries, $pkgname-libs has the .so's (so $pkgname typically depends on $pkgname-libs if the binaries are dynamically linked), $pkgname-dev has the headers and static libs, and (this is ugly but consistent) $pkgname-libs-dev has the .so link to the .so.maj.min, that link is only needed when actually building stuff that links against that .so
2020-10-02 12:58:31 <skarnet> that's a lot of subpackages, but if you want a logical semantic separation, that's what you need
2020-10-02 12:59:18 <maxice8> I'd do that but without -libs-dev
2020-10-02 12:59:45 <skarnet> and where would you put the /usr/lib/foobar.so symlink to foobar.so.2.6 ?
2020-10-02 12:59:52 <maxice8> -dev
2020-10-02 13:00:24 <skarnet> that means that either you have a dangling symlinks, or foobar-dev depends on foobar-libs
2020-10-02 13:00:27 <skarnet> which I wanted to avoid
2020-10-02 13:01:00 <skarnet> because you shouldn't need the shared libs when doing development
2020-10-02 13:02:20 <artok> unless linking shared?
2020-10-02 13:02:54 <skarnet> of course, in which case you install foobar-libs-dev because you need it, and it depends on foobar-libs and everything works as intended
2020-10-02 13:04:51 <maxice8> and foobar-libs-dev depends on foobar-dev ?
2020-10-02 13:05:10 <skarnet> no
2020-10-02 13:05:42 <maxice8> So you'll need to install foobar-dev and foobar-libs-dev
2020-10-02 13:06:18 <skarnet> yeah. -dev because you're doing development, and -libs-dev because you're doing development that needs the shared libs.
2020-10-02 13:07:07 <skarnet> but if you wanted to avoid that step, you could artificially add a dep from -libs-dev to -dev
2020-10-02 13:08:44 <Cogitri> I'd say the proposed setup but without -libs-dev also sounds good to me
2020-10-02 13:09:09 <skarnet> again, I don't like -libs-dev aesthetically, but I don't know where else to put it logically
2020-10-02 13:09:22 <Cogitri> Into -dev
2020-10-02 13:09:39 <skarnet>  <skarnet> that means that either you have a dangling symlink, or foobar-dev depends on foobar-libs
2020-10-02 13:09:49 <Cogitri> Most development is with shared libs, dev machines have enough space available usually and the separation seems confusing and artificial to me
2020-10-02 13:09:59 <Cogitri> -dev should depend on -libs, yes
2020-10-02 13:10:11 <skarnet> I thought the point of Alpine was to be small and avoid bloat
2020-10-02 13:10:37 <skarnet> you can say 'who cares it's for development' but that's a slippery slope
2020-10-02 13:11:00 <ikke> are there cases when you need one but not the other?
2020-10-02 13:11:10 <skarnet> I do that all the time.
2020-10-02 13:11:20 <skarnet> I never need shared libs while developing.
2020-10-02 13:11:57 <skarnet> shared libs are another level of complexity that I prefer to handle once I got my shit fixed with static libs already.
2020-10-02 13:12:48 <Cogitri> I'd argue alpine is about not having bloat on user machines, not necessarily dev machines
2020-10-02 13:13:01 <skarnet> how do you tell the difference?
2020-10-02 13:13:05 <skarnet> are devs not users?
2020-10-02 13:13:21 <skarnet> since I'm a dev, I don't deserve a lean machine?
2020-10-02 13:13:32 <Cogitri> At that point you could argue that we shouldn't package headers in -dev because people who don't use C(++) don't need those
2020-10-02 13:13:52 <skarnet> tbh I originally wanted to separate headers from .a's
2020-10-02 13:14:07 <skarnet> because it's not the same functionality, and if you link with shared you don't need the .a's
2020-10-02 13:14:15 <skarnet> but I was told a resounding 'no'
2020-10-02 13:14:18 <skarnet> so, meh
2020-10-02 13:15:09 <skarnet> it's all a question of what granularity we want to have, and of course people like me who like control will want the smallest reasonable granularity possible
2020-10-02 13:15:26 <skarnet> and packagers and maintainers, who have different interests, will want a larger granularity
2020-10-02 13:17:28 <mps> skarnet: developers with knowledge (like you) can do development in minimal system, but average ones would be lost in this
2020-10-02 13:18:08 <skarnet> I appreciate the compliment, but I don't think distain for 'average developers' is a good position to have
2020-10-02 13:18:19 <skarnet> disdain, even
2020-10-02 13:18:59 <mps> it is not disdain (at least not my intention) but my experience
2020-10-02 13:19:29 <skarnet> I can understand that, but it is with packagers and developers as it is with developers and users
2020-10-02 13:19:50 <skarnet> I *know* that most users suck and won't be able to tell the head of my software from its ass
2020-10-02 13:20:10 <skarnet> but making the assumption that they will suck leads to terrible software design
2020-10-02 13:20:28 <skarnet> it's an information I cannot use when writing software
2020-10-02 13:20:57 <skarnet> I have to write assuming users are knowledgeable and smart and will use the software correctly
2020-10-02 13:21:28 <mps> understand, but we are trying to make distro for 'average' developer to be usable (average is not pejorative)
2020-10-02 13:21:29 <skarnet> it makes power users happy, and it challenges other users a little but they can overcome the challenges and actually become better
2020-10-02 13:21:46 <skarnet> same thing with distributions and developers, I believe
2020-10-02 13:23:20 <mps> ime even well known and knowledgeable developers ask sometimes 'trivial' questions about alpie and musl when I report bug to them
2020-10-02 13:23:24 <skarnet> I don't think you can pretend that a lean-and-mean, server-oriented, docker-oriented, musl libc-using distribution is targetting 'average' developers - you are already challenging them
2020-10-02 13:23:28 <skarnet> (and it's a good thing)
2020-10-02 13:24:01 <mps> yes, that is how I 'accepted' alpine (and musl)
2020-10-02 13:24:25 <mps> but again my experience show that not all do this so easy
2020-10-02 13:25:26 <skarnet> coming back down to the specifics, if we're talking about development package granularity, this could certainly be solved with metapackages
2020-10-02 13:26:15 <skarnet> foobar-kitchensink that will install -dev, -libs-dev, and whatever else you want
2020-10-02 13:26:29 <mps> sure, but is that optimal solution
2020-10-02 13:27:29 <skarnet> it's a solution that keeps me happy, that keeps lazy devs happy, and that has a small overhead for packagers, so of course it's not an optimal solution for packagers. :P
2020-10-02 13:28:05 <mps> personally for me current situation is not problem, but repeating answers on our support channels is boring at least
2020-10-02 13:29:08 <skarnet> yeah, you can't tech your way out of a user education and culture problem (people don't read the docs and prefer asking live, it's not new)
2020-10-02 13:29:43 <mps> yes, right
2020-10-02 13:30:07 <mps> (says someone who do same from time to time)
2020-10-02 13:30:15 <skarnet> (guilty too)
2020-10-02 13:31:58 <mps> to finish my talk about this, I agree with Cogitri how to do 'this' and actually I do that for most pkgs I maintain
2020-10-02 15:39:09 <maxice8> Some packages on ppc64le are failing with CMakeFiles/KPimItinerary.dir/KPimItinerary_autogen/mocs_compilation.cpp.o uses 64-bit long double, /usr/lib/gcc/powerpc64le-alpine-linux-musl/10.2.0/../../../../lib/libgcc_s.so.1 uses 128-bit long double
2020-10-02 17:08:11 <[[sroracle]]> The strongest advantage of having .a in a separate -static subpackage from the distro dev perspective is being able to more easily track which packages are consuming static libraries
2020-10-02 17:08:24 <[[sroracle]]> and therefore need to be rebuilt in case of security issues
2020-10-02 17:08:58 <[[sroracle]]> ideally nothing would be consuming these packages but it happens occasionally (i think php is an example)
2020-10-02 17:09:04 <maxice8> I see no infra for managing usage of static by distros
2020-10-02 17:09:24 <[[sroracle]]> it also ensures that packages that SHOULD be dynamically linking libraries... actually are
2020-10-02 17:09:45 <maxice8> That is true, I found s6 was linking static after we switched to separate -static
2020-10-02 19:13:45 <skarnet> it's on purpose
2020-10-02 19:14:15 <skarnet> s6 uses so little libc that it's an actual *gain* to link it statically
2020-10-02 19:14:59 <skarnet> also, there was a time when I had hope it could be used in the base system, and static linking ensures it doesn't break when you change libcs etc.
2020-10-02 21:54:25 <[[sroracle]]> yes, there are exceptions where it is better to statically link
2020-10-02 21:54:32 <[[sroracle]]> and this makes it easy to track those cases :)
2020-10-03 11:49:28 <maxice8> ncopa: ping
2020-10-03 12:04:54 <mps> maxice8: I think his cron daemon activated suspend-on-weekend feature
2020-10-03 12:10:02 <mps> static or dynamic linking should be user and build system controlled
2020-10-03 12:14:15 <skarnet> of course
2020-10-03 21:42:30 <aparcar[m]> fabled: ping
2020-10-04 18:58:03 <gjabell> What's the name of the PKGBUILD to APKBUILD converter?
2020-10-04 18:59:51 <Cogitri> gjabell: toapk
2020-10-04 19:00:28 <Cogitri> Keep in mind that it's an imperfect conversion so make sure to check the APKBUILD afterwards and run the linter on it
2020-10-04 19:01:26 <gjabell> Thanks
2020-10-04 19:01:32 <gjabell> Yeah just want a starting point
2020-10-04 19:02:06 <Cogitri> 👍
2020-10-05 08:42:36 <ncopa> maxice8: pong
2020-10-05 09:22:26 <HRio> any plans for a v3.12.1 in the near future?
2020-10-06 04:51:56 <ikke> python 3.9 is out
2020-10-06 04:58:29 <ikke> maxice81: kitinary started to fail on ppc64le (perhaps due to gcc10?). THe error is about 64-bit long doubles vs 128 bit long doubles
2020-10-06 04:59:49 <ikke> PureTryOut[m]: ^
2020-10-06 06:09:56 <ncopa> morning
2020-10-06 06:10:16 <ncopa> HRio: we should make a 3.12.1 release, yes
2020-10-06 06:24:51 <mps> do we plan to move gtk from main to community for 3.13 release
2020-10-06 06:25:15 <mps> and good morning all
2020-10-06 07:11:12 <Cogitri1> mps: not really feasible, we'd have to move loads of stuff
2020-10-06 07:11:42 <Cogitri1> And since gtk+3.0 won't really change much now that gtk4.0 is around the corner it's not a problem to leave it in main imho
2020-10-06 07:47:23 <ikke> Cogitri1: I think it's more about dependencies, not?
2020-10-06 08:49:04 <Cogitri1> ikke: You mean the dependencies gtk+3.0 has?
2020-10-06 08:51:33 <ikke> yeah
2020-10-06 08:52:36 <ikke> Things that need to stay in main because gtk+3.0 is in main
2020-10-06 08:56:55 <Cogitri1> Hm fair, I guess that might be more of a concern
2020-10-06 10:35:00 <maxice81> <ikke "maxice8: kitinary started to fai"> Already mentioned on other packages too
2020-10-06 12:07:46 <fabled> python3 and/or popler requires rebuild against new gdbm? i'm not able to do upgrade --latest in edge atm.
2020-10-06 12:11:10 <maxice81> python3 already has been rebuilt against new libgdbm and poppler was upgraded more recently that the gdbm upgrade
2020-10-06 12:11:45 <fabled> hum, then it must be avahi-ui-gtk3-0.7-r3
2020-10-06 12:12:17 <maxice81> triggered rebuild
2020-10-06 12:16:24 <fabled> yeah, that helped. thanks.
2020-10-06 12:16:51 <fabled> seems libreoffice and gdal needs rebuild for the poppler update
2020-10-06 12:20:02 <maxice81> gdal already depends on libpoppler.so.103
2020-10-06 12:21:21 <mps> Cogitri1: ikke: I was out of link for few hours, power outage
2020-10-06 12:22:01 <mps> yes, idea is to move gtk and other gui programs to community from main
2020-10-06 12:22:27 <maxice81> libreoffice is currently not building due to gcc-10
2020-10-06 12:22:45 <maxice81> most likely -fno-common
2020-10-06 12:25:48 <Cogitri1> mps: Sure, glad to review MRs :)
2020-10-06 12:25:52 <maxice81> fabled: !13344
2020-10-06 12:26:33 <Cogitri1> maxice8: Hmmm, I think the error message didn't really fit what fno-common causes
2020-10-06 12:26:57 <maxice81> I'll find out that now
2020-10-06 12:28:19 <mps> Cogitri1: :)
2020-10-06 12:53:20 <markand> seriously the UX of gitlab is insane, you create a merge request in alpine/ project and it still selects your own repository by default as destination
2020-10-06 12:56:49 <Hello71> I think you have it backwards
2020-10-06 12:57:03 <Hello71> you are supposed to open your own repository and then click merge request
2020-10-06 12:57:27 <ikke> You can do it from alpine/aports, I do it all the time, and it create an MR from my personal fork to alpine/aports
2020-10-06 12:57:50 <markand> Hello71, I think it also select my repository by default, let me check
2020-10-06 12:58:14 <Hello71> I think it is important to pick the right repository and also right branch
2020-10-06 12:58:20 <Hello71> if you pick master it may go other way
2020-10-06 13:06:01 <insep_> never happened to be with gitlab.com ^^
2020-10-06 13:06:31 <ikke> I typically use the link that gitlab provides over ssh, or the one that appears right after you pushed a branch
2020-10-06 13:06:34 <ikke> that always works for me
2020-10-06 14:09:24 <maxice81> can't resolve hostname to gitlab.alpinelinux.org
2020-10-06 14:09:38 <ikke> https://status.linode.com/incidents/5k68c46r4sgl
2020-10-06 14:10:09 <ikke> Is it the newest rage to rename yourself to <name><number>? :P
2020-10-06 14:10:10 <maxice81> oof
2020-10-06 14:10:32 <ikke> I just noticed myself
2020-10-06 14:10:34 <Hello71> i think Cogitri1 matrix had some isues
2020-10-06 14:11:05 <maxice81> Don't think he uses linode
2020-10-06 14:11:38 <ikke> I think that was a reply to my remark
2020-10-06 14:11:43 <ikke> 172.105.78.12 is the gitlab IP
2020-10-06 14:12:23 <ikke> oops, no
2020-10-06 14:12:48 <ikke> 172.105.69.85
2020-10-06 14:26:13 <Cogitri1> Hello71: No, I don't use Linode, I use Contabo
2020-10-06 14:26:26 <Hello71> yes but I'm saying about the numbers
2020-10-06 14:26:55 <Cogitri1> Huh?
2020-10-06 14:27:08 <Hello71> 14:10 <@ikke> Is it the newest rage to rename yourself to <name><number>? :P
2020-10-06 14:28:07 <ikke> Cogitri1: maxice81 (Hello71 :P)
2020-10-06 14:28:46 <Cogitri1> Ahh, I'm Cogitri1 on IRC?
2020-10-06 14:28:51 <ikke> yes
2020-10-06 14:29:51 <Cogitri1> Ah
2020-10-06 14:30:51 <ikke> apparently harware issues are causing dns to fail
2020-10-06 14:31:02 <ikke> "Our team has identified the hardware issue affecting DNS resolution"
2020-10-06 14:50:15 <meowkitten> hullo, I'm trying to create an alpine package but the docs are really confusing. is there a starting guide that's not multiple 10-page wiki articles, or any other resources yall would point me towards?
2020-10-06 14:52:51 <wsinatra> meowkitten: I felt the same way when I started, this was by far the most helpful reference for me -> https://wiki.alpinelinux.org/wiki/APKBUILD_Reference
2020-10-06 14:53:21 <wsinatra> if the package you're trying to convert is already available in the AUR for Arch Linux you can try and convert it using toAPK to get a decent starting point
2020-10-06 14:53:59 <maxice8> there is newapkbuild
2020-10-06 14:54:16 <insep_> https://wiki.alpinelinux.org/wiki/APKBUILD_examples
2020-10-06 14:54:21 <meowkitten> it is in the AUR, i'll try with that
2020-10-06 14:55:29 <meowkitten> i'm just kinda overwhelmed at there not being a "steps from git repository to apk file", I guess. I know I start by making an apkbuild file, then at some point I put some files in tar archives and combine them together.
2020-10-06 14:55:38 <meowkitten> * at least not one that I could find
2020-10-06 14:57:14 <wsinatra> I'd say the first step is getting the APKBUILD itself together, if you've already configured abuild then abuild checksum && abuild -r will start the build process
2020-10-06 14:57:51 <wsinatra> once you've grokked all of the errors (or lack thereof) you can move onto getting it into aports :)
2020-10-06 14:58:05 <meowkitten> alright
2020-10-06 14:58:46 <wsinatra> feel free to ask questions though, there are tons of people here happy to help, I wouldn't know how to package any of the things I maintain without help from fine folks here
2020-10-06 15:00:05 <meowkitten> appreciate it c:
2020-10-06 15:01:38 <Cogitri> Nick should be fixed after a good ol' restart of the bridge I think
2020-10-06 15:03:16 <ikke> yes, you are now Cogitri again
2020-10-06 15:03:22 <ikke> and maxice8
2020-10-06 15:03:52 <Cogitri> Hooray :)
2020-10-06 15:05:36 <the6543> !13170 is ready to now
2020-10-06 15:06:08 <the6543> in the end it was only because tests need more memory witch armv7 worker do not have
2020-10-06 15:09:56 <meowkitten> quick q, why does abuild-keygen seem to require sudo? I personally use doas and it just prints a "sudo not found" error (but appears to complete successfully)
2020-10-06 15:22:47 <ikke> meowkitten: there is a SUDO env variable that you can use to specify the sudo-like command
2020-10-06 15:22:57 <ikke> meowkitten: it needs sudo for -i
2020-10-06 15:24:09 <meowkitten> oh gotcha, ty
2020-10-06 15:31:19 <the6543> @ikke do you have some spare time to look at gitea package?
2020-10-06 16:31:27 <mps> wsinatra: newapkbuild, abuild sanitycheck, apkbuild-lint
2020-10-06 16:31:58 <mps> and 'eyes' is/are most important
2020-10-06 16:33:01 <wsinatra> didn't know of sanitycheck, sounds useful
2020-10-06 16:33:18 <Newbyte> Why might it be that my shasums are fine when building locally but not in the CI on GitLab? (working on MR 13324 at alpine/aports)
2020-10-06 16:33:21 <wsinatra> apkbuild-lint I abuse though :)
2020-10-06 16:33:24 <mps> I don't think it is good to 'blindly' convert build scripts from other distros
2020-10-06 16:33:37 <Hello71> Newbyte: rm /var/cache/distfiles/*
2020-10-06 16:33:46 <wsinatra> Oh I agree entirely, there's some scary shit on the AUR
2020-10-06 16:33:52 <Hello71> !13324
2020-10-06 16:34:16 <Newbyte> nice
2020-10-06 16:34:29 <Newbyte> there we go, shasums updated
2020-10-06 16:34:33 <Newbyte> thanks
2020-10-06 16:34:49 <wsinatra> but if you just need to get from point a -> b it helps. I use AUR/Void/Gentoo packages a lot as starting points
2020-10-06 16:35:04 <Hello71> also no codeload
2020-10-06 16:36:05 <mps> wsinatra: yes, also I sometimes read PKBUILDs but I write APKBUILD after that, not copy
2020-10-06 16:36:10 <Newbyte> also, different issue: when building, /usr/include/SDL2/SDL_syswm.h does not find directfb.h. originally I assumed this was due to directfb-dev not being part of the makedepends, but I added it there and no dice
2020-10-06 16:36:25 <Newbyte> SDL2 packaging issue?
2020-10-06 16:38:14 <mps> Newbyte: /usr/include/SDL2/SDL_syswm.h   sdl2-dev            edge
2020-10-06 16:38:56 <mps> 'apk-file SDL_syswm.h'
2020-10-06 16:39:35 <Newbyte> mps: I do have sdl2-dev in the makedepends, and it does find SDL_syswm.h. It is rather SDL_syswm.h that does not find directfb.h even with directfb-dev in the makedepends
2020-10-06 16:40:04 <mps> sorry, /usr/include/directfb/directfb.h   directfb-dev        edge
2020-10-06 16:40:30 <mps> I misread your msg
2020-10-06 16:42:42 <Newbyte> mps: again, I do have directfb-dev in my makedepends. I also tried installing it with apk but no dice. I'm rather new to Alpine and packaging as a whole however so I might be missing something.
2020-10-06 16:43:00 <Newbyte> mps: again, I do have directfb-dev in my makedepends. I also tried installing it with apk but no dice. Header still not found. I'm rather new to Alpine and packaging as a whole however so I might be missing something.
2020-10-06 16:46:04 <mps> without looking in build log it is hard to say what could be cause
2020-10-06 16:46:29 <wsinatra> mps: I typically end up rewriting the build and packaging functions by hand with converted packages, the parsing in toAPK right now isn't perfect, but I'm working on a peg parser to fix it
2020-10-06 16:46:33 <mps> can you paste to tpaste.us part of build log which show this
2020-10-06 16:46:41 <Newbyte> I'll see about it. Removing distfiles seems to have revealed some stuff I messed up so I'll solve that first and see if my issue persists
2020-10-06 16:46:53 <Newbyte> I'll see about it. Removing distfiles revealed some stuff I messed up so I'll solve that first and see if my issue persists
2020-10-06 16:47:39 <Newbyte> evidently I'm new to IRC as well
2020-10-06 16:48:40 <mps> wsinatra: yes I know that you are careful. Just wanted to emphasize that is not good idea for new contributors to 'blindly' convert
2020-10-06 16:54:56 <wsinatra> valid point
2020-10-06 17:16:20 <Newbyte> here's the log from building supertuxkart and directfb.h not being found when included in SDL2's headers: http://sprunge.us/nVsKsj
2020-10-06 17:20:21 <mps> #include <directfb.h> => #include <directfb/directfb.h>
2020-10-06 17:20:26 <mps> maybe
2020-10-06 17:20:30 <Newbyte> I'll try
2020-10-06 17:21:24 <mps> or set '-I' (include path) somewhere in Makefile
2020-10-06 17:27:16 <Newbyte> putting directfb/directfb.h did the trick, although now I'm having a different error (which probably could be solved with the same hack). I presume it is SuperTuxKart's CMakeLists.txt that needs altering?
2020-10-06 17:28:16 <mps> Newbyte: probably, need to tell it to search more 'include' paths, but I don't know Cmake much
2020-10-06 17:28:30 <Newbyte> I wonder how this is supposed to work
2020-10-06 17:29:11 <mps> and look if directfb-dev have pkgconf
2020-10-06 23:56:03 <maxice8> Can someone look at 3.12-armhf and 3.12-armv7 builders ? they seem to keep hitting checksum errors on Samba while all other arches buld.
2020-10-07 04:26:30 <ikke> maxice8: https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10009
2020-10-07 04:26:41 <ikke> maxice8: it looks like they succesfully built the next time
2020-10-07 05:16:41 <craftyguy> would someone be able to review this MR? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/12066
2020-10-07 05:17:23 <craftyguy> there are some problems with lurch/omemo on some clients, but it works when both clients use lurch for omemo, so it seems worth having it
2020-10-07 05:17:49 <craftyguy> and the other two plugins seem to work fine in the testing I've done
2020-10-07 05:18:24 <Ariadne> needs rebase
2020-10-07 05:18:27 <craftyguy> if that needs to be 3 separate MRs.. I can do that too. It's been stuck for a few days
2020-10-07 05:18:31 <craftyguy> yeah sure I'll rebase
2020-10-07 05:20:02 <craftyguy> done. there were no conflicts since they are new aports.. so hopefully that wasn't why it has been stuck
2020-10-07 05:20:05 <Ariadne> i went ahead and accepted it
2020-10-07 05:20:19 <Ariadne> looked ok to me at a glance and i didnt see anything bad on CI
2020-10-07 05:20:20 <Ariadne> :)
2020-10-07 05:20:29 <craftyguy> Ariadne: awesome, thanks :)
2020-10-07 05:20:34 <Ariadne> np
2020-10-07 05:21:26 <ikke> :)
2020-10-07 07:20:29 <Newbyte> hi, I was here asking about SuperTuxKart stuff yesterday. I figured out my previous issue (the directfb one), but now it complains about not finding ns_name_ntop(), which seems to come from glibc in this context
2020-10-07 07:20:43 <Newbyte> and I cannot find anything called ns_name_ntop in musl's source code
2020-10-07 07:20:59 <Newbyte> so I presume this is a glibc-only thing. what would I do in a situation like this?
2020-10-07 07:21:46 <Newbyte> is there any glibc compatibility include I could add?
2020-10-07 07:25:55 <Ariadne> no
2020-10-07 07:26:34 <Ariadne> for some things, there are replacement libraries providing those features, but i am not familiar with any library offering that.
2020-10-07 07:26:39 <Newbyte> why is glibc like this
2020-10-07 07:26:58 <Newbyte> I found this, but I haven't checked whether the API is the same: https://www.libspf2.org/docs/html/____ns__name__uncompress_8c.html
2020-10-07 07:27:20 <Newbyte> or if it's the same thing at all
2020-10-07 07:30:11 <Newbyte> seems to have the same API look at the signature
2020-10-07 07:30:33 <Ariadne> what leads you to believe that it has the same API?
2020-10-07 07:31:23 <Newbyte> same return type, same types in parameters, same variable names. exact same. seeems like it could be deliberate
2020-10-07 07:32:07 <Newbyte> the implementation looks the same as well
2020-10-07 07:33:02 <Newbyte> and libspf is packaged in Alpine so … let's see!
2020-10-07 07:39:17 <Ariadne> ...
2020-10-07 07:39:27 <Ariadne> that is not the correct way to solve this
2020-10-07 07:42:08 <Newbyte> Yeah, it feels hacky. What do you suggest?
2020-10-07 07:43:07 <Ariadne> figure out why supertuxkart needs this function
2020-10-07 07:43:49 <Newbyte> and find a suitable replacement in musl?
2020-10-07 07:44:21 <Ariadne> yes or remove the offending code from supertuxkart if it is not really needed
2020-10-07 07:50:35 <mps> I'm not much excited about new langs features but this about zig looks very promising https://kristoff.it/blog/zig-new-relationship-llvm/
2020-10-07 07:51:46 <mps> incremental compilation, in-place binary patching, llvm not needed (self compiling)
2020-10-07 08:11:52 <Cogitri> Yup, zig looks neato
2020-10-07 08:19:02 <insep_> zig's syntax looks ugly
2020-10-07 08:21:41 <mps> insep_: huh, what syntax you like
2020-10-07 08:22:09 <skarnet> DWIM syntax!
2020-10-07 08:23:30 <mps> what is it
2020-10-07 08:23:57 <mps> do what I mean?
2020-10-07 08:24:44 <skarnet> yes
2020-10-07 08:26:41 <insep_> [mps](https://matrix.to/#/@freenode_mps:matrix.org): c# and d have pretty neat syntax
2020-10-07 08:28:51 <mps> insep_: ah, now I understand, you are kidding with me ;p
2020-10-07 08:29:37 <mps> forth have best syntax of all programming langs
2020-10-07 08:34:07 <insep_> i also like smalltalk syntax
2020-10-07 08:38:20 <aparcar[m]> fabled: may I ask which time zone you're in?
2020-10-07 08:59:54 <Ariadne> whatever one finland is
2020-10-07 09:04:26 <aparcar[m]> Ariadne: thanks
2020-10-07 10:03:51 <the6543_> @clandmeter may you have a look at !13170 ?
2020-10-07 12:43:46 <maxice8> I think all py.test invocations should call -v
2020-10-07 12:43:50 <maxice8> helps a lot instead of having TAP output
2020-10-07 12:54:13 <maxice8> @Ikke can you kill the builders ? they are hanging on py3-pyzmq
2020-10-07 12:55:21 <ikke> rip builders
2020-10-07 13:04:51 <maxice8> ty
2020-10-07 13:27:05 <fcolista> any idea on how to catch $repo, $pkgname, $pkgrel, $pkgver in a post-commit git hook?
2020-10-07 13:27:57 <ikke> source the APKBUILD?
2020-10-07 13:28:11 <ikke> for $repo, I guess you need to use basename
2020-10-07 13:29:38 <fcolista> umh
2020-10-07 13:29:56 <fcolista> pre-commit is generic. How to make it source the APKBUILD?
2020-10-07 13:30:10 <fcolista> How does he know the path of the APKBUILD?
2020-10-07 13:30:38 <ikke> look what
2020-10-07 13:30:38 <fcolista> I should make extract it from the commit message ( e.g. testing/package: upgrade to x)
2020-10-07 13:30:40 <ikke> what's staged
2020-10-07 13:31:24 <Hello71> did you read .githooks
2020-10-07 13:31:26 <fcolista> git log --pretty=oneline | awk '{print $2}'|head -1
2020-10-07 13:31:39 <maxice8> the Alpine githooks do that if you need example implementation
2020-10-07 13:33:20 <fcolista> Hello71, maxice8 : yeah I didn't remember about .githooks
2020-10-07 13:33:30 <fcolista> I'll look ath this
2020-10-07 13:34:41 <fcolista> thx ikke for the suggestion
2020-10-07 15:50:37 <Ariadne> i wish that programmers having problems with their programs on alpine would come talk to us first instead of just bothering dalias
2020-10-07 15:50:47 <dalias> it's not a problem
2020-10-07 15:51:09 <dalias> but i wish they would spend their 20 minutes doing the research requested rather than writing email rants
2020-10-07 15:51:28 <dalias> there is probably a good case for a small set of *_l functions including the requested one
2020-10-07 15:51:40 <dalias> but i don't want to go do the homework of determining whether that's the case
2020-10-07 15:52:00 <dalias> i'd like that minimal degree of effort from someone requesting a function
2020-10-07 15:52:43 <Ariadne> yes, but we are capable of distilling that argument and coming to you if necessary :)
2020-10-07 15:53:20 <Ariadne> for example, musl does not want ucontext functions, but we require them for some programs.  we have ucontext functions outside musl :)
2020-10-07 15:53:24 <Ariadne> or obstack, or whatever :)
2020-10-07 15:56:18 <Ariadne> anyway, it is already the case that a program built on alpine may or may not function on other musl systems that do not also ship the other alpine runtime libraries
2020-10-07 15:56:36 <Ariadne> and i do not really see that as a problem :)
2020-10-07 15:59:26 <dalias> "musl does not want ucontext functions" isn't entirely true. there are reasons both to want and not-want, but for the time being the overall leaning is in the direction of not doing it
2020-10-07 15:59:46 <dalias> i see that as a problem :)
2020-10-07 15:59:51 <dalias> but it wouldn't happen if they're building static
2020-10-07 15:59:56 <dalias> which i think is normally the intent
2020-10-07 16:00:15 <insep_> or program that builds with musl doesn't build with glibc :D
2020-10-07 16:03:00 <insep_> welp, seems like the issue was missing libm in ldflags or smth like that
2020-10-07 16:04:17 <Hello71> i think sorear said that glibc is finally merging libpthread
2020-10-07 16:13:31 <Ariadne> https://lists.alpinelinux.org/~alpine/devel/%3C13150407.38Gu9qM0DN%40localhost%3E
2020-10-07 16:13:34 <Ariadne> let the flamewar begin
2020-10-07 16:13:39 <Ariadne> haha just kidding
2020-10-07 16:14:42 <maxice8> sgtm, I always wondered about utmps
2020-10-07 16:20:01 <skarnet> and you still managed to find a way to hate on s6
2020-10-07 16:20:13 <skarnet> I'm impressed by your dedication. :P
2020-10-07 16:21:10 <Ariadne> ?????
2020-10-07 16:21:13 <skarnet> want me to edit the apkbuild to put the s6-ipcserver and s6-ipcserverd programs in a subpackage?
2020-10-07 16:21:24 <Ariadne> hate on it how
2020-10-07 16:21:42 <Ariadne> i was just saying we will need to split those out :)
2020-10-07 16:21:50 <skarnet> "the s6 package is too big for us to have a dependency on it, we need to split the programs out"
2020-10-07 16:22:59 <skarnet> which I find amusing considering the previous discussions where people don't mind having the .so's in the same package as the .a's because who cares it's development :P
2020-10-07 16:23:20 <Ariadne> they aren't talking about libfoo.so.1
2020-10-07 16:23:25 <Ariadne> just libfoo.so
2020-10-07 16:24:52 <Ariadne> and yes, that change would be welcome :)
2020-10-07 16:24:53 <skarnet> anyway. let me grab an alpine VM if I still have one and I'll make a subpackage with the minimal things you need for utmps.
2020-10-07 16:34:10 <skarnet> sorry, been a long time. All apkbuild development should be done on edge, right?
2020-10-07 16:34:15 <Ariadne> yes
2020-10-07 16:34:46 <skarnet> also, the preferred method for upstreaming changes is github? I've heard of a cmdline tool for this, named mkmr, is it operational?
2020-10-07 16:34:57 <maxice8> gitlab.alpinelinux.org
2020-10-07 16:35:07 <maxice8> I think you can auth with GitHub
2020-10-07 16:35:37 <skarnet> ah, gitlab, sorry. No preference. Is there a cmdline tool I can use to create MRs up there without using the web UI?
2020-10-07 16:35:49 <maxice8> there is mkmr
2020-10-07 16:35:49 <ikke> yes, mkmr, like you mentioned
2020-10-07 16:35:54 <skarnet> cool, thanks.
2020-10-07 16:37:17 <dalias> :)
2020-10-07 16:37:28 <dalias> yay utmps
2020-10-07 16:38:00 <Ariadne> skarnet: i am in favor of s6, but until we have a replacement service manager that can fully leverage s6 ... 1MiB of install size is a hard sell
2020-10-07 16:38:24 <Ariadne> i got pushback on real iproute2 instead of busybox iproute for same reason -- so not looking to do that again :)
2020-10-07 16:39:54 <skarnet> Ariadne: working on it :P
2020-10-07 16:39:54 <mps> you want utmps in alpine by default? alpine-base?
2020-10-07 16:40:04 <mps> Ariadne: ^
2020-10-07 16:40:29 <Ariadne> mps: yes.  it is only a minimal amount of KB.
2020-10-07 16:40:41 <insep_> Ariadne: so the service manager of your dreams should be compatible with openrc, systemd and s6 scripts?
2020-10-07 16:40:55 <Ariadne> insep_: no :)
2020-10-07 16:41:13 <mps> Ariadne: I vote against
2020-10-07 16:41:14 <Ariadne> insep_: but i see no reason to reinvent the wheel when a good supervisor already exists.
2020-10-07 16:41:34 <mps> I'm not against utmps but as option
2020-10-07 16:42:00 <mps> several times I told users about it and how to install it
2020-10-07 16:42:01 <Ariadne> mps: i have no opinion on alpine-base per se
2020-10-07 16:42:33 <Ariadne> mps: i agree for things like containers it is just extra weight -- we can solve it by asking in the installer if you want it
2020-10-07 16:43:02 <Ariadne> "Would you like to enable user accounting? [yes/no]" -> if yes, install and enable utmps
2020-10-07 16:43:05 <dalias> i dont understand the situation but i dont see a good reason you couldn't have linking against utmps client-side but still have it be optional whether you want to have utmp at all
2020-10-07 16:43:17 <mps> size is not big so size is not problem, but have something which most users will not use doesn't belong to 'base' imo
2020-10-07 16:43:19 <Ariadne> dalias: yes, that is the situation i am proposing :)
2020-10-07 16:43:45 <Ariadne> mps: i think most users outside of containers will answer yes to "Would you like to enable user accounting?"
2020-10-07 16:44:03 <Ariadne> mps: but i agree that installer is the most appropriate path to handle it, not alpine-base directly :)
2020-10-07 16:44:12 <mps> Ariadne: that optional questions looks ok to me
2020-10-07 16:44:33 <dalias> is there a reason they would?
2020-10-07 16:44:45 <dalias> i haven't used utmp in like decades
2020-10-07 16:45:08 <detha> very much so. For anything that is not a personal workstation
2020-10-07 16:45:10 <dalias> and it's not clear who it's supposed to be useful to except admins of multi-user systems who want to spy on their users
2020-10-07 16:45:10 <Ariadne> dalias: making who(1) work is a frequently requested item in my experience
2020-10-07 16:45:26 <detha> and even then, a working utmp is useful
2020-10-07 16:45:31 <mps> I missed it when I switched to alpine but now I quite fine without 'who'
2020-10-07 16:45:59 <Ariadne> "i don't want to reboot the machine if other people are using it" being a common user story for that
2020-10-07 16:46:19 <Ariadne> so then they check who
2020-10-07 16:46:22 <Ariadne> and who doesn't work
2020-10-07 16:46:37 <Ariadne> the smart ones then check to see if there are other sshd processes
2020-10-07 16:46:47 <Ariadne> however, most are annoyed by that point
2020-10-07 16:47:22 <Ariadne> so i think making who(1) work is really useful
2020-10-07 16:49:16 <mps> amen, will not have to answers users anymore about "why who doesn't work on alpine"
2020-10-07 16:49:28 <dalias> i just think the number of users for whom "other ppl are using it" is a possibility is just fairly small
2020-10-07 16:49:53 <dalias> yes i'm in favor of having utmps as option to make who work :-p
2020-10-07 16:50:01 <mps> dalias: I think same but there is some
2020-10-07 16:50:09 <mps> are*
2020-10-07 16:50:12 <Ariadne> downstream of alpine, this really is one of the largest complaints we received from customers
2020-10-07 16:50:15 <dalias> but i don't think "most users should say yes"
2020-10-07 16:50:52 <mps> so: default _is_ 'n'
2020-10-07 16:51:00 <Ariadne> dalias: in an ideal world, they should not, but encouraging them to say yes makes my life easier
2020-10-07 16:51:13 <Ariadne> default is probably yes
2020-10-07 16:51:16 <dalias> i would mention "who" and "w" in the question
2020-10-07 16:51:32 <dalias> since "user accounting" is confusing
2020-10-07 16:51:50 <mps> good note
2020-10-07 16:52:44 <Ariadne> let me put it this way, if i had $1 for every user who has come into IRC asking why who doesn't work over the years, i would have at least $500
2020-10-07 16:53:00 <dalias> :)
2020-10-07 16:53:18 <Ariadne> so i think it is worthwhile to put users on a path where they get working who
2020-10-07 16:53:27 <Ariadne> and users who know better can say they don't want it
2020-10-07 16:54:12 <mps> iirc, I saw few users asking why systemd doesn't work on alpine ;)
2020-10-07 16:54:42 <skarnet> last summer I wrote a systemctl shim for s6-rc
2020-10-07 16:54:54 <skarnet> yes, I was being paid for it
2020-10-07 16:55:08 <mps> ah, I forgive then
2020-10-07 16:55:08 <skarnet> wouldn't have done it otherwise :P
2020-10-07 16:55:18 <dalias> lol
2020-10-07 16:55:24 <skarnet> the problem was puppet modules being hardcoded to invoke systemctl
2020-10-07 16:55:35 <Ariadne> i think systemctl shim seems reasonable enough
2020-10-07 16:56:10 <skarnet> the problem with that is that the systemd model and the s6 model don't 100% map
2020-10-07 16:56:21 <Ariadne> insep_: anyway to answer your question, skarnet has already heard about what we would like to see in a replacement to openrc and seems amenable to making most of it happen
2020-10-07 16:56:21 <skarnet> so there are totally irrelevant options to systemctl
2020-10-07 16:57:11 <skarnet> and there's not much else I could do than "systemctl: warning: option --lennartize-service ignored"
2020-10-07 16:57:51 <dalias> :)
2020-10-07 16:58:11 <mps> someone already made alpine on glibc
2020-10-07 16:58:18 <dalias> i'd be excited to see s6-based-for-init alpine
2020-10-07 16:58:30 <Ariadne> but if i were to guess, i would say that we probably won't have an answer for the openrc problem until after 3.14
2020-10-07 16:58:36 <insep_> Ariadne: so alpine with s6 might happen, huh?
2020-10-07 16:58:37 <Ariadne> possibly .15, probably .16
2020-10-07 16:59:02 <skarnet> Ariadne: we still need to discuss the details of the features you need
2020-10-07 16:59:05 <Ariadne> insep_: yes, with some sort of alpine twist on it :)
2020-10-07 16:59:22 <tehcloud> s6 as an option or as default?
2020-10-07 16:59:25 <skarnet> the overview seems reasonable especially since you're handling the network manager part
2020-10-07 16:59:27 <Ariadne> tehcloud: default
2020-10-07 16:59:30 <tehcloud> oh, nice
2020-10-07 16:59:55 <skarnet> so as long as you can send events and the service manager can process events everything should be doable
2020-10-07 16:59:58 <Ariadne> we have had a good run with openrc, but openrc maintainers only care about gentoo
2020-10-07 17:00:00 <insep_> yay, i'll finally have a motivation to try out s6
2020-10-07 17:00:05 <skarnet> but I'd like to dive into the details sometime
2020-10-07 17:00:11 <tehcloud> s6 seems leaner anyway
2020-10-07 17:00:22 <insep_> the only time i did that was when i booted obarun livecd
2020-10-07 17:00:47 <mps> how s6 compare to runit
2020-10-07 17:00:59 <skarnet> s6 is maintained
2020-10-07 17:01:05 <skarnet> that's the main difference :P
2020-10-07 17:01:16 <Ariadne> openrc only caring about gentoo even though alpine installs count for a non-trivial part of openrc's install base (probably more than gentoo) is a serious problem for us
2020-10-07 17:01:19 <mps> skarnet: I know that :)
2020-10-07 17:01:38 <Ariadne> also our openrc is quite heavily modified if you haven't noticed
2020-10-07 17:01:48 <skarnet> mps: ask heliocat in #s6, he'll give you the rundown of all the differences
2020-10-07 17:01:55 <Cogitri> Ariadne: Isn't openrc upstream dead?
2020-10-07 17:01:56 <mps> long time ago I switched debian on runit as init 1
2020-10-07 17:01:59 <skarnet> (s6 guy at home, using runit at work)
2020-10-07 17:02:13 <Ariadne> Cogitri: it seems to be a dead man walking
2020-10-07 17:02:25 <Ariadne> gentoo did a hotfix release 0.41.2 which we do not yet ship :)
2020-10-07 17:02:27 <Cogitri> The only problem with s6 that I see is that it's rather complex to use for end users
2020-10-07 17:02:40 <skarnet> Cogitri: yeah, known problem, working on it
2020-10-07 17:02:42 <Cogitri> But if we have a simpler wrapper around it that'd be pretty neato
2020-10-07 17:02:46 <Ariadne> Cogitri: yes, that's what i am hoping to sit down with skarnet and tackle :)
2020-10-07 17:02:53 <Cogitri> 👍️
2020-10-07 17:03:22 <Ariadne> unfortunately i have been quite busy with ifupdown-ng and other initiatives driven by downstream customer requirements
2020-10-07 17:03:23 <Cogitri> Maybe it'd be worth looking into what 66 and tt (very google-able names) are doing since those are working on making s6-rc easier to use
2020-10-07 17:03:50 <skarnet> I have
2020-10-07 17:03:51 <u0jQx9gPyrYg> and s6 immediately with execline scripts?
2020-10-07 17:03:53 <Ariadne> 66 is close to what i would like to see, but does not actually support systemd units (instead they made a similar format)
2020-10-07 17:04:10 <Ariadne> u0jQx9gPyrYg: no plans to ever support that configuration
2020-10-07 17:04:34 <Ariadne> however you can install that today and build it yourself if you want
2020-10-07 17:04:37 <Ariadne> the packages are there
2020-10-07 17:04:46 <skarnet> Ariadne: it's impossible to really support systemd units without being systemd, because how units are organized is intricately mixed with the systemd model
2020-10-07 17:04:59 <u0jQx9gPyrYg> i know. i have my own setup since long, some of it is even on gh: https://github.com/stef/s6-services/blob/master/services-network/unbound/run
2020-10-07 17:05:18 <mps> I think we don't need systemd units
2020-10-07 17:05:26 <skarnet> I can see myself writing a parser for unit files, but translating the modelization of systemd units into something usable will be much harder
2020-10-07 17:05:35 <u0jQx9gPyrYg> meh. EURLTOOLONG sorry
2020-10-07 17:05:40 <Ariadne> mps: correct, i just want to be able to use them as a source of knowledge
2020-10-07 17:05:56 <maxice8> Nosh has a converted
2020-10-07 17:05:59 <Ariadne> mps: since upstreams are shipping them
2020-10-07 17:06:07 <maxice8> I looked at it long ago but the build system was... suboptimal
2020-10-07 17:06:23 <mps> Ariadne: yes, also I look sometimes at them
2020-10-07 17:06:36 <skarnet> maxice8: the nosh model isn't perfect either
2020-10-07 17:06:37 <Ariadne> programmatic knowledge capture from systemd units is highly useful
2020-10-07 17:07:03 <Ariadne> it has been a want since 2015 when we first started talking about replacing openrc in alpine :)
2020-10-07 17:07:14 <Hello71> "knowledge capture" is Ariadne officially enterprise now
2020-10-07 17:07:52 <skarnet> tbh it would be less effort to manually convert every openrc script on Alpine into the new service manager format, whatever it is, than to write a translator from systemd unit
2020-10-07 17:08:22 <Ariadne> Hello71: [|> systemd logo here] "don't open this container!  it's dangerous!!  we were once a great and powerful nation."
2020-10-07 17:08:24 <skarnet> I absolutely do not want to be constrained by the systemd way of looking at things
2020-10-07 17:08:44 <Ariadne> skarnet: i just want to be able to extract the basic data from systemd unit files
2020-10-07 17:08:54 <Ariadne> like "run this command"
2020-10-07 17:09:05 <skarnet> but that's my point
2020-10-07 17:09:18 <skarnet> the data will be organized in a very specific way
2020-10-07 17:09:30 <skarnet> it will impose an architectural view on your clients
2020-10-07 17:09:48 <skarnet> your clients will have to look at the data in the way systemd decided
2020-10-07 17:09:51 <Ariadne> true
2020-10-07 17:10:04 <skarnet> service files are probably translatable
2020-10-07 17:10:06 <Hello71> skarnet: even a translator that fails on all ordering except pre-defined relations (basically sysv like $network etc) is still useful
2020-10-07 17:10:12 <skarnet> but socket files and target files, not so much
2020-10-07 17:10:13 <Hello71> and only handles service units
2020-10-07 17:10:14 <Ariadne> what Hello71 said basically
2020-10-07 17:10:55 <skarnet> I will write that for money
2020-10-07 17:11:01 <skarnet> I'm absolutely not doing it on my free time
2020-10-07 17:11:05 <Ariadne> likely doable :)))
2020-10-07 17:11:32 <Hello71> you could do a shitty awk implementation in ten minutes
2020-10-07 17:11:41 <skarnet> lol
2020-10-07 17:12:06 <skarnet> analyzing relations between services is not simple syntax
2020-10-07 17:12:16 <skarnet> the parser is probably the less annoying part of all that
2020-10-07 17:14:09 <skarnet> least*
2020-10-07 17:14:41 <Hello71> yes but that applies to only 1% of service files. I think probably even if you include Wants/After=network.target and such built-in options probably 99% of service files (excluding systemd bundled services) are Type=simple/forking+PIDFile with no ordering
2020-10-07 17:15:55 <skarnet> I'm not in the habit of writing programs that work 99% of the time
2020-10-07 17:15:58 <Hello71> and I don't think anybody but systemd has a concept of network-online.target or device units etc anyways
2020-10-07 17:16:12 <skarnet> ^ yes, that's precisely my point
2020-10-07 17:16:23 <Hello71> or anything remotely similar
2020-10-07 17:16:54 <mps> is it so hard to write run scripts from 'head'
2020-10-07 17:17:46 <skarnet> but if you want to understand how stuff is booted and maintained by systemd in order to translate it to whatever format you want, you need to understand the whole set of unit files and the systemd logic
2020-10-07 17:18:11 <skarnet> and that's what is constraining and artificial and annoying
2020-10-07 17:18:20 <Hello71> you can't say the problem is in the translator if the target simply does not contain some functionality
2020-10-07 17:19:02 <skarnet> the global functionality can *be there*, but the way it's achieved can be fundamentally different
2020-10-07 17:19:16 <Ariadne> mps: the desire is to use the ones upstreams already provide
2020-10-07 17:19:25 <Ariadne> so they cannot complain
2020-10-07 17:19:26 <Ariadne> :)
2020-10-07 17:20:06 <skarnet> for instance, I'm never going to do "socket activation" the way systemd does, i.e. "start everything in parallel and pray that the loggers don't fail"
2020-10-07 17:20:07 <mps> why we have to care if upstream complain
2020-10-07 17:20:31 <ikke> To get them to cooperate
2020-10-07 17:20:34 <skarnet> but the overall functionality of parallel startup exists
2020-10-07 17:20:56 <mps> instead of complains they can write run script/file for alpine
2020-10-07 17:20:57 <skarnet> the functionality of fd-holding exists
2020-10-07 17:21:12 <skarnet> the functionality of super-servers exists
2020-10-07 17:21:16 <mps> that is how I see cooperation
2020-10-07 17:21:31 <skarnet> but a "socket activated" service can map to either of those 3, or all of them
2020-10-07 17:21:39 <Hello71> but which upstreams use systemd socket activation, even by default
2020-10-07 17:21:39 <ikke> mps
2020-10-07 17:21:57 <Ariadne> that way of cooperation is how we got systemd to begin with
2020-10-07 17:21:57 <skarnet> Hello71: you either write a unit file converter or you don't
2020-10-07 17:22:01 <Hello71> I don't know of any that use it exclusively except for inetd style services
2020-10-07 17:22:24 <Hello71> skarnet: space bar heating much
2020-10-07 17:22:31 <skarnet> you can't say "I'm gonna write a converter that works for the 90% of services that are actually easy to convert" because it's useless, those are the ones that are easy to understand by hand
2020-10-07 17:22:49 <ikke> mps: they don't know openrc or whatever service manager we happen to use.
2020-10-07 17:22:59 <Hello71> skarnet: are you volunteering to convert all of them then
2020-10-07 17:23:11 <skarnet> that's exactly what I said above, yes
2020-10-07 17:23:18 <Ariadne> there are several thousand runscripts
2020-10-07 17:23:20 <Ariadne> in aports
2020-10-07 17:23:24 <Ariadne> :))))
2020-10-07 17:23:29 <skarnet> run scripts are easy
2020-10-07 17:23:51 <mps> ikke: I'm not much confident in converters, however they are good written
2020-10-07 17:24:02 <Ariadne> anyway
2020-10-07 17:24:31 <Ariadne> i guess systemd unit compat is not a requirement, but i think the syntax used for configuration should be declarative and in a similar syntax
2020-10-07 17:24:46 <Hello71> i think we have talked enough about this. better have someone actually work on it and let code talk, before we turn into gentoo bureaucracy simulator
2020-10-07 17:24:47 <skarnet> if you want automatic conversion you also need automatic parsing and rewriting of openrc files with start-stop-daemon invocation and other eldritch horrors
2020-10-07 17:24:49 <Ariadne> at least then an upstream can easily port their unit file over :)
2020-10-07 17:25:21 <Ariadne> either way, we had our wakeup call in 2015, its 2020 now and openrc is all but dead
2020-10-07 17:25:44 <Ariadne> and since openrc has been basically exclusively a gentoo production they did not care about us anyway :P
2020-10-07 17:25:51 <ikke> What was the wake-up call?
2020-10-07 17:26:21 <skarnet> Ariadne: hmu at some point to discuss detailed requirements
2020-10-07 17:26:24 <Ariadne> ikke: i forget, i think we tried to reconcile some of our changes with openrc and it was a huge pain :)
2020-10-07 17:26:37 <skarnet> I'll be rather available in the upcoming days
2020-10-07 17:27:02 <Ariadne> skarnet: i'm presently gathering up all necessary documentation to get netherlands visa
2020-10-07 17:30:15 <Ariadne> so probably won't have much time
2020-10-07 17:30:44 <skarnet> whenever you have time
2020-10-07 17:31:08 <skarnet> I'll go out a lot less in the next weeks
2020-10-07 17:31:18 <skarnet> so will be online more
2020-10-07 17:33:08 <skarnet> how do you say to APKBUILD that the main package depends on a subpackage?
2020-10-07 17:33:18 <maxice8> add it to depends
2020-10-07 17:33:56 <skarnet> depends isn't inherited by subpackages?
2020-10-07 17:34:10 <maxice8> if in the subpackage function you pass depends="" then no
2020-10-07 17:34:14 <skarnet> okay, thanks.
2020-10-07 17:34:17 <Ariadne> i think a more urgent item is to replace elogind with a cleanroom impelementation :)
2020-10-07 17:34:39 <insep_> https://sr.ht/~kennylevinsen/seatd/
2020-10-07 17:34:41 <maxice8> there is seatd on sr.ht
2020-10-07 17:34:43 <maxice8> heh
2020-10-07 17:35:00 <insep_> tried packaging it at one point, but never did test it
2020-10-07 17:35:09 <insep_> i think i still have apkbuild somewhere in git stash
2020-10-07 17:35:15 <insep_> it even builds!!!!!!!!!!!
2020-10-07 17:35:20 <maxice8> amazing
2020-10-07 17:35:35 <Ariadne> that does not support the dbus api though afaik
2020-10-07 17:35:50 <Ariadne> dbus being shit aside, its what is standard these days
2020-10-07 17:36:05 <dalias> what is elogind and what is it needed for?
2020-10-07 17:36:12 <dalias> some FDO hell?
2020-10-07 17:36:20 <Ariadne> no, it is actually useful
2020-10-07 17:36:48 <maxice8> Can anyone confirm a circular dep for me ?
2020-10-07 17:36:52 <Ariadne> it lets the system know who is sitting in front of the computer
2020-10-07 17:37:07 <Ariadne> it also manages things like permissions to device nodes
2020-10-07 17:37:08 <maxice8> brotli->(m)cmake->(m)curl-dev->(m)brotli-dev
2020-10-07 17:37:19 <Ariadne> so you no longer have
2020-10-07 17:37:51 <Cogitri> Something systemd user session-ish would be neato too
2020-10-07 17:37:57 <Ariadne> "user running X cannot use 3D graphics because DRI permissions are missing"
2020-10-07 17:38:10 <dalias> maxice8, eeew
2020-10-07 17:38:19 <maxice8> ?
2020-10-07 17:38:25 <dalias> that circular dep
2020-10-07 17:38:36 <dalias> also i hate brotli
2020-10-07 17:38:45 <maxice8> ok but can anyone confirm
2020-10-07 17:38:51 <dalias> the codebase is FULL of UB
2020-10-07 17:38:54 <Ariadne> maxice8: yes i confirm it
2020-10-07 17:38:57 <dalias> for no justifiable reason
2020-10-07 17:38:58 <maxice8> thanks
2020-10-07 17:39:13 <dalias> if it were me i'd just scrub the curl dep on brotli
2020-10-07 17:39:20 <dalias> but maybe users insist on having it? :(
2020-10-07 17:39:31 <Ariadne> i doubt users actually care
2020-10-07 17:39:35 <Ariadne> :)
2020-10-07 17:40:01 <skarnet> the thrifty solution
2020-10-07 17:40:09 <skarnet> have brotli-bootstrap without the curl dep
2020-10-07 17:40:14 <skarnet> and brotli with the curl dep
2020-10-07 17:41:53 <maxice8> brotli requires curl because cmake requires curl-dev on makedepends
2020-10-07 17:42:03 <maxice8> guess we can build brotli with  ./configure ?
2020-10-07 17:42:21 <Cogitri> Yes, just wanted to suggest that
2020-10-07 17:42:26 <Cogitri> Just using autotools should work around it
2020-10-07 17:42:46 <dalias> yeah why use cmake if it also offers autoconf?
2020-10-07 17:42:58 <dalias> autoconf has better behavior in pretty much all ways
2020-10-07 17:43:40 <insep_> https://dpaste.com/HPLAC8J2V in case someone wants an apkbuild for seatd ^^
2020-10-07 17:43:43 <mps> dalias: cmake is new and shiny :)
2020-10-07 17:43:56 <mps> newer*
2020-10-07 17:44:42 <maxice8> makedepends="elogind-dev"
2020-10-07 17:44:43 <maxice8> nice :D
2020-10-07 17:45:00 <maxice8> yes I am poking fun and know it can be changed
2020-10-07 17:45:06 <dalias> eew what??
2020-10-07 17:45:11 <maxice8> also +1 for using proper meson invocations
2020-10-07 17:45:13 <mps> interesting, I didn't know that my workstation don't know that I'm 'seating' in front, though I don't run elogind
2020-10-07 17:45:37 <insep_> it requires it for logind support and i decided to add it cuz why not
2020-10-07 17:46:21 <mps> then alpine is small^W, simple^W
2020-10-07 17:46:45 <dalias> ariadne, re: elogind/seating and "actually useful", it's useful to the 0.1% of users who are running desktops with multiple user accounts
2020-10-07 17:47:09 <Ariadne> dalias: its also useful because it fixes the permissions for audio and video access
2020-10-07 17:47:13 <dalias> if you don't do that, chmod g+rw is the right solution
2020-10-07 17:47:50 <mps> or adduser user video, audio, netdev etc
2020-10-07 17:47:57 <dalias> the 'logind' type approach is almost certainly also broken in the presence of retaining sessions or file descriptors
2020-10-07 17:48:12 <skarnet> a login hook in a regular display manager or even in .profile with a tty test (to do it on VTs, not on pseudo-ttys) that chmods the devices would work just as well
2020-10-07 17:48:30 <dalias> in the sense that you can't make it actually a security boundary unless you do the systemd thing of killing all the user's processes when they log out
2020-10-07 17:48:36 <dalias> (breaking screen/tmux)
2020-10-07 17:49:31 <Ariadne> mps: sure :)
2020-10-07 17:49:38 <dalias> the right way to do all this is to have the display server mediate access
2020-10-07 17:50:10 <dalias> but FDO folks hate X because it got things right before they came up with all their wrong ideas :-p
2020-10-07 17:50:25 <Ariadne> agreed, unfortunately FDO went in a different direction
2020-10-07 17:50:39 <Ariadne> i hate X because it doesn't support zero-copy compositing
2020-10-07 17:50:55 <skarnet> I want my audio device to work when I log in on a VT even if I don't use X
2020-10-07 17:51:10 <Ariadne> which is needed to get decent framerates at higher resolutions
2020-10-07 17:51:17 <skarnet> my point being: tying this to a graphical display manager is a mistake
2020-10-07 17:51:27 <Ariadne> yes
2020-10-07 17:51:41 <Ariadne> anyway i want to fix all that too, but can only fight so many battles at once
2020-10-07 17:52:28 <Ariadne> other things i would like to do: remove CONFIG_VT from linux and replace with userspace version that properly uses the GPU to render full unicode text
2020-10-07 17:52:30 <Ariadne> :)
2020-10-07 17:52:46 <afontain_> I find the concept of graphical display manager weird
2020-10-07 17:53:44 <mps> afontain_: from time when on machine is used by more X terminals at same time
2020-10-07 17:53:51 <mps> one*
2020-10-07 17:54:26 <Ariadne> even if you want VGA text mode (which in our EFI world is going the way of the dodo)
2020-10-07 17:54:35 <Ariadne> userspace can do that better than CONFIG_VT too
2020-10-07 17:55:02 <mps> kernel messages in utf
2020-10-07 18:00:41 <Ariadne> mps: i was thinking more like vim but sure why not :)
2020-10-07 18:02:47 <insep_> as long as you keep fbcon alive and in kernel, useful when bringing up new devices :P
2020-10-07 18:07:02 <mps> huh, looks like irssi freezes from time to time on my server
2020-10-07 18:08:25 <mps> for kernel I would like if they fix some bugs I reported and some waiting in my queue to report
2020-10-07 18:25:18 <skarnet> utmps has 2 daemons, utmpd and wtmpd. What's the preferred way of starting them? 2 openrc services or 1 service that starts both?
2020-10-07 18:26:28 <skarnet> I personally prefer 2 separate services, but I'm not sure how to implement that with the foobar-openrc automatic packaging in abuild
2020-10-07 18:26:54 <skarnet> (*cough* it's much simpler when you start the services with s6 *cough*)
2020-10-07 18:27:28 <insep_> i think abuild automatically splits all .initd files to -openrc
2020-10-07 18:27:44 <insep_> just add $pkgname-openrc to $subpackages
2020-10-07 18:27:53 <maxice8> but there are multiple -openrcs I guess
2020-10-07 18:28:10 <skarnet> well I'd like to have an utmpd.initd and a wtmpd.initd
2020-10-07 18:28:29 <skarnet> would utmps-openrc automatically have these?
2020-10-07 18:28:50 <maxice8> openrc() moves everything in /etc/init.d and /etc/conf.d
2020-10-07 18:29:06 <skarnet> I'll take a look at default_openrc in abuild
2020-10-07 18:29:18 <maxice8> but there is only one openrc in the package ?
2020-10-07 18:29:33 <skarnet> it's one package that has 2 daemons
2020-10-07 18:35:20 <maxice8> Yes
2020-10-07 18:36:49 <Newbyte> Okay, so, I got SuperTuxKart 1.2 to build without anything ugly, but the CI fails on uploading artefacts as the archive is too large. I forgot how to tell that bot to link an MR but it's MR 13324
2020-10-07 18:37:00 <maxice8> !13324
2020-10-07 18:37:08 <Newbyte> Is that something I did wrong or just the nature of said game having a bunch of assets?
2020-10-07 18:37:52 <ikke> Mostly the latter. How big is the package?
2020-10-07 18:38:05 <Newbyte> I think it's around half a gigabyte
2020-10-07 18:39:47 <ikke> supertux-data is currently just 150MB
2020-10-07 18:40:32 <insep_> Newbyte: nice
2020-10-07 18:41:34 <Newbyte> ikke: All right. I don't think I'm doing anything that would bloat the build size, but I could very well be missing something or having forgotten to adapt something.
2020-10-07 18:43:16 <Newbyte> Anyhow, would that build artefact size be a blocker for having the upgrade merged?
2020-10-07 18:44:50 <Cogitri> Nope
2020-10-07 18:45:34 <Newbyte> Should I ping the maintainer or something like that?
2020-10-07 18:48:28 <skarnet> what's the Alpine policy on user and group creation by packages? should they be added in preinstall, with dynamic uid/gids? should they be statically allocated?
2020-10-07 18:50:59 <mps> skarnet: I usually add users in pre-install
2020-10-07 18:51:14 <skarnet> wfm
2020-10-07 18:51:28 <mps> for example https://tpaste.us/yNal
2020-10-07 18:52:14 <skarnet> missing "exit 0" or ":" at the end
2020-10-07 18:52:41 <skarnet> your script can return false if svxlink already exists
2020-10-07 18:53:02 <mps> heh, yes
2020-10-07 18:53:11 <mps> didn't noticed till now :)
2020-10-07 18:54:07 <mps> that was package long time in local repo and when I pushed I didn't looked carefully, shame on me. thanks for notice
2020-10-07 18:54:14 <skarnet> np :)
2020-10-07 18:57:28 <mps> also missing in testing/aprx (HAM software stays long in local repo)
2020-10-07 19:02:20 <Newbyte> btw, I noticed that testing/love does not build any more (due to change in source URL), but the package is the latest version available. would it be reasonable to send in a MR to make it build again? and if so, should the pkgrel be bumped, considering it doesn't/shouldn't change the package?
2020-10-07 19:07:11 <mps> Newbyte: yes
2020-10-07 19:07:22 <Newbyte> yes to both?
2020-10-07 19:07:31 <mps> yes :)
2020-10-07 19:08:37 <Newbyte> thank you
2020-10-07 19:09:04 <mps> np :)
2020-10-07 20:35:44 <mixi> dalias: re "the 'logind' type approach is almost certainly also broken in the presence of retaining sessions or file descriptors": logind uses device specific ioctls like DRM_DROP_MASTER (drm) and EVIOCREVOKE (evdev) to invalidate the fd they handed out on session end (or switch)
2020-10-07 20:42:11 <dalias> does that work for sound or other things too tho?
2020-10-07 20:50:35 <mixi> it doesn't seem to handle revocation for more than drm and evdev
2020-10-07 20:51:50 <mixi> according to https://github.com/systemd/systemd/blob/master/src/login/logind-session-device.c#L211
2020-10-07 22:14:42 <Hello71> alsa doesn't support receiving fds at all. for audio, logind uses acls on /dev/snd/*
2020-10-07 22:16:25 <Hello71> i don't think access is revoked on session exit or change, probably in part because alsa doesn't support it but also users probably expect sound to continue playing while their session is in the background
2020-10-07 22:16:59 <Hello71> in theory I think it could support it but it would need to be wired into alsa-lib and I don't think anyone sensible wants to touch that (see: iproute2)
2020-10-07 22:18:26 <Hello71> or some system-wide audio daemon, but i don't think even lennart is that crazy (pulseaudio is recommended to be run per user)
2020-10-07 22:21:07 <Hello71> also dsnoop/dmix is fragile enough as it is
2020-10-07 22:51:30 <dalias> hello71, the issue is not playing but recording. you leave a recording process open in the background to spy on a victim user
2020-10-07 22:52:04 <dalias> for playing i think it's at most an annoyance/jump-scare issue
2020-10-07 22:54:29 <Hello71> same technical problems though (multiple layers need support)
2020-10-07 22:57:19 <dalias> right. i wonder if this really calls for a general solution rather than per-device...
2020-10-07 22:58:02 <dalias> i.e. a device-generic ioctl that invalidates existing open file descriptions for the device and works on any char or block device
2020-10-07 23:07:16 <Hello71> I think this would probably cause unnecessary breakage in otherwise-working programs. also, it doesn't address the issue of resuming access
2020-10-07 23:08:27 <dalias> well you just wouldn't use it (it would need root) if you didn't want to. but in the situation where you do want it, there is no "resuming access"
2020-10-07 23:08:46 <dalias> the whole point is that you want to enforce a policy that users can't hold onto 'seat' devices after leaving the seat
2020-10-07 23:08:57 <Hello71> what about switching vts
2020-10-07 23:09:24 <dalias> i dont know what logind does but i would not consider vt switching an appropriate time to apply this policy
2020-10-07 23:10:02 <Hello71> actually now that I think about it the drm/evdev revocation might be for practical, not security reasons (only one program can hold exclusive access to the drm node)
2020-10-07 23:10:04 <dalias> if you have a setup where you leave multiple users logged in at console both handing off input device back and forth between each other, you don't have any secure seat policy
2020-10-07 23:10:42 <dalias> the drm thing is just stupid and because linux's graphics device architecture is wrong :-p
2020-10-07 23:10:56 <dalias> users should never have access to the drm devices; if they do they almost certainly have a gaping root hole
2020-10-07 23:11:22 <dalias> but this is the classic gl issue that's not getting fixed anytime soon :(
2020-10-07 23:11:49 <dalias> in fact FDO broke it even more by disabling glx module by default in Xorg and letting it bitrot to the point it crashes the system if you override to enable it
2020-10-07 23:11:51 <Hello71> actually you're a bit behind on that. gpu virtualization is popular again because of "cloud computing"
2020-10-07 23:12:06 <dalias> but it's not actually virtualization
2020-10-07 23:12:22 <Hello71> i'm talking about gvt-g etc, not vfio
2020-10-07 23:12:23 <dalias> it's mediation of access with iommu
2020-10-07 23:12:30 <dalias> no?
2020-10-07 23:12:42 <Hello71> that's passthrough, which I agree is not true virtualization
2020-10-07 23:12:56 <dalias> how does true virtualization work?
2020-10-07 23:13:05 <Hello71> not sure :p
2020-10-07 23:13:12 <dalias> i ssuspect there's no such thing :-p
2020-10-07 23:13:18 <Hello71> but the selling point is that multiple vms can simultaneously use a single gpu
2020-10-07 23:13:46 <dalias> i'm pretty sure that jusst means task switching/scheduling on the gpu
2020-10-07 23:14:01 <dalias> possibly even running programs from multiple guests concurrently with fewer gpu cores or whatever
2020-10-07 23:14:24 <Hello71> again, I don't know how it's implemented, but at least the theory is that they can securely multiplex work from multiple guests
2020-10-07 23:14:28 <dalias> but still with the guest having direct access to the gpu, limited only by iommu and on-gpu policy enforcements
2020-10-07 23:15:02 <dalias> and the only reason anyone believes they're "secure" is that it's a black box of closed-source drivers that hide how it actually works
2020-10-07 23:16:00 <Hello71> afaik Serious Cloud Providers already use this technology. if google is willing to put billions of dollars of servers on the line, I'm going to go ahead and assume that it's at least practically secure even if it's not information-theoretically secure
2020-10-07 23:16:37 <dalias> it's not practically secure either
2020-10-07 23:16:40 <Hello71> i could be wrong on that first part though
2020-10-07 23:16:57 <dalias> nothing "serious cloud providers" are doing is secure
2020-10-07 23:17:10 <Hello71> secure against what threat model
2020-10-07 23:17:15 <Hello71> is the question
2020-10-07 23:17:16 <dalias> you can almost surely steal private keys from other guests on the same node with side channel attacks
2020-10-07 23:17:58 <dalias> the only mitigation is that most of the time an attacker is not on the same physical node as anything worth attacking
2020-10-07 23:18:10 <dalias> but the whole ecosystem is utterly insecure
2020-10-07 23:19:25 <Hello71> there's a lot of actual money riding on the assumption that it's "mostly ok"
2020-10-07 23:20:11 <Hello71> and I don't mean bug bounties
2020-10-07 23:20:21 <dalias> yeah i know
2020-10-07 23:21:53 <Hello71> so sure, if your threat model is "someone with a new spectre-type vulnerability that's actually practical and hasn't yet been mostly mitigated" or "someone with millions of dollars to spend acquiring the former" then yeah
2020-10-07 23:23:56 <Hello71> returning to the topic of session isolation, i reckon you could fix everything with a proper SAK that kills all non-system processes
2020-10-07 23:25:35 <Hello71> ignoring the problem of excessively complicated gpu apis
2020-10-07 23:27:16 <dalias> you don't want to kill other user's processes though
2020-10-07 23:27:20 <dalias> just prevent them from spying on you
2020-10-07 23:27:30 <dalias> for example if they left "nice make" running
2020-10-07 23:27:35 <dalias> killing that would suck
2020-10-07 23:30:20 <Hello71> slows your session though, at least until linux scheduling is fixed (the whole system, not the kernel cfs in isolation)
2020-10-07 23:31:05 <Hello71> 
ACTION shrugs

2020-10-07 23:32:55 <Hello71> SOCK_DESTROY gives some precedent for this "forcibly killing file descriptions" idea though
2020-10-07 23:33:34 <Hello71> but maybe linus will say it is misguided and should never have been added
2020-10-08 00:45:03 <Sodomon> Hello everyone
2020-10-08 00:45:47 <Sodomon> I am making the virtualbox package as you can see here
2020-10-08 00:45:49 <Sodomon> Yhttps://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/9373/
2020-10-08 00:48:17 <Sodomon> I have already compiled virtualbox and the interface works
2020-10-08 00:49:16 <Sodomon> here is the proof
2020-10-08 00:49:22 <Sodomon> https://gitlab.alpinelinux.org/alpine/aports/uploads/04cb3e13569f882cce10335ed5511368/ss.png
2020-10-08 00:51:29 <Sodomon> https://i.imgur.com/VQ5AJUq.png
2020-10-08 00:51:41 <Sodomon> but when starting a virtual machine it gives that error
2020-10-08 00:52:07 <Hello71> you stripped suid
2020-10-08 00:52:32 <Sodomon> I don't understand
2020-10-08 00:52:59 <Sodomon> I just wanted to know if anyone was interested in helping me package it and avoid all its mistakes
2020-10-08 00:53:44 <Hello71> virtualbox mostly sucks anyways
2020-10-08 00:54:29 <Hello71> the code quality sucks, puel sucks, oracle sucks in general
2020-10-08 00:56:42 <Sodomon> but having it in alpine would be very good for users who have alpine and want to arch,debian,etc in a virtual machine
2020-10-08 00:57:46 <Hello71> the only reason people use vbox is stockholm syndrome from windows
2020-10-08 00:58:17 <Hello71> it used to have better usb passthrough but qemu has that now
2020-10-08 00:58:30 <Hello71> without selling oracle your firstborn
2020-10-08 00:59:36 <Hello71> for most purposes a chroot is fully sufficient for using multiple distros
2020-10-08 00:59:55 <dalias> with proper use of unshare(1) even moreso
2020-10-08 01:00:01 <Hello71> i guess they're off to provide their firstborn
2020-10-08 01:01:05 <Sodomon> but still, isn't there someone who wants to help pack it up?
2020-10-08 01:02:02 <dalias> hello71, i don't think your response to sodomon is helpful tho
2020-10-08 01:03:20 <wsinatra> wouldn't virtualbox fit into the unfree license category?
2020-10-08 01:03:45 <wsinatra> I know when I packaged yED there wasn't resistance, but it wasn't really embraced with open arms either
2020-10-08 01:03:48 <Hello71> dalias: I did give the (probable) right answer. if you want to be the sucker^Wgenerous fellow to give the baby steps, I'm not stopping anyone
2020-10-08 01:04:03 <Hello71> wsinatra: vbox core is gpl. it's the addons which require puel
2020-10-08 01:04:40 <Hello71> it's a little more complicated because their bios (i think seabios fork?) needs open watcom which debian said is not oss
2020-10-08 01:04:46 <Hello71> but i think binaries are available under free license
2020-10-08 01:05:26 <wsinatra> ah, that's definitely confusing. I thought it was similar to yED in that commercial distribution required paid licensing, but the system was otherwise "free to use"
2020-10-08 01:05:31 <wsinatra> didn't realize the core was gpl'd
2020-10-08 01:07:28 <Hello71> even puel is afaik not *horribly* objectionable, but people are legitimately worried about its aggressive termination clauses combined with oracle's standard business model of license noncompliance extortion
2020-10-08 01:13:29 <Sodomon> the virtualbox has an oss version
2020-10-08 01:19:20 <Hello71> seems like debian removed virtualbox from stable releases due to impossibility of backporting security fixes
2020-10-08 01:19:53 <Hello71> although alpine like most other non-huge distros rarely backports patches, this still seems pretty against "small simple secure"
2020-10-08 01:22:09 <Sodomon> Well, I'm trying to eliminate all the mistakes.
2020-10-08 05:26:25 <mps> Hello71: +1
2020-10-08 05:50:05 <ncopa> morning
2020-10-08 05:50:38 <ikke> o/
2020-10-08 05:51:15 <mps> \o
2020-10-08 05:55:04 <ncopa> i think we might need a machine-id service for https://www.freedesktop.org/software/systemd/man/machine-id.html
2020-10-08 05:55:32 <ncopa> its super simple, if /etc/machine-id is missing during boot, create it
2020-10-08 05:56:42 <ncopa> we currently create it with dbus post-install, but i think that is wrong
2020-10-08 05:58:14 <mps> machine-id is wrong from privacy standpoint
2020-10-08 05:59:01 <ncopa> it is needed for things like kubernetes
2020-10-08 05:59:10 <mps> but looks like a lot of things doesn't work without it
2020-10-08 05:59:31 <mps> yes, I understand :(
2020-10-08 05:59:51 <ncopa> problem is that dbus generates it, but things that does not uses dbus needs it
2020-10-08 06:00:06 <ncopa> apparently main/gcr needs it. test suite fails without it
2020-10-08 06:01:55 <mps> 
ACTION thinking of retirement from computers

2020-10-08 06:03:14 <ncopa> if we add an /etc/init.d/machine-id service, in what package do we ship it?
2020-10-08 06:04:24 <mps> alpine-base?
2020-10-08 06:09:58 <ncopa> actually, i think /etc/init.d/bootmisc might be suiteable
2020-10-08 06:17:57 <mps> and add option in /etc/conf.d/bootmisc to start 'machine-id=yes/no'?
2020-10-08 06:18:33 <mps> whatever is default
2020-10-08 06:20:05 <mps> maybe even recreate it on every boot
2020-10-08 06:54:36 <ikke> someone had an idea to generate a constant machine-id
2020-10-08 06:54:50 <ikke> so it would be the same for everyone
2020-10-08 08:31:50 <ikke> andypost[m]: php7-pecl-redis is failing on armhf atm:
2020-10-08 08:31:53 <ikke> PHP Warning:  PHP Startup: Unable to load dynamic library 'modules/redis.so' (tried: modules/redis.so (Error relocating modules/redis.so: igbinary_unserialize: symbol not found), /usr/lib/php7/modules/modules/redis.so.so (Error loading shared library /usr/lib/php7/modules/modules/redis.so.so: No such file or directory)) in Unknown on line 0
2020-10-08 09:29:33 <andypost[m]> ikke, will check soon
2020-10-08 09:29:48 <ikke> thanks
2020-10-08 10:01:07 <andypost> ikke, I can't reproduce locally in docker
2020-10-08 10:11:33 <Ariadne> what is igbinary_unserialize ?
2020-10-08 10:12:06 <ikke> there is an igbinary extension
2020-10-08 10:12:12 <ikke> php7-pecl-igbinary-3.1.6_rc1-r0
2020-10-08 10:12:25 <andypost> yes, this one
2020-10-08 10:12:52 <andypost> ah, it still 3.1.5 for armhf
2020-10-08 10:13:12 <Ariadne> sounds too me that redis.so depends on igbinary but not loaded.
2020-10-08 10:13:41 <andypost> https://pkgs.alpinelinux.org/packages?name=php7-pecl-igbinary&branch=edge
2020-10-08 10:14:03 <ikke> interesting
2020-10-08 10:14:43 <ikke> Installed:                                Available:
2020-10-08 10:14:46 <ikke> php7-pecl-igbinary-3.1.6_rc1-r0         = 3.1.6_rc1-r0
2020-10-08 10:14:48 <ikke> ot
2020-10-08 10:14:55 <ikke> it's rebuilt, but not yet uploaded
2020-10-08 10:15:05 <ikke> or it's built, I must say
2020-10-08 10:16:33 <ikke> andypost: php7 -i | grep igbinary returns nothing
2020-10-08 10:17:14 <andypost> but for me php7 --ri igbinary works
2020-10-08 10:17:33 <andypost> and reports 3.1.5
2020-10-08 10:17:41 <ikke> Extension 'igbinary' not present.
2020-10-08 10:17:51 <ikke> the module is installed
2020-10-08 10:18:27 <ikke> /usr/lib/php7/modules/igbinary.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, stripped
2020-10-08 10:19:02 <andypost> maybe ini file is broken
2020-10-08 10:19:02 <ikke> andypost: there is no ini file enabling this module
2020-10-08 10:19:16 <Ariadne> :D
2020-10-08 10:19:35 <Ariadne> this is why when i see PHP i go running in the other direction
2020-10-08 10:19:49 <andypost> ikke, but /etc/php7/conf.d/10_igbinary.ini is here for me(
2020-10-08 10:20:06 <ikke> https://tpaste.us/QWDE
2020-10-08 10:20:16 <ikke> andypost: well, you still have the old version
2020-10-08 10:20:20 <ikke> 1.3.5, right?
2020-10-08 10:20:33 <andypost> yes... now I see
2020-10-08 10:20:48 <andypost> that's my clean-up - thank you a lot
2020-10-08 10:20:53 <ikke> np
2020-10-08 10:22:59 <andypost> but that's valid line https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/php7-pecl-igbinary/APKBUILD#L44
2020-10-08 10:23:58 <ikke> it's not
2020-10-08 10:24:02 <ikke> look carefully
2020-10-08 10:24:45 <andypost> sure... need to wake up
2020-10-08 10:24:49 <ikke> I mean, syntactically it works, but it does not do what you expect
2020-10-08 10:25:36 <ikke> strange it only happens on armhf, though..
2020-10-08 10:25:54 <Ariadne> needs -r1
2020-10-08 10:28:47 <Ariadne> :)
2020-10-08 10:29:14 <andypost> thank you)
2020-10-08 10:32:10 <skarnet> Ariadne: Alpine policy is never to add openrc scripts to runlevels by default, right? if you have a button [*] enable user accounting then utmpd and wtmpd will need to be in the boot runlevel, will the installer or alpine-setup or whatever handle that?
2020-10-08 10:32:50 <skarnet> iow: should I leave any "rc-update add utmpd boot" shenanigans out of the APKBUILD?
2020-10-08 10:34:26 <Ariadne> yes installer will sort that part out :)
2020-10-08 10:34:34 <mps> yes
2020-10-08 10:34:54 <mps> hmm, someone was faster :)
2020-10-08 10:35:41 <skarnet> okay
2020-10-08 10:36:30 <mps> Ariadne: just fixed vboot-utils. looks like you don't need to download apk from my site anymore :)
2020-10-08 11:42:39 <skarnet> conflict question
2020-10-08 11:43:16 <skarnet> utmps-dev has a /usr/include/utmpx.h file, and so does musl-dev
2020-10-08 11:44:24 <skarnet> how should that be addressed? if Alpine's policy is to have utmps in base, then the official utmpx.h should be utmps's, and the musl one should just be removed
2020-10-08 11:45:11 <skarnet> but if the policy is "people can choose to build without utmps" then there needs to be an alternatives mechanism
2020-10-08 11:45:52 <mps> ask dalias to put your file in musl
2020-10-08 11:46:10 <skarnet> (note that building against utmps's utmpx.h won't break anything if the utmps daemons are not running, the utmpx functions just won't do anything)
2020-10-08 11:47:15 <skarnet> mps: not possible, there's some utmps-specific stuff in there
2020-10-08 11:47:19 <mps> but yes, this is conflict
2020-10-08 11:48:09 <mps> overwriting files are not allowed
2020-10-08 11:48:42 <mps> maybe pre/post install script to move/rename file
2020-10-08 11:49:20 <mps> utmps-dev will depend on musl-dev, I think
2020-10-08 11:49:21 <skarnet> that 1. will not work since the conflict mechanism is at the apk level directly, 2. would be extremely ugly
2020-10-08 11:49:44 <skarnet> I'm not asking for technical answers, I know how to manage the technical part
2020-10-08 11:49:59 <skarnet> it's a policy question: what's the correct way of managing that under Alpine policy?
2020-10-08 11:50:07 <Cogitri> utmps doesn't have a pkgconfig file since projects just auto-discover the header, right?
2020-10-08 11:50:21 <mps> ok, then my answer above, overwrite is not allowed
2020-10-08 11:50:39 <Cogitri> If it did I'd put it in a separate folder and adjust the pkgconfig file, it it doesn't then I'd say remove the header from mus
2020-10-08 11:50:41 <Cogitri> l
2020-10-08 11:51:02 <skarnet> Cogitri: there's no conflict and no problem with the utmps library itself. The only conflict is with the utmpx.h file, which is standards-mandated
2020-10-08 11:51:23 <skarnet> musl provides a nop implementation of the standard
2020-10-08 11:51:31 <skarnet> utmps provides another implementation
2020-10-08 11:51:40 <Cogitri> Yes, I meant the header. But if that's the standard location which we shouldn't change then remove the header from musl
2020-10-08 11:51:47 <Cogitri> I don't see the point of providing the header with subs
2020-10-08 11:51:53 <Cogitri> s/subs/stubs/
2020-10-08 11:51:53 <alpine-meetbot> Cogitri meant to say: I don't see the point of providing the header with stubs
2020-10-08 11:52:06 <skarnet> good bot XD
2020-10-08 11:52:53 <mps> Cogitri: it couldn't be removed, it is part of musl-dev
2020-10-08 11:53:24 <skarnet> it can, it's a policy decision
2020-10-08 11:53:50 <mps> technically yes
2020-10-08 11:54:15 <skarnet> in my MR I can add a commit removing utmpx.h from musl-dev, if it's accepted that programs that use utmp now have to depend on utmps-dev as well as musl-dev
2020-10-08 11:54:23 <skarnet> but it's not my decision to make
2020-10-08 11:55:20 <mps> what will return back utmpx.h if we remove utmps-dev and keep musl-dev
2020-10-08 11:55:35 <skarnet> nothing, that's the point
2020-10-08 11:56:09 <skarnet> but it will only matter for building programs that use utmp
2020-10-08 11:56:26 <skarnet> building these programs will require installing utmps-dev
2020-10-08 11:57:08 <mps> I can't recall example now but some programs require utmpx.h right now
2020-10-08 11:57:18 <skarnet> yes, like who
2020-10-08 11:57:26 <mps> yes
2020-10-08 11:57:48 <skarnet> that's why it's a distro-wide decision to make
2020-10-08 11:58:23 <mps> I don't have correct answer now
2020-10-08 11:58:50 <skarnet> yeah, I can see that. :P
2020-10-08 11:59:08 <mps> sensible, better to say :)
2020-10-08 11:59:43 <skarnet> I'm just exposing the problem for distro heads to think about.
2020-10-08 11:59:51 <skarnet> and come to a decision later.
2020-10-08 12:38:45 <maxice8> cogitri: zfs 0.8.5 is out
2020-10-08 13:27:57 <Ganwell> The seccomp issue with chromium is annoying. One can't core-dump processes with seccomp, but the problem disappears if one sets --no-sandbox.
2020-10-08 13:32:00 <Hello71> seems like there are two questions here: first, should it be possible to install musl utmpx.h at all; second, if it is, which should the default be
2020-10-08 13:32:49 <Hello71> imo the answers are yes and no respectively. this points to splitting utmpx.h into subpackages (musl-dev-utmpx or somesuch) which conflict with each other
2020-10-08 13:33:44 <Hello71> you can't use pkgconfig because each package would need to individually support utmps, and the point of utmps is supposed to be that it's a system wide shim
2020-10-08 13:33:56 <Hello71> or "alternative implementation" if you will
2020-10-08 13:34:14 <Hello71> Ganwell: can't you do it as root
2020-10-08 13:35:53 <Ganwell> Hello71: I read this as, the whole functionality is disabled: https://1042.ch/f
2020-10-08 13:36:21 <Hello71> they mean from perspective of chromium itself
2020-10-08 13:38:37 <Ganwell> Hello71: I just realized that I set ulimit wrong: now I have "ulimit -c unlimited", lets see if I get a core-dump on a seccomp crash.
2020-10-08 13:41:28 <skarnet> Hello71: it's still "using another implementation over the libc's", so you need -lutmps in every package you build. You can work around this via distro linker config but it's ugly.
2020-10-08 13:45:28 <Hello71> hm.
2020-10-08 13:49:56 <fcolista> any idea on this error within dmesg?
2020-10-08 13:49:58 <fcolista> [Wed Oct  7 18:32:33 2020] ptrace attach of "radiusd -C"[7755] was attempted by "radiusd -C"[7756]
2020-10-08 13:50:08 <fcolista> radius is running in an lxc container
2020-10-08 13:50:17 <Hello71> crashed and trying to do backtrace?
2020-10-08 13:50:24 <fcolista> ah-a
2020-10-08 13:50:36 <fcolista> not a segfault
2020-10-08 13:50:42 <fcolista> just a crahs of the service
2020-10-08 13:50:46 <Hello71> or you have some zero day, but probably the other one
2020-10-08 13:51:17 <fcolista> someone tryign to abuse of radius service?
2020-10-08 14:24:22 <dalias> skarnet, what utmps-specific stuff does its utmpx.h need?
2020-10-08 14:24:55 <dalias> also is it possible to just have pkgconfig use a different -I ahead of /usr/include for the utmpx.h from utmps in programs that will link against it?
2020-10-08 15:04:02 <skarnet> dalias: typically https://github.com/skarnet/utmps/blob/master/src/include/utmps/utmpx.h#L71
2020-10-08 15:04:17 <skarnet> this should not matter but just in case
2020-10-08 15:06:05 <skarnet> also, yes, if -I/usr/include/utmps happens before /usr/include then the correct utmpx.h will be found
2020-10-08 15:06:56 <skarnet> so, not installing utmps's /usr/include/utmpx.h (which just includes utmps/utmpx.h) at all is another possibility
2020-10-08 15:46:48 <dalias> skarnet, that sounds like the cleanest option
2020-10-08 15:51:48 <skarnet> again, this is a decision for the Alpine heads to make
2020-10-08 15:54:37 <dalias> yes
2020-10-08 15:54:45 <dalias> it's my recommendation for them tho
2020-10-08 15:56:20 <skarnet> I can probably make a first utmps apk on this basis because it's entirely opt-in and doesn't conflict with anything
2020-10-08 15:56:28 <skarnet> and change it later if it's not what people want
2020-10-08 16:03:06 <dalias> yeah
2020-10-08 16:13:57 <Ganwell> Hello71: tab just failed, no core dump :(
2020-10-08 16:25:20 <skarnet> uuuuuuh wait
2020-10-08 16:26:12 <skarnet> mkmr requires me to create a fork of the gitlab repo and push a branch to it?
2020-10-08 16:26:31 <maxice8> yes
2020-10-08 16:26:40 <skarnet> can I create such a fork without interacting with the gitlab web UI?
2020-10-08 16:27:21 <Cogitri> Maybe via the API but that's definitely more work than pressing one button i the webui once
2020-10-08 16:27:30 <maxice8> No tooling in mkmr exists for that
2020-10-08 16:27:35 <ikke> https://docs.gitlab.com/ee/api/projects.html#fork-project
2020-10-08 16:27:51 <Cogitri> Alternatively you can send patches to Gitlab via email but you need to access the UI to get the mail to send the patches to
2020-10-08 16:27:53 <skarnet> I feel this does not fill the niche that the ML was filling
2020-10-08 16:28:12 <Cogitri> Having to press one button is a problem?
2020-10-08 16:28:14 <skarnet> the point of the ML was to streamline dev cycles by not having to use a GUI at all
2020-10-08 16:28:16 <skarnet> yes, it is
2020-10-08 16:28:17 <skarnet> very much
2020-10-08 16:28:35 <skarnet> I don't want to have to interact with a web UI for development, *ever*
2020-10-08 16:28:40 <Cogitri> It's a one-time cost, you could add it in mkmr if it's really *that* much of a problem
2020-10-08 16:28:57 <skarnet> it's a one-time cost for every project I want to work on
2020-10-08 16:29:11 <ikke> gitlab has generally good API support, so it's quite easy to make tooling to do these things
2020-10-08 16:29:38 <skarnet> great, please make such tooling
2020-10-08 16:30:00 <skarnet> else it's not a replacement for the ML
2020-10-08 16:30:01 <ikke> https://pkgs.alpinelinux.org/package/edge/community/x86_64/lab
2020-10-08 16:31:04 <insep_> ikke: oh cool, this eхists
2020-10-08 16:31:19 <skarnet> looks good
2020-10-08 16:31:32 <insep_> kinda ironic that it's hosted on github
2020-10-08 16:33:16 <Ganwell> ~alpine/aports@lists.alpinelinux.org still exists, not?
2020-10-08 16:33:24 <maxice8> yes
2020-10-08 16:33:48 <skarnet> how many months nowadays between the moment a mail is sent and the moment it's processed? :P
2020-10-08 16:34:33 <maxice8> depends
2020-10-08 16:34:59 <skarnet> "for someone annoying like skarnet, it can take up to a year" :D
2020-10-08 16:35:09 <maxice8> Oh no
2020-10-08 16:35:30 <maxice8> it depends if you're ddevault or not
2020-10-08 16:35:44 <insep_> lol
2020-10-08 16:37:50 <Cogitri> The ML still exists, but IMHO we should get rid of it already, most devs don't work with it so I feel like it does more harm than good
2020-10-08 16:38:46 <PureTryOut[m]> insep: https://github.com/zaquestion/lab/issues/406
2020-10-08 16:39:20 <insep_> PureTryOut: nice
2020-10-08 16:40:36 <skarnet> just be aware that removing the ML bumps the initial burden for contributors from 1. git-send-email to 1. install lab 2. install mkmr 3. write scripts to streamline the process of forking a whole repo, cloning it, making your changes, upstreaming them, creating the MR, sending the MR 4. call the script
2020-10-08 16:41:01 <skarnet> I'm willing to do it but I'm making noise about it and I won't be the last one
2020-10-08 16:41:45 <ikke> skarnet: for others it has become easier.
2020-10-08 16:42:43 <skarnet> for maintainers*
2020-10-08 16:42:46 <Cogitri> And if it's super easy to send patches but then no one ends up reviewing those patches because it's a massive pain to do that on the ML then it's of no use
2020-10-08 16:43:19 <insep_> from a maintainer standpoint, gitlab is much easier to use for review and merging patches
2020-10-08 16:43:38 <skarnet> oh, I'm definitely not arguing with that
2020-10-08 16:43:39 <insep_> also https://gitlab.com/groups/gitlab-org/-/epics/260 is a thing, let's hope they'll work on it (lol)
2020-10-08 16:44:07 <skarnet> I'm just underlining that it raises the barrier of entry
2020-10-08 16:44:17 <skarnet> by what I think is a significant height
2020-10-08 16:44:30 <ikke> skarnet: fyi, mailing lists have a barrier of entry as well
2020-10-08 16:46:47 <mps> when I tested gitlab.a.o (when we preparing to move) I did all with cli, 'lab' and 'git' but nowadays I'm mostly 'web' user :)
2020-10-08 16:58:22 <Hello71> Ganwell: I thought you said ptrace
2020-10-08 16:59:15 <Hello71> skarnet: assuming users already know how to use git send-email
2020-10-08 17:00:16 <skarnet> what did I say a few days ago?
2020-10-08 17:00:43 <skarnet> if you assume that users are dumb, and design procedures around that assumption, your procedures will be *terrible*
2020-10-08 17:01:32 <ikke> It's not about the inteligence of users
2020-10-08 17:01:42 <ikke> but what they are experienced with
2020-10-08 17:02:15 <skarnet> soon you'll be telling me that Alpine cares more about developers who like web uis than developers who like the command line
2020-10-08 17:02:46 <skarnet> because it's exactly what this whole exchange sounds like
2020-10-08 17:03:06 <skarnet> and the only thing I can say is, I very much hope this is not it, because 5 years ago it wasn't like this
2020-10-08 17:04:24 <mps> 
ACTION contemplating for months is there a way to not use gitlab

2020-10-08 17:04:40 <ikke> We try to cater for a wide public. People who like CLI and people who prefer web
2020-10-08 17:05:25 <mps> ikke: yes, but this is hard job
2020-10-08 17:05:27 <ikke> If we just cared about the core contributers, we could do with a lot less
2020-10-08 17:06:07 <mps> I remember how hard you and clandmeter worked on gitlab to get it ready for us
2020-10-08 17:06:34 <ikke> But at least the CI part helps us a lot
2020-10-08 17:06:43 <ikke> drone ci was limited in arches
2020-10-08 17:06:53 <mps> yes, that is 'good part' of it :)
2020-10-08 17:07:30 <mps> CI saves us of a lot of headaches
2020-10-08 17:07:46 <skarnet> having CI is unarguably a good thing
2020-10-08 17:09:42 <mps> 
ACTION remember times when use 'git am $ML' sync on four lxcs, run abuild on all of them, check results and then 'git push origin'

2020-10-08 17:10:09 <mps> that is, for ML patches
2020-10-08 17:27:15 <skarnet> MR submitted. I didn't want to spend my evening scripting around lab and mkmr, so I used the UI. And seedless to nay, I hate you all. :P
2020-10-08 17:27:35 <ikke> heh :)
2020-10-08 17:27:43 <ikke> you're welcome :P
2020-10-08 17:28:16 <ikke> Talking about gitlab, going to restart it for a patch update, should be back up soon
2020-10-08 17:28:41 <mps> today I had unintentional merge by wrongly press wrong button
2020-10-08 17:29:09 <mps> and I feel scared of that
2020-10-08 17:29:18 <skarnet> ikke: you missed the opportunity to supremely annoy me by a few minutes! (by having gitlab down *right as* I was creating the MR). You need to work on your timing.
2020-10-08 17:29:19 <Ticho> sounds like a missing confirmation dialog :)\
2020-10-08 17:30:40 <ikke> skarnet: :)
2020-10-08 17:32:27 <ikke> gitlab is starting again
2020-10-08 17:33:07 <ikke> Done
2020-10-08 17:42:51 <insep_> don't mind if i review ^^
2020-10-08 17:43:20 <ikke> review what?
2020-10-08 17:45:15 <insep_> mr with utmps
2020-10-08 17:45:39 <ikke> ah
2020-10-08 18:03:25 <insep_> aaand done
2020-10-08 18:03:33 <insep_> i think i nitpicked too hard though :(
2020-10-08 19:10:38 <skarnet> insep_: thanks for the comments, I've changed to WIP because I've also noticed a thing I need to change. Will work on it tomorrow.
2020-10-08 23:27:53 <aparcar[m]> any apk developers here?
2020-10-08 23:28:01 <aparcar[m]> or is there a dedicated channel?
2020-10-08 23:29:54 <[[sroracle]]> #apk-tools but most of the discussion happens here
2020-10-08 23:30:09 <aparcar[m]> thanks
2020-10-08 23:30:24 <[[sroracle]]> fabled is the primary dev but i think he is missing currently
2020-10-08 23:30:59 <aparcar[m]> yea I hoped he would stick around here...
2020-10-08 23:31:48 <[[sroracle]]> what's up anyway
2020-10-08 23:32:15 <aparcar[m]> I'd replace the OpenWrt package manager with apk, at least in the long run
2020-10-08 23:32:50 <aparcar[m]> the current tool, opkg, is a fork of a fork and doesn't received much love lately
2020-10-08 23:33:35 <aparcar[m]> I'm mostly curious how much alpine (or apk devs) cares about support low resource hardware
2020-10-08 23:33:54 <aparcar[m]> as in, we have usually 8mbit of storage and some 64mbit of ram to work with
2020-10-08 23:40:06 <Hello71> openwrt hasn't supported <4MB flash or <32MB RAM for a long time
2020-10-08 23:41:02 <Hello71> i doubt stock openwrt kernel even fits in 8 MB RAM
2020-10-08 23:42:03 <Hello71> i don't think stock linux even supports xip
2020-10-08 23:57:45 <aparcar[m]> Hello71: ram = memroy, flash = storage. so you can easily install OpenWrt on a 8MB device, I didn't talk about 8Mb of memory
2020-10-09 00:01:06 <Hello71> 
ACTION bails

2020-10-09 00:03:50 <aparcar[m]> ¯\_(ツ)_/¯
2020-10-09 05:51:47 <craftyguy> Cogitri: thoughts on adding these plugins to Chatty's depends once MR !13441 is merged? OMEMO seems to work now (tested against Conversations and another session with Chatty). The problems I was having before weren't due to purple-lurch, but due to an old key being re-used for encryption on the other device talking to chatty
2020-10-09 05:53:49 <Ariadne> skarnet: don't we need to link utmps client lib against programs too?
2020-10-09 06:16:34 <ncopa> morning
2020-10-09 06:16:50 <ncopa> i think im gonna tag an abuild release candidate
2020-10-09 06:23:43 <ncopa> we really need to add more tests to abuild
2020-10-09 06:26:10 <ikke> +1
2020-10-09 07:27:56 <skarnet> Ariadne: yes of course. -I/usr/include/utmps and -lutmps -lskarnet (I recommend linking statically because the amount of code is really tiny, but iirc that's not Alpine policy)
2020-10-09 07:28:35 <Ariadne> I think for this case it is fine
2020-10-09 07:29:24 <Ariadne> it would be nice if utmps had a .pc file :)
2020-10-09 07:30:10 <skarnet> bleh
2020-10-09 07:30:12 <Ariadne> that would allow the utmps integration to be very easily upstreamed
2020-10-09 07:30:44 <skarnet> sorry, not going to depend on pkgconf upstream
2020-10-09 07:30:54 <Ariadne> no need to do so?
2020-10-09 07:31:17 <Ariadne> I meant for things like coreutils
2020-10-09 07:31:44 <Ariadne> they can just say "oh, utmps is installed, pull it in"
2020-10-09 07:31:48 <Ariadne> :)
2020-10-09 07:32:16 <skarnet> yeah but that requires utmps to craft a .pc file. Can probably do it manually in the APKBUILD.
2020-10-09 07:32:52 <skarnet> where's the standard location for that file?
2020-10-09 07:33:19 <Ariadne> /usr/lib/pkgconfig
2020-10-09 07:34:42 <skarnet> oh, it's handled by default_dev
2020-10-09 07:35:08 <skarnet> so if I just install a /usr/lib/pkgconfig/utmps.pc file in my package() then everything will work automagically?
2020-10-09 07:43:35 <Ariadne> yes
2020-10-09 08:45:19 <skarnet> insep_: I'm trying your "copy docs in package() so default_doc does the right thing and there's no need to declare a doc() function" thing
2020-10-09 08:45:49 <skarnet> and abuild fails with: ERROR: skalibs-doc*: Missing /home/ska/src/aports/main/skalibs/pkg/skalibs-doc
2020-10-09 08:46:00 <skarnet> wut?
2020-10-09 08:47:50 <mps_> look aports/main/skalibs
2020-10-09 08:48:27 <skarnet> yes, that's what I'm working on
2020-10-09 08:48:36 <mps_> hmm, strange
2020-10-09 08:48:49 <skarnet> no shit, Sherlock
2020-10-09 08:48:56 <mps_> :)
2020-10-09 08:50:24 <skarnet> anyway I have no time to spend debugging abuild, so I'll freeze that until someone can help me with this
2020-10-09 08:51:09 <ikke> skarnet: are you copying the files to a directory that the default_doc function looks for?
2020-10-09 08:51:26 <insep_> [skarnet](https://matrix.to/#/@freenode_skarnet:matrix.org): wut
2020-10-09 08:52:07 <insep_> send apkbuild
2020-10-09 08:52:08 <skarnet> ikke: in package() I'm copying the files to $pkgdir/usr/share/doc
2020-10-09 08:52:33 <ikke> yeah, can you share your APKBUILD?
2020-10-09 08:53:35 <skarnet> https://bpa.st/NQJA
2020-10-09 08:54:07 <mps_> abuild -r in skalib dir worked for me
2020-10-09 08:54:27 <skarnet> lines 29-30 are the relevant changes
2020-10-09 08:54:40 <skarnet> mps_: with the pasted APKBUILD ?
2020-10-09 08:55:00 <skarnet> the skalibs build succeeds, but the packaging of skalibs-doc fails
2020-10-09 08:55:28 <mps_> no
2020-10-09 08:55:50 <mps_> with one currently in aports
2020-10-09 08:56:34 <mps_> try without this line `       cp -a "$builddir/doc" "$pkgdir/usr/share/doc/$pkgname"`
2020-10-09 08:57:07 <mps_> abuild_doc() should find doc automatically
2020-10-09 08:57:45 <ikke> mps_: only when they are installed in $pkgdir
2020-10-09 08:57:54 <ikke> it has no idea where to look for them in the $builddir
2020-10-09 08:58:54 <skarnet> I've added a "sleep 120" after the cp -a line and checked manually in $pkgdir, everything is where it's supposed to be
2020-10-09 08:59:03 <skarnet> so why is default_doc() failing? o.O
2020-10-09 08:59:09 <ikke> I get a strange different issue with your APKBUILD
2020-10-09 08:59:20 <ikke> : not founduild: /home/build/aports/main/skalibs/APKBUILD: line 13:
2020-10-09 08:59:31 <skarnet> not founduild?
2020-10-09 08:59:34 <mps_> could you tpaste skalibs.pc
2020-10-09 09:00:01 <ikke> ah
2020-10-09 09:00:03 <ikke> crlf :-/
2020-10-09 09:00:04 <skarnet> ah yes, totally irrelevant
2020-10-09 09:00:11 <skarnet> just touch skalibs.pc
2020-10-09 09:00:27 <ikke> skarnet: the paste contains crlf
2020-10-09 09:00:34 <ikke> dos2unix fixed it
2020-10-09 09:00:49 <skarnet> yeah, sorry for the bad paste :/
2020-10-09 09:03:29 <skarnet> with the fixed APKBUILD, are you getting the same error as I am?
2020-10-09 09:03:37 <ikke> yes
2020-10-09 09:03:55 <ikke> after `abuild package`, it looks correct
2020-10-09 09:04:51 <ikke> but after abuild rootpkg, the docs are gone
2020-10-09 09:08:56 <mps_> it doesn't create pkg/skalibs-doc
2020-10-09 09:09:09 <ikke> default_doc should do that
2020-10-09 09:10:26 <mps_> yes
2020-10-09 09:10:30 <ikke> found it
2020-10-09 09:10:38 <ikke> skarnet: look at your dev() function
2020-10-09 09:11:07 <skarnet> gah
2020-10-09 09:11:14 <skarnet> yeah, that would explain it.
2020-10-09 09:11:22 <skarnet> thanks.
2020-10-09 09:12:00 <ikke> (for the rest, there is a rm -rf $pkgdir/usr there, which deletes the docs before they are split)
2020-10-09 09:12:53 <mps_> ikke: huh, nice catch. I didn't looked there :)
2020-10-09 09:13:29 <ikke> I added set -x to the default_doc function and noticed it did not find the $pkgdir/usr/share/doc directory
2020-10-09 09:13:45 <ikke> so it was already removed before the default_doc function was run
2020-10-09 09:15:04 <skarnet> yeah, it was a shortcut to remove the empty dirs
2020-10-09 09:15:22 <skarnet> but with the doc move, /usr is not so empty anymore >.>
2020-10-09 10:10:19 <skarnet> MC:[AL29]:APKBUILD:14:$pkgname should not be used in the source url
2020-10-09 10:10:29 <skarnet> huh? is there a good reason for that lint rule?
2020-10-09 10:12:16 <ikke> skarnet: to decouple the packagename from the upstream name
2020-10-09 10:13:26 <skarnet> sure, but when the package name and the upstream name happen to be the same, I don't see the problem in using $pkgname
2020-10-09 10:14:05 <afontain_> and then you fork the package and it breaks
2020-10-09 10:14:07 <skarnet> it seems like an arbitrary rule that doesn't help with anything
2020-10-09 10:14:34 <afontain_> well, it's kinda a little better that way, IMO
2020-10-09 10:14:36 <ikke> afontain_: yes, that's one of the reasons bheind it
2020-10-09 10:15:22 <skarnet> my reason for using $pkgname in URL is that it allowed me to write several APKBUILDs with less editing, since my upstream location always has the same pattern
2020-10-09 10:15:39 <skarnet> changing it incurs *more* work
2020-10-09 10:16:46 <mps_> (whatever you do someone will argue opposite, always)
2020-10-09 10:17:16 <skarnet> I don't care about what other people do, I just dislike lint complaining about what is generally seen as good practice
2020-10-09 10:17:23 <skarnet> i.e. using a variable instead of a magic constant
2020-10-09 10:17:42 <skarnet> let people use magic names if they want, and let me use a variable if I want
2020-10-09 10:17:48 <mps_> I agree with you but linter doesn't :)
2020-10-09 10:18:28 <afontain_> linter probably values consistency. that's a good thing
2020-10-09 10:18:39 <skarnet> what happened to "be liberal in what you accept"
2020-10-09 10:18:40 <mps_> I'm not sure
2020-10-09 10:18:51 <mps_> afontain_: ^
2020-10-09 10:20:55 <skarnet> anyway, MR updated, and the linter can go shove it
2020-10-09 10:21:53 <mps_> for now linter 'bugs' are ignored on builders, and that is 'good thing' :)
2020-10-09 10:22:06 <skarnet> yeah, they better
2020-10-09 10:22:28 <mps_> (there are no 'good things' in the world, only bad, worse ....)
2020-10-09 10:24:28 <ikke> Ignored, meaning just warnings, and there is no intention to change that
2020-10-09 10:25:35 <skarnet> good :)
2020-10-09 10:25:52 <ikke> But what afontain_ mentioned is correct, we decided it was nice to have consistency in APKBUILDs. Having different maintainers with different rules was really confusing for outsiders trying to contribute. It's better to be able to give a single style guide.
2020-10-09 10:30:17 <ikke> A lot of discussion about style disappears when you have a documented style and linting that tells contributors when they deviate from that style.
2020-10-09 10:50:30 <Ganwell> It is the second time I built a linux-lts from edge to test it (test if a bug goes away) on my 3.12 machine and I got no modesetting and therefore no GUI. That used to work in the past. Do I have to build linux-firmware too, or some other packages?
2020-10-09 10:56:37 <mps_> Ganwell: which bug
2020-10-09 10:59:27 <Ganwell> mps_: In this case something in drm. laggy rendering in the browser. It is not a alpine bug, just some normaler kernel-hickup, these things that usually go a way on the next kernel release.
2020-10-09 11:01:03 <mps_> Ganwell: you can try with linux-edge from testing
2020-10-09 11:01:14 <mps_> and see if there are diffs
2020-10-09 11:04:13 <Ganwell> mps_: yes. will it work if I just build linux-edge and install it? Or do I have to build other packages too, like linux-firmware? It bothers me that I can't update a linux-lts anymore. That used to work for the last 8 years.
2020-10-09 11:05:06 <mps_> Ganwell: you don't need even to build it, if your arch is x86_64, just install it
2020-10-09 11:05:53 <mps_> and you don't need newer firmware version but you can install if you like
2020-10-09 11:06:54 <mps_> Ganwell: and when you install linux-edge linux-lts will *not* be removed
2020-10-09 11:06:57 <Ganwell> ah you mean directly from edge. I try that, thanks a lot!
2020-10-09 11:07:12 <mps_> you can keep boot and boot one you like
2020-10-09 11:07:19 <ikke> yeah, the kernel has no dependencies, so you can safely install it from edge
2020-10-09 11:58:34 <mps_> ncopa: why linux-firmware is built from git and not from tarball snapshot
2020-10-09 12:01:43 <ikke> last time I checked (Someone asked about it), it _was_ from a snapshot
2020-10-09 12:02:18 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/linux-firmware/APKBUILD#L20
2020-10-09 12:03:19 <mps_> ikke: yes, snapshot() 'git fetch' it and make tarball and then upload to dev.a.o which is in source
2020-10-09 12:03:32 <ikke> ah, like that
2020-10-09 12:05:07 <mps_> I'm just trying to build from upstream tarball directly, skipping snapshot()
2020-10-09 12:05:24 <mps_> and looks like it works
2020-10-09 12:05:48 <ikke> So something like this: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/snapshot/linux-firmware-20200918.tar.gz
2020-10-09 12:06:02 <mps_> yes
2020-10-09 12:06:46 <ikke> Seems like these snapshot are quite recent
2020-10-09 12:06:46 <mps_> https://tpaste.us/prQ4
2020-10-09 12:06:55 <ikke> So I guess this came from a time they did not exist yet
2020-10-09 12:07:02 <mps_> APKBUILD diff
2020-10-09 12:07:08 <ikke> Oldest is from march last year
2020-10-09 12:07:29 <mps_> no, look https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
2020-10-09 12:07:44 <ikke> looking here: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/refs/
2020-10-09 12:07:48 <mps_> it is nearly monthly releases
2020-10-09 12:08:00 <mps_> tags
2020-10-09 12:08:07 <ikke> Yes, but the oldest tag is from march 2019
2020-10-09 12:08:14 <ikke> so before that, there were no tags afaict
2020-10-09 12:08:19 <mps_> ah, yes
2020-10-09 12:08:40 <mps_> I understood you wrongly, sorry
2020-10-09 12:08:42 <ikke> so no one adjusted it to make use of these snapshots yet
2020-10-09 12:08:52 <ikke> I misunderstood you first as well :)
2020-10-09 12:08:53 <mps_> I'm starting :)
2020-10-09 12:09:23 <mps_> but want to hear BDFL, do he agree to change this
2020-10-09 12:10:53 <ikke> I guess open an MR? :P
2020-10-09 12:12:15 <mps_> I think he is busy and usually don't look much there
2020-10-09 12:12:56 <mps_> I already had few assigned and wait till I tell here
2020-10-09 12:13:13 <mps_> but sure, I'm preparing MR
2020-10-09 12:13:37 <mps_> uh, my nick is incorrect :|
2020-10-09 12:13:56 <mps> and now it is not
2020-10-09 12:33:01 <Eighth_Doctor> huh, I'm surprised that an apk backend is being added to gnome-software and not packagekit
2020-10-09 12:33:03 <Eighth_Doctor> that seems like a weird choice :/
2020-10-09 12:33:14 <Cogitri> Packagekit is dead
2020-10-09 12:33:21 <insep_> isn't packagekit dead?
2020-10-09 12:33:24 <Eighth_Doctor> no?
2020-10-09 12:33:30 <Cogitri> https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/
2020-10-09 12:33:35 <insep_> https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/
2020-10-09 12:33:37 <ikke> lol
2020-10-09 12:33:43 <Cogitri> Heh
2020-10-09 12:33:51 <Eighth_Doctor> https://github.com/hughsie/PackageKit/commits/master
2020-10-09 12:34:03 <Eighth_Doctor> not very dead for a "dead project"
2020-10-09 12:34:44 <ikke> Maybe read that post
2020-10-09 12:34:46 <insep_> Cogitri: you cannot beat my ctrl+v.
2020-10-09 12:34:58 <ikke> "Of course, I’ve still been merging PRs and have been slinging tarballs over the wall every few months, but nothing new was happening with the project, and I’ve worked on many other things since."
2020-10-09 12:35:18 <Eighth_Doctor> I've read the blog post, yes
2020-10-09 12:35:49 <ikke> It's in maintenance mode, not really gaining new features
2020-10-09 12:36:48 <Cogitri> Individual plugins for both GNOME Software and KDE Discover are the way to go forward
2020-10-09 12:37:07 <Cogitri> For tighter integration and better functionality
2020-10-09 12:38:01 <Eighth_Doctor> yeah, that's going to be an awesome shitshow
2020-10-09 12:38:51 <Eighth_Doctor> neither Discover nor Software agree on interfaces for anything, so app developers are basically screwed if they need to request things like codecs and stuff
2020-10-09 12:39:24 <Eighth_Doctor> ikke: and what "new features" do you want?
2020-10-09 12:39:49 <Eighth_Doctor> aside from Richard, there are ~5 other committers to the codebase, all are able to review PRs and some are even writing code themselves
2020-10-09 12:40:16 <ikke> Eighth_Doctor: Me, none
2020-10-09 12:40:47 <insep_> <Eighth_Doctor "neither Discover nor Software ag"> put codecs in app dependencies?
2020-10-09 12:41:15 <insep_> either way, they are already screwed because every distro loves to name stuff differently
2020-10-09 12:41:33 <Eighth_Doctor> that doesn't matter if you're doing gstreamer codec request
2020-10-09 12:41:46 <Eighth_Doctor> or something like that, because there are already ways to discover and handle that
2020-10-09 12:41:52 <Eighth_Doctor> those are handled by the PackageKit backends
2020-10-09 12:44:44 <Cogitri> You can open by appid in GNOME Software too, so implementing it via GNOME Software and Discover's DBus API doesn't seem too much of a problem
2020-10-09 12:45:53 <mps> ikke: !13456
2020-10-09 12:46:07 <mps> if you have any comment
2020-10-09 12:46:32 <mps> except about linter :)
2020-10-09 12:47:10 <ikke> mps: The linter does the commenting for me :P
2020-10-09 12:47:43 <mps> https://gitlab.alpinelinux.org/mps/aports/-/jobs/225149#L80
2020-10-09 12:47:54 <mps> 502 http error
2020-10-09 12:48:46 <mps> restart this one CI?
2020-10-09 12:49:40 <Eighth_Doctor> Cogitri: GNOME Software is also in a position of possibly being retired or replaced
2020-10-09 12:49:41 <ikke> seems like an issue with kernel.org
2020-10-09 12:50:01 <Eighth_Doctor> because GNOME folks and developers are unhappy with it
2020-10-09 12:50:07 <Eighth_Doctor> so yay? :(
2020-10-09 12:50:31 <mps> ikke: on other CIs it works
2020-10-09 12:50:54 <ikke> maybe depending on the location?
2020-10-09 12:51:05 <Eighth_Doctor> Cogitri: https://gitlab.gnome.org/GNOME/gnome-software/-/issues?label_name%5B%5D=2.+RFC
2020-10-09 12:51:21 <ikke> mps: trying it on that host, and its just hanging
2020-10-09 12:51:44 <ikke> It does the HTTP request, but the response is not comming
2020-10-09 12:51:54 <mps> yes
2020-10-09 12:52:02 <mps> but on other it works
2020-10-09 12:52:13 <mps> and on 'my' lxc
2020-10-09 12:52:20 <ikke> Yes, can still be location dependendt
2020-10-09 12:52:23 <ikke> dependent
2020-10-09 12:52:23 <mps> x86_64 lxc, I mean
2020-10-09 12:52:43 <Eighth_Doctor> anyway, y'all do what you want for apk support in GUI tools, I just think it's probably a bad idea
2020-10-09 12:52:52 <Eighth_Doctor> to do it in GNOME Software
2020-10-09 12:53:19 <ikke> mps: https://tpaste.us/W7aN
2020-10-09 12:54:20 <mps> I see, and can't do anything about that
2020-10-09 12:54:25 <ikke> me neither
2020-10-09 12:54:50 <Cogitri> Eighth_Doctor: at this point we already have the plugin and everything in place
2020-10-09 12:54:56 <mps> will try to restart it on x86_64 CI few hours latter
2020-10-09 12:55:03 <Eighth_Doctor> 
ACTION shrugs

2020-10-09 12:55:16 <Cogitri> And I don't feel like poking in dead software and working with GNOME Software was a pretty decent experience
2020-10-09 14:46:45 <the6543> anybody time to look at !13170
2020-10-09 14:46:55 <the6543> it's hanging around for a while
2020-10-09 14:50:11 <skarnet> ah, so that's how it works :D
2020-10-09 14:50:27 <skarnet> Ariadne: whenever you have time, !13421
2020-10-09 15:03:24 <mps> my MRs hangs sometimes long time, although I can merge them ;)
2020-10-09 15:31:24 <the6543> you are lucky :D
2020-10-09 15:31:29 <the6543> do you?
2020-10-09 15:43:30 <mps> the6543: well, I'm not in hurry
2020-10-09 15:44:36 <mps> and I like if more people look at MRs if I made some errors or mistakes, oversight something etc
2020-10-09 15:45:45 <the6543> yes, they happen just to easely
2020-10-09 15:48:39 <mps> insep_: (to not join pmOS, just to inform you) I found some time today to make alpine kernel for n900, now it boots fine and works
2020-10-09 15:48:58 <mps> finally have alpine on nokia n900
2020-10-09 15:49:41 <the6543> nice!
2020-10-09 15:50:14 <mps> hope I will find time later to test if iwd can work on it
2020-10-09 15:50:43 <the6543> do you still be able to call or conect to mobile network?
2020-10-09 15:50:58 <the6543> what is 'iwd' ?
2020-10-09 15:51:18 <mps> apk info iwd
2020-10-09 15:52:10 <the6543> :) now i understand ...
2020-10-09 15:52:25 <mps> iwd have FILS (Fast Internet Link Setup), about 200 mS
2020-10-09 15:53:06 <mps> and integrated dhcp client
2020-10-09 15:53:47 <insep_> cool
2020-10-09 15:53:55 <insep_> does iwd work?
2020-10-09 15:54:36 <mps> didn't tried yet, don't have much free time these days
2020-10-09 15:56:30 <insep_> the6543: ofono should support all of these, but calls will require separate lib and they'll suck
2020-10-09 15:56:36 <insep_> and
2020-10-09 15:56:41 <insep_> > talking to people
2020-10-09 16:02:48 <insep_> mps: oh, now i have full rights to call iwd bloated
2020-10-09 16:10:27 <mps> insep_: sure, anything not written in forth is bloated :)
2020-10-09 16:11:07 <insep_> anything not written in v /s
2020-10-09 17:04:31 <Cogitri> craftyguy: If Chatty works fine with those plugins then let's add them
2020-10-09 18:37:59 <craftyguy> Cogitri: sounds good. I'll make the MR then
2020-10-10 09:12:56 <ikke> mps: linux-firmware now passed on x86_64 as well
2020-10-10 09:28:21 <mps> ikke: good, so network problem is self healed
2020-10-10 09:28:33 <ikke> or some sysadmin fixed the underlying issue :)
2020-10-10 09:28:43 <mps> hehe
2020-10-10 09:29:15 <mps> last night I restarted it but it didn't pass
2020-10-10 09:29:23 <ikke> ok
2020-10-10 09:29:42 <mps> anyway, I would left it for ncopa to look and comment and merge
2020-10-10 09:30:29 <ikke> changes look good to me
2020-10-10 09:30:47 <mps> also to me ;)
2020-10-10 09:32:13 <mps> I have a question, someone yesterday asked on #alpine-linux will we enable NTS (NTP SSL) in chrony
2020-10-10 09:32:32 <ikke> Yes, I saw that question
2020-10-10 09:32:53 <mps> what is your opinion
2020-10-10 09:33:03 <ikke> Is there any drawback to enabling it?
2020-10-10 09:33:28 <mps> yes, gnutls and nettle libs in basic install
2020-10-10 09:33:39 <ikke> aha
2020-10-10 09:34:19 <mps> if it is openssl I think we can enable it, but not sure because of extra libs
2020-10-10 09:35:44 <mps> maybe we can raise this question on workdays here when more of us are here
2020-10-10 09:36:11 <ikke> Would we remove chrony if it would've depended on gnutls/nettle by default?
2020-10-10 09:36:45 <ikke> (remove from base install)
2020-10-10 09:37:13 <mps> hmmm, maybe and use BB ntp client
2020-10-10 09:38:29 <mps> or ask chrony upstream if openssl build option can be added
2020-10-10 09:39:11 <ikke> right
2020-10-10 11:23:49 <mps> do we have netboot.alpinelinux.org or similar?
2020-10-10 11:24:25 <ikke> http://boot.alpinelinux.org/
2020-10-10 11:24:57 <mps> yes, just found by engaging memory :) but thank you ikke
2020-10-10 11:31:33 <telmich> Where do I find the script/repo that builds the install media / the initramfs?
2020-10-10 11:31:44 <ikke> alpine/aports/scripts
2020-10-10 11:31:54 <telmich> ikke: thanks!
2020-10-10 11:36:12 <telmich> I'm trying to understand how the profiles relate/things build on top of each other - is there any docs on how a new release is being created?
2020-10-10 11:37:20 <telmich> Motivation: I'd like to patch the images / scripts upstream to install `ndisc6` by default and to start `rdnssd` if networking is requested. This change will allow alpine to be installed in IPv6 only environments
2020-10-10 11:39:38 <ikke> telmich: mkimg.standard.sh -> mkimg.base.sh -> mkimage.sh
2020-10-10 11:40:34 <ikke> You run mkimage.sh with --profile
2020-10-10 11:41:51 <telmich> Hmm
2020-10-10 11:42:15 <ikke> I'm not aware of any documentation, I mostly try to read the scripts to see what is done
2020-10-10 11:42:25 <telmich> `./mkimage.sh --profile standard` fails with `ERROR: unable to select packages:` ... `alpine-base (no such package):`
2020-10-10 11:42:44 <telmich> Just updating my tree, in case I'm outdated
2020-10-10 11:43:02 <telmich> Same error on `v20200917-2101-g7ad3efa885`
2020-10-10 11:44:15 <ikke> Does it give this? http://boot.alpinelinux.org/
2020-10-10 11:44:18 <ikke> oops
2020-10-10 11:44:20 <ikke> this
2020-10-10 11:44:22 <ikke> warning "no repository set"
2020-10-10 11:46:34 <telmich> No. I've uploaded the output to https://www.nico.schottelius.org/temp/alpine-mkimage-20201010
2020-10-10 11:47:24 <telmich> Argh, yes it did
2020-10-10 11:47:35 <telmich> But the colour is very bright on my lightyellow2 terminal
2020-10-10 11:47:35 <ikke> so you need to specify --repository
2020-10-10 11:48:37 <telmich> Ok, that seems to run
2020-10-10 11:49:38 <telmich> What is the policy for migrating a package like ndisc6 from community to main?
2020-10-10 11:56:52 <ikke> main is maintained for 2 years, so we expect packages that go into main to be maintained for that long as well, meaning receiving security fixes on older releases
2020-10-10 11:57:06 <ikke> And dependencies play a role a s well
2020-10-10 11:57:09 <ikke> as well
2020-10-10 11:57:29 <ikke> there is no formal process, you could just open an MR that moves it to main
2020-10-10 11:57:37 <mps> and the pkg is really needed in main :P
2020-10-10 11:57:46 <ikke> mps: for a base install
2020-10-10 11:58:02 <ikke> supporting installing alpine on ipv6 only
2020-10-10 11:58:50 <mps> I didn't tried ipv6 install for some time, but we should consider other options if they exist
2020-10-10 12:00:07 <ikke> telmich: I wonder why somehting like ndisc6 is required?
2020-10-10 12:01:17 <ikke> telmich: doesn't linux support neighbor discovery oob?
2020-10-10 12:01:24 <ikke> ootb*
2020-10-10 12:01:51 <telmich> So without rdnssd, you do not have DNS entries in IPv6 only networks
2020-10-10 12:01:59 <telmich> IP address configuration is supported in the kernel
2020-10-10 12:02:09 <ikke> yes, I understand rdnssd
2020-10-10 12:02:23 <ikke> Or is it part of the same package?
2020-10-10 12:02:29 <telmich> rdnssd is part of ndisc6
2020-10-10 12:02:32 <ikke> ok
2020-10-10 12:02:47 <telmich> And I believe ncopa addded the init script for it some time ago
2020-10-10 12:03:14 <ikke> Heh, I happen to even maintain ndisc6 :P
2020-10-10 12:03:25 <telmich> Ah, or it was you :-)
2020-10-10 12:03:38 <mps> 'apk info ndisc6' => ndisc6 gathers a few diagnostic tools for IPv6 networks including
2020-10-10 12:03:48 <telmich> Yep, that is a bit misleading
2020-10-10 12:03:59 <mps> strange pkg description :)
2020-10-10 12:04:45 <telmich> I think other distros have rdnssd in a separate package - but I do not have a strong opinion how it is packaged, but would really appreciate if we could install in IPv6 only environments
2020-10-10 12:05:03 <ikke> 95ff6546c9b01ed9857a2e1aa701d32e5add2664
2020-10-10 12:05:22 <ikke> telmich: If it make sense, we can make separate subpackages
2020-10-10 12:05:28 <mps> what is rdnssd for
2020-10-10 12:05:39 <ikke> mps: getting dns information in an SLAAC only environment
2020-10-10 12:05:53 <mps> aha, thanks
2020-10-10 12:06:49 <telmich> Ahhh, Ahmed did that!
2020-10-10 12:07:56 <ikke> last commit was one year ago
2020-10-10 12:08:21 <ikke> Though, for tools like this, it's not strange to not receive a lot of changes
2020-10-10 12:10:56 <mps> stable and secure
2020-10-10 12:11:20 <mps> ? ofc
2020-10-10 12:12:11 <ikke> hmm, apparently maintained by the developer(s) of vlc
2020-10-10 12:12:13 <ikke> https://www.remlab.net/
2020-10-10 12:12:24 <ikke> "With over fifteen years experience in the development of the renowed open-source VLC media player"
2020-10-10 12:12:43 <telmich> Haa...also doing miredo
2020-10-10 12:12:51 <telmich> So they must have been into IPv6 since the early days
2020-10-10 12:13:16 <ikke> Which I guess makes sense then that they built ndisc6
2020-10-10 12:13:22 <ikke> if linux didn't support it yet
2020-10-10 12:13:35 <ikke> or maybe because of some other reason
2020-10-10 12:14:21 <telmich> Not sure what you mean by "didn't support yet" - afaics the tools are not replacing, but aiding to debug IPv6 connectivity
2020-10-10 12:15:14 <mps> https://code.woboq.org/linux/linux/net/ipv6/ndisc.c.html
2020-10-10 12:23:32 <telmich> So I think we do not need ndisc6 and friends installed - if we want to keep it small, we should probably create a sub/rdnssd package
2020-10-10 12:25:28 <ikke> But it probably also means we need a rdnssd-openrc package I guess
2020-10-10 12:26:36 <telmich> That's already in the ndisc6 package
2020-10-10 12:26:59 <ikke> yes, but if you want to split that, the openrc package would also need to be split
2020-10-10 12:27:49 <ikke> hmm, there is only an rdnssd init, ok
2020-10-10 12:27:56 <telmich> Right, sorry, I thought it was already named rdnssd-openrc, but it is ndisc6-openrc at the moment
2020-10-10 12:28:02 <ikke> yes
2020-10-10 12:28:15 <telmich> It should probably be renamed rdnssd-openrc in any case
2020-10-10 12:28:30 <ikke> ok
2020-10-10 12:28:45 <ikke> But is there a logical reason rndssd should be split, while the other tools not?
2020-10-10 12:31:39 <telmich> Yes, only rdnssd is needed in general from the whole package. The other tools are "nice to have for debugging" but in practice almost never used. Besides maybe traceroute6, which might also come from other packages nowadays
2020-10-10 12:32:40 <telmich> Or in other words: looking at almost every other distro I know: there is an rdnssd package. Until Alpine, I did not even know that here is an "ndisc6 package"
2020-10-10 12:36:43 <ikke> iputils has traceroute6
2020-10-10 12:38:28 <telmich> Ok. So from my side, we could even rename ndisc6 to rdnssd and only install rdnssd. And/or cp the ndisc6 package as a base and create a downstripped rdnssd package version
2020-10-10 12:39:07 <ikke> ndisc6-utils or something like that
2020-10-10 12:41:37 <telmich> That sounds about right
2020-10-10 12:41:40 <ikke> rename the package to rdnss, move the other utils to a -utils subpackage
2020-10-10 12:47:25 <telmich> So rdnss goes into main and the others stay in community?
2020-10-10 12:47:54 <ikke> They all go together
2020-10-10 12:48:14 <ikke> It's still a single APKBUILD
2020-10-10 12:48:30 <ikke> That way, you don't have to separately update the utils from rdnssd
2020-10-10 12:49:16 <ikke> the ndisc6 dependencies are quite limited, so that's not reason to not move it to main
2020-10-10 12:49:59 <telmich> True
2020-10-10 12:52:03 <ikke> It might be easier to just leave the ndisc6 main package, and move rdnssd to a subpackage
2020-10-10 13:59:07 <ikke> telmich: this change does mean that anything that had ndisc6 installed to get rndss6, will now have to be updated to install rndssd instead
2020-10-10 14:00:32 <ikke> telmich: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/13513
2020-10-10 14:24:29 <telmich> <ikke "nico: https://gitlab.alpinelinux"> It looks good to me - plus probably the typical pkgrel changes.
2020-10-10 14:26:53 <ikke> telmich: nod, good that you remind me
2020-10-10 14:27:25 <ikke> done
2020-10-10 14:44:22 <telmich> The only change missing from my side is the move to main so that it can be included in the default images
2020-10-10 14:49:19 <BitL0G1c> Hi, where should I request being added to gitlab as a maintainer so I can make Merge Requests ? (at the moment MR emails are rejected)
2020-10-10 14:52:59 <Cogitri> You have to send MRs/email patches to your fork
2020-10-10 14:53:07 <Cogitri> And not to alpine/aports
2020-10-10 14:53:16 <Cogitri> Only core developers are maintainers
2020-10-10 14:53:27 <BitL0G1c> ok
2020-10-10 14:53:46 <ikke> telmich: yes, I wanted to separate those changes
2020-10-10 14:53:58 <ikke> first get the package proper, then a separate MR to move to main
2020-10-10 14:56:40 <telmich> ack
2020-10-10 15:13:43 <BitL0G1c> thx Cogitri - MR made
2020-10-10 15:15:47 <Cogitri> 👍
2020-10-10 16:17:14 <telmich> rdnssd-1.0.4-r3 x86_64 {ndisc6} (GPL-2.0-or-later) [installed] -- lgtm
2020-10-10 16:17:32 <ikke> :)
2020-10-10 16:17:58 <ikke> For the move to mean, I'd like to get some feedback from the other devs as well
2020-10-10 16:18:02 <ikke> s/mean/main/
2020-10-10 16:18:02 <alpine-meetbot> ikke meant to say: For the move to main, I'd like to get some feedback from the other devs as well
2020-10-10 17:17:36 <mps> insep_: got iwd working in nokia n900
2020-10-10 17:17:40 <mps> \o/
2020-10-10 17:31:57 <insep_> aaaaaaaaaaaa why ping sound is so louuuuuuuuuuuuuuuud
2020-10-10 17:31:58 <insep_> mps: wait how
2020-10-10 17:31:58 <insep_> oh, i had volume lowered in game and haven't noticed it хD
2020-10-10 17:33:42 <mps> heh
2020-10-10 17:34:37 <mps> had to upgrade to kernel 5.8.14 and it works nice
2020-10-10 17:35:05 <insep_> oh
2020-10-10 17:35:42 <insep_> did they add support for nl80211 in that kernel?
2020-10-10 17:35:49 <insep_> actually, not sure when we last updated kernel for n900
2020-10-10 17:35:51 <mps> personally I think it is faster than wpa_s
2020-10-10 17:36:36 <mps> no, nl80211 was in 5.7 but iwd freeze with this kernel
2020-10-10 17:37:21 <insep_> mps: yeah but we also care about all those devices that will never see kernel support for iwd
2020-10-10 17:38:10 <mps> sure, I understand
2020-10-10 17:38:35 <insep_> oh wow we have kernel 5.8
2020-10-10 17:38:45 <mps> and pmOS helped me a lot to make alpine working on n900
2020-10-10 17:39:10 <ikke> :)
2020-10-10 17:39:29 <mps> insep_: and you especially ofc :)
2020-10-10 17:43:36 <insep_> *5.7
2020-10-10 17:43:37 <MartijnBraam> don't we use the kernel from alpine for it?
2020-10-10 17:43:37 <insep_> for n900, that is
2020-10-10 17:43:37 <insep_> MartijnBraam: wanna try upgrading n900 kernel? it might fiх some of our issues with wifi
2020-10-10 17:43:37 <insep_> too bad i don't have n900
2020-10-10 17:43:37 <insep_> somehow making iwd and wpa-supplicant device-specific would be cool though
2020-10-10 17:46:51 <insep_> MartijnBraam: nope
2020-10-10 17:46:51 <insep_> https://gitlab.com/postmarketOS/pmaports/-/tree/master/device/community/linux-nokia-n900
2020-10-10 17:46:52 <insep_> but it's possible
2020-10-10 17:46:52 <insep_> 2 patches are from leste and 1 some from drebrez
2020-10-10 17:48:19 <mps> MartijnBraam: no, you have separate kernel for n900
2020-10-10 17:48:51 <MartijnBraam> hmm I think it was running directly on the alpine kernel once
2020-10-10 17:49:08 <insep_> never
2020-10-10 17:49:17 <insep_> probably
2020-10-10 17:49:19 <mps> not sure, we don't all omap options enabled
2020-10-10 17:49:34 <insep_> remember linuх-postmarketos-stable?
2020-10-10 17:49:39 <insep_> this is what it ran before
2020-10-10 17:49:41 <mps> s/don't/don't have/
2020-10-10 17:49:42 <alpine-meetbot> mps meant to say: not sure, we don't have all omap options enabled
2020-10-10 18:41:50 <Ariadne> [03:33] <3f51b5mps> yes, gnutls and nettle libs in basic install
2020-10-10 18:42:05 <Ariadne> I would prefer to avoid gnutls in base install
2020-10-10 18:42:13 <Ariadne> not due to bloat but due to security record
2020-10-10 18:43:44 <ikke> Yeah, makes sense
2020-10-10 18:50:10 <Hello71> it's not like just having it installed creates security holes though
2020-10-10 19:01:22 <Hello71> and chrony can't be combined with openssl due to missing openssl linking exception
2020-10-10 20:08:51 <MartijnBraam> mps: I got the pinebook pro booting on Linux 5.9 with only a single patch and kconfig changes, the patch is from linux-next
2020-10-10 20:14:31 <MartijnBraam> with that I think it's basically everything that's needed to support alpine edge on the pinebook pro, except that you'd need to flash the bootloader first from another OS to the SPI flash
2020-10-10 20:18:20 <mps> MartijnBraam: good to hear
2020-10-10 20:23:48 <mps> other OS is needed because we don't have bootable image for it?
2020-10-10 20:25:41 <mps> PBP can't boot from sd/mmc card
2020-10-10 20:25:42 <mps> ?
2020-10-10 20:28:39 <MartijnBraam> PBP can boot from sd/emmc, but you'll need an uboot that's quite nasty to build
2020-10-10 20:31:39 <mps> yes, I will try when someone give me one :)
2020-10-10 21:50:58 <Ariadne> MartijnBraam: what about 3D accel
2020-10-10 21:51:37 <MartijnBraam> panfrost seems to be working great
2020-10-10 21:51:47 <MartijnBraam> I'm currently running gnome shell on it
2020-10-10 21:55:02 <mps> MartijnBraam: X or wayland?
2020-10-10 21:55:19 <MartijnBraam> wayland
2020-10-10 21:55:56 <mps> I tried with X and panfrost is unusable in it
2020-10-10 21:56:07 <mps> it works but very slow
2020-10-10 21:56:42 <MartijnBraam> yeah I think there was some issue with panfrost and X, wayland environments have been better on it for a while
2020-10-10 21:57:40 <mps> yes, I chatted with upstream and they are not much interested to make it 'great' on X
2020-10-10 22:02:51 <MartijnBraam> X seems to cause quite some issues on arm gpus, it's also a bit problematic on lima.
2020-10-10 22:16:12 <Ariadne> X uses a lot of assumptions that only hold true on x86
2020-10-10 22:16:47 <Ariadne> (those assumptions are irrelevant to X the protocol, just x.org)
2020-10-10 22:18:06 <Ariadne> X pretty has accelerated memory access on x86, but slow path is really bad on non-x86
2020-10-10 22:18:16 <Ariadne> GLAMOR also has alignment issues
2020-10-10 22:18:56 <MartijnBraam> yeah I think there's also something with tiled rendering, but no clue what it means :P
2020-10-10 22:19:07 <Ariadne> that's the GLAMOR alignment bug
2020-10-10 22:19:15 <MartijnBraam> xorg is faster for some  2D things though
2020-10-10 22:19:25 <Ariadne> the texture renders off by N for each scanline
2020-10-10 22:19:47 <Ariadne> i work around it by forcing small textures into GTT memory instead of VRAM
2020-10-10 22:20:06 <Ariadne> but a sufficiently large texture will still glitch
2020-10-10 22:20:47 <Ariadne> X cannot be faster for some 2D things, as all 2D things use GLAMOR
2020-10-10 22:21:10 <Ariadne> (that workaround is specific to radeon, i have no idea if panfrost even has anything like GTT memory)
2020-10-10 22:21:40 <MartijnBraam> well just scrolling in GTK3 apps is faster on an xorg session than a wayland session on the pinephone
2020-10-10 22:21:56 <Ariadne> is GTK3 using wayland natively?
2020-10-10 22:22:06 <MartijnBraam> yes
2020-10-10 22:22:17 <Ariadne> most likely it is due to GTK3 using software compositing
2020-10-10 22:22:22 <MartijnBraam> actually, on manjaro scrolling is also smooth on wayland
2020-10-10 22:22:23 <Ariadne> on X, it would use GLAMOR (and thus GL)
2020-10-10 22:22:53 <Ariadne> i think there is a way to make GTK3 composite using GL
2020-10-10 22:22:58 <Ariadne> which is probably what manjaro is doing
2020-10-10 22:23:19 <Ariadne> but i switched to Qt years ago and haven't looked back
2020-10-10 22:23:38 <Ariadne> (Qt also use GL to composite, so performance on X and Wayland are basically identical)
2020-10-10 22:24:15 <Ariadne> mps: i would like to pick your thoughts on ifupdown-ng + wpa-supplicant integration
2020-10-10 22:24:46 <Ariadne> mps: namely, do you think wpa-supplicant itself should be managed by ifupdown-ng or by openrc
2020-10-10 22:50:26 <skarnet> if it's network, it should be managed by the network manager
2020-10-10 22:50:43 <skarnet> the service manager doesn't know about wpa
2020-10-11 00:00:46 <Hello71> Ariadne: don't traditional ddxs still exist
2020-10-11 00:00:52 <Hello71> or are they x86 only too
2020-10-11 05:31:38 <Ariadne> Hello71: some do, but they mostly target GPUs you would not find in use on a modern machine (even counting the AST2k IPMI chipset on servers)
2020-10-11 05:32:09 <Ariadne> Hello71: and for the most part, GLAMOR + xf86-video-modesetting with software rendering is still faster than those DDXs
2020-10-11 06:00:32 <mps> Ariadne: what is idea about managing wpa_s with ifupdown-ng? start/stop it when interface goes up/down?
2020-10-11 06:01:48 <mps> (and we should consider rename it to wsup, a lot easier to type ;) )
2020-10-11 06:02:41 <mps> skarnet: are you kidding about network-manager
2020-10-11 06:23:31 <insep_> MartijnBraam: manjaro also uses mesa-git
2020-10-11 06:23:40 <insep_> which has gl3.0
2020-10-11 09:46:51 <MartijnBraam> insep: ehm the gpu doesn't support gl3
2020-10-11 09:47:21 <insep_> welp
2020-10-11 09:47:43 <insep_> qemu needs it
2020-10-11 09:47:45 <insep_> https://gitlab.com/postmarketOS/pmbootstrap/-/issues/1938#note_422386288
2020-10-11 10:02:08 <skarnet> mps: I'm not kidding at all, no, but "the network manager" does not mean what you think it means.
2020-10-11 16:05:46 <mps> 
ACTION thinks that network should be managed by scripts

2020-10-11 16:14:45 <ikke> mps: good luck when you're regularly roaming between different networks :)
2020-10-11 16:18:19 <markand> looks like mkinitfs does not get many attention regarding to pending merge requests
2020-10-11 16:19:45 <mps> ikke: easier with scripts than with NM, at least for me
2020-10-11 16:29:17 <ikke> I uses Archlinux netctl / netctl auto, works great for me
2020-10-11 16:49:09 <u0jQx9gPyrYg> ikke: i do roam between different networks, and my magic is one-liners in my shell history and ^r to switch to them - works perfectly
2020-10-11 16:59:27 <ikke> u0jQx9gPyrYg: I don't need to do anything ;-)
2020-10-11 18:23:54 <Hello71> ikke: ironically netctl is less and less supported/used. it was recently removed from archiso, to the confusion of users used to typing wifi-menu
2020-10-11 18:26:01 <ikke> yeah, wasn't even aware of that
2020-10-11 18:57:45 <Ariadne> skarnet means ifupdown-ng there fwiw
2020-10-11 19:07:26 <artok> so uboot is now really working for rpi boot
2020-10-11 19:07:44 <artok> rpi4 usb boot that is
2020-10-11 19:08:38 <ikke> hmm, interesting
2020-10-11 19:10:02 <mps> artok: I know that it works on RPi zero
2020-10-11 19:11:42 <artok> now mainline aarch64 kernel to the works
2020-10-11 19:13:48 <mps> again yes, but I only tested on RPi zero
2020-10-11 19:14:09 <artok> I got archlinux working with 'em
2020-10-11 19:14:23 <mps> 5.10 will have VC4 driver also, I think
2020-10-11 19:15:02 <mps> it is queued
2020-10-11 19:15:05 <artok> it seemed to be plan
2020-10-11 21:17:47 <artok> so, getting new start4.elf etc from rpi, also makes usb boot ok
2020-10-11 22:38:16 <Ticho> how can one support multi-thread compilation in alpine packages? most APKBUILDs just use "make", or even force "make -j1"
2020-10-11 22:48:57 <u0jQx9gPyrYg> set JOBS=<number> in /etc/abuild.conf
2020-10-11 22:49:27 <Ticho> u0jQx9gPyrYg: ah, thanks!
2020-10-11 22:49:35 <maxice8> MAKEFLAGS is set and should be respected
2020-10-11 22:51:32 <Hello71> unless you use ninja
2020-10-11 22:51:46 <Hello71> ninja go brrrrr
2020-10-11 22:52:01 <Ticho> nope, I'm dealing with good old autotools+make, and cmake+make
2020-10-11 22:56:20 <Hello71> i think the meme format would be "you can't just use all the cpus!" "haha ninja go brrrrrr"
2020-10-11 22:58:19 <maxice8> s/ninja/cpuload
2020-10-11 22:58:29 <maxice8> 7.5/10
2020-10-11 23:39:36 <Ticho> where can I find some info about what process to follow if I want to take over maintainership of a package in "unmaintained"? it also involves introducing another package as a dependency
2020-10-11 23:42:31 <maxice8> 1 MR with 1 commit adding the new package to testing/ another commit moving the package from unmaintained/ to testing/ and another adding yourself as maintainer to the package of the previous commit.
2020-10-11 23:43:50 <Ticho> the second commit should include both the move from unmaintained and any changes to the APKBUILD file?
2020-10-11 23:44:08 <maxice8> no, 1 commit purely moving
2020-10-11 23:44:10 <maxice8> you can use `git mv`
2020-10-11 23:44:21 <Ticho> right
2020-10-11 23:44:56 <Ticho> so the changes (version bump, fixes to build process, etc.) should be in a yet another commit?
2020-10-11 23:45:32 <Ticho> btw if this is described somewhere in detail, just point me to the documentation and don't waste your time :)
2020-10-11 23:47:22 <maxice8> There isn't documentation for that atm
2020-10-11 23:47:30 <maxice8> I wouldn't invest (not waste) my time otherwise
2020-10-12 04:47:17 <ikke> Hello71: nowadays we set SAMUFLAGS as well
2020-10-12 04:49:00 <ikke> (We use samurai instead of ninja)
2020-10-12 06:16:14 <ncopa> good morning
2020-10-12 06:22:59 <Cogitri> Morning 👋
2020-10-12 06:29:49 <mps> good morning
2020-10-12 06:32:46 <mps> ncopa: do you have time to look !13456
2020-10-12 06:33:25 <mps> changed to use uptream tarballs and removed snapshot()
2020-10-12 06:34:05 <mps> and ikke already looked at it
2020-10-12 06:35:55 <mps> also fakeroot upgrade MR
2020-10-12 06:36:25 <mps> !13278
2020-10-12 08:05:37 <ncopa> mps: re !13278 did you verify that the two patches are upstreamed or are not needed anymore?
2020-10-12 08:08:22 <mps> no, fakeroot-hide-dlsym-errors.patch is the same as what they did upstream
2020-10-12 08:09:00 <mps> second one, fakeroot-no-ldlibrarypath.patch, I think it is not needed
2020-10-12 08:10:15 <mps> I'm using this upgraded fakeroot for about then days on 3 arches in 3 lxc builders without issues till now
2020-10-12 09:53:27 <mps> `grep -r '^pkgdesc' {main,community} | less' can make full day of good laugh
2020-10-12 09:54:33 <ikke> Any particular good examples?
2020-10-12 09:55:05 <mps> I would left this to personal humor preferences
2020-10-12 09:56:45 <ikke> While I was interested in what you found humerous :)
2020-10-12 09:57:36 <mps> heh, maybe I can post in private to you
2020-10-12 09:57:55 <mps> main/dhcp/APKBUILD:pkgdesc="ISC Dynamic Host Configuration Protocol (DHCP)"
2020-10-12 09:59:22 <mps> to much of descs starts with 'A ' or 'The ' which doesn't make sense for descs
2020-10-12 10:01:46 <mps> two aports have same desc, main/font-cursor-misc and main/font-daewoo-misc
2020-10-12 10:02:17 <mps> and third main/font-sun-misc
2020-10-12 10:08:08 <ncopa> mps: maybe remove the WIP is fakerrot is tested and works
2020-10-12 10:08:19 <ncopa> s/fakerrot/fakeroot/
2020-10-12 10:08:19 <alpine-meetbot> ncopa meant to say: mps: maybe remove the WIP is fakeroot is tested and works
2020-10-12 10:08:44 <ncopa> linux 5.9 is out
2020-10-12 10:08:53 <ncopa> not marked as LTS yet though
2020-10-12 10:22:52 <mps> yes, and LTS is wrong term imo. LTM sounds better 'LongTerm Maintained'
2020-10-12 10:24:13 <mps> https://www.kernel.org/category/releases.html
2020-10-12 10:25:15 <mps> and, if you remember, looks like my intuition worked about this, I told you that next LTS (LTM) will be 5.10
2020-10-12 10:25:27 <ikke> LTS is a commonly used term though
2020-10-12 10:25:59 <mps> ikke: yes, but it is still not right, imo
2020-10-12 10:26:18 <ikke> well, isn't providing patches not a form of support?
2020-10-12 10:26:56 <mps> or maintenance
2020-10-12 10:27:59 <mps> ncopa: removed WIP from fakeroot, !13278
2020-10-12 10:33:57 <ikke> mps: isn't maintenance a for of support? :P
2020-10-12 10:35:10 <ikke> s/for/form
2020-10-12 10:35:10 <alpine-meetbot> ikke meant to say: mps: isn't maintenance a form of support? :P
2020-10-12 11:00:58 <mps> ikke: if we are nitpicking more, support sounds like 'payed' service while maintenance could also sound like this, it usually doesn't
2020-10-12 11:01:40 <ikke> mps: so we cannot give support, because people are not paying us :)
2020-10-12 11:02:43 <mps> my reasoning comes from https://www.kernel.org/category/releases.html 'Longterm' 'There are usually several "longterm maintenance" kernel releases provided ....'
2020-10-12 11:04:11 <mps> and yes. we don't give support we just maintain pkgs by coincidence
2020-10-12 11:07:02 <mps> (writting someone who just barely understand english terms)
2020-10-12 11:34:58 <artok> mm llvm 11
2020-10-12 12:21:43 <ncopa> i'd like to tag 3.12.1 release this week
2020-10-12 12:22:46 <ncopa> would be nice to get some help colsing some of the issues for 3.12.1 target
2020-10-12 12:23:24 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/issues?milestone_title=3.12.1
2020-10-12 12:23:37 <mps> are there list somewhere, or search through gitlab issues
2020-10-12 12:23:45 <mps> oh
2020-10-12 12:23:52 <ikke> We use milestones for those
2020-10-12 12:24:25 <ikke> ncopa: Is there anything left to do for https://gitlab.alpinelinux.org/alpine/aports/-/issues/11599 ?
2020-10-12 12:28:03 <mps> some of these bugs are 'longstanding'
2020-10-12 12:28:10 <ikke> yes
2020-10-12 12:28:13 <ikke> correct
2020-10-12 12:28:32 <ikke> They keep being bumped forward
2020-10-12 12:29:45 <ncopa> ikke: not sure if there are much more to do for #11599
2020-10-12 12:30:02 <ncopa> it can be configured in /etc/inittab
2020-10-12 12:30:55 <ikke> And not something we ought to do by default for virt images?
2020-10-12 12:32:01 <ncopa> we enable serial console by default on -virt images
2020-10-12 12:32:08 <ikke> :)
2020-10-12 12:32:10 <ncopa> which is hte problem i suppose
2020-10-12 12:32:12 <ikke> Yeah
2020-10-12 12:33:40 <ikke> #11620 seems a simple fix or close as well
2020-10-12 12:34:35 <artok> ncopa #11278 still valid? you did changes to linux-rpi ..today?
2020-10-12 14:07:47 <ncopa> artok: tbh, i dont know, becuase i have not been able to reproduce it, ever
2020-10-12 14:08:26 <ncopa> i suspect it is due to how the rpi was installed. I think the proper solution would be to support disk install of rpi, which currently does not work
2020-10-12 14:08:28 <artok> because of sake of it, just booted edge on my rpi4
2020-10-12 14:09:51 <ncopa> and usb works?
2020-10-12 14:10:02 <artok> yeah, booted from usb even
2020-10-12 14:10:23 <ncopa> maybe comment to the issue, and i can close it
2020-10-12 14:10:25 <artok> sda1 fat with boot stuff, sda2 ext4 root
2020-10-12 14:10:54 <ncopa> do you mount /dev/sda1 as /boot?
2020-10-12 14:11:49 <artok> actually fstab has /dev/sda1 -> /media/sda1, and then I've got symbolic link /boot -> /media/sda1/boot
2020-10-12 14:11:58 <ncopa> ok
2020-10-12 14:54:53 <minimal> ncopa: Re RPI, !11052 is still an issue
2020-10-12 14:55:52 <minimal> I run Alpine on RPI via sys but I'm building the SD card image in advance in a chroot environment rather than installing directly on the RPI
2020-10-12 14:57:56 <mps> maybe we can switch RPis boot to use u-boot and then keep dtbs under /boot/dtbs-$flavor
2020-10-12 14:58:59 <minimal> mps: u-boot is an option but I'd like to still be able to boot using the usual bootloader.
2020-10-12 15:00:13 <minimal> The underlying issue is that the dtb stuff needs to be in /boot and also need to handle the RPI files for the several distinct machines (RPI, RPI2, RPI4)
2020-10-12 15:01:27 <artok> dtb needs to be in the root of the fat, yeah
2020-10-12 15:01:45 <mps> minimal: ok
2020-10-12 15:02:03 <mps> and I don't care much for RPis
2020-10-12 15:02:24 <mps> whatever ncopa decide is ok for me
2020-10-12 15:02:48 <minimal> artok: I currently kludge around the issue using a bind mount for the DTS but a proper solution is needed
2020-10-12 15:03:43 <mps> but their nonsense with boot should be solved when alpine upgrade to next -lts kernel imo
2020-10-12 15:04:36 <minimal> currently linux-rpi and linux-rpi4 (for example) contain some of the same files and have them in /boot/dtbs-rpi and /boot/dtbs-rpi4
2020-10-12 15:05:01 <minimal> mps: upstream kernel won't resolve Alpine packaging issues for the DTS files
2020-10-12 15:05:30 <mps> no, it wont, but we should
2020-10-12 15:06:05 <minimal> agreed, I'm happy to help but someone needs to take a lead on it
2020-10-12 15:06:30 <mps> and for now keeping separate dtbs for separate kernels is proper
2020-10-12 15:06:47 <mps> kernel flavors, I mean
2020-10-12 15:07:41 <mps> all dtbs in one dir for separate kernel flavors will make a big mess
2020-10-12 15:08:46 <minimal> agreed, only need/want the files for the type of RPI you're using. However the files need to be in the correct directory - which they're not currently
2020-10-12 15:10:18 <mps> iiuc, for RPis correct dir is '/' on fat partition
2020-10-12 15:10:29 <minimal> at the moment if you download the Alpine RPI images and use them everything is fine - until you update your linux-rpi/linux-rpi2/linux-rpi4 package and then it breaks. The downloadable image has the DTBs in the right place, the kernel packages have them in the wrong place
2020-10-12 15:12:54 <mps> and I'm starting to think that we will have all these separate kernels also for 3.13 release
2020-10-12 15:13:26 <mps> I had a hope that we will remove RPi kernel in 3.13 and use -lts
2020-10-12 15:13:41 <mps> kernels*
2020-10-12 15:16:08 <minimal> bottom line, how do "we" resolve the current issue? its been an issue for a while...
2020-10-12 15:17:41 <mps> I looked at the issue but didn't touched aports about this, left it to maintainer to decide
2020-10-12 15:20:59 <minimal> I'm sure ncopa's got a huge list of things to deal with and guess unfortunately that this issue would be low down that list
2020-10-12 15:34:50 <ncopa> so aceb2e5ecdfb69be55dd5592c94f2d9294db06e6 didnt work
2020-10-12 15:35:49 <artok> oh wait
2020-10-12 15:36:28 <artok> yeah I've got them now on both
2020-10-12 15:37:15 <mps> local INSTALL_DTBS_PATH="$_outdir"/boot/dtbs-$_buildflavor
2020-10-12 15:37:32 <mps> local INSTALL_DTBS_PATH="$_outdir"/boot
2020-10-12 15:38:21 <artok> kernel and initramfs needs to be moved also one dir up, and then mount that fat partition to /boot
2020-10-12 15:38:25 <mps> expecting that boot partition is mounted under /boot during kernel install/upgrade, iiuc
2020-10-12 15:42:53 <ncopa> i think we want to mount the fat partition as /boot on rpi
2020-10-12 15:43:03 <ncopa> when doing sys install
2020-10-12 15:45:05 <mps> yes, otherwise will make a mess
2020-10-12 15:50:22 <artok> yeah +1
2020-10-12 15:55:29 <minimal> ncopa: what I have working here is /dev/mmcblk0p0 as 133MB fat32 partition mounted as /boot, and root as ext4/f2fs partition
2020-10-12 15:57:50 <minimal> inside /boot (partition 1) are the bootloader binary files, directories dtbs-rpi and overlays (from package linux-rpi), the bootloader config files, and the initramfs and kernel;
2020-10-12 16:00:03 <minimal> ncopa: part of the issue is that the bootloader's config.txt and usercfg.txt content must match with the actual layout of the contents of /boot
2020-10-12 16:02:59 <mps> minimal: true, if kernel and initramfs have to be in /, then *txt files also must be adjusted
2020-10-12 16:03:51 <minimal> I'm using a "kludge" of bind-mounting /boot/dtbs-rpi as /boot so that when package linux-rpi is installed/updated then when it puts stuff in /boot/dtbs-rpi/overlays/ it actually ends up in /boot/overlays/
2020-10-12 16:03:57 <mps> but they can be kept where are they now
2020-10-12 16:04:54 <minimal> mps: from memory the problem is the config.txt and usercfg.txt from the downloadable RPI image does *not* reference the same locations where the linux-rpi/linux-rpi2/linux-rpi4 put things.
2020-10-12 16:06:00 <mps> no, they are ok
2020-10-12 16:06:02 <minimal> the other thing my kludge ensures is that when linux-rpi puts DTB files in /boot/dtbs-rpi/ that they end up in /boot/ which again is where the bootloader config is expecting them.
2020-10-12 16:07:04 <mps> though I think all this can be solved more elegantly with u-boot
2020-10-12 16:11:07 <minimal> mps: its ok? there are linux-rpi, linux-rpi2, and linux-rpi4 packages which put files in /boot/dtbs-rpi, /boot/dtbs-rpi2, and /boot/dtbs-rpi4 respectively. The bootloader doesn't handle this, it expects the files in standard locations
2020-10-12 16:18:10 <minimal> Here's the RPI docs about the expected boot partition contents: https://www.raspberrypi.org/documentation/configuration/boot_folder.md
2020-10-12 16:20:19 <minimal> "The overlays sub-folder contains Device Tree overlays.". That's referring to overlays as a subfolder of boot whereas the linux-rpiX packages makes it a subfolder of /boot/dtbs-rpiX
2020-10-12 16:21:32 <minimal> "There are various Device Tree blob files, which have the extension .dtb. These contain the hardware definitions of the various models of Raspberry Pi, and are used on boot to set up the kernel according to which Pi model is detected.". Likewise that's referring to multiple *.dtb files in /boot whereas the linux-rpiX packages place them in /boot/dtbs-rpiX/
2020-10-12 16:22:42 <mps> hmm, maybe I misunderstand you, you install all linux-rpi/linux-rpi2/linux-rpi4 at the same FS and at 'same' time?
2020-10-12 16:23:26 <artok> same sd can boot on rpi4,rpi3, whatever
2020-10-12 16:23:30 <artok> usually
2020-10-12 16:23:51 <artok> config.txt has setting which kernel and initramfs to load
2020-10-12 16:24:00 <mps> and yes, we know how is this 'organized' on RPis
2020-10-12 16:24:12 <minimal> nope, I'm referring to there being 3 separate kernel packages depending on the type of RPI that you have.
2020-10-12 16:24:24 <mps> artok: yes, I know how that all works
2020-10-12 16:24:37 <mps> minimal: ok
2020-10-12 16:24:54 <artok> well that is just that =)
2020-10-12 16:25:13 <minimal> regardless of which one in installed they should put there RPI hardware DTB files in /boot and the overlay files in /boot/overlays/ but they do not.
2020-10-12 16:25:16 <mps> artok: hehe
2020-10-12 16:25:56 <mps> minimal: so solution for your problem will be just put dtbs to mounted /boot
2020-10-12 16:25:57 <artok> mainline kernel might do things differently
2020-10-12 16:27:06 <artok> tbh I had that booting issue back in day and I did whole diff to move everything so /boot would be the root fat partition
2020-10-12 16:27:21 <minimal> I'm looking at an aarch64 RPI2 here running Alpine edge. So its got the linux-rpi package installed which placed files into /boot/dtbs-rpi and /boot/dtbs-rpi/overlays which is wrong.
2020-10-12 16:27:43 <mps> minimal: true
2020-10-12 16:28:15 <mps> solution is as I wrote above 'local INSTALL_DTBS_PATH="$_outdir"/boot'
2020-10-12 16:28:20 <minimal> If I had a RPI4 here then I'd see the linux-rpi4 package installed and that would place files wrongly into /boot/dtbs-rpi4/ and /boot/dtbs-rip4/overlays/
2020-10-12 16:29:27 <mps> yes
2020-10-12 16:29:54 <minimal> mps: yes that would put them in the right place - but then wouldn't that cause a Alp[ine package linting issue as then multiple packages would contain the same files (linux-rpi, linux-rpi2, and linux-rpi4)
2020-10-12 16:30:53 <mps> who cares for lintian :)
2020-10-12 16:31:22 <mps> if it works and solves issues it is good
2020-10-12 16:31:32 <minimal> minimal: I've had MRs held up by lint issues in the past
2020-10-12 16:31:38 <artok> subpackage for linux-rpi-dtbsoverlays
2020-10-12 16:31:39 <artok> =)
2020-10-12 16:31:42 <minimal> oops, talking to myself ;-)
2020-10-12 16:32:12 <mps> minimal: no, it is probably held by developer insisting on lintian report
2020-10-12 16:32:26 <artok> as dtbs+overlays can be done with own build command, right?
2020-10-12 16:32:55 <mps> artok: you mean subpkg?
2020-10-12 16:33:03 <minimal> mps: yes that's my point - its about Alpine "policy" decisions
2020-10-12 16:34:16 <minimal> also I think the bootloader config files (cmdline.txt, config.txt, usercfg.txt) should be part of some package rather than only exist in the installable image - otherwise their contents can't be managed/updated going forward
2020-10-12 16:34:18 <artok> yeah, pkg is package shortened? =)
2020-10-12 16:34:37 <MartijnBraam> is it known when linux-edge will move to 5.9?
2020-10-12 16:34:58 <artok> minimal: config.txt and cmdline.txt are like passwd...
2020-10-12 16:35:36 <minimal> config.txt defined where to find initramfs and kernel and whether to use 64bit or not
2020-10-12 16:35:47 <mps> MartijnBraam: I'm hesitating to upgrade it before 5.9.1, there are some issues reported already
2020-10-12 16:36:16 <MartijnBraam> oh interesting
2020-10-12 16:36:45 <mps> for example https://bugzilla.kernel.org/show_bug.cgi?id=209469
2020-10-12 16:37:01 <artok> minimal: actually yeah, that can be done, as long as user does usercfg.txt thingies
2020-10-12 16:37:22 <MartijnBraam> oh modeswitch stuffs
2020-10-12 16:38:03 <mps> actually udev
2020-10-12 16:39:58 <MartijnBraam> I'm wondering what to do with my pinebookpro kernel, I rebased the one in postmarketOS to 5.9.0 now and it seems to run great, but still needs the small patch from linux-next
2020-10-12 16:41:01 <MartijnBraam> so my options are 1. package it in postmarketOS, 2. make a seperate linux-pinebookpro kernel in alpine 3. add that patch to linux-edge
2020-10-12 16:41:07 <minimal> artok: user can still manage/override those files going forward, but they're not in any Alpine package at all, only in the installable image
2020-10-12 16:42:38 <artok> minimal: so you'd make package that runs script to check file existense, and if not, place default that is now done in installer script
2020-10-12 16:43:55 <minimal> artok: I'd expect them to be part of the bootloader package. Like any package's config file once you modify it a package update/upgrade will *not* then modify it
2020-10-12 16:44:15 <mps> MartijnBraam: if it is not big patch we can add it to linux-edge and report upstream in hope that they will merge in some of next version
2020-10-12 16:44:49 <MartijnBraam> doesn't it being in linux-next mean it is going to be in 5.10 already?
2020-10-12 16:45:18 <minimal> as an example, for my RPIs I actually build SD card images (using static apk inside a chroot) rather than use the downloadable image. In that situation there are no bootloader config files at all and so I have to create them manually
2020-10-12 16:45:22 <mps> should be if Linus didn't already branched 5.10
2020-10-12 16:45:26 <artok> minimal: bootloader seems ok package
2020-10-12 16:45:35 <mps> but that usually takes two weeks
2020-10-12 16:46:01 <mps> i.e. when we will see 5.10-rc1
2020-10-12 16:46:08 <artok> minimal: but then there is different for aarch64 ...
2020-10-12 16:46:52 <MartijnBraam> it's this patch: https://www.spinics.net/lists/arm-kernel/msg840928.html
2020-10-12 16:47:32 <MartijnBraam> without the patch linux runs fine but the display just won't come up
2020-10-12 16:47:33 <ikke> looking at hyperscan, which fails because some binaries have $HOME in their rpath, but if I user chrpath -d on those binaries, it also errors (open: no suchs file or directory, elf_open: no such file or directory).
2020-10-12 16:47:47 <ikke> I also tried `-DCMAKE_SKIP_INSTALL_RPATH=TRUE`, but does not help
2020-10-12 16:48:17 <mps> MartijnBraam: interesting, on my rk3399 (gru-kevin) it works fine
2020-10-12 16:49:16 <MartijnBraam> it's specifically for fixing the eDP stuff not working when the bootloader has already turned on the display
2020-10-12 16:49:38 <minimal> artok: yupe, and the contents of config.txt will differ between armv7 and aarch64 as aarch64 will specify 64bit
2020-10-12 16:51:49 <artok> and armhf is still for those rpi0
2020-10-12 16:51:51 <mps> MartijnBraam: ok, I will test it with my chromebooks
2020-10-12 16:52:03 <artok> actually.. naah, they should do their own baremetal =)
2020-10-12 16:53:05 <mps> minimal: afaik, same config.txt file is used for RPi 0, RPi 1 and RPi 2
2020-10-12 16:53:46 <MartijnBraam> I think you can make confix.txt include extra config files so you can have packaged defaults and user overrides?
2020-10-12 16:53:52 <minimal> mps: yes so I noticed, that surprised me as why have seperate kernels but the same kernel config.
2020-10-12 16:54:04 <mps> maybe even RPi 4, but my RPi is down now so can't check
2020-10-12 16:54:33 <minimal> artok: does armv7 not work for RPI0? Never used one. These days I only tend to use aarch64 on the RPIs I have
2020-10-12 16:54:46 <artok> minimal: no, rpi0 is armv6
2020-10-12 16:55:36 <artok> pi1, pizero, pizerow have armv6 kernel, rpi2 pi3 pi3+ and cm3 have armv7 kernel, and rpi4 has own armv7 kernel
2020-10-12 16:55:58 <artok> aaaand then aarch64 versions rpi3+ and rpi4 have own kernel each
2020-10-12 16:56:26 <artok> (foundation kernels)
2020-10-12 16:59:40 <minimal> actually the aarch64 linux-rpi package is for *some* RPI2s as well as RPI3 and RPI3+. More recent manufactured RPI2 have a 64bit chip as cost saving "improvement"
2020-10-12 17:01:20 <artok> yah yah, true,rpi2 v1.2 (or something like that) started to use same rpi3 armv8 chippie
2020-10-12 17:03:11 <minimal> I'm running 64bit aarch64 on RPI3 here (not RPI3+)
2020-10-12 17:05:46 <mps> they like to haras distributors of linux :)
2020-10-12 17:10:56 <artok> hmm.. what if I'd put my alpine sd that I used to do rpi4 install into my rpi3...
2020-10-12 17:12:19 <ikke> 11
2020-10-12 17:12:21 <ikke> oops
2020-10-12 17:12:22 <artok> should do some nice headless apkolv
2020-10-12 17:14:00 <minimal> artok: should be fine as /boot/*.dtb will have rpi3 as well as rpi4 files
2020-10-12 17:14:23 <minimal> though your usercfg.txt may need modified depending on what's in there
2020-10-12 17:14:34 <artok> should be fine yeah but I can't remember how much configuration I already did =D
2020-10-12 17:15:13 <artok> better just to attach it to laptop and edit hostname so I'll get resolving correctly
2020-10-12 17:16:13 <minimal> artok: one reason I build ready-to-go SD card images is for headless machines
2020-10-12 17:16:30 <artok> minimal: I do my configs so that [pi4] has things that I want to enable on pi4
2020-10-12 17:17:12 <minimal> yupe, same here: I build separate SD images for RPI3, RPI4 (as well as virt aarch86, physical and virtual x86_64)
2020-10-12 17:17:38 <minimal> and use cloud-init for 1st boot configuration of Alpine
2020-10-12 17:24:51 <artok> oh
2020-10-12 17:25:08 <artok> I've done installations again slightly drunk
2020-10-12 17:25:23 <artok> forgot that I even started the installation from the usb media
2020-10-12 17:26:45 <mps> MartijnBraam: I found mentioned PBP (and not only PBP) patch as kernel git commit 457f74abbed060a0395f75ab5297f2d76cada516
2020-10-12 17:27:44 <mps> it applies cleanly to 5.9.0
2020-10-12 17:27:50 <MartijnBraam> oh nice
2020-10-12 17:28:01 <MartijnBraam> >  This commit does not belong to any branch on this repository.
2020-10-12 17:28:02 <MartijnBraam> thanks github
2020-10-12 17:28:45 <mps> linux-next
2020-10-12 17:29:32 <MartijnBraam> it's also in torvalds/linux, somewhere
2020-10-12 17:30:33 <mps> ncopa: I updated !13278, there is new version and old tarball is removed from their server
2020-10-12 17:31:26 <mps> MartijnBraam: well, already started build with patch from linux-next, lets see
2020-10-12 17:32:05 <mps> ncopa: are you if I merge it or you want another review
2020-10-12 17:32:12 <mps> hmmmm
2020-10-12 17:32:30 <mps> are you ok if I merge it or you want another review
2020-10-12 17:52:46 <insep_> s/you/you ok/g?
2020-10-12 17:52:53 <insep_> oh wait
2020-10-12 17:52:54 <insep_> wrong sed
2020-10-12 17:52:57 <insep_> s/if/ok if/g
2020-10-12 17:53:04 <mps> MartijnBraam: applied and built 5.9.0 with mentioned patch, works fine, don't see any problem on rk3399 gru-kevin chromebook
2020-10-12 17:53:24 <MartijnBraam> :) great
2020-10-12 17:53:48 <mps> so we can add it when we upgrade to 5.9.1
2020-10-12 17:54:17 <MartijnBraam> perfect, then I'll package my kernel in temp/ for now in postmarketOS
2020-10-12 17:56:33 <mps> I would like upgrade linux-edge right now but I saw some issues with some network drivers (rtw 8...??ce) and this with usb_modeswitch
2020-10-12 17:57:05 <mps> don't want to break someone working system because we are in hurry
2020-10-12 17:57:47 <MartijnBraam> yep, also upgrading to 5.9 a day after release is really quick
2020-10-12 18:35:45 <walbon> maxice8: have you fixed that issue with package for ppc64le? I have noticed a set of packages are failing then I addopting changes like https://gitlab.alpinelinux.org/alpine/aports/-/commit/4c7a9baecaeca0572cd2859a53e7184cd1f6b89c
2020-10-12 19:56:09 <maxice8> <walbon "maxice8: have you fixed that iss"> I disabled some that were failing
2020-10-12 19:57:22 <walbon> maxice8: do you ignore the ppc64le packages?
2020-10-12 19:57:36 <maxice8> mostly
2020-10-12 20:00:12 <walbon> maxice8: I see many packages failing because the missing of 128b supports, and I'm figuring out how to fix all of them. Maybe in your setup you could add into abuild.conf the 128b support into cxxflags
2020-10-12 20:00:32 <maxice8> I'm not using ppc64le
2020-10-12 20:00:43 <walbon> ow, ok
2020-10-12 20:02:10 <maxice8> There must be a way to fix this without sprinkling the magic flag everywhere it fails
2020-10-12 20:04:29 <walbon> maxice8: that's my  question I saw a bunch of packages failing
2020-10-12 20:11:38 <walbon> ncopa, mps: mksully and me noticed a set of packages that are failing in ppc64le after the libc adopted 128 support. What is it the better approach, update one by one(almost 200 packages) or add in other way as abuild.conf instead of those 200 individual commits?
2020-10-12 20:14:50 <mps> walbon: what are changes? (and i think you two will better know how to do update)
2020-10-12 20:16:10 <walbon> mps: adding export CXXFLAGS="$CXXFLAGS -mlong-double-128" just for ppc64le as I did in this MR https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/13547
2020-10-12 20:17:45 <ikke> walbon: if that's necessary for (almost) all packages on ppc64le, it would make sense to add that to abuild.conf
2020-10-12 20:17:47 <mps> then I think it is ok to do that in one MR, but with commit for every package which need it
2020-10-12 20:18:08 <Hello71> pretty sure it needs to match on whole system
2020-10-12 20:18:14 <mps> ah, ikke understant this better than me
2020-10-12 20:18:28 <ikke> mps: No, I just pretend to
2020-10-12 20:18:32 <Hello71> because it's an abi break
2020-10-12 20:18:36 <ikke> Hello71: right
2020-10-12 20:18:54 <ikke> Hello71: ooh, so we may need to do a full rebuild then?
2020-10-12 20:19:06 <mps> looks so
2020-10-12 20:19:07 <ikke> like with 32-bits systems..
2020-10-12 20:20:36 <Hello71> i'm not sure what is meant by "the libc adopted 128 support" though, since I don't follow ppc
2020-10-12 20:20:45 <Hello71> probably Ariadne or dalias should know
2020-10-12 20:21:05 <Hello71> but I'm almost certain that adding this flag on a package-by-package basis is broken
2020-10-12 20:22:18 <walbon> Hello71: I don't know how the libc was built to use this 128b which don't work well with packages without it
2020-10-12 20:23:39 <Hello71> log example?
2020-10-12 20:25:51 <walbon> Hello71: give me a minute
2020-10-12 20:27:30 <walbon> Hello71: https://pastebin.com/raw/1mkszMbU
2020-10-12 20:27:43 <ikke> Yeah, I have seen that error more often lately
2020-10-12 20:27:56 <ikke> maybe gcc10 upgrade?
2020-10-12 20:28:44 <Hello71> this error is unrelated to libc
2020-10-12 20:30:18 <walbon> ikke: that was the cause do you think?
2020-10-12 20:33:01 <dalias> ikke, it's wrong
2020-10-12 20:33:44 <dalias> walbon, what do you mean by "after libc adopted 128 support" ? no such thing happened
2020-10-12 20:36:08 <mps> i think that is related to -mlong-double-128 flag
2020-10-12 20:37:27 <dalias> which is not valid
2020-10-12 20:37:40 <dalias> it's an abi-changing flag to compile for a mismatched abi
2020-10-12 20:46:10 <Hello71> how is this flag supposed to work anyways? the direct explanation is that gcc got compiled wrong. but then how do you ever use this flag? afaik you can't just "avoid gcc_s"
2020-10-12 20:46:54 <dalias> it's for repurposing the compiler to build for a different ABI
2020-10-12 20:47:55 <dalias> in theory you can do a mixed thing, if you carefully track the ABIs involved in different modules and make sure you don't link mismatched interfaces
2020-10-12 20:58:56 <ikke> dalias: what is wrong? that it's gcc10?
2020-10-12 20:59:29 <ikke> or to set that flag
2020-10-12 20:59:49 <walbon> dalias: I saw the error message and then I supposed that.
2020-10-12 21:01:12 <dalias> what was the error message?
2020-10-12 21:01:46 <dalias> ikke, -mlong-double-128 is wrong
2020-10-12 21:02:16 <ikke> dalias: right
2020-10-12 21:02:33 <ikke> ...addressdelegate.cpp.o uses 64-bit long double, /usr/lib/gcc/powerpc64le-alpine-linux-musl/10.2.0/../../../../lib/libgcc_s.so.1 uses 128-bit long double
2020-10-12 21:04:57 <dalias> *sigh*
2020-10-12 21:05:27 <dalias> i think libgcc just *has* softfloat code for ld128 in it, that's unused
2020-10-12 21:05:30 <dalias> and has always had it
2020-10-12 21:05:44 <dalias> but now some broken change in ld is erroring out saying the ABI mismatches because of that
2020-10-12 21:05:57 <dalias> it's likely a binutils regression not a gcc or application one
2020-10-12 21:12:36 <mcrute> Ariadne: do you have a good starting point for a MIPS64 install? I know it's still WIP but I've got an ER-4 just waiting to be converted to Alpine
2020-10-12 21:13:10 <mcrute> the wiki page just has a TODO, I'd be happy to write the docs if you can give me a good starting point
2020-10-12 21:17:43 <walbon> dalias: so, that mismatches is broking all of new builds using the current binutils?
2020-10-12 21:18:26 <dalias> that's my guess
2020-10-12 21:18:32 <dalias> well
2020-10-12 21:18:37 <dalias> all that link libgcc_s
2020-10-12 21:18:45 <dalias> so that'll only be stuff that uses c++/exceptions
2020-10-12 21:19:03 <dalias> otherwise only libgcc.a is used, and .o files from the archive that aren't needed won't get linked
2020-10-12 21:21:02 <Hello71> I think the problem with this theory is that binutils wasn't upgraded recently
2020-10-12 21:21:10 <Hello71> otherwise it sounds plausible
2020-10-12 21:27:39 <walbon> Hello71: the binutils is the latest version, 2.35.1
2020-10-12 21:28:24 <dalias> hmm, i guess it could be something new gcc is doing in the build of libgcc_s
2020-10-12 21:28:30 <dalias> but it's one of those two
2020-10-12 21:28:35 <dalias> nothing else plays a role in it
2020-10-12 21:29:54 <Ariadne> mcrute: on octeon devices the easiest way is to prepare an image with qemu-mips64, and then install that using a recovery
2020-10-12 21:31:55 <Ariadne> mcrute: an alternative may be to install NSL (which is a commercially supported subset of alpine), and then crossgrade to alpine
2020-10-12 21:32:17 <Ariadne> mcrute: if you have time, i can walk you through either way
2020-10-12 21:33:06 <Ariadne> mcrute: if you need a recovery that is known to work on ER-4, http://as57335.net/static/alpine-mips64/distfiles/vmlinux-5.4.17-1-octeon-recovery
2020-10-12 21:35:30 <Ariadne> UBNT have a recovery and some other dude made one as well
2020-10-12 21:35:34 <mcrute> Ariadne: I've got time... I'd rather go for option 1
2020-10-12 21:35:51 <Ariadne> with my recovery you could install directly, actually
2020-10-12 21:36:01 <Ariadne> my recovery literally boots into a run from ram alpine environment
2020-10-12 21:36:02 <Ariadne> :D
2020-10-12 21:36:08 <mcrute> so you're taking the approach of build a shqashfs and kernel image then just drop it where their bootloader expects it to be?
2020-10-12 21:36:18 <Ariadne> no
2020-10-12 21:36:32 <Ariadne> thats only for recovery
2020-10-12 21:36:40 <Ariadne> normally you just run off the flash
2020-10-12 21:36:46 <Ariadne> partitioned however you want it
2020-10-12 21:36:48 <Ariadne> its just an emmc
2020-10-12 21:37:12 <Ariadne> (or a literal USB stick inside the case in the case of E100)
2020-10-12 21:37:12 <mcrute> right, I just though their uboot config had really specific assumptions?
2020-10-12 21:37:26 <Ariadne> not really
2020-10-12 21:37:28 <mcrute> haha, yeah I had one of those old routers RIP :-P
2020-10-12 21:37:46 <Ariadne> on the octeons, the uboot stuff is pretty much vanilla
2020-10-12 21:37:47 <mcrute> okay, I've never done a recovery, how does that work?
2020-10-12 21:37:53 <Ariadne> drop it in boot
2020-10-12 21:38:12 <Ariadne> setenv bootrecovery 'fatload mmc 0 $(loadaddr) vmlinux.recovery;bootoctlinux $(loadaddr) numcores=2 endbootargs mem=0 rw mtdparts=phys_mapped_flash:640k(boot0),640k(boot1),64k(eeprom)'
2020-10-12 21:38:15 <Ariadne> saveenv
2020-10-12 21:38:15 <ikke> Today I saw a USB stick which was just a micro SD card soldered on a PCB
2020-10-12 21:38:18 <Ariadne> env run bootrecovery
2020-10-12 21:38:33 <Ariadne> well
2020-10-12 21:38:36 <Ariadne> numcores=$(numcores)
2020-10-12 21:38:38 <Ariadne> but yeah
2020-10-12 21:39:08 <Ariadne> setenv bootrecovery 'fatload mmc 0 $(loadaddr) vmlinux.recovery;bootoctlinux $(loadaddr) numcores=$(numcores) endbootargs mem=0 rw mtdparts=$(mtdparts)'
2020-10-12 21:39:11 <Ariadne> that
2020-10-12 21:39:13 <Ariadne> and uhh
2020-10-12 21:39:22 <mcrute> oh cool, so basically the same approach you can use to flip back to an old image if you screw up the primary boot image
2020-10-12 21:39:24 <Ariadne> save the recovery kernel as vmlinux.recovery in /boot
2020-10-12 21:39:46 <Ariadne> NSL just installs as normal linux system
2020-10-12 21:39:53 <Ariadne> no primary/secondary
2020-10-12 21:39:56 <mcrute> got it, and that should give me a boot from ram Alpine environment and I can just wipe out the EMMC and go to town with a regular install?
2020-10-12 21:40:04 <Ariadne> yep
2020-10-12 21:40:23 <Ariadne> you'll just want to install linux-octeon
2020-10-12 21:40:32 <mcrute> is there stuff that doesn't work yet? like the SFPs and the switch chip (I also have an ER-12 I'd like to test)
2020-10-12 21:40:42 <Ariadne> ER-12 is completely fucked
2020-10-12 21:40:52 <Ariadne> ER-XG is completely fucked too
2020-10-12 21:40:56 <mcrute> I mean in software, I know the hardware is ;-) ;-)
2020-10-12 21:41:03 <Ariadne> yes
2020-10-12 21:41:05 <Ariadne> in software
2020-10-12 21:41:12 <Ariadne> there is no upstream driver for the switch chip
2020-10-12 21:41:26 <Ariadne> and there is no upstream driver for octeon3 ethernet in XG case
2020-10-12 21:41:34 <mcrute> ah okay, I know that mikrotik has a line based on that exact same qualcomm SKU so I thought mainline might have a driver
2020-10-12 21:41:43 <Ariadne> qualcomm??
2020-10-12 21:41:48 <Ariadne> octeon is marvell :)
2020-10-12 21:42:01 <Ariadne> we tried to reverse engineer the proprietary o3 nic driver, but discovered that it had a lot of bugs
2020-10-12 21:42:10 <mcrute> yes... but... the switching chip in the ER-12 is a Qualcom part
2020-10-12 21:42:15 <Ariadne> oh
2020-10-12 21:42:18 <Ariadne> true
2020-10-12 21:42:37 <mcrute> yeah that's part of why I want to do this, the UI drivers are total shit
2020-10-12 21:42:41 <Ariadne> well i do not have an ER-12 so haven't done much of a deep dive there
2020-10-12 21:42:56 <mcrute> does what they call "hardware offload" work?
2020-10-12 21:43:08 <Ariadne> on ER-4 it does
2020-10-12 21:43:17 <mcrute> the switch chip is Qualcomm QCA8511-AL1C in the ER-12 FWIW
2020-10-12 21:43:21 <Ariadne> the customer which wanted the octeon port anyway wanted it for a project that got cancelled
2020-10-12 21:43:35 <maxice8> llvm11 is out apparently
2020-10-12 21:43:46 <mcrute> is the "offloading" just the way the octeon ethernet driver works or is there some hacking to be done?
2020-10-12 21:44:03 <Ariadne> for other customers, we are pushing the standard ARM (NXP) and X86 (BCM chips like Qumran) solutions
2020-10-12 21:44:28 <Ariadne> for customers with a lot of money, there is also mellanox :)
2020-10-12 21:44:51 <mcrute> oh if only I had a spare $20k, those SN2000s look really nice
2020-10-12 21:45:21 <mcrute> I feel like the UI stuff has a lot of potential it's mostly held back by UIs horrible software stack
2020-10-12 21:45:38 <mcrute> the hardware at least... what are you recommending in the ARM and X86 area?
2020-10-12 21:50:11 <Ariadne> we're mostly targeting solidrun's NXP stuff and various whitebox switches on the X86 side
2020-10-12 21:50:27 <Ariadne> and of course Octeon, but marvell doesn't care much about octeon :)
2020-10-12 21:50:51 <Ariadne> with wave technology going bankrupt ...
2020-10-12 21:50:57 <Ariadne> i don't think mips has much of a future
2020-10-12 21:51:25 <mcrute> it's always been pretty niche I guess... but the rumor on LKML a while back was that they hired a contract house to maintain their upstream drivers
2020-10-12 21:52:21 <Ariadne> the drivers still live in staging sooo :)
2020-10-12 21:52:45 <mcrute> yeah not much actual movement it seems
2020-10-12 21:53:24 <mcrute> would be nice if BCM would get on the switchdev bandwagon that would make their stuff a lot easier to deal with
2020-10-12 21:55:56 <Ariadne> seems unlikely
2020-10-12 21:56:23 <Ariadne> we are working on an abstraction layer for SAI vs switchdev
2020-10-12 21:57:15 <mcrute> is it a proprietary thing or OSS?
2020-10-12 21:57:40 <Ariadne> the abstraction layer itself is OSS, the BCM bits will unfortunately be proprietary
2020-10-12 21:58:21 <mcrute> I'd love to try it out
2020-10-12 21:58:36 <Ariadne> should land in alpine 3.14
2020-10-12 21:58:50 <mcrute> it would be nice if BCM would drop a blob and then wire it up to switchdev but I guess I can dream
2020-10-12 21:58:55 <mcrute> what's it called?
2020-10-12 21:59:43 <Ariadne> the plan is, actually, to use ifupdown-ng to drive merchant silicon directly by replacing the shell scripts ifupdown-ng normally comes with
2020-10-12 22:00:00 <Ariadne> right now we're calling it SAL (Switch-framework Abstraction Library)
2020-10-12 22:00:38 <mcrute> cool, I'll watch for it
2020-10-12 22:00:57 <mcrute> does it do any of the kernel FIB -> TCAM stuff?
2020-10-12 22:01:38 <mcrute> a lot of what switchdev does on the SN2000s seems like you'd need a kernel module or at least a userland daemon listening to netlink to do
2020-10-12 22:02:17 <Ariadne> i assume you're talking about integrating stuff like FRR there
2020-10-12 22:02:31 <mcrute> or BIRD in my case, but yeah
2020-10-12 22:02:49 <Ariadne> the way they do it on SN3k on cumulus is to have a custom backend for FRR which replaces zebra
2020-10-12 22:03:14 <Ariadne> our plan is to do the same with SAL :)
2020-10-12 22:03:33 <mcrute> oh really? I haven't looked at what Cumulus is doing, I thought it all happened in the kernel as the routing daemon updated the tables
2020-10-12 22:04:06 <mcrute> but that sounds cool, so are you basically building an open-source version of switchdev where the actual ASIC config is the proprietary BCM bits?
2020-10-12 22:04:38 <Ariadne> switchdev itself is open source (it's the kernel bits)
2020-10-12 22:04:43 <Ariadne> but yes
2020-10-12 22:06:30 <mcrute> nifty! it's really exciting to hear that there's work going on in that area
2020-10-12 22:07:03 <mcrute> I have some BCM switches (more UI gear) that I'd like to migrate off of their shitty firmware but can't because of the BCM chips
2020-10-12 22:07:21 <Ariadne> the unifi crap with the touchscreen ? :)
2020-10-12 22:07:36 <mcrute> same formfactor, previous generation
2020-10-12 22:08:23 <mcrute> like the US-48-500W
2020-10-12 22:08:49 <mcrute> the hardware itself is pretty great for how cheap it is but it's really held back back crap software
2020-10-13 06:44:28 <craftyguy> Cogitri: (you're the maintainer for gnome-online-accounts) I'd like to include a patch that reorders the list of services presented to the user, and places proprietary services after non-proprietary services. I'm not sure upstream will want this.. and I'm not sure if this patch would be accepted in the alpine package. thought I'd ask before making a MR for it..
2020-10-13 06:44:58 <Cogitri> That's something that should be upstreamed first, yes
2020-10-13 06:46:22 <craftyguy> alright, I can try
2020-10-13 19:19:28 <mps> aports/main > ap revdep gtk+2.0-dev => nothing
2020-10-13 19:20:10 <mps> in same dir, ap revdep gtk+-dev show 3 pkgs
2020-10-13 19:20:19 <mps> note, gtk version
2020-10-13 19:20:57 <mps> i.e. gnokii, libdv, obex-data-server
2020-10-13 21:41:35 <Ariadne> mps: gtk+-dev is virtual
2020-10-13 21:50:01 <mps> yes, I know
2020-10-13 21:50:41 <mps> but don't know why it is needed (and don't care much)
2020-10-13 21:51:14 <mps> so please do not waste time on time on this
2020-10-13 21:51:47 <mps> and good night
2020-10-13 22:27:04 <Ariadne> mps: gtk+2.0 used to be gtk+, then gtk+3.0 came out :)
2020-10-14 06:36:30 <mps> good morning
2020-10-14 06:36:42 <maxice8> morning
2020-10-14 06:38:17 <mps> yesterday I looked vim aport, I think it should be reworked. split out gvim and move to community and make more subpkgs, i.e. tutor, doc (help), maybe syntax and compiler scripts
2020-10-14 06:39:59 <mps> any objections to this idea?
2020-10-14 06:40:58 <mps> also, nothing in main depends on gtk+2.0-dev, maybe it should be moved to community
2020-10-14 06:41:10 <maxice8> no and yes
2020-10-14 06:41:38 <mps> ?
2020-10-14 06:42:26 <mps> gtk+-dev?
2020-10-14 06:58:00 <maxice8> no objections, move to community
2020-10-14 06:58:41 <mps> you mean gtk+?
2020-10-14 06:59:01 <maxice8> no
2020-10-14 06:59:06 <maxice8> no objection to the vim aport idea
2020-10-14 06:59:11 <maxice8> yes move gtk+2.0 to community
2020-10-14 07:00:00 <mps> aha, ok
2020-10-14 07:00:21 <mps> nothing depends on gtk+2.0 in main
2020-10-14 07:02:16 <mps> split gvim out of vim will and move to community will require some 'thinkering', except if someone doesn't have bright/smart idea
2020-10-14 07:02:31 <mps> s/will//
2020-10-14 07:02:31 <alpine-meetbot> mps meant to say: split gvim out of vim  and move to community will require some 'thinkering', except if someone doesn't have bright/smart idea
2020-10-14 07:03:40 <maxice8> have 2 separate packages
2020-10-14 07:04:29 <mps> yes
2020-10-14 07:05:09 <mps> and 'trim' gvim to use vim subpkgs
2020-10-14 07:05:56 <mps> then they have to be kept 'in sync', i.e. versions
2020-10-14 07:06:15 <mps> or totally as separate pkgs
2020-10-14 07:09:40 <mps> maxice8: thanks for encouragement, I will start in more steps, not all in one commit
2020-10-14 07:10:41 <ikke> You could technically build 2 versions of vim in the same package
2020-10-14 07:12:27 <mps> yes, but I don't think it is good, except in special cases
2020-10-14 07:13:11 <ikke> 2 separate pacakges aren't ideal either
2020-10-14 07:14:10 <mps> also yes
2020-10-14 07:14:59 <mps> but if we want to move gtk out of main then gvim should be moved first
2020-10-14 11:44:26 <Ariadne> ncopa: https://github.com/ifupdown-ng/ifupdown-ng/pull/110 :)
2020-10-14 12:17:19 <ncopa> nice!
2020-10-14 12:26:24 <ncopa> looks like we have no build-3-12-mips64
2020-10-14 12:26:47 <ncopa> i wonder if i should postpone 3.12.1 til that is fixed or if i should do 3.12.1 release without mips64
2020-10-14 12:27:31 <ikke> I think that was the idea, right?
2020-10-14 13:32:32 <ddevault> libreoffice appears to have vanished from edge
2020-10-14 13:32:47 <ikke> yes
2020-10-14 13:33:01 <ikke> It does not compile atm with gcc10
2020-10-14 13:33:06 <ddevault> ah
2020-10-14 13:36:30 <ddevault> I'll see if I can fix it
2020-10-14 13:37:53 <ncopa> looks like thunderbird is failing on edge due to some missing directory or similar
2020-10-14 13:38:09 <ncopa> causing builders to rebuild it every push
2020-10-14 13:38:13 <ikke> yes
2020-10-14 13:38:26 <ikke> I saw an MR being merged trying to fix it, but didn't work apparently
2020-10-14 13:39:02 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&search=thunderbird
2020-10-14 13:48:31 <u0jQx9gPyrYg> ddevault: i asked a libreoffice dev, and he said they just had some patch for gcc11 trunk, so maybe it's fixed in git already
2020-10-14 13:49:03 <ddevault> aye, I'm hoping it'll be as simple as cherry picking some patches
2020-10-14 13:49:05 <ddevault> we'll see
2020-10-14 13:50:20 <u0jQx9gPyrYg> also there is a 7.0.2 libreoffice available, which is a bit fresher than what is in aports
2020-10-14 13:50:42 <Hello71> maybe stale^Wstill
2020-10-14 13:50:47 <u0jQx9gPyrYg> in aports is still: 6.4.6.2
2020-10-14 14:04:35 <Cogitri> Yup, couldn't upgrade because the new version would just fail on builders
2020-10-14 14:43:28 <mps> could someone update https://wiki.alpinelinux.org/wiki/Development_using_git and add gitlab as preferred method for workflow
2020-10-14 16:25:07 <mps> would someone except me test !13278 before merging
2020-10-14 16:25:35 <mps> actually "upgrade to 1.25.3"
2020-10-14 16:44:43 <ddevault> whelp
2020-10-14 16:45:00 <ddevault> I checked out libreoffice and build the sources outside of abuild, exact same tree, exact same patches
2020-10-14 16:45:05 <ddevault> and it works /o\
2020-10-14 16:51:19 <ikke> ddevault: but it does not work when you build it with the APKBUILD?
2020-10-14 16:51:24 <ddevault> no
2020-10-14 16:51:34 <ddevault> and it actually only almost worked in a separate tree
2020-10-14 16:51:46 <ddevault> I'm out of patience, I'm just gonna write this invoice with latex
2020-10-14 16:56:27 <gzmorell> Hi, I am trying to build qch files for qt5. I have rebuilt qttools with a missing dependency in order to have qdoc built. I can build qch files now but the problem is how to integrate this into the packages.
2020-10-14 16:57:49 <gzmorell> To build the qch files (make docs) must be called. Where should it be in the APKBUILD?
2020-10-14 16:58:51 <mps> gzmorell: in build() function
2020-10-14 16:59:50 <mps> what is qch
2020-10-14 17:00:18 <gzmorell> They are the help files for Qt libraries.
2020-10-14 17:00:40 <mps> thanks
2020-10-14 17:00:58 <gzmorell> They are not built and obviously not included in the qt5-*-doc packages.
2020-10-14 17:02:07 <mps> hmm, maybe something qt5-*-dev-doc
2020-10-14 17:04:38 <gzmorell> They are missing in all kind of qt packages. In fact qdoc which is the tool to make this files is missing also due to a dependency not included in qt5-qttools
2020-10-14 17:05:06 <gzmorell> It needs clang-dev which is not installed.
2020-10-14 17:06:59 <mps> hmm, hmm, I'm not good with qt, someone else should give guidance
2020-10-14 17:08:46 <gzmorell> To complete the installation 'make install INSTALL_ROOT="subpkgdir" install_docs' should be executed. Is it possible to use it under doc() ?
2020-10-14 17:09:23 <gzmorell> I have tried and there are multiple errors with wrong file paths
2020-10-14 17:09:34 <mps> usually these things goes in package()
2020-10-14 17:09:53 <gzmorell> The problem is that this is documentation
2020-10-14 17:10:29 <mps> package() is where all install goes, later it can be moved/split in subpkg functions
2020-10-14 17:10:45 <gzmorell> I have looked at archlinux, they have a different package for all qt docs (qt5-doc) which includes all the documentation.
2020-10-14 17:11:16 <gzmorell> Ok, I understand. Thans.
2020-10-14 17:11:32 <mps> well, we don't copy arch linux build process
2020-10-14 17:12:26 <mps> though it can look similar (even same) at first glances
2020-10-14 17:12:31 <gzmorell> Yes I know. But I was trying to figure out what was wrong. Having docs in multiple files is better, you install what you need.
2020-10-14 17:12:51 <mps> right
2020-10-14 17:13:28 <mps> alpine tries to keep minimal dependencies, I hope at least
2020-10-14 17:57:22 <ncopa> whats wrong with thunderbird? 3.0G    pkg/thunderbird/usr/lib/thunderbird/libxul.so
2020-10-14 17:57:32 <ncopa> its 3 gigabyte!
2020-10-14 17:58:25 <ncopa> oh, its not stripped
2020-10-14 17:59:33 <ncopa> stripping it makes it go down to 116MB
2020-10-14 18:06:52 <Hello71> javascript
2020-10-14 18:49:19 <Ariadne> ncopa: i can see why build-3-12-mips64 didn't show up
2020-10-14 19:17:41 <ikke> ncopa: thunderbird is still failing on ppc64le, something with gkrust not being able to compile
2020-10-14 19:28:12 <mps> ikke: not only ppc64le
2020-10-14 19:46:41 <ikke> right
2020-10-14 19:54:06 <mps> /usr/bin/abuild: line 308: can't create /home/buildozer/aports/testing/thunderbird/pkg/thunderbird/usr/bin/thunderbird: nonexistent directory
2020-10-15 06:24:25 <mps> https://lwn.net/Articles/834297/
2020-10-15 06:24:52 <mps> BleedingTooth: critical kernel Bluetooth vulnerability
2020-10-15 06:25:07 <mps> good morning
2020-10-15 06:30:30 <ncopa> good morning
2020-10-15 06:31:10 <ncopa> does the 5.4.71 release have a fix for it?
2020-10-15 06:31:52 <mps> I think no one release have it yet
2020-10-15 06:32:50 <mps> we have to wait for GKH what he will or say today
2020-10-15 06:33:14 <mps> else, pick fix from Linus tree
2020-10-15 06:34:29 <mps> hmm, 'he will do'*
2020-10-15 07:01:14 <ikke> Just came here for that
2020-10-15 07:04:06 <ikke> https://twitter.com/mjg59/status/1316484882877435904
2020-10-15 07:05:30 <ikke> https://t.co/B5G5Oxrnr5?amp=1
2020-10-15 07:05:39 <ikke> Actual link: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00435.html
2020-10-15 07:06:33 <mps> no worries, there are a lot more bugs waiting to be disclosed at 'right time' :)
2020-10-15 07:07:11 <ikke> heh
2020-10-15 07:07:32 <mps> I disabled bluetooth five (or more) years on all of my devices
2020-10-15 07:07:48 <ikke> I regularly use BT
2020-10-15 07:08:06 <mps> to much risky, imo
2020-10-15 07:08:11 <mps> too*
2020-10-15 07:09:12 <mps> especially nowadays with these insanity of proximity detection of potentially ill peoples around :)
2020-10-15 07:09:20 <ikke> heh
2020-10-15 07:10:16 <mps> (all people around me have illness and I, mental though :D )
2020-10-15 07:35:35 <ikke> seems thunderbird is just failing on ppc64le still
2020-10-15 08:04:56 <Newbyte> Is there any way to try installing my APKBUILD after building it locally without making an entire repo via buildrepo?
2020-10-15 08:06:07 <maxice8> apk add --allow-untrusted /path/to/pkg.apk
2020-10-15 08:09:23 <ikke> Newbyte: note that abuild -r already creates a valid repository that you can install packages from in ~/packages
2020-10-15 08:11:16 <Newbyte> aha, thank you both!
2020-10-15 09:51:55 <qiu3344> Hi, why is libreoffice on edge gone?
2020-10-15 09:52:20 <ikke> Issues compiling it
2020-10-15 09:52:23 <ikke> with gcc10
2020-10-15 09:52:58 <ikke> it's temporarily disabled until that's fixed
2020-10-15 09:53:48 <qiu3344> I see, but is there any reason we can't use clang?
2020-10-15 09:54:09 <ikke> qiu3344: no idea
2020-10-15 09:54:22 <qiu3344> I saw that someone commited a APKBUILD that does that, but it was reverted
2020-10-15 09:55:04 <ikke> 936fe57fb693f3647b3be9dad3b50c8d8e181871
2020-10-15 09:55:15 <ikke> "fails to pass ./configure on builders"
2020-10-15 09:55:37 <Ariadne> just build libreoffice with -fno-common
2020-10-15 09:55:42 <Ariadne> or -fcommon
2020-10-15 09:55:43 <Ariadne> i guess
2020-10-15 09:56:14 <Cogitri> I don't think it's due to fcommon
2020-10-15 09:56:26 <ikke> 'undefined reference to `non-virtual thunk to cppu::WeakImplHelper<com::sun::star::io::XInputStream>::acquire()'
2020-10-15 09:56:31 <ikke> from the commit message
2020-10-15 11:51:11 <maxice8> py3-loky has such flaky tests
2020-10-15 11:53:23 <ikke> confusing: py3-loky and py3-loki :)
2020-10-15 11:53:54 <maxice8> loki was removed
2020-10-15 11:54:36 <ikke> es
2020-10-15 11:54:38 <ikke> yes
2020-10-15 11:55:26 <ikke> if you read quickly, it looked like you added a package, and then immediately removed it again
2020-10-15 13:51:58 <minimal> Ariadne: now that I've battered cloud-init into handling WOL I see that ifupdown-ng isn't handling it. Is this just because the ethtool executor script isn't part of the package?
2020-10-15 13:52:54 <Ariadne> which ifupdown-ng
2020-10-15 13:53:07 <Ariadne> I think ethtool is part of 0.10 which I haven't shipped yet
2020-10-15 13:53:52 <minimal> 0.9.1-r0 as that's what's in Edge
2020-10-15 13:58:56 <minimal> Ariadne: so if I build a local copy do I add "ethtool" to _executor_stubs in APKBUILD?
2020-10-15 13:59:35 <Ariadne> no
2020-10-15 13:59:44 <Ariadne> it's not in 0.9
2020-10-15 13:59:54 <Ariadne> just wait until tonight please :)
2020-10-15 14:00:08 <minimal> ok. Thanks
2020-10-15 14:02:48 <ncopa> cool! mips64 builder is building 104% of expected builds :)
2020-10-15 14:03:00 <ncopa> https://build.alpinelinux.org/
2020-10-15 14:38:28 <telmich> You can keep the 4 addition percent for when it fails at a later time to round up to 100%...
2020-10-15 16:48:05 <mps> maxice8: is the ok to be merged !13071
2020-10-15 17:13:39 <mps> hmm, looks like kernel 5.9 have fixes for BleedingTooth
2020-10-15 17:14:27 <Cogitri> I think Intel claimed that it's fixed in 5.9 when it's actually not?
2020-10-15 17:14:50 <mps> not sure, need some time to investigate
2020-10-15 17:15:01 <mps> any help will be welcomed
2020-10-15 17:15:29 <mps> actually I upgraded linux-edge for armv7 and tested it locally
2020-10-15 17:15:52 <mps> on monday
2020-10-15 17:16:46 <mps> https://lwn.net/Articles/834418/
2020-10-15 17:17:07 <mps> about fedora 5.9
2020-10-15 17:18:20 <mps> and 'everal flaws in the BlueZ kernel Bluetooth stack prior to Linux 5.9 are being reported....' at https://lwn.net/Articles/834297/
2020-10-15 17:18:29 <mps> Several*
2020-10-15 17:18:37 <mps> copy-paste :)
2020-10-16 00:53:34 <maxice8> new atools :D
2020-10-16 00:53:50 <maxice8> fixes problems with dealing with multiple -DCMAKE_BUILD_TYPE= declarations
2020-10-16 01:02:18 <maxice8> cargo and libgit2 problems again
2020-10-16 01:32:08 <maxice8> algitbot: retry master
2020-10-16 06:39:35 <mps> hmm, intel changed announce about BleedingTooth, https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00435.html
2020-10-16 06:40:16 <mps> we can take patches or wait for fixed releases
2020-10-16 06:40:55 <Cogitri> > Affected Products: All Linux kernel versions that support BlueZ.
2020-10-16 06:40:57 <Cogitri> Yikes
2020-10-16 06:41:59 <mps> 'All Linux kernel versions before 5.10 that support BlueZ.'
2020-10-16 06:43:56 <mps> but as I read around android is more safe because they use somewhat changed bluez stack
2020-10-16 08:31:51 <Newbyte> trying to make testing/love build again but after changing the source URL, right after it tells me it's unpacking the archive, it tells me the following: /usr/bin/abuild: line 20: automatic: not found
2020-10-16 08:31:59 <Newbyte> automagic*
2020-10-16 08:32:03 <Newbyte> what might that be about?
2020-10-16 08:34:05 <ikke> in the prepare function: "platform/unix/automagic"
2020-10-16 08:38:00 <ncopa> um. we have aproblem with mips64 builder for 3.12...
2020-10-16 08:38:12 <Newbyte> as in, the prepare function in the APKBUILD?
2020-10-16 08:38:58 <Newbyte> I don't find any occurrences of automagic in it
2020-10-16 08:45:16 <maxice8> ansible package has been remade for 2.10.x
2020-10-16 08:45:27 <ikke> Newbyte: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/testing/love/APKBUILD#L20
2020-10-16 08:46:30 <mps> 'love', what a strange name for package
2020-10-16 08:47:31 <ikke> The official name is LÖVE
2020-10-16 08:47:59 <Newbyte> turns out I was looking in the wrong file somehow, thanks
2020-10-16 08:48:12 <Newbyte> not sure I'd say "LÖVE" makes more sense
2020-10-16 08:49:37 <mps> names should have meaning ("nomen est omen")
2020-10-16 08:49:52 <ikke> What does alpine mean? :P
2020-10-16 08:50:21 <mps> highest in Europe
2020-10-16 08:50:52 <mps> though it is not true, Elbrus is higher than Mont Blanc
2020-10-16 08:51:39 <maxice8> Can Ansible alpine users check !13626 ?
2020-10-16 08:51:45 <mps> so 'Alpine Linux' is 'top linux in europe/
2020-10-16 08:52:01 <mps> s/\/\/
2020-10-16 08:52:12 <mps> s/\/\'/
2020-10-16 08:52:52 <mps> s/\//\'/
2020-10-16 08:52:52 <alpine-meetbot> mps meant to say: so 'Alpine Linux' is 'top linux in europe\'
2020-10-16 08:53:05 <mps> meh :)
2020-10-16 08:55:44 <mps> ikke: if you want to see what alpine means go to alpinelinux.org and see :)
2020-10-16 09:00:06 <Ticho> "top" as in wordplay for the alps being the tallest mountain range in europe? :)
2020-10-16 09:00:44 <Ticho> eh, nevermind, I just read the backlog
2020-10-16 09:02:05 <mps> it is Elbrus at the top of Europe
2020-10-16 09:03:04 <mps> and there is CPU named elbrus
2020-10-16 09:32:31 <Newbyte> What commit message should I put if I've just made a package build again?
2020-10-16 09:32:40 <Newbyte> no version bump or other changes
2020-10-16 09:33:22 <mps> fedora backported BleedingTooth patches https://www.linuxcompatible.org/story/fedora-31-update-kernel5815101fc31/
2020-10-16 09:35:12 <ikke> Newbyte: testing/love: fix build issues
2020-10-16 09:35:15 <ikke> or something like that
2020-10-16 09:35:24 <Ariadne> [02:37:59] <ncopa> um. we have aproblem with mips64 builder for 3.12...
2020-10-16 09:35:25 <Newbyte> thank you
2020-10-16 09:35:28 <Ariadne> what is the problem ?
2020-10-16 09:53:48 <Newbyte> Recent versions of Telegram Desktop need some undocumented library called "tg_owt". I presume it's some functionality of the desktop app refactored into a library. Now, what I'm wondering is, should I let building this be part of building Telegram desktop, or make it its own package?
2020-10-16 09:53:58 <Newbyte> Latter seems more reasonable
2020-10-16 09:54:31 <ikke> Newbyte: if it's part of the same source, you could split it into a subpackage
2020-10-16 09:54:50 <Newbyte> it's in a different repo, so I presume that does not apply then
2020-10-16 09:54:51 <ikke> If you need to build it separately, then it makes sense to make a separate package for it
2020-10-16 09:54:55 <ikke> yea
2020-10-16 09:54:57 <Newbyte> all right, thanks
2020-10-16 09:55:17 <Newbyte> libtg-owt? does that sound like a reasonable name?
2020-10-16 10:01:29 <ncopa> Ariadne: the /etc/apk/repositories had 'edge' repos, so various packages was built with edge dependenceis. I have deleted some of them so they get rebuilt
2020-10-16 10:01:44 <Ariadne> oh ok
2020-10-16 10:01:55 <ncopa> and I have ofc updated the /etc/apk/repositories to only have local main repo
2020-10-16 10:05:47 <Newbyte> What does it take for a package to be put in community instead of testing?
2020-10-16 10:06:02 <Ariadne> asking
2020-10-16 10:06:03 <ikke> Newbyte: a merge request doing so
2020-10-16 10:06:18 <Newbyte> but they should always start out in testing?
2020-10-16 10:06:30 <Ariadne> generally
2020-10-16 10:06:51 <ikke> yes, though, when they are suddenly required as a dependency, exceptions can be made
2020-10-16 10:07:40 <Newbyte> dare I try getting this one (tg_owt, the new Telegram Desktop dependency) into community directly?
2020-10-16 10:08:42 <mps> let it first to pass build test on builders in testing and then move
2020-10-16 10:09:04 <Newbyte> I'll do just that
2020-10-16 10:12:17 <Newbyte> now that's fun, this tg_owt package doesn't even have releases
2020-10-16 10:13:05 <ikke> indeed, fun
2020-10-16 10:33:27 <mps> ncopa: c2e6ed4d625c7f1961f4c23b84bcbf83ed0f6303
2020-10-16 10:33:53 <mps> if you want to backport to -lts
2020-10-16 10:34:29 <mps> and didn't added last patch, not sure is it needed
2020-10-16 10:51:53 <maxice8> PureTryOut: made MRs for kdeconnect CVE !13676 !13677
2020-10-16 11:32:49 <mps> ncopa: here is patch for -lts bleedingtooth https://tpaste.us/49qr
2020-10-16 11:33:56 <mps> I'm not sure I can make this fixes for linux-rpi with genpatch()
2020-10-16 12:05:11 <minimal> Ariadne: Thanks for the ifupdown-ng update. Have run a quick test on a VM that works as expects (gives an error while trying to check wol which virtio-net doesn't support). Will test a physical machine later today. Question about the new ifupdown-ng-openrc package's "Replaces: openrc", does this mean that future updates to openrc will not modify any (packaged) files or modify all but the 2 files in ifupdown-ng-openrc?
2020-10-16 12:28:00 <mps> any trick to have 'depends=pkg-a || pkg-b' (or dependencies)
2020-10-16 12:29:27 <ikke> only by using provides
2020-10-16 12:30:01 <ikke> afaik
2020-10-16 12:30:13 <mps> which means no
2020-10-16 13:33:54 <Ariadne> minimal: correct.  ifupdown-ng version will be preferred for those 2 files
2020-10-16 13:38:17 <minimal> Ariadna: cool, didn't know "Replaces" worked that way, thought it took over everything owned by the named package. Hmm, I can see some kludgy (ab)uses for Replaces - apk doesn't currently provide a way to remove and keep specific files removed (like Debian dpkg's exclude/include functionality), until it does could maybe abuse "Replaces" to create a local package to kludge that
2020-10-16 13:41:15 <minimal> e.g. currently for Alpine hardened machines I might want to prevent isofs kernel modules being used, currently I'd do so using a file in /etc/modprobe.d/ to "map" that module to /bin/true so a modprobe won't actually load it. With hardened Debian currently I can delete the actual kernel module file and create a dpkg config file that will prevent any future kernel package updates from ever reinstalling the file.
2020-10-16 14:29:55 <maxice8> Ariadne: merged the s6 MR
2020-10-16 16:23:41 <maxice8> @PureTryOut: ping
2020-10-16 17:03:25 <midasi> hello, when is the next release 3.12.1 planned?
2020-10-16 17:15:19 <ikke> midasi: soon (tm)
2020-10-16 17:20:42 <midasi> how soon? days or weeks?
2020-10-16 17:23:39 <ikke> I suspect next week or the week after
2020-10-16 17:23:46 <midasi> ok, great!
2020-10-16 17:28:50 <mps> do we need 'Virtual Box Guest PCI device' driver in kernel?
2020-10-16 19:59:21 <CoolITKitty> Hi
2020-10-16 20:02:32 <CoolITKitty> quick question, maybe someone has some pointers; we're trying to use an IO board and we're connected the SC16IS752 to SPI0 instead of SP1; Alpine Linux doesn't include the SPI0 variant of the device and copying the overlay from the stock Raspbian image does not work, Alpine reports that SPI0 is already in use?
2020-10-16 20:05:32 <mps> raspberi pi?
2020-10-16 20:09:21 <CoolITKitty> yes, my appologies
2020-10-16 20:10:08 <mps> what board?
2020-10-16 20:10:22 <CoolITKitty> ah it's our own in-house IO board
2020-10-16 20:10:38 <mps> I mean what RPi board, sorry
2020-10-16 20:10:43 <CoolITKitty> oh :)
2020-10-16 20:10:58 <CoolITKitty> Pi2
2020-10-16 20:11:28 <mps> uhm, I don't have this board to check
2020-10-16 20:12:45 <mps> you could ask on #alpine-linux also, maybe someone there have this board and can help
2020-10-16 20:12:51 <CoolITKitty> I think the "new" Pi2 and Pi3 have the same CPU?
2020-10-16 20:13:04 <ikke> CoolITKitty: I've heard similar things
2020-10-16 20:16:46 <CoolITKitty> done
2020-10-16 20:17:19 <CoolITKitty> if the SPI0 is being used by the kernel, then an option for us is to respin the board using SPI1
2020-10-16 20:18:18 <CoolITKitty> if it is not, then it's a problem with simply having the right dtbo and maybe I should build that from source instead of copying it from Rasbian?
2020-10-16 20:19:53 <mps> if spi0 is used then yes
2020-10-16 20:21:04 <mps> you can install spi-tools and check
2020-10-16 20:23:53 <CoolITKitty> hmm, spi-tools is not listed
2020-10-16 20:24:25 <mps> in community repo
2020-10-16 20:24:49 <mps> ohm, it is edge not stable
2020-10-16 20:26:08 <CoolITKitty> got it
2020-10-16 20:31:57 <mps> heh, just noticed that 'apk add --allow-unt' works
2020-10-16 20:49:54 <ikke> Looks like we don't even have issues yet for CVE-2020-12351 CVE-2020-12352 CVE-2020-24490
2020-10-16 20:58:01 <mps> I thought about that but didn't raise it because we don't keep CVE records in kernels
2020-10-16 21:02:55 <ikke> Good to keep a track record of it
2020-10-16 21:02:58 <ikke> though
2020-10-16 21:03:56 <mps> you mean bug/issues reports
2020-10-16 21:04:11 <ikke> yes
2020-10-16 21:04:19 <ikke> I'm making a ticket ftr
2020-10-16 21:04:52 <mps> good
2020-10-16 21:07:08 <mps> hmm, I have to add 'fixes: #numbers' to commit
2020-10-16 21:08:21 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12023
2020-10-16 21:08:50 <ikke> Well, for these kinds of issues affecting multiple branches, you don't want to 'fix' it, which will close the issue
2020-10-16 21:09:51 <mps> yes, I see
2020-10-16 21:10:14 <mps> they have to closed manually after all branches 'fixed'?
2020-10-16 21:10:15 <ikke> You can still refer to the issue, but not 'fixes' or 'closes'
2020-10-16 21:10:49 <mps> actually I put CVE numbers in git commit
2020-10-16 21:11:05 <mps> c2e6ed4d625c7f1961f4c23b84bcbf83ed0f6303
2020-10-16 21:15:21 <mps> I applied patches on linux-lts and linux-edge, applies cleanly on both and builds fine
2020-10-16 21:44:54 <CoolITKitty> would it be too much to ask for a kernel option to not have it use SPI0?
2020-10-16 21:45:31 <CoolITKitty> spidev0.0 doesn't even show in the /dev folder so spi-tools won't touch it
2020-10-16 22:08:42 <mps> CoolITKitty: what option should be changed
2020-10-17 06:45:44 <mps> soon we will have https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.9.y&id=213f323329f1567e09f85ddb54cfb80769340b50
2020-10-17 06:46:19 <mps> linux 5.9.1 release with bleedingtooth fixed
2020-10-17 06:49:47 <mps> actually it is released but not yet announced
2020-10-17 08:36:40 <mps> we have kernel 4.19.x in some previous and supported releases. do we have 4.14.x in some of supported releases?
2020-10-17 09:47:43 <ikke> 3.9 has 4.19, and 3.9 is the oldest supported version
2020-10-17 09:51:42 <mps> aha, thanks
2020-10-17 09:53:05 <ikke> 3.8 has 4.14.x
2020-10-17 09:53:44 <mps> there are these third party kernel modules in separate pkgs, not sure should I start upgrading -lts
2020-10-17 09:54:15 <mps> maybe ncopa already working on them
2020-10-17 09:54:19 <ikke> ncopa has a script to update them all at the same time
2020-10-17 09:54:47 <mps> that would be nice to have
2020-10-17 09:55:21 <mps> for now I could do this just manually
2020-10-17 09:57:16 <ikke> https://tpaste.us/axMq
2020-10-17 09:58:12 <mps> yes, already looked at aports
2020-10-17 09:59:04 <mps> -rpi is showstopper for me now
2020-10-17 11:51:48 <mps> ikke: with kernel 5.9 and we will not need community/rtl8821ce-lts, community/wireguard-lts and some other pkgs
2020-10-17 11:51:57 <mps> and up*
2020-10-17 11:52:17 <ikke> mps: fine with me
2020-10-17 11:52:28 <mps> and community/virtualbox-guest-modules-lts also
2020-10-17 11:52:47 <ikke> we might want to add replaces=".." to linux-lts for those modules
2020-10-17 11:53:20 <mps> sure, when new -lts is declared
2020-10-17 13:43:02 <Silver40> Hi, i would like to get some help/pointer what i'm doing wrong. I'm trying to build a package, i have everything set up, hopefully, but i'm getting error on building. ERROR: No such package: .makedepends-mypackage. I wasn't able to find from google how to solve it.
2020-10-17 13:43:12 <Silver40> I also posted it to stackexchange
2020-10-17 13:43:13 <Silver40> https://unix.stackexchange.com/questions/614957/creating-an-alpine-package
2020-10-17 13:45:12 <ikke> Silver40: most likely it failed to install the dependencies in the first place
2020-10-17 13:46:51 <ikke> Silver40: can you paste the output of abuild -r somewhere?
2020-10-17 13:47:23 <Silver40> Sure, one sec
2020-10-17 13:47:58 <Silver40> https://pastebin.com/qLpYHeUA
2020-10-17 13:48:45 <ikke> run apk fix
2020-10-17 13:51:17 <Silver40> It shows that i have 1 error
2020-10-17 13:51:29 <Silver40> 1 error; 3124 MiB in 695 packages
2020-10-17 13:51:36 <ikke> It should report something before that
2020-10-17 13:52:20 <Silver40> (1/1) [APK unavailable, skipped] Reinstalling ttf-opensans (1.10-r0)
2020-10-17 13:53:15 <Silver40> chromium depends on that. Unable to remove
2020-10-17 13:54:11 <ikke> Do you have community available in /etc/apk/repositories?
2020-10-17 13:54:55 <Silver40> I removed chromium also. That part should be OK for now.
2020-10-17 13:55:57 <Silver40> Ok, now it did something more but still ends with an error
2020-10-17 13:55:58 <Silver40> https://pastebin.com/s9GdUgcS
2020-10-17 13:56:43 <ikke> Can you share your APKBUILD?
2020-10-17 13:57:13 <Silver40> Oh, looks like i got it. It's building now from source.
2020-10-17 13:57:20 <ikke> ok
2020-10-17 13:57:33 <Silver40> Thanks for quick help :)
2020-10-17 13:57:48 <ikke> no problem
2020-10-17 14:34:27 <Silver40> Ok, it compiles nicely, but at the end it still fails with >>> ERROR: libdigidoc*: package failed and >>> ERROR: libdigidoc: rootpkg failed. Any hints there ikke?
2020-10-17 14:35:45 <ikke> Look at the output before that
2020-10-17 14:35:58 <ikke> sometihng in the package stage is failing
2020-10-17 14:41:25 <Silver40> Few warnings for project developers but everything else seems to be OK. No errors etc. Builds and installs under pkg dir.
2020-10-17 14:47:37 <ikke> Something is returning an exit code >0
2020-10-17 14:49:03 <Silver40> I'll try to build with -v
2020-10-17 14:57:12 <mps> I'm working on split-out gvim from vim and move/create gvim pkg in community. by this one less in dependency on gtk in main
2020-10-17 14:57:24 <mps> any objections?
2020-10-17 14:58:12 <ikke> apart from the usual maintenance objects, no
2020-10-17 14:59:18 <mps> yes, but we have to pay toll somewhere
2020-10-17 14:59:30 <ikke> s/objections/
2020-10-17 14:59:50 <ikke> yea, understood
2020-10-17 15:01:35 <mps> gtk+2.0 could be moved right now. maybe?
2020-10-17 15:04:06 <mps> also, dconf? should it be in main?
2020-10-17 15:04:39 <ikke> seems like nothing depends on gtk+2.0 anymore
2020-10-17 15:04:42 <ikke> in mian
2020-10-17 15:06:04 <mps> yes, except two, gnokii and obex-data-server depends on gtk+-dev vritual pkg
2020-10-17 15:06:32 <ikke> ah
2020-10-17 15:06:41 <mps> not sure could they be built with gtk+3.0
2020-10-17 15:07:00 <ikke> Me neither
2020-10-17 15:07:12 <mps> though also not sure could they be moved to community
2020-10-17 15:07:41 <mps> or removed from repo. who uses them nowadays
2020-10-17 15:08:30 <ikke> gnokii sounds like something that not needs to live in main
2020-10-17 15:09:46 <mps> yes, nothing depends on it in main
2020-10-17 15:11:09 <mps> ok, we should ask maintainer on monday
2020-10-17 15:12:04 <mps> also, for gvim move/split
2020-10-17 15:41:52 <Silver40> Another build issue: Found uncompressed man pages:
2020-10-17 15:41:52 <Silver40> 	/usr/share/man/man1/cdigidoc.1
2020-10-17 15:42:29 <ikke> I guess you should compress them, then
2020-10-17 15:43:10 <afontain_> I've heard doc() autocompresses them
2020-10-17 15:43:18 <Silver40> Ok it's a cmake thing then ..
2020-10-17 15:43:35 <afontain_> is subpkgs="$pkgname-doc" present?
2020-10-17 15:43:37 <Cogitri> Yup, adding a -doc subpkg should do the trick
2020-10-17 15:44:12 <ikke> right: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L1782
2020-10-17 15:44:19 <Cogitri> mps: dconf should probably remain in main, you need it for permanent settings in about any GLib application
2020-10-17 15:44:43 <Cogitri> Otherwise you glib uses the memory backend for settings, so everything set is only temporary
2020-10-17 15:44:57 <Silver40> Yeah, that did the trick!
2020-10-17 15:48:46 <Silver40> Next error: ERROR: /usr/local/lib64/libdigidoc.so...: Could not find owner package
2020-10-17 15:49:03 <Silver40> But i have in build section cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ..
2020-10-17 15:57:16 <afontain_> there's also lib64
2020-10-17 15:57:36 <afontain_> it could have something to do with --prefix?
2020-10-17 16:01:36 <Silver40> lib64 is under /usr
2020-10-17 16:02:17 <Silver40> As i understand, nothing can't be installed under /usr/local, /opt etc
2020-10-17 16:02:24 <ikke> corret
2020-10-17 16:02:34 <Silver40> By default, this software tries to install itself under /usr/local
2020-10-17 16:02:53 <Silver40> That's why i changed prexif.
2020-10-17 16:03:38 <mps> Cogitri: so no chances to move gtk from main
2020-10-17 16:15:03 <mps> hmm, `ap revdep dconf' in main doesn't show anything
2020-10-17 16:20:06 <Cogitri> mps: Yes, it's only a weak dep
2020-10-17 16:20:18 <Cogitri> i.e. users have to install it or their stuff is broken but at least we have minimal deps :)
2020-10-17 16:20:59 <mps> I don't have it and everything is fine
2020-10-17 16:21:14 <Cogitri> Actually not sure why dconf depends on gtk3, that seems wrong
2020-10-17 16:21:26 <Cogitri> Doesn't seem like it actually needs it
2020-10-17 16:21:28 <Cogitri> 
ACTION removes the dep

2020-10-17 16:22:01 <Cogitri> Oh, seems like I introduced that makedep, whoops :D
2020-10-17 16:22:08 <Cogitri> 1a0103dda978655bb1480be3869e4bdc4dd07a30
2020-10-17 16:22:10 <mps> :)
2020-10-17 16:22:26 <ikke> blame self
2020-10-17 16:23:19 <Cogitri> 3b18e9f85576cfec0fdca33003a9a639e650b3ab there we go
2020-10-17 16:24:15 <Cogitri> Oof, the one time I push directly from master I didn't switch branch before and had another commit on master that wasn't supposed to land yet
2020-10-17 16:24:30 <ikke> ouch
2020-10-17 16:26:21 <Cogitri> Well, at least it only is a upgrade of mellowplayer to git that I had around to test it on CI, so won't break anyone's system
2020-10-17 16:50:35 <Silver40> Any hints how to solve package build error? ERROR: /usr/local/lib64/libdigidoc.so...: Could not find owner package
2020-10-17 16:51:52 <mps> build system (cmake) need to be fixed
2020-10-17 16:52:46 <Silver40> It's like a bug in cmake or i should do something differently?
2020-10-17 16:53:14 <mps> no cmake itself, but package cmake files
2020-10-17 16:54:44 <Silver40> No, at this point i can't do nothing?
2020-10-17 16:54:50 <Silver40> So*
2020-10-17 16:55:19 <artok> what is the package you're trying to build?
2020-10-17 16:55:59 <ikke> libcdigidoc
2020-10-17 16:56:40 <Silver40> Dependency package for Smart card software
2020-10-17 16:57:34 <Silver40> https://github.com/open-eid/libdigidoc
2020-10-17 16:59:50 <artok> geh, subprojected cmake modules
2020-10-17 17:03:23 <artok> forcing -DLIBDIGIDOC_LIBRARY -DLIBDIGIDOC_INCLUDE_DIR thingies might be something
2020-10-17 17:07:08 <artok> some people just don't know how to do cmake scripts
2020-10-17 17:07:57 <artok> "hey I created another wrapper macro!"
2020-10-17 17:08:45 <Cogitri> artok: You mean 5 layers of custom abstraction for every package in a build system aren't a good idea? :^)
2020-10-17 17:10:12 <artok> and you need to have always prefixed with some project acronym
2020-10-17 17:11:41 <Silver40> Tried with -DLIBDIGIDOC_LIBRARY=/usr/lib64 -DLIBDIGIDOC_INCLUDE_DIR=/usr/lib64 but no luck
2020-10-17 17:50:03 <Silver40> Ok, i found the culprit with ERROR: /usr/local/lib64/libdigidoc.so...: Could not find owner package
2020-10-17 17:50:09 <Silver40> That's me.
2020-10-17 17:51:02 <Silver40> I had this /usr/local/lib64/libdigidoc.so file in my system, because i was compiling before and made "make install"
2020-10-17 17:56:12 <Hello71> just because it installs doesn't mean it meets packaging standards
2020-10-17 17:57:03 <Silver40> I think it's true
2020-10-17 19:18:18 <mps> for some reason latest mutt-doc manual.txt is zero size on edge, same version built on 3.12-stable is ok
2020-10-17 19:47:33 <Silver40> Building a package i get: install: can't create '/usr/bin/xsd': Permission denied. If i understand correctly then, /srv, /usr/local or /opt is not permitted. Why i get permission denied in /usr/bin?
2020-10-17 19:47:47 <Silver40> Under package section i use: make install_prefix=/usr install
2020-10-17 19:47:49 <Hello71> you failed to specify DESTDIR
2020-10-17 19:48:05 <Silver40> I tried DESTDIR also
2020-10-17 19:48:14 <Hello71> destdir isn't the same as prefix
2020-10-17 19:48:58 <Silver40> So like this? make DESTDIR="$pkgdir/usr" install
2020-10-17 19:51:21 <ikke> DESTDIR=$pkgdir
2020-10-17 19:51:27 <ikke> prefix=/usr
2020-10-17 19:51:33 <ikke> You need both
2020-10-17 19:52:15 <Silver40> You can fine-tune the installation locations with the following make
2020-10-17 19:52:15 <Silver40> variables:
2020-10-17 19:52:16 <Silver40> install_prefix       default is /usr/local
2020-10-17 19:52:23 <Silver40> That's from documentation
2020-10-17 19:52:24 <ikke> that should be /usr
2020-10-17 19:52:34 <ikke> but there should also be something like a DESTDIR
2020-10-17 19:53:42 <ikke> maybe they conflate the 2
2020-10-17 19:53:55 <ikke> I assume it's this? https://www.codesynthesis.com/projects/xsd/extras/build-unix.xhtml
2020-10-17 19:54:02 <Silver40> yes
2020-10-17 19:55:49 <ikke> You can try install_prefix=$pkgdir/usr
2020-10-17 20:06:30 <Silver40> hmm
2020-10-17 20:06:38 <Silver40> got >>> xsd: Entering fakeroot...
2020-10-17 20:06:38 <Silver40> make: *** empty variable name.  Stop.
2020-10-17 20:07:46 <Silver40> Oh, extra space ..
2020-10-17 20:25:13 <Silver40> Using make install prefix="$pkgdir/usr" still gives errors like install: can't create '/usr/local/bin/xsd': Permission denied and install: can't create directory '/usr/local/include/': Permission denied (a lot of those)
2020-10-17 20:25:49 <ikke> it means it's not installing the file in $pkgdir, but tries to directly install it on your system
2020-10-17 20:27:36 <Silver40> So, that DESTDIR is required
2020-10-17 20:29:03 <Silver40> Btw, is there option to keep compiled files so that i don't have to build them every single run?
2020-10-17 20:29:16 <ikke> -K
2020-10-17 20:30:52 <ikke> Silver40: btw, it's install_prefix, not prefix
2020-10-17 20:31:56 <Silver40> I tried that also, it's from documentation. But maybe something else was wrong at that time.
2020-10-17 20:54:57 <Silver40> Ok, it works like this: make install_prefix=$pkgdir/usr install
2020-10-17 22:09:24 <Hello71> isn't this a cmake package
2020-10-17 22:09:29 <Hello71> is it just a broken cmake package
2020-10-18 07:11:48 <mps> ikke: goede morgen
2020-10-18 07:11:57 <ikke> morning
2020-10-18 07:12:51 <mps> sorry to annoy you you early in morning but how should look git msg for linux-lts related to #12023
2020-10-18 07:13:09 <mps> no 'fixes' or 'closes', but what
2020-10-18 07:13:26 <ikke> See #12023 works
2020-10-18 07:13:41 <mps> aha, ok. thanks
2020-10-18 07:14:00 <mps> 'see #12023'
2020-10-18 07:14:06 <ikke> yes
2020-10-18 07:14:13 <mps> :)
2020-10-18 07:51:31 <telmich> ikke mps ncopa do you think rdnssd could migrate to main soon? It would solve some problems for me
2020-10-18 08:00:01 <ikke> Ill make an MR and let others comment on it
2020-10-18 08:05:47 <mps> telmich: could you write mail to (bad) alpine-devel ML
2020-10-18 08:21:24 <telmich> mps: sure
2020-10-18 08:23:49 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/13738
2020-10-18 08:34:22 <telmich> https://lists.alpinelinux.org/~alpine/devel/%3C874kmsoruc.fsf%40ungleich.ch%3E
2020-10-18 08:36:42 <ikke> (y)
2020-10-18 08:44:47 <ikke> I do notice that rdnssd depends on sed
2020-10-18 08:46:05 <mps> not good
2020-10-18 08:46:21 <ikke> Yeah
2020-10-18 08:46:24 <mps> isnogood :)
2020-10-18 08:46:34 <ikke> bebc4234d6557e897fa01536d7032f2cd2a16e84
2020-10-18 08:46:54 <ikke> It's a merge-hook that uses regular expressions
2020-10-18 08:47:01 <ikke> so maybe we can work around it
2020-10-18 09:10:53 <ikke> maxice8: Would've been nice if 5ed0f177 would contain some context about why the change has been made
2020-10-18 09:15:22 <mps> !13740
2020-10-18 09:15:48 <mps> first time made such 'big' kernel change
2020-10-18 09:16:01 <mps> but skipped -rpi pkgs
2020-10-18 09:16:56 <mps> lets see what CI will say
2020-10-18 09:19:45 <ikke> mps: I think the reference to the ticket should be on a new line
2020-10-18 09:24:06 <mps> aha, ok
2020-10-18 09:26:56 <ikke> Currently the issue does not show the MR as related
2020-10-18 09:28:05 <mps> 'see: #12023' in new line is ok?
2020-10-18 09:29:55 <mps> how to do that? 'git commit -v --amend' will not work because there are commits after that one
2020-10-18 09:30:22 <ikke> git rebase -i master
2020-10-18 09:30:29 <ikke> then change pick to reword for that commit
2020-10-18 09:30:31 <mps> 'git rebase --interative'?
2020-10-18 09:30:34 <ikke> yes
2020-10-18 09:30:45 <mps> huh, git is not easy
2020-10-18 09:31:27 <ikke> the integrity part of git makes some operations a bit more complex
2020-10-18 09:31:48 <ikke> You cannot just randomly change commits in the middle of your history without affecting anything else
2020-10-18 09:31:53 <mps> but, 'show me the tool and will tell you all about master/craftsman
2020-10-18 09:32:49 <ikke> craftsmen use tools that are not necessarily easy to use
2020-10-18 09:33:02 <mps> I use 'git rebase --interactive' in other projects, hmm overuse ;)
2020-10-18 09:33:23 <artok> ...but they use tools that are made for the work they're doing
2020-10-18 09:34:06 <ikke> artok: is your point that git is not made for the work people are doing?
2020-10-18 09:34:35 <artok> no, just addition to the craftsmen analogue =)
2020-10-18 09:34:41 <ikke> ok
2020-10-18 09:34:48 <mps> yes, good explanation of relation tools and masters are Miyamoto Musashi in 'Five rings' book, 'gorin no shyo' (for japanese friends)
2020-10-18 09:34:56 <artok> when git has been really started for kernel source management...
2020-10-18 09:36:19 <ikke> And it's made for people who take version control serious, not just as a means to push code
2020-10-18 09:38:14 <ikke> svn was easier for people who just want the latter
2020-10-18 09:40:22 <artok> hence, binary files with svn
2020-10-18 09:40:48 <artok> on projects that need to have built dependencies as binary, that is
2020-10-18 09:40:56 <ikke> git handles binaries just as well, but because it's decentralized, everyone shares the pain, not just the server admin
2020-10-18 09:42:08 <ikke> One thing that git is just gaining that was easier with svn is partial checkouts
2020-10-18 09:44:05 <mps> ikke: does it looks ok now?
2020-10-18 09:45:15 <ikke> mm, no
2020-10-18 09:45:24 <mps> uh
2020-10-18 09:46:45 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12023
2020-10-18 09:47:08 <ikke> Not sure why
2020-10-18 09:48:06 <mps> aha
2020-10-18 09:48:39 <mps> 'see: #12023' is wrong for some reason
2020-10-18 09:48:53 <ikke> Usually it's done without colon
2020-10-18 09:48:53 <mps> ':' not needed?
2020-10-18 09:49:07 <mps> hm, lets try again
2020-10-18 09:52:21 <mps> hmmm, no luck again
2020-10-18 09:55:52 <ikke> :(
2020-10-18 09:56:17 <ikke> mmaybe because it's a confidential issue?
2020-10-18 09:56:31 <mps> could be
2020-10-18 09:56:33 <ikke> Not sure why that shoul dmatter though
2020-10-18 09:57:04 <mps> anyway, kernel usually doesn't go through gitlab MRs
2020-10-18 09:57:17 <ikke> correct, but it's not wrong to do :)
2020-10-18 09:58:42 <mps> and this issue report, it is not confidential
2020-10-18 09:59:13 <ikke> The reason we make them confidential is because we don't want the issue list to be a repository of unpatched issues
2020-10-18 09:59:28 <ikke> but on the other hand, it's nice if others can see the progress of these issues
2020-10-18 09:59:29 <mps> I mean, problem is known for few days
2020-10-18 10:00:11 <ikke> yes, that's the case for most CVE's we patch
2020-10-18 10:00:51 <mps> but, even if it is confidential added MR which references it should be shown in it
2020-10-18 10:01:58 <mps> (security theater must go)
2020-10-18 10:01:58 <ikke> yes
2020-10-18 10:49:11 <ikke> mps: seems like ncopa was already working on the kernel upgrade
2020-10-18 10:50:25 <ikke> mps: 3778c690
2020-10-18 10:50:39 <ikke> 3778c69066701e3289fe0eadbd22eaeab24bd32b
2020-10-18 10:57:29 <mps> i see
2020-10-18 10:57:47 <mps> that was an exercise for me
2020-10-18 10:58:35 <mps> to see can I do that if ncopa was busy or offline for some time and important things happens
2020-10-18 10:59:45 <mps> if I intended to upgrade I would push it and not create MR
2020-10-18 13:39:21 <nmeum> I think we are really starting to overuse subpackages, why does a simple text editor like vim have 6 subpackages nowadays? :S
2020-10-18 13:46:44 <tehcloud> what's a simple text editor?
2020-10-18 13:47:25 <ikke> I guess hey mean vim
2020-10-18 13:47:31 <u0jQx9gPyrYg> ed(1)
2020-10-18 13:47:32 <nmeum> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/13672#note_119421
2020-10-18 13:48:18 <nmeum> with vim tutor the trade-off is even worse
2020-10-18 13:49:20 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests?scope=all&utf8=%E2%9C%93&state=all&search=main%2Fvim+split
2020-10-18 13:49:41 <nmeum> yeah, i know
2020-10-18 13:50:14 <ikke> Just for others
2020-10-18 13:52:41 <Cogitri> Yeah, I think the main problem is users not knowing about those subpkgs
2020-10-18 13:53:01 <nmeum> yep
2020-10-18 13:53:30 <nmeum> but given that file locations may change et cetera you also need to make sure to keep the split functions up to date
2020-10-18 13:59:09 <mps> nmeum: how big in size vim before split
2020-10-18 13:59:29 <mps> how big is xxd and vimdiff
2020-10-18 14:00:11 <nmeum> 28 MiB, i think
2020-10-18 14:00:20 <mps> right, about
2020-10-18 14:00:20 <nmeum> xxd can be use independendly of vim
2020-10-18 14:00:26 <nmeum> vimdiff maybe too, idk
2020-10-18 14:01:06 <mps> vimdiff depend on vim
2020-10-18 14:01:11 <mps> also xxd
2020-10-18 14:01:25 <nmeum> the argument for splitting xxd is: you might want xxd but not vim, thus installing a 28 MiB vim package might be considered overkill
2020-10-18 14:01:46 <nmeum> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/1153#note_54634
2020-10-18 14:01:56 <mps> sorry, xxd doesn't
2020-10-18 14:02:34 <nmeum> well, I don't really like the vimdiff split either tbh
2020-10-18 14:03:16 <nmeum> maybe a coherent policy on when subpackages should be used and when they shouldn't would be nice?
2020-10-18 14:04:08 <nmeum> the syntax and help split in particular will imho really confuse users
2020-10-18 14:04:18 <mps> well, understand. and I plan at the end of splitting vim to add vim-full metapackage
2020-10-18 14:04:51 <mps> or, vim-small and vim as full pkg
2020-10-18 14:09:27 <nmeum> I wouldn't mind if we had a vim-tiny subpackages like debian does which compiles vim with --with-features=tiny, i think that's the way to go for a small vim package
2020-10-18 14:12:00 <mps> vim-tiny as debian have is not needed for alpine, busybox vim is enough
2020-10-18 14:12:12 <mps> BB vi*
2020-10-19 08:05:42 <ikke> PureTryOut[m]: there are a few kde related packages that are failing on different arches, would you be able to take a look at it?
2020-10-19 10:21:27 <ncopa> -ash: ./kdeconnect/APKBUILD: line 41: syntax error: unexpected redirection
2020-10-19 10:21:34 <ncopa> in 3.12-stable
2020-10-19 10:22:50 <ikke> merge conflict committed
2020-10-19 10:23:27 <ikke> 575d05f370915ded4053169bfe03c476b7536e27
2020-10-19 10:24:16 <ncopa> fixed
2020-10-19 10:30:19 <ncopa> ugh.. kdeconnect is broken on all arches apparently :-(
2020-10-19 10:30:54 <ncopa> so no 3.12.1 release today either :-(
2020-10-19 10:31:25 <artok> party pooper
2020-10-19 10:34:20 <ncopa> i think 575d05f370915ded4053169bfe03c476b7536e27 is wrong. we cannot do updates like that  in stable branch
2020-10-19 10:34:48 <ncopa> i think we need a kdeconnect 20.04.x
2020-10-19 10:34:56 <ncopa> or backport a fix for that cve
2020-10-19 10:42:59 <ikke> ncopa: btw, keeping https://gitlab.alpinelinux.org/alpine/aports/-/issues/12023 up-to-date. Both edge and 3.12-stable should've been fixed now, correct?
2020-10-19 10:48:55 <ncopa> i believe so, but I havent verified that 5.4.72 fixes it
2020-10-19 10:50:56 <ncopa> looks like its possible to backport the 10 patches for kdeconnect, they apply to 20.04.x and it builds. but the tests fails :-/
2020-10-19 10:52:11 <ikke> The changelog for .72 mentions fixes for bluetooth
2020-10-19 10:52:17 <ikke> https://lwn.net/Articles/834537/
2020-10-19 10:53:23 <mps> re #12023 fixes are bacported to all longterm kernels
2020-10-19 10:55:26 <mps> ncopa: btw, do you have some script/s to upgrade kernels and depending pkgs
2020-10-19 10:56:32 <mps> would be nice to post it to me, to not 'reinvent the wheel'
2020-10-19 10:56:49 <mps> when you find time, ofc
2020-10-19 11:01:31 <ncopa> i normally do something like: abump linux-lts-5.4.72 && sh ../abump-kmods main/linux-lts && testboot.sh
2020-10-19 11:01:59 <ncopa> $ tpaste < ../abump-kmods
2020-10-19 11:02:00 <ncopa> https://tpaste.us/5VY0
2020-10-19 11:02:34 <ncopa> $ tpaste < testboot.sh
2020-10-19 11:02:34 <ncopa> https://tpaste.us/vZ7L
2020-10-19 11:05:31 <mps> thanks. looking at them
2020-10-19 11:20:04 <ikke> Hmm, seems like the rdnssd ipv6 matching regexp has a bug
2020-10-19 11:20:10 <ikke> {,1} is not valid
2020-10-19 11:22:05 <ikke> But apparently the real sed allows that
2020-10-19 11:22:17 <ikke> Or at least, does not report an error
2020-10-19 11:46:00 <mps> does \{,\1\} work
2020-10-19 11:48:11 <ikke> {0,1} works
2020-10-19 11:48:26 <mps> aha
2020-10-19 11:57:44 <artok> well there is an easy patch
2020-10-19 11:58:42 <ikke> yup
2020-10-19 11:59:00 <ikke> I already have the patch, just need to test and commit it
2020-10-19 12:57:27 <mps> is there trick for abuild to build pkg for other arch, on armv7 for armhf
2020-10-19 12:57:46 <ikke> I don't think so
2020-10-19 12:58:10 <ikke> You'd need a separate chroot for that
2020-10-19 12:58:38 <mps> hmm, chroot don't work in develepors lxc
2020-10-19 12:58:45 <ikke> so rootbld could do it
2020-10-19 12:58:48 <ikke> yeah
2020-10-19 12:58:49 <ikke> that's the issue
2020-10-19 12:58:53 <ikke> seem with rootbld
2020-10-19 12:59:07 <ikke> ncopa did manage to get docker to work in lxc
2020-10-19 12:59:21 <ikke> but not sure it that required extra privileges
2020-10-19 12:59:51 <mps> ok, I will try with my local disk in armhf lxc
2020-10-19 13:00:32 <mps> it will take time with disk on usb
2020-10-19 13:01:43 <Ariadne> i've been using dabuild to cross-compile lately
2020-10-19 13:01:50 <mps> now I'm sure that RPi zero works very fine with mainline kernel
2020-10-19 13:02:16 <ikke> Ariadne: but I guess only for arches that are supported on the hardware?
2020-10-19 13:23:36 <ncopa> i changed color of favicon of gitlab, so it becomes easier to see difference with th eother sites, like a.o, build.a.o, pkgs.a.o
2020-10-19 13:23:48 <ncopa> what do you think?
2020-10-19 13:23:55 <ikke> I like it
2020-10-19 13:24:22 <ncopa> i picked the same color as gitlab logo
2020-10-19 13:26:09 <ikke> I figured
2020-10-19 13:26:13 <mps> hmm, so it will not be easy to distinguish gitlab.a.o and other gitlab.com tabs
2020-10-19 13:26:59 <ncopa> its easy to distinguish. different shape of the favicon
2020-10-19 13:27:11 <ncopa> actually, im not sure i like the new color
2020-10-19 13:27:12 <wener[m]> red ?
2020-10-19 13:27:17 <ikke> orange
2020-10-19 13:27:26 <ncopa> orange/red yes
2020-10-19 13:27:29 <mps> ah, I see
2020-10-19 13:27:43 <mps> colors are quite different
2020-10-19 13:28:36 <mps> darkred?
2020-10-19 13:28:47 <wener[m]> kind  of allergic to this red, maybe pick one from  https://material.io/design/color/the-color-system.html#tools-for-picking-colors
2020-10-19 13:29:34 <mps> choose one neutral, dark (black) :)
2020-10-19 13:29:40 <ikke> It kind of needs to make sense
2020-10-19 13:29:54 <ikke> And I guess we want to do something similar for the other apps
2020-10-19 13:30:05 <mps> for me everything is ok
2020-10-19 13:30:06 <ncopa> yes, we have an issue for it
2020-10-19 13:30:14 <ikke> nod
2020-10-19 13:30:27 <ncopa> the current orange is a bit ugly when there are lots of tabs
2020-10-19 13:30:44 <ncopa> black or dark grey is better
2020-10-19 13:31:07 <ncopa> or maybe the navyblue-ish that the gitlab top bar has?
2020-10-19 13:31:35 <ncopa> its close to the a.o color, but i think the difference is enough
2020-10-19 13:32:37 <wener[m]> but make sure it distinguishable in dark theme, maybe add bg color ?
2020-10-19 13:56:28 <ncopa> i changed it to black. i think it may work for dark theme too
2020-10-19 13:58:49 <mps> huh, though I wrote everything is ok for me, but hmmm looks somewhat unpleasant
2020-10-19 13:59:11 <mps> on dark theme
2020-10-19 14:22:47 <ncopa> :)
2020-10-19 14:34:28 <mps> huh, no luck with local armhf lxc, 'apk add tmux' => Illegal instruction
2020-10-19 14:37:40 <ncopa> ugh. the 5.4.72 kernel is having issues on shutdown on my desktop
2020-10-19 14:38:11 <ncopa> looks like its bluetooth related
2020-10-19 14:45:07 <mps> hm, apk fails on armhf lxc but apk.static works
2020-10-19 14:49:42 <mps> ncopa: https://security-tracker.debian.org/tracker/source-package/linux
2020-10-19 14:50:12 <mps> good summary info of the kernels security
2020-10-19 14:50:25 <ikke> nice,
2020-10-19 14:56:33 <mps> if I add armhf in arch on linux-edge will it be built on armhf builder?
2020-10-19 14:59:20 <ikke> Yes, armhf builder on an aarch64 hsot
2020-10-19 15:01:28 <mps> looks like it is only option for me to build armhf apk kernel
2020-10-19 15:03:10 <mps> btw, anyone have armhf lxc 'box' to check does apk works in it
2020-10-19 16:58:44 <mps> heh, fixed apk on armhf in lxc by rebuilding kernel with 'some' options enabled
2020-10-19 16:59:10 <ikke> so it was due to kernel options apk was broken?
2020-10-19 16:59:16 <mps> yes
2020-10-19 16:59:22 <ikke> curious
2020-10-19 16:59:57 <mps> actually I think apk or musl uses some obsolete asm instructions
2020-10-19 17:01:26 <mps> CONFIG_ARMV8_DEPRECATED=y
2020-10-19 17:01:26 <mps> CONFIG_CP15_BARRIER_EMULATION=y
2020-10-19 17:01:26 <mps> CONFIG_SWP_EMULATION=y
2020-10-19 17:01:26 <mps> CONFIG_SETEND_EMULATION=y
2020-10-19 17:01:49 <mps> these need to be set on aarch64 kernel
2020-10-19 17:08:59 <dne> re: kernel security, there's also https://www.linuxkernelcves.com/
2020-10-19 17:14:46 <ikke> helpnodeatemyram.org
2020-10-19 17:44:43 <ikke> hmm, jirutka just pushed an upgrade for node from 12.18.4 to 12.19.0 on 3.12-stable, and it's failing on all arches
2020-10-19 18:41:09 <CoolITKitty> "what option should be changed" -- to allow SPI0 to be accessed? unless there already is one?
2020-10-19 18:42:12 <ikke> To be accessed from where?
2020-10-19 18:42:53 <CoolITKitty> I'm unable to load the 'sc16is752-spi0' driver because it claims there's a conflict with SPI0
2020-10-19 18:42:59 <mps> CoolITKitty: could you describe what should be changed in kernel config for this
2020-10-19 18:43:24 <CoolITKitty> Raspbian does not; I'm able to use the device normally there
2020-10-19 18:44:15 <mps> we "can't' use raspbian kernels (and tools) so we need info what should be changed/enabled
2020-10-19 18:44:21 <CoolITKitty> compiling kernels is out of my experience depth
2020-10-19 18:44:39 <CoolITKitty> and I have no idea why SPI0 would be allocated by the kernel
2020-10-19 18:45:04 <mps> I don't have spi device which I could connect to RPi to test what must be enabled or changed
2020-10-19 18:45:53 <mps> for allwinner A20 I had to patch kernel and dts file to enable spi
2020-10-19 18:48:26 <CoolITKitty> hmm
2020-10-19 18:48:54 <CoolITKitty> odd that SPI1 is okay
2020-10-19 19:39:06 <obarun> passage rapide avant d'aller bosser
2020-10-19 19:39:09 <obarun> bien ou quoi?
2020-10-19 19:39:23 <obarun> enlever kiocreator suffit pour que kde demarre?
2020-10-19 19:39:32 <ikke> on pas parle francais
2020-10-19 19:39:44 <obarun> opps sorry, wrong chat
2020-10-19 19:40:10 <obarun> btw hi :)
2020-10-19 19:40:12 <ikke> :)
2020-10-19 19:40:15 <ikke> hi
2020-10-19 20:17:43 <crosbymichael> where can we get alpine stickers, i have to show my support ;)
2020-10-19 20:20:15 <wsinatra> https://www.redbubble.com/i/sticker/Alpine-Linux-by-devtee/30065482.EJUG5 <- crosbymichael
2020-10-19 20:20:27 <wsinatra> I got one from here, it's a decent size and quality
2020-10-20 09:31:48 <mps> https://www.freetype.org/ 2020-10-20 "All users should update immediately"
2020-10-20 09:32:06 <ikke> fun times
2020-10-20 09:32:26 <Ariadne> ikke: no  you can use dabuild in combination with qemu-user
2020-10-20 09:32:32 <ikke> aha, ok
2020-10-20 09:33:50 <mps> mps: All users should disconnect web immediately :)
2020-10-20 10:04:05 <maxice8> mps: thanks for the notice, made MRs for edge and 3.12
2020-10-20 10:30:47 <mps> maxice8: very fine, I see it is pushed
2020-10-20 11:16:02 <mps> 'rpiz:~ # uname -a' => Linux rpiz 5.9.1-0-edge #1-Alpine PREEMPT Tue, 20 Oct 2020 08:59:20 UTC armv6l Linux
2020-10-20 11:16:41 <mps> mainline alpine built kernel apk pkg on RPi zero W \o/
2020-10-20 11:26:06 <telmich> How long did that build take, mps?
2020-10-20 11:27:21 <mps> less than hour (didn't measured) in armhf lxc on aarch64 with two JOBS=2 in abuild.conf
2020-10-20 11:28:03 <telmich> Not bad
2020-10-20 11:29:32 <mps> it is somewhat 'trimmed down' kernel, not all drivers for other SOCs are enabled
2020-10-20 11:30:18 <mps> and rootfs is on ssd disk attached on usb
2020-10-20 12:24:00 <mps> !13773
2020-10-20 12:24:52 <mps> should we upgrade llvm when the new stable release 'on horizon'
2020-10-20 12:38:26 <Ariadne> lets hold off until after 3.13
2020-10-20 12:38:34 <Ariadne> i don't want to deal with the fallout right now
2020-10-20 12:38:47 <Ariadne> i doubt anyone else wants to either
2020-10-20 12:39:24 <ikke> no please :P
2020-10-20 12:51:36 <mps> agree with you, someone should mark this MR with hold
2020-10-20 12:51:59 <ikke> It's already WIP
2020-10-20 12:52:52 <mps> yes, I see, but comment would be nice to have
2020-10-20 12:53:59 <ikke> Would merely adding this package cause issues? Isn't it until packages start using it that it can cause problems?
2020-10-20 12:54:48 <mps> second one, I feel
2020-10-20 13:14:05 <Ariadne> problem is
2020-10-20 13:14:07 <Ariadne> once its added
2020-10-20 13:14:12 <Ariadne> people will want to use it :))
2020-10-20 13:17:48 <ikke> Well, they are free to use it if they fix any issues with it :P
2020-10-20 13:18:37 <ikke> I did notice it declares it's the default llvm package
2020-10-20 13:18:50 <ikke> so it does add the provides part
2020-10-20 13:19:15 <ikke> We could set that to no initially
2020-10-20 13:45:43 <ncopa> i have spent all day on cleaning up a zillion secfixes comments https://gitlab.alpinelinux.org/alpine/aports/-/issues/11914
2020-10-20 13:45:58 <ncopa> would be nice if CI could error if secfixes comment has duplicates
2020-10-20 13:46:57 <ikke> ncopa: yeah, noticed you've been busy
2020-10-20 13:47:15 <ikke> sounds like something the existing secfix linting could do (if they don't already)
2020-10-20 14:03:05 <ncopa> i see light in the end of the tunnel...
2020-10-20 14:09:49 <maxice8> secfixes-check has checks for it
2020-10-20 14:26:28 <ncopa> maxice8: awesome! thanks!
2020-10-20 14:26:47 <ncopa> btw, i fixed a handful of your dedupe cve secfixes
2020-10-20 14:27:12 <ncopa> sometimes the original fix wasnt enough, and a floowup release/patch was added
2020-10-20 14:27:24 <ncopa> in those cases we should use the latest release that has the complete fix
2020-10-20 14:27:34 <ncopa> so people dont think they are safe when they arent
2020-10-20 14:44:52 <ncopa> i finally fixed all CVE dupes reported in https://gitlab.alpinelinux.org/alpine/aports/-/issues/11914. Someone owes me a beer or two
2020-10-20 15:04:23 <maxice8> run secfixes-check {main,community,testing}/*/APKBUILD
2020-10-20 15:04:47 <maxice8> and grep for 'AL59'
2020-10-20 15:04:57 <maxice8> that is the designation for duplicate CVE fields
2020-10-20 16:49:02 <maxice8> ncopa: mooping up duplicate secfixes
2020-10-20 16:49:06 <maxice8> 3.12-stable:nomad
2020-10-20 16:49:53 <maxice8> only one :D
2020-10-20 20:43:54 <jim_new> Hi all! I came across this discussion on optional dependencies for Alpine packages (https://lists.alpinelinux.org/~alpine/devel/%3C883dca1a-b7f3-6137-059d-f561ef22c126%40cosmoborsky.com%3E)
2020-10-20 20:44:01 <jim_new> That kind of minimalism is what makes Alpine so attractive and useful over other distributions.
2020-10-20 20:44:15 <jim_new> Typically optional aspects of a package are broken into subpackages, most commonly "dev" and "doc" pagkages. So, I was curious why donesn't Apline formalize a list of subpackages that maintainers would be encouraged to break out?
2020-10-20 20:45:19 <jim_new> One example would be for a package to have wayland, X, framebuffer, SDL1/2, or non-GUI variants.
2020-10-20 20:45:33 <jim_new> Would it be possible to break those variants out as subpackages?
2020-10-20 20:46:25 <jim_new> Should something like that be encouraged as a standard?
2020-10-20 20:52:43 <Cogitri> Well, the problem is that that's something that has to be done on a package-by-package basis
2020-10-20 20:53:04 <Cogitri> it might be possible to split out the X/Wayland part for some packages but not for others
2020-10-20 20:53:23 <Cogitri> Actually, it's probably only possible to split it out on a fraction of the packages that need it
2020-10-20 20:55:49 <mps> i'm for splitting whenever possible
2020-10-20 20:56:48 <jim_new> What about package variations for situations where a pure split isn't possible?
2020-10-20 20:58:10 <mps> meta or virtual pkg
2020-10-20 20:59:20 <jim_new> It could be a meta package. You might have parts of that meta package that aren't functional on their own though.
2020-10-20 20:59:57 <jim_new> And an end user might not realize that a subpackage might need to be installed with other parts of a metapackage to work.
2020-10-20 21:00:41 <mps> virtual pkg then
2020-10-20 21:01:27 <jim_new> I guess I don't know how virtual would differ from meta.
2020-10-20 21:02:05 <jim_new> I might work in a case like the XFCE example from the optional dependency discussion.
2020-10-20 21:02:07 <mps> in term practically
2020-10-20 21:02:41 <jim_new> Where XFCE and icons are different packages.
2020-10-20 21:02:43 <jim_new> Ok
2020-10-20 21:04:44 <jim_new> I don't know how APK treats meta different from virtual. I guess if one had a hard constraint that it would have to be bundled then it could work.
2020-10-20 21:05:34 <jim_new> This would be like a simplified version of USE flags from Gentoo.
2020-10-20 21:05:55 <jim_new> And only at the per package level.
2020-10-20 21:07:54 <jim_new> GUI packages are really the best use case for this. Some come with audio bindings as well, that aren't always needed.
2020-10-21 06:24:10 <ncopa> any volunteers to help us keep the alpine versions in osinfo-db updated? https://gitlab.com/libosinfo/osinfo-db/-/tree/master/data/os/alpinelinux.org
2020-10-21 06:27:30 <Ariadne> if i wasn't already busy i would do it
2020-10-21 06:28:19 <ncopa> i was hoping for someone that isnt too busy, want to contribute with something that is not too advanced, and someone who is actually using virt-manager
2020-10-21 06:28:35 <Ariadne> :D
2020-10-21 06:28:43 <ncopa> :)
2020-10-21 06:32:55 <indy> hi all, how apk is sorting releases? i have (due lazyness) in pkgrel for example r20201021.10 but apk policy shows  r20201021.10 on top instead of r20201021.13, pkgver is same
2020-10-21 06:35:07 <afontain_> that's an usual pkgrel for sure
2020-10-21 06:56:15 <indy> but why apk think r20201021.10 is better to install and not r20201021.13 one??
2020-10-21 06:56:41 <afontain_> maybe there's a bug?
2020-10-21 07:26:47 <indy> well apk in 3.12 all the time complain that apk-tools is old
2020-10-21 07:27:02 <indy> "WARNING: This apk-tools is OLD! Some packages might not function properly."
2020-10-21 07:28:56 <ikke> indy: apk --version
2020-10-21 07:29:12 <indy> apk-tools 2.10.5, compiled for x86_64.
2020-10-21 07:29:31 <ikke> date
2020-10-21 07:29:55 <indy> after apk upgrade
2020-10-21 07:29:58 <indy> Wed Oct 21 07:29:44 UTC 2020
2020-10-21 07:31:46 <ikke> indy: seems like this error triggers if apk encounters flags in the database that it does not recognize
2020-10-21 07:33:35 <indy> which flags?
2020-10-21 07:34:10 <ikke> It something part of the internal apk db format
2020-10-21 07:35:10 <indy> is there way to trace/debug/verify it?
2020-10-21 07:36:31 <ikke> indy: What does `</lib/apk/db/installed cut -d: -f1 | sort -u` return?
2020-10-21 07:36:59 <ikke> hmm, no, it's about the index
2020-10-21 07:37:27 <Cogitri> You don't happen to use edge repos, do you, indy?
2020-10-21 07:37:50 <indy> Cogitri, no
2020-10-21 07:37:55 <indy> Cogitri, 3.12
2020-10-21 07:38:35 <indy> ikke, `</lib/apk/db/installed cut -d: -f1 | sort -u` returns "/bin/sh: A: not found"
2020-10-21 07:38:46 <Cogitri> Can you show us your /etc/apk/repositories ?
2020-10-21 07:39:28 <indy> Cogitri, after small censorship :)
2020-10-21 07:40:43 <ikke> indy: Without the backticks ;-)
2020-10-21 07:41:35 <ikke> indy:  for I in /var/cache/apk/*.tar.gz; do tar xzf APKINDEX.066df28d.tar.gz -O APKINDEX | cut -d: -f1; done | sort -u
2020-10-21 07:41:46 <ikke> This is for checking the flags in the index files
2020-10-21 07:42:58 <indy> Cogitri, ikke https://paste.debian.net/1168065/
2020-10-21 07:43:23 <ikke> Ok, so this might be an incompattibility issue with artifactory
2020-10-21 07:44:44 <indy> https://paste.debian.net/1168066/
2020-10-21 07:46:29 <indy> ikke, on customer's jfrog artifactory it says it should support apk since 3.10.3
2020-10-21 07:46:53 <indy> so since alpine 3.10
2020-10-21 07:47:02 <indy> maybe 3.9
2020-10-21 07:53:21 <indy> ikke, which kind of incompatibility?
2020-10-21 07:53:34 <ikke> hmm, I cannot find the 'y' and the 'z' flags
2020-10-21 07:53:42 <ncopa> indy: the -rN is for revision number so its a single integer, not a version string with dots
2020-10-21 07:54:07 <ncopa> i guess apk ignores the chars after last digit, the dot in this case
2020-10-21 07:54:44 <afontain_> ah, yes, that's the kind of behaviour strtoi has
2020-10-21 07:55:54 <mps> also I had local package with this problem, fixed by removing and creating new and correct -rN
2020-10-21 07:56:25 <mps> when I started to 'play' with alpine :)
2020-10-21 07:57:03 <indy> ncopa, yes - https://paste.debian.net/1168068/
2020-10-21 07:58:01 <ikke> ncopa: Am I correct in my conclusion that apk does not know the 'y' and 'z' flags in the index?
2020-10-21 08:04:25 <indy> ncopa, from discussion above to me it seems apk bug, at least apt/dpkg has no problems with such strings (1.2.3-20201019.13~buster1 updates 1.2.3-20201019.10~buster1)
2020-10-21 08:04:43 <ikke> indy: apk has it's own version requirements
2020-10-21 08:05:05 <ikke> what works / is allowed for apt/dpkg is not necessary valid for apk
2020-10-21 08:10:00 <afontain_> Maybe it would make sense make a MR to apk so that this becomes an error
2020-10-21 08:14:08 <ncopa> i think we dont error so it is legal to add a descriptive string that gets ignored
2020-10-21 08:14:18 <ncopa> -r2git
2020-10-21 08:14:22 <ncopa> or whatever
2020-10-21 08:15:14 <mps> -r2d2 :)
2020-10-21 08:15:32 <indy> ikke, i agree, according to APKBUILD_Reference what should work is put pipeline build name to version (1.2.3_20201021.10) and pkgrel keep all the time 0
2020-10-21 08:15:46 <indy> as workaround
2020-10-21 08:16:26 <mps> no _
2020-10-21 08:17:05 <mps> there must be -rN
2020-10-21 08:17:12 <ikke> mps: as the pkgver
2020-10-21 08:17:27 <mps> yes
2020-10-21 08:17:34 <ikke> -r is not allowed in pkgver
2020-10-21 08:17:40 <afontain_> how about 1.2.3.20201021-r10 ?
2020-10-21 08:17:46 <mps> but must end with -rN
2020-10-21 08:18:12 <ikke> -rN is defined by pkgrel=
2020-10-21 08:18:20 <indy> i can keep r alway zero
2020-10-21 08:18:38 <ikke> If it's a new source release, it makes sense to have it part of pkgver, not pgkrel
2020-10-21 08:19:00 <ikke> pkgrel basically means the source remained the same (same upstream version), but the package was rebuilt for one reason or the other
2020-10-21 08:20:38 <indy> ikke, that's why i've put pipeline build name (like 20201019.10) to pkgrel because build are triggerred manually or automatically even code was not changed
2020-10-21 08:20:55 <ikke> ok, right
2020-10-21 08:29:28 <indy> afontain_, better workaround is 1.2.3.20201019.19-r0 if i have to take build name from pkgrel
2020-10-21 08:30:05 <afontain_> yeah
2020-10-21 08:30:25 <afontain_> I thought it was something similar to a git commit date
2020-10-21 08:34:50 <mps> uh, I see that I forgot enable ell on s390x and mips64, sorry and thanks ncopa
2020-10-21 08:35:48 <ncopa> mps: i think they were disabled due to a test failure. i disabled the test because bluez failed, and disabling bluez would lead to disabling lots other stuff
2020-10-21 08:35:55 <ncopa> was simpler to just disable the failing test.
2020-10-21 08:36:21 <mps> yes, I thought about disabling failed tests only
2020-10-21 08:36:42 <mps> or ask tmhoang to upgrade kernel on s390x builder
2020-10-21 08:37:26 <mps> it passed on s390x CI
2020-10-21 08:40:06 <ncopa> bluez failed dut to missing ell dependency
2020-10-21 08:40:51 <mps> I wonder anyone use bluez on s390x?
2020-10-21 08:41:05 <mps> but I don't know
2020-10-21 08:41:35 <ikke> other packages depend on bluez
2020-10-21 08:41:37 <ikke> asterisk
2020-10-21 08:41:56 <mps> ah, now understand
2020-10-21 08:42:00 <ncopa> i don think anyone uses bluez on s390x, but id rather have a failing test that disable all the packages
2020-10-21 08:42:20 <ncopa> or add conditional bluez support in those packages
2020-10-21 08:43:12 <mps> I think it will pass all tests on never kernels, but not 100% sure
2020-10-21 08:45:38 <ncopa> it was bluez that failed on kernel config on the dev machine. but it coudl be as easy as reboot the machine so the kernel module gets loaded
2020-10-21 08:45:45 <ncopa> not ell
2020-10-21 08:46:18 <ncopa> i pushed bluez anyway, since i think the tests would pass on the build machines
2020-10-21 08:46:42 <ncopa> ell test suite fails on mips64 and s390x does not have anything to do with kernel config
2020-10-21 08:49:19 <mps> hmm, iirc it passed CI
2020-10-21 08:50:15 <ikke> What I do on my personal systems after a kernel upgrade is just extract the old kernel modules, and remove them after reboot
2020-10-21 08:54:39 <indy> another issue i have is -dev package dependencies - in all packages i have only -dev and -dbg subpackages. when building another package (let's say zzz) that is depending on such i put to makedepends let's say yyy-dev, but abuild -r for zzz installs yyy-dev but not yyy itself
2020-10-21 08:55:18 <ikke> yyy-dev shoud automatically depend on yyy
2020-10-21 09:03:28 <indy> i see it in abuild output, but apk install zzz-dev installs boost-dev which i have in depends_dev and yyy-dev, but not yyy and zzz
2020-10-21 09:03:47 <indy> is that related to problem with pkgrel?
2020-10-21 09:03:52 <ncopa> no
2020-10-21 09:04:29 <ncopa> there is no automaic depends of zzz from zzz-dev
2020-10-21 09:05:09 <ncopa> it normally happens in practice because there is normally a libzzz.so symlink -> libzzz.so.0 in the -dev
2020-10-21 09:05:22 <ikke> right
2020-10-21 09:05:29 <ncopa> and abuild will detect that and pull in zzz as depends due to the symlink
2020-10-21 09:06:25 <ncopa> but if there are no real need for zzz it should not be pulled in
2020-10-21 09:08:39 <indy> ncopa, in this case it is because one can't link to some library if that library isn't present
2020-10-21 09:10:44 <indy> ncopa, result is zzz-dev package brought all xxx-dev yyy-dev packages, so i have in /usr/lib 3 'dead links'
2020-10-21 09:18:49 <ncopa> im not following
2020-10-21 09:18:54 <indy> ncopa, because packages xxx, yyy, zzz were not installed
2020-10-21 09:19:27 <ncopa> zzz-dev will normally pull in zzz as dep due to the symlink as i explained
2020-10-21 09:20:08 <ncopa> xxx-dev should pull in xxx simliar way and yyy-dev  should pull in yyy
2020-10-21 09:20:30 <ncopa> if zzz-dev has depends_dev="xxx-dev yyy-dev" then all should be pulled in
2020-10-21 09:20:39 <mps> !tracepeds in APKBUILD?
2020-10-21 09:21:42 <ncopa> if zzz-dev has a symlink pointing to a file in zzz and zzz is not pulled in as a dep, then there is a bug somewhere
2020-10-21 09:22:34 <ncopa> im gonna tag 3.12.1 now
2020-10-21 09:22:40 <ikke> \o/
2020-10-21 09:24:40 <indy> ncopa, it should and i just verified in abuild log from particular build: https://paste.debian.net/1168073/
2020-10-21 09:29:38 <ncopa> it depends on zzz=5.6.7-r20201015.2
2020-10-21 09:29:50 <ncopa> what does apk info -R zzz-dev say?
2020-10-21 09:30:11 <ncopa> the -r20201015.2 looks wrong
2020-10-21 09:30:49 <ncopa> what does the 20201015.2 mean?
2020-10-21 09:31:13 <indy> https://paste.debian.net/1168074/
2020-10-21 09:31:18 <mps> debian
2020-10-21 09:31:49 <ncopa> the -rN is meant to be the revision of the APKBUILD itself. so if for example the package splitting is done differently, or install locations etc
2020-10-21 09:32:00 <ncopa> -rN is not to be used as upstream version number
2020-10-21 09:32:15 <indy> ncopa, it is build name from azure pipeline
2020-10-21 09:34:06 <ncopa> does source change when buildname change?
2020-10-21 09:34:13 <indy> no
2020-10-21 09:35:04 <ncopa> so building apk package 5.6.7-rX gives same build output as 5.6.7-rY
2020-10-21 09:35:56 <ncopa> do you repackage precompiled binaries?
2020-10-21 09:36:04 <indy> no
2020-10-21 09:36:16 <indy> from source, but that is not changed
2020-10-21 09:36:35 <ncopa> so its basically same apk build, regardles of the -rN here
2020-10-21 09:37:10 <ncopa> if that is the case, I'd recommend to simply drop the -rN part and go for 5.6.7-r0
2020-10-21 09:37:42 <ikke> ncopa: I guess they are publishing the apk to artifactory, so I think it should have a unique name / version
2020-10-21 09:38:17 <indy> i can't because in jfrog artifactory policy is to not overwrite
2020-10-21 09:38:37 <indy> i can upload but not remove/rename/rewrite
2020-10-21 09:39:00 <ncopa> so you build a new identical package with new version string
2020-10-21 09:40:05 <ncopa> how about use -rYYYYMMDDNN where NN is a serial number
2020-10-21 09:40:22 <ikke> I guess that's their format, but with a . in between
2020-10-21 09:40:23 <ncopa> eg, simply drop the dot in there
2020-10-21 09:40:27 <ikke> :)
2020-10-21 09:40:47 <indy> that what i'm thinking about
2020-10-21 09:41:19 <ncopa> i find it weird that the build log says that zzz is pulled in as dep, but apk info -R says that it wasnt
2020-10-21 09:41:57 <ncopa> can you have a look in pkg/zzz-dev/.PKGINFO and see if it was added
2020-10-21 09:42:01 <ncopa> i thikn it was
2020-10-21 09:42:19 <ncopa> but apk is probably ignoring it due  to the weird version string
2020-10-21 09:42:25 <indy> i think it is due dot in pkgrel
2020-10-21 09:42:42 <ikke> apk version -c rejects it as a valid version
2020-10-21 09:43:00 <ikke> although, I guess it does not want -r anyway
2020-10-21 09:43:19 <ikke> oh, it does
2020-10-21 09:43:27 <ikke> -r1 is accepted, -r1.1 is rejected
2020-10-21 09:44:10 <indy> i would suggest abuild will fail or at least warn if such pkgrel is used
2020-10-21 09:44:16 <ncopa> ok, we should have abuild fail
2020-10-21 09:44:20 <ncopa> yes
2020-10-21 09:44:46 <ncopa> indy: can you please file an issue on https://gitlab.alpinelinux.org/alpine/abuild
2020-10-21 09:48:29 <indy> https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10011
2020-10-21 09:54:25 <indy> ncopa, added pastebin as they expire tomorrow
2020-10-21 09:55:17 <ncopa> thanks 👍
2020-10-21 10:36:44 <dne> ncopa: https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/13
2020-10-21 10:37:31 <ncopa> thanks!
2020-10-21 10:37:59 <dne> thanks! :)
2020-10-21 10:39:31 <dne> 14, 17 and 15 are duplicates of that one, but 16 still applies: https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/16/
2020-10-21 10:40:30 <dne> (I think, not my MR)
2020-10-21 12:40:02 <Newbyte> So I ran $APORTS_DIR/scripts/bootstrap.sh aarch64 to set up an aarch64 chroot for cross-compilation, but how do I actually use this chroot to cross-compile packages from x86_64 to aarch64?
2020-10-21 13:57:52 <Newbyte> So I'm trying to make Minetest use OpenGL ES on arm* and aarch64, but it seems that requires Irrlicht to be built with OpenGL ES support, and (not so) conveniently it seems this requires you to build Irrlicht from a separate OpenGL ES branch. This branch is 552 commits ahead of master (and 2710 commits behind). How would you suggest this to be handled?
2020-10-21 14:01:13 <Thermi> Check if you can merge that branch into master without conflict
2020-10-21 14:01:15 <Thermi> (probably not)
2020-10-21 14:01:35 <Newbyte> Place your bets
2020-10-21 14:01:44 <Thermi> Then you need to resolve the conflicts and decide on if it's worth the effort or not
2020-10-21 14:01:54 <Thermi> maybe latest OpenGL ES works fine, assuming you don't use that already.
2020-10-21 14:02:28 <Newbyte> The issue is that I'm trying to update the Minetest package in Alpine's repos
2020-10-21 14:02:38 <Newbyte> So I don't think anything will float
2020-10-21 14:03:25 <Newbyte> okay, that's a lot of merge conflicts
2020-10-21 14:10:25 <Thermi> Develop some kind of strategy to deal with that
2020-10-21 14:10:28 <Thermi> I'm busy
2020-10-21 14:10:30 <Thermi> :P
2020-10-21 14:10:46 <Newbyte>  No worries
2020-10-21 15:55:57 <Ariadne> [07:57:51] <Newbyte> So I'm trying to make Minetest use OpenGL ES on arm* and aarch64, but it seems that requires Irrlicht to be built with OpenGL ES support, and (not so) conveniently it seems this requires you to build Irrlicht from a separate OpenGL ES branch. This branch is 552 commits ahead of master (and 2710 commits behind). How would you suggest this to be handled?
2020-10-21 15:56:05 <Ariadne> separate package and use provides to hook everything up
2020-10-21 15:56:07 <Ariadne> :)
2020-10-21 15:56:51 <Ariadne> however
2020-10-21 15:57:25 <Ariadne> opengl is highly unpleasant situation on ARM, because desktops on ARM still use traditional opengl
2020-10-21 15:57:52 <Ariadne> embedded however is opengles ;/
2020-10-21 16:01:55 <Newbyte> sounds like a reasonable idea. definitely an unpleasant situation though …
2020-10-21 16:19:41 <ncopa> the /etc/profile.d/locale -> /etc/profile.d/locale.sh in 3.12-stable scares me: https://github.com/docker-library/official-images/pull/8927#issuecomment-713465346
2020-10-21 16:20:31 <ncopa> people rebuliding their docker images will now have different env vars set in their container apps
2020-10-21 16:21:22 <ikke> oh, it was changed between 3.12.0 and 3.12.1?
2020-10-21 16:21:38 <ncopa> yup, that is what scares me
2020-10-21 16:21:55 <ncopa> a5e6bb7ba5d7bf0f099b2fe4c12a8d935514c409 and c3ce4065bd8a69d20ad392d4cf006ed652c3f1a7
2020-10-21 16:24:41 <ncopa> hopefully everything will be ok, but you never know what garbage people run in their containers
2020-10-21 16:34:02 <Ariadne> dalias: any progress on these MT-fork improvements?
2020-10-21 18:58:24 <dalias> ariadne, yes, i just need to get some time to clean up and review things. sorry i got bogged down in the other abort lock concerns right after the last update on it
2020-10-21 18:58:59 <dalias> i think i possibly do want to pursue the signal wrapping thing that fixes exec, but it's a bigger project than i'd do in this release cycle
2020-10-21 21:36:35 <Ariadne> dalias: well i am just asking because i am having to restart X 15 times a day due to KWin deadlocking
2020-10-21 21:36:50 <Ariadne> which is a new innovation with musl 1.2.1
2020-10-21 21:36:53 <Ariadne> (:
2020-10-21 21:36:55 <dalias> :/
2020-10-21 21:37:41 <dalias> let me see if i can take care of it in the next day or two. working on paid stuff right now with meetings coming up in the next few hours
2020-10-22 08:39:06 <ikke> All builders are currently blocked..
2020-10-22 08:39:17 <ikke> All seem to be related to KDE
2020-10-22 09:08:17 <ikke> xorg-server, multiple vulnerabilities
2020-10-22 09:16:48 <maxice8> !13852
2020-10-22 09:19:19 <maxice8> systemsettings seem to be having a fit
2020-10-22 09:19:43 <maxice8> locally with busybox tar and GNU tar, for both me and PureTryOut, it seems to extract normally, but fails on CI and the builders
2020-10-22 09:20:13 <ikke> I can take a look later
2020-10-22 09:20:44 <maxice8> I'm "fixing" the ones in mips* and s390x
2020-10-22 09:20:59 <PureTryOut[m]2> There is Plasma 5.20.1 already, I'll get that going
2020-10-22 09:21:37 <maxice8> ikke: That is fast
2020-10-22 09:21:45 <maxice8> how did you fix systemsettings ?
2020-10-22 09:21:56 <maxice8> nevermind
2020-10-22 09:36:41 <maxice8> xorg-server to community move revealed 4 packages fail with gcc-10
2020-10-22 10:50:27 <ikke> strange, when I manually run tar on the archive, it works, but abuild unpack fails
2020-10-22 10:53:05 <ikke> ok, it first does unxz -c on the archive and pipes that to tar
2020-10-22 10:53:36 <ikke> maxice8: The extension is wrong
2020-10-22 10:53:50 <ikke> the extension is .xz, but it's a gzip compressed archive
2020-10-22 10:55:02 <maxice8> nice
2020-10-22 10:55:18 <mps> what was reason to move xorg to community
2020-10-22 10:55:42 <ikke> maxice8: quick fix is to override the local filename
2020-10-22 10:55:44 <mps> move all gui tools also?
2020-10-22 10:56:25 <ikke> maxice8: found it by running abuild -v unpack
2020-10-22 10:59:06 <ikke> What I do wonder is why this was pushed, is it seems to fail even locally
2020-10-22 11:07:04 <ikke> maxice8: even with that fix, it does not seem to build
2020-10-22 11:07:34 <maxice8> looking into it
2020-10-22 11:07:36 <ikke> libkworkspace is not up-to-date, probably the issue
2020-10-22 11:07:47 <ikke> ie, it needs to be built before this one (when testing)
2020-10-22 11:08:23 <ikke> https://tpaste.us/oPQR
2020-10-22 11:09:47 <ikke> should we file an upstream issue?
2020-10-22 11:12:45 <maxice8> yes
2020-10-22 11:13:02 <ikke> I guess at bugs.kde.org?
2020-10-22 11:13:22 <ikke> PureTryOut[m]2: can you arrange that?
2020-10-22 13:51:20 <PureTryOut[m]2> Sorry, what issue?
2020-10-22 13:51:30 <PureTryOut[m]2> Also it might already be fixed in 5.20.1, let's see that CI complete first
2020-10-22 13:51:39 <PureTryOut[m]2> !13853
2020-10-22 13:54:32 <ikke> PureTryOut[m]2: the archive for that version has the xz extension, but is actually gz
2020-10-22 13:56:24 <PureTryOut[m]2> Ah well no need to file an isuse, 5.21.1.1 is already out for systemsettings
2020-10-22 13:56:38 <PureTryOut[m]2> And that does use an XZ compression
2020-10-22 13:56:43 <ikke> ok
2020-10-22 13:56:47 <PureTryOut[m]2> Not sure what happened with 5.20.101 🤷‍♂️
2020-10-22 13:56:50 <PureTryOut[m]2> *5.20.0.1
2020-10-22 14:05:13 <maxice8> made !13862 !13863 !13864
2020-10-22 14:05:24 <maxice8> should fix all xorg-servers
2020-10-22 14:06:10 <mps> maxice8: nice
2020-10-22 14:08:42 <mps> I see that you moved xorg to community (and I think this good) but what are reasons
2020-10-22 14:09:18 <mps> so, all gtk and gui things must be moved from main?
2020-10-22 14:12:32 <maxice8> I made an MR to guage interest in reducing maintanance burden by moving xorg-server to community
2020-10-22 14:13:13 <mps> good move, I support it
2020-10-22 14:14:17 <mps> now we have to check what else must be moved
2020-10-22 14:29:56 <maxice8> there is adep check
2020-10-22 14:30:36 <mps> ah, I use 'ap revdep'
2020-10-22 14:37:51 <maxice8> also works
2020-10-22 14:38:03 <maxice8> adep check just does tha checks you do manually
2020-10-22 14:38:45 <maxice8> http://ix.io/2BD2
2020-10-22 14:50:08 <maxice8> it is not perfect
2020-10-22 14:50:17 <maxice8> it can't handle dependencies in subpackages
2020-10-22 14:55:17 <ollieparanoid[m]> it seems that alsa + pulseaudio is currently broken in edge. I'm testing if rebuilding pulseaudio against today's alsa update fixes it
2020-10-22 14:55:53 <mps> ap revdep detected that gvim (subpkg of vim) depends on libx11-dev
2020-10-22 14:57:04 <ollieparanoid[m]> regarding alsa, downstream bug report: https://gitlab.com/postmarketOS/pmaports/-/issues/833
2020-10-22 14:59:49 <Hello71> mps: that's not xorg-server though, is it?
2020-10-22 15:06:00 <mps> Hello71: no it is not, but keep libx11 after xorg is moved to community doesn't make sense, imo
2020-10-22 15:06:14 <mps> keep in main*
2020-10-22 15:06:18 <Hello71> x forwarding is a thing
2020-10-22 15:06:49 <Hello71> or xwayland (although that is part of xorg-server)
2020-10-22 15:52:52 <PureTryOut[m]2> !13853 is ready and will unblock the x86_64, x86, armv7 and aarch64 builders
2020-10-22 16:10:31 <maxice8> am handling groceries, if someone else could merge
2020-10-22 16:11:00 <ikke> checking
2020-10-22 16:26:50 <ollieparanoid[m]> I've figured out the alsa breakage in edge and I'm preparing a patch: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12041
2020-10-22 16:27:26 <ikke> ah ok, gjabell ^
2020-10-22 16:27:54 <gjabell> sweet, thanks :)
2020-10-22 16:28:10 <gjabell> glad it's not just me being dumb haha
2020-10-22 16:53:17 <ollieparanoid[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/13870
2020-10-22 17:00:48 <ollieparanoid[m]> build passed. would be great if somebody could take a look at this and merge it if it's fine.
2020-10-22 17:25:21 <mps> ollieparanoid[m]: alsa works fine here on edge
2020-10-22 17:28:17 <ikke> maxice8: mgmr keeps saying the MR is rebasing, even though the interface says it's already done
2020-10-22 17:28:36 <ikke> >>> 13853 is currently rebasing, waiting 4 seconds to check if it still rebasing
2020-10-22 17:28:51 <ikke> (first time I try to use it)
2020-10-22 17:37:12 <maxice8> weird
2020-10-22 17:59:15 <ollieparanoid[m]> mps: it's defintively broken when using plugins like pulseaudio, and it's obvious when looking at the current fix-dlo.patch, it just returns in that function without setting the plugin path
2020-10-22 18:59:20 <PureTryOut[m]2> Ugh polkit being disabled on s390x because of missing Rust means I have to add `!s390x` to a ton of packages 😢
2020-10-22 19:19:48 <insep_> what's the nick of https://gitlab.alpinelinux.org/fabled in this room?
2020-10-22 19:21:08 <PureTryOut[m]2> ikke: disabled the failing packages on s390x, they all dependent in one way or another on polkit which is blocked on s390x
2020-10-22 19:21:14 <PureTryOut[m]2> *they all depended
2020-10-22 19:21:26 <PureTryOut[m]2> !13853 should be good to go
2020-10-22 19:21:46 <insep_> oh, seems like he just left this room :(
2020-10-22 19:21:48 <Cogitri> insep_: Timo's fabled on IRC too but he's not always on
2020-10-22 19:22:13 <insep_> i'll leave the link in issue then
2020-10-22 19:22:28 <insep_> gotta use that gitlab account at least for something :D
2020-10-22 19:28:20 <ollieparanoid[m]> alsa upstream is fast, the bug is fixed properly in alsa-lib. I've updated my patch to use the upstream patch: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/13870
2020-10-22 19:29:00 <ikke> nice!
2020-10-22 19:29:00 <ollieparanoid[m]> thanks, Leo!
2020-10-22 19:29:08 <insep_> maxice8: how are you that fast, tell me more about your power
2020-10-22 19:29:24 <maxice8> Notifications
2020-10-22 19:29:30 <PureTryOut[m]2> Probably has a big button he can just smash when he sees a notification
2020-10-22 19:29:48 <insep_> gitlab notifications?
2020-10-22 19:30:16 <maxice8> yes
2020-10-22 19:30:17 <PureTryOut[m]2> chat probably
2020-10-22 19:30:23 <PureTryOut[m]2> Oh
2020-10-22 19:30:38 <insep_> cool
2020-10-22 19:30:40 <maxice8> they appear on my email which notifies me in GNOME
2020-10-22 19:31:13 <insep_> > gnome
2020-10-22 19:31:26 <maxice8> yes
2020-10-22 19:31:31 <PureTryOut[m]2> > not KDE Plasma
2020-10-22 19:31:45 <maxice8> can't even start that thing on Wayland
2020-10-22 19:32:14 <PureTryOut[m]2> KDE Plasma? Works fine on Wayland
2020-10-22 19:32:16 <insep_> > not fbcon
2020-10-22 19:32:47 <maxice8> 4u
2020-10-22 19:33:06 <PureTryOut[m]2> How does it not launch for you? Can you make an issue for it?
2020-10-22 19:33:14 <insep_> aaaaaaaa i don't remember what u in sed do
2020-10-22 19:33:46 <maxice8> PureTryOut: I can try get a log later
2020-10-22 19:53:22 <PureTryOut[m]2> Thanks
2020-10-22 19:54:38 <Cogitri> PureTryOut[m]2: fwiw your nick is different
2020-10-22 20:00:41 <PureTryOut[m]2> I know
2020-10-22 20:00:57 <PureTryOut[m]2> Using a different Matrix acc atm, my homeserver is shitting itself constantly currently so am using matrix.org on the side now
2020-10-22 20:13:27 <Cogitri> Oh okie
2020-10-22 20:26:45 <maxice8> merged plasma upgrade, thanks PureTryOut
2020-10-22 20:26:59 <ikke> 
ACTION hopes it helps

2020-10-22 20:27:09 <PureTryOut[m]2> No thank you! 😃 Can't wait to run Plasma 5.20 myself on all my PC's
2020-10-23 04:47:35 <ikke> oh, nice, someone found the linking issue with ppc64le
2020-10-23 07:06:42 <PureTryOut[m]2> the 128-bit thing?
2020-10-23 07:09:00 <ikke> yes
2020-10-23 07:09:04 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12045
2020-10-23 07:24:13 <PureTryOut[m]2> Nice!
2020-10-23 07:37:43 <PureTryOut[m]2> anyways, pma!1590 is ready
2020-10-23 07:50:42 <ikke> I don't think that's what you meant :P
2020-10-23 10:05:13 <insep_> abc!1234
2020-10-23 10:05:22 <insep_> oh fun
2020-10-23 10:05:35 <insep_> i can put anything i want before !
2020-10-23 10:25:15 <ikke> Interesting docker issue (another user ran into it before as well): binaries that come with capabilities refuse to run by default in docker
2020-10-23 10:35:46 <PureTryOut[m]2> Well yes, just the pmOS bot uses something before the ! to specify a repo
2020-10-23 10:39:35 <mps> maybe we can discuss fusion alpine and pmOS :)
2020-10-23 10:40:24 <PureTryOut[m]2> Well the goal is to have no need for that lol. We upstream everything we can and that makes sense
2020-10-23 10:41:07 <mps> if everything is upstream what is diff between then
2020-10-23 10:41:11 <PureTryOut[m]2> Eventually we just want device specific stuff in postmarketOS, everything else (for example not-yet-ready Plasma Mobile applications or other tools) should eventually move to Alpine
2020-10-23 10:41:40 <PureTryOut[m]2> Well lots of devices use downstream kernels, Alpine probably doesn't want to package all of those so they stay in pmOS, same with the device packages
2020-10-23 10:42:37 <mps> heh, about a week I'm contemplating to make linux-edge-n900, linux-edge-rpizw ....
2020-10-23 10:42:52 <PureTryOut[m]2> n900 doesn't need it's own kernel really
2020-10-23 10:42:56 <PureTryOut[m]2> Runs quite well on mainline
2020-10-23 10:42:57 <insep_> mps: no i don't want to switch to irc, i still like my replies :(
2020-10-23 10:43:41 <mps> PureTryOut[m]2: linux-edge is mainline
2020-10-23 10:43:43 <insep_> also we still use our custom mkinitfs, but you already know this by now ^^
2020-10-23 10:44:11 <mps> insep_: yes
2020-10-23 10:50:22 <maxice8> !13852
2020-10-23 10:52:05 <maxice8> YAY or NAY for replacing GNUTLS with OpenSSL on rsyslog !13883
2020-10-23 10:52:33 <mps> 'yes' counts?
2020-10-23 10:54:08 <maxice8> anything that roundabout converts to an affirmative counts
2020-10-23 10:55:14 <mps> few days ago I read somewhere that next main openssl release will have more relaxed license
2020-10-23 11:21:16 <Ariadne> maxice8: we can't until openssl 3 happens.  present openssl license remains gpl incompatible without an exception present.
2020-10-23 11:30:00 <maxice8> doesn't that mean that any linking of openssl in GPL projects is verboten ?
2020-10-23 11:33:15 <ikke> Except if that project adds and exception
2020-10-23 11:34:42 <maxice8> Someone will have to check the 208 instances of GPL-* in license= and openssl-dev present
2020-10-23 11:49:45 <maxice8> #12046
2020-10-23 11:51:55 <Ariadne> :D
2020-10-23 11:52:03 <maxice8> SPDX has no generic GPL-Linking-Exception
2020-10-23 11:52:08 <Ariadne> we used to check for this stuff
2020-10-23 11:52:26 <Ariadne> in practice, i don't think it matters that much.  but legally... it is an invalid combination
2020-10-23 11:52:29 <maxice8> they do have GPL-3.0-linking-exception with {name_of_library}
2020-10-23 11:52:48 <maxice8> can we use a GPL-linking-exception for {L,}GPL-2.0* in the meantime ?
2020-10-23 11:52:56 <Ariadne> GPLv3 could link against openssl as it is considered a 'system library'
2020-10-23 11:53:00 <Ariadne> the only problem is with GPLv2
2020-10-23 11:53:50 <Ariadne> and, that seems fine to me.  i don't know much about SPDX.
2020-10-23 11:56:14 <maxice8> SPDX is just a repository of "definitive" names for licenses
2020-10-23 11:56:37 <maxice8> just an attempt at normalization instead of having apache_2_0 (seen this in Perl) apache-2.0, apache-2 Apache-2.0
2020-10-23 11:56:53 <maxice8> people following SPDX will just write Apache-2.0
2020-10-23 12:00:24 <yZ5vlALg86lP> ohio, i fixed the latest v of ejabberd to build under erlan23, see my patch here: https://tpaste.us/1Jn0 - i would be obliged if anyone would apply this
2020-10-23 12:00:37 <yZ5vlALg86lP> erlang23 even.
2020-10-23 12:01:27 <maxice8> Ikke spooked me
2020-10-23 12:01:36 <ikke> lol
2020-10-23 12:02:18 <maxice8> "I don't remember checking git"
2020-10-23 12:02:21 <maxice8> "it disappeared!"
2020-10-23 12:03:33 <maxice8> also please add
2020-10-23 12:03:44 <maxice8> 'WITH OpenSSL-Exception' to license= if you find the exceptions
2020-10-23 12:04:26 <maxice8> @Ariadne how much would an apkbuild-lint check for 'openssl-dev' in makedepends and GPL* in license= help ?
2020-10-23 12:04:36 <maxice8> it would miss cases where it is not linked
2020-10-23 12:15:53 <insep_> i wait i thought you can link gpl program against whatever you want and nobody would care
2020-10-23 12:22:40 <Cogitri> LGPL does that, not GPL
2020-10-23 12:22:52 <Cogitri> GPL infects programs upon linking, LGPL doesn't
2020-10-23 12:23:23 <tehcloud> love the use of the word "infect" there
2020-10-23 12:23:41 <tehcloud> MPL 2.0 for life :p
2020-10-23 12:23:46 <maxice8> libwebsockets is now MIT! :D
2020-10-23 12:25:05 <Cogitri> Well, I use GPL for my applications and GPL for libraries, so that works
2020-10-23 12:25:29 <Cogitri> Realistically licenses are mostly a statement of intent and not something that's really being enforced (unfortunately!)
2020-10-23 12:28:06 <dne> debian now considers openssl part of the system: https://salsa.debian.org/ftp-team/website/-/commit/c804b2d2d0ff28ce50bbeaecaec6db05a58949b8
2020-10-23 12:29:13 <tehcloud> I avoid GPL whenever possible, it is just annoying and the language is highly ideological for what should have been a software license
2020-10-23 12:30:42 <tehcloud> but that being said, I own a few GPL codebases and I don't have any reason to change the license on those
2020-10-23 12:32:26 <mps> GPL is bad for those with selfish interest, imo
2020-10-23 12:34:52 <afontain_> isn't that a good thing?
2020-10-23 12:35:25 <mps> afontain_: I think yes
2020-10-23 12:35:28 <tehcloud> it depends, my personal intent sometimes is to just give something away without dictating how they use it, GPL tells people how they must use it
2020-10-23 12:36:11 <ikke> tehcloud: it doesn't tell users of software anything :)
2020-10-23 12:36:17 <mps> tehcloud: everyone is free to do with its software whatever want
2020-10-23 12:36:41 <tehcloud> except use the code in a more liberally licensed codebase without the GPL overriding everything else
2020-10-23 12:38:10 <mps> actually I think idea of licenses and copyright is bad at the base, imo everything released should be fully without restrictions, but we live in a greedy world
2020-10-23 12:38:23 <tehcloud> yes, I can agree with you 100% there
2020-10-23 12:38:51 <Cogitri> You can always use the unlicense or something for that
2020-10-23 12:38:54 <Cogitri> or Public-Domain
2020-10-23 12:39:13 <tehcloud> MPL 2.0 is what I found to be the best balance
2020-10-23 12:39:28 <tehcloud> it does not infect the rest of a codebase but still has copyleft protections
2020-10-23 12:39:44 <mps> in our world PD is not considered license
2020-10-23 12:39:52 <tehcloud> and without the ideological language of the LGPL
2020-10-23 12:40:31 <mps> simple is 'software is free' should apply to all software
2020-10-23 12:44:14 <mps> and fighting greedy selfish world without ideology is not possible, imo. So I understand RMS and FSF
2020-10-23 12:45:47 <maxice8> almost done with the checking
2020-10-23 12:45:52 <maxice8> it does not look good
2020-10-23 13:00:42 <ikke> maxice8: I think LGPL should be fine
2020-10-23 13:01:26 <maxice8> Let's document all of them just to be sure
2020-10-23 13:01:42 <ikke> understood
2020-10-23 13:01:45 <gavodavo[m]> So I
2020-10-23 13:01:51 <gavodavo[m]> Oops
2020-10-23 13:09:50 <gavodavo[m]> So I'm thinking of adding multiarch support for Alpine since musl now supports it. However, there's a limitation. For it to work, it needs to have separated include/ and lib/. A good way for doing this is the Debian way, which is /usr/lib(or include)/$(binarch). However, this would potentially mean modifying every APKBUILD that uses these directories.
2020-10-23 13:10:29 <maxice8> is separate include really needed ?
2020-10-23 13:10:41 <gavodavo[m]> An alternative would be to leave the include dir of the base arch to include/ and make the other archs a subdirectory, but idk how that would work
2020-10-23 13:10:47 <gavodavo[m]> maxice8: yes
2020-10-23 13:10:52 <gavodavo[m]> Source:
2020-10-23 13:11:01 <maxice8> Didn't Exherbo have a really nice multiarch arch @Cogitri ?
2020-10-23 13:11:11 <gavodavo[m]> https://wiki.musl-libc.org/guidelines-for-distributions.html
2020-10-23 13:11:15 <gavodavo[m]> >musl does support full multiarch with separate include and lib paths for each separate arch/ABI in the same filesystem, similar but not exactly the same as what Debian does. (Debian shares top-level include just not sys and bits; for musl this may unofficially work but it’s not officially supported and there’s no reason to believe it’s compatible with 3rd-party libs that may install arch-dependent headers gen
2020-10-23 13:11:15 <gavodavo[m]> at build time into that dir.)
2020-10-23 13:11:29 <gavodavo[m]> maxice8: Wut
2020-10-23 13:11:31 <gavodavo[m]> Nice
2020-10-23 13:11:59 <gavodavo[m]> Then I guess I'll wait for Cogitri's response
2020-10-23 13:16:38 <Cogitri> Exherbo did something similar to Debian: install everything to /usr/$CHOST/ and then symlink back to /usr for the actual host
2020-10-23 13:17:06 <Cogitri> So for x86_64-alpine-linux it'd link /usr/lib -> /usr/x86_64-alpine-linux/lib
2020-10-23 13:21:33 <gavodavo[m]> We can technically implement it, right?
2020-10-23 13:23:16 <maxice8> so --prefix=/usr/$CHOST basically
2020-10-23 13:23:34 <Cogitri> Yup
2020-10-23 13:23:54 <Cogitri> gavodavo[m]: Yup, but that's need support from both abuild and apk
2020-10-23 13:23:58 <Cogitri> And our tooling
2020-10-23 13:24:14 <Cogitri> And all APKBUILDs
2020-10-23 13:24:35 <Cogitri> since they're very simple they don't have much abstraction, so the last one is probably the most work
2020-10-23 13:24:46 <gavodavo[m]> Hmm, so it would be definitely a hard job
2020-10-23 13:24:54 <Cogitri> right now most APKBUILDs just assume that cc gotta be the right compiler
2020-10-23 13:25:36 <gavodavo[m]> I can work on various APKBUILDs, but for the rest...
2020-10-23 13:26:13 <mps> 
ACTION wonders do we need multilib

2020-10-23 13:26:23 <ikke> wine
2020-10-23 13:26:28 <gavodavo[m]> For stuff like box86, yeah
2020-10-23 13:26:30 <gavodavo[m]> Wine too
2020-10-23 13:26:32 <mps> 
ACTION wonders do we need wine :)

2020-10-23 13:26:45 <gavodavo[m]> We do need box86 though
2020-10-23 13:26:48 <gavodavo[m]> Imo
2020-10-23 13:26:53 <ikke> mps: I'd love to not need wine :P
2020-10-23 13:27:10 <mps> what is box86?
2020-10-23 13:27:18 <gavodavo[m]> Wait a sec
2020-10-23 13:27:28 <gavodavo[m]> https://github.com/ptitSeb/box86
2020-10-23 13:27:56 <gavodavo[m]> It's the biggest reason why I care about multilib
2020-10-23 13:29:29 <mps> ah, games
2020-10-23 13:30:05 <mps> few days ago I wrote that alpine becoming gamers platform ;p
2020-10-23 13:30:37 <gavodavo[m]> Well, I don't daily drive Alpine (yet)
2020-10-23 13:30:52 <gavodavo[m]> I do use postmarketOS and contribute to it though
2020-10-23 13:33:03 <mps> did I wrote above about fusion :)
2020-10-23 13:36:55 <gavodavo[m]> Fusion?
2020-10-23 13:40:30 <mps> 12:39 ............. mps| maybe we can discuss fusion alpine and pmOS :)
2020-10-23 13:46:18 <gavodavo[m]> Ah, I didn't join before that lol
2020-10-23 13:46:41 <gavodavo[m]> Yeah, some upstreaming from pmOS would be awesome
2020-10-23 14:36:29 <maxice8> ncopa: https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/60 https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/69
2020-10-23 14:37:05 <ikke> License adjustments can be tricky though
2020-10-23 14:38:36 <maxice8> yes
2020-10-23 14:39:01 <ikke> You'd need agreement for everyone who contributed to the repo
2020-10-23 14:40:59 <maxice8> even people that never touched with anything that interacts with openssl ?
2020-10-23 14:41:46 <ikke> afaik, yes. it affects the entire proejct, but IANAL :)
2020-10-23 14:42:25 <maxice8> very unfortunate
2020-10-23 14:42:49 <Hello71> problem is satisfying: 1. GPL cannot be combined with openssl; 2. whole project must be under same license; 3. each contributor must agree to change license on their part
2020-10-23 14:42:50 <ikke> But do we even have copyright over libfetch?
2020-10-23 14:43:18 <Hello71> the point 2 depends on which license you pick. copyleft licenses frequently require it
2020-10-23 14:43:28 <Hello71> otherwise point 1 wouldn't be a problem either
2020-10-23 14:46:44 <maxice8> apk info -W can't tell the owner of a directory
2020-10-23 14:51:10 <Hello71> isn't the point of a directory that it can contain multiple files potentially owned by different packages
2020-10-23 14:53:12 <ikke> yes
2020-10-23 14:53:26 <ikke> otherwise / could only be owned by one package
2020-10-23 15:40:23 <gavodavo[m]> Anyone, if they're interested to help in the multiarch stuff please lemme know.
2020-10-23 17:24:57 <ikke> Hmm, pulseaudio is interesting license wise
2020-10-23 17:25:27 <ikke> It seems in many cases the server side is effectively GPL, not LGPL
2020-10-23 19:18:55 <maxice8> https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/24
2020-10-23 19:19:48 <maxice8> the code looks great ^
2020-10-23 20:41:07 <maxice8> youtube-dl and dlc got dmca'd
2020-10-23 20:41:37 <maxice8> https://github.com/github/dmca/blob/master/2020/10/2020-10-23-RIAA.md , how does this affects us beside the obvious we have no sources and thus can't build it anymore ?
2020-10-23 20:41:38 <ikke> yeah
2020-10-23 20:41:49 <ikke> mentioned earlier in #a-ot
2020-10-23 20:42:10 <ikke> We do still have the source
2020-10-23 20:42:33 <maxice8> i see
2020-10-23 20:42:57 <ikke> http://distfiles.alpinelinux.org/distfiles/youtube-dl-2020.09.20.tar.gz
2020-10-23 20:43:09 <ikke> so, for now we can still build it
2020-10-23 20:43:42 <ikke> I guess we'll have to see what will happen in the future
2020-10-23 21:00:54 <detha> ehm, is git.a.o having issues?
2020-10-23 21:01:32 <ikke> apparently
2020-10-23 21:02:38 <ikke> But also just
2020-10-23 21:06:48 <ikke> load is very high
2020-10-23 21:28:04 <ikke> detha: it's back
2020-10-23 21:29:10 <detha> ikke: thanks for investigating (and fixing)
2020-10-23 21:29:35 <ikke> detha: I did not fix anything :P
2020-10-23 21:29:53 <ikke> Just noticed the host provider detected issues and I guess they restarted the host
2020-10-23 21:30:25 <ikke> Though, if they didn't, I would have restarted the machine :)
2020-10-23 21:30:42 <detha> ah, ok. It was just sitting there, looking at me, so I wondered if it was me or something else
2020-10-23 21:31:10 <ikke> Well, you reported it right before our own monitoring did :)
2020-10-23 22:16:01 <aparcar[m]> where can I find the source code of pkgs.alpinelinux.org/ ?
2020-10-23 22:20:18 <ikke> aparcar[m]: https://gitlab.alpinelinux.org/alpine/infra/aports-turbo
2020-10-23 22:20:42 <aparcar[m]> ikke: thanks for the quick response!
2020-10-23 22:21:11 <ikke> :_
2020-10-23 22:21:16 <ikke> :)
2020-10-23 22:21:24 <aparcar[m]> ikke: do you know the developers working on that code? I'm somewhat intrigued to build something similar for OpenWrt
2020-10-23 22:21:36 <ikke> clandmeter mostly
2020-10-23 22:22:09 <aparcar[m]> clandmeter: hello
2020-10-23 22:22:17 <ikke> He's kind of busy lately
2020-10-23 22:22:24 <aparcar[m]> who isn't...
2020-10-23 22:22:38 <aparcar[m]> okay thanks I'll open an issue in the repo asking if I can reuse some of the code
2020-10-24 00:19:47 <Ariadne> oh yeah openwrt is looking at app
2020-10-24 00:19:50 <Ariadne> apk
2020-10-24 00:19:56 <Ariadne> i keep forgetting about that
2020-10-24 00:35:03 <dalias> sorear, i checked path_open and it doesn't mishandle empty components
2020-10-24 00:35:33 <dalias> the first strspn skips all consecutive separators so that the strcspn can't return 0 except on end-of-string
2020-10-24 00:35:41 <dalias> oops wrong chan
2020-10-24 04:38:54 <aparcar[m]> Ariadne: currently only two of ~30 main devs are looking at apk but I'm confident ;)
2020-10-24 09:57:12 <np57> Hello everyone
2020-10-24 09:58:03 <np57> I wonder why I can't use the command wrmsr after loading msr kernel module like I do in Ubuntu
2020-10-24 09:58:45 <np57> I'll be thankful if someone could give more information why I couldn't
2020-10-24 10:01:26 <mps> np57: probably because there is no such command in alpine
2020-10-24 10:03:09 <ikke> np57: loading a kernel modules does not make commands available
2020-10-24 10:03:23 <ikke> it just makes the kernel support more things
2020-10-24 10:03:29 <np57> I'm newbie, thanks for the info
2020-10-24 10:03:42 <np57> I found that these commands related to a package called msr-tools
2020-10-24 10:05:08 <mps> yes, and this is not packaged in alpine, afaik
2020-10-24 10:05:14 <ikke> cannot find it
2020-10-24 10:05:18 <ikke> so someone would need to package it
2020-10-24 10:05:38 <ikke> There is no package that has wsmsr
2020-10-24 10:05:55 <mps> I thought about it few months ago but not sure is it much useful for general 'users'
2020-10-24 10:06:10 <np57> Yes, not in the repository
2020-10-24 10:06:15 <np57> https://github.com/intel/msr-tools
2020-10-24 10:06:44 <mps> it is useful for those who works with kernel
2020-10-24 10:07:30 <mps> np57: yes I know what is it and where it is, but again not sure if we should package it for alpine
2020-10-24 10:07:38 <mps> ikke: what you think?
2020-10-24 10:08:00 <ikke> I have no idea
2020-10-24 10:08:34 <mps> hmm, maybe we can because I looked at void and arch, they have it
2020-10-24 10:09:02 <mps> anyway, we already have a lot of pkgs, one more is not big problem
2020-10-24 10:09:18 <np57> Yayy!
2020-10-24 10:09:40 <mps> at the end it is simple pkg
2020-10-24 10:09:43 <ikke> yeah
2020-10-24 10:10:09 <np57> Because after like 7 hours I figured out how to make lbu work and how to use alpine in diskless mode properly
2020-10-24 10:10:14 <np57> now this is the only missing thing
2020-10-24 10:10:14 <mps> ok, I will copy it from my local aports and make MR later today
2020-10-24 10:10:25 <ikke> nice
2020-10-24 10:11:02 <np57> Thanks in advance guys.
2020-10-24 10:11:15 <np57> I really appreciate your efforts
2020-10-24 10:11:46 <mps> np57: np :)
2020-10-24 10:12:06 <mps> ikke and I live to make world happy :)
2020-10-24 10:12:20 <maxice8> mps: reviewed lxcfs
2020-10-24 10:12:29 <mps> maxice8: and?
2020-10-24 10:12:37 <maxice8> you forgot to reset pkgrel when upgrading
2020-10-24 10:12:44 <mps> uh
2020-10-24 10:13:02 <maxice8> actually lxd
2020-10-24 10:13:11 <maxice8> lxcfs is fine, actually merging it atm
2020-10-24 10:13:21 <mps> mps: don't make MR before morning coffer
2020-10-24 10:13:36 <maxice8> or use my githooks which check for that by looking at git diffs
2020-10-24 10:13:52 <maxice8> it will complain if you change pkgver and doesn't reset pkgrel to 0 :D
2020-10-24 10:13:56 <mps> I use your githooks
2020-10-24 10:14:06 <mps> maybe I need upgrade it
2020-10-24 10:15:31 <maxice8> https://github.com/maxice8/meltryllis/blob/gnome/alpinelinux/pre-commit
2020-10-24 10:17:00 <ikke> I use abump :P
2020-10-24 10:17:49 <mps> maxice8: thanks for reminding me
2020-10-24 10:18:39 <mps> btw, I'm not sure we need to have lxcfs anyore. afontain_ ?
2020-10-24 10:18:55 <ikke> What is it used for?
2020-10-24 10:19:06 <mps> iirc, anbox
2020-10-24 10:20:40 <afontain_> I don't think anbox uses that?
2020-10-24 10:20:53 <afontain_> it doesn't
2020-10-24 10:21:42 <mps> afontain_: sorry then, I thought you insisted on keeping it. must be someone else but I can't remember who
2020-10-24 11:32:33 <gavodavo[m]> Should the APKBUILD or abuild do the symlinking from include/$CHOST/file to include/
2020-10-24 11:32:41 <gavodavo[m]> ?
2020-10-24 11:35:19 <Cogitri> That'd probably be done in the alpine-baselayout APKBUILD
2020-10-24 12:33:26 <gavodavo[m]> Cogitri: Hmm
2020-10-24 12:34:21 <gavodavo[m]> Btw the symlink should be for each individual file, right?
2020-10-24 12:35:17 <gavodavo[m]> Because if the symlink was to the directory, stuff inside include/$CHOST could easily get messy
2020-10-24 12:35:59 <ikke> how so?
2020-10-24 12:39:00 <gavodavo[m]> ikke: Because then, another multiarch directory, for example, would get inside include/$CHOST/$CHOST-multiarch
2020-10-24 12:40:24 <Cogitri> The symlink is for the dir
2020-10-24 12:40:37 <Cogitri> You just set prefix to /usr/$CBUILD
2020-10-24 12:42:03 <insep_> mps: do you have any armv7 machines around?
2020-10-24 12:42:22 <mps> insep_: yes
2020-10-24 12:42:41 <insep_> can you try installing libogg on them?
2020-10-24 12:43:08 <insep_> for me it fails with BAD signature, among with several other packages
2020-10-24 12:43:20 <ikke> I can try in a docker container
2020-10-24 12:43:26 <insep_> pls do
2020-10-24 12:43:49 <mps> it works without problem
2020-10-24 12:44:08 <insep_> i might be because my machine crashed during running apk, but i just want to check
2020-10-24 12:44:10 <insep_> welp
2020-10-24 12:44:20 <insep_> seems like i have to regenerate my image :\
2020-10-24 12:44:56 <gavodavo[m]> Cogitri: Wait I don't understand. Wdym by prefix? The multiarch directory?
2020-10-24 12:45:12 <ikke> ./configure --prefix=
2020-10-24 12:45:12 <mps> insep_: /o\
2020-10-24 12:45:48 <insep_> any way of fiхing it without rebuilding image? :D
2020-10-24 12:46:11 <ikke> apk fix?
2020-10-24 12:46:30 <mps> depends what it broken
2020-10-24 12:46:37 <insep_> didn't help
2020-10-24 12:46:46 <ikke> When do you get those errors?
2020-10-24 12:47:03 <gavodavo[m]> ikke: Oh.
2020-10-24 12:47:14 <Cogitri> inseo_: Since the CDN uses a different server for different countries it doesn't really mean anything if it works for mps and not for you
2020-10-24 12:47:44 <insep_> both when running `apk fix libogg` and `apk add` on package which pulls it
2020-10-24 12:48:03 <insep_> Cogitri: i have dl-2 mirror
2020-10-24 12:48:26 <gavodavo[m]> So the layout would be /usr/include for base $CARCH and /usr/include-multiarch?
2020-10-24 12:48:48 <mps> 'curl -X ...'
2020-10-24 12:49:00 <Cogitri> No, it'd be /usr/include for your $CHOST and /usr/$CBUILD/include for any other arch
2020-10-24 12:49:24 <gavodavo[m]> Ohh
2020-10-24 12:49:34 <gavodavo[m]> Then it's easier than I thought
2020-10-24 12:51:22 <gavodavo[m]> Then I don't need to modify every APKBUILD
2020-10-24 12:51:58 <gavodavo[m]> We just need to create a multilib repo.
2020-10-24 12:52:15 <Cogitri> Well, you'd need to modify them to set --prefix to /usr/$CBUILD
2020-10-24 12:52:29 <Cogitri> right now they all install to /usr/ which won't fly for multiarch
2020-10-24 12:53:23 <insep_> mps: can you give an eхample?
2020-10-24 12:54:26 <mps> insep_: I lost it, maybe ikke have it ready
2020-10-24 12:54:59 <mps> curl call to invalidate bad checksum on mirrors
2020-10-24 12:55:58 <ikke> Even with dl-2 it doesn't give any errors
2020-10-24 12:56:05 <ikke> insep_: does /etc/apk/cache exist?
2020-10-24 12:56:43 <insep_> yup
2020-10-24 12:56:50 <ikke> then remove the offending packages from that dir
2020-10-24 12:57:14 <insep_> ...and i wonder why it didn't get clean when i ran apk cache clean :<
2020-10-24 12:58:43 <gavodavo[m]> Cogitri: Oh, so binaries would be separated too?
2020-10-24 12:59:22 <maxice8> everything would be separated I think
2020-10-24 12:59:39 <insep_> welp, at least now peruse doesn't fail with linker errors :D
2020-10-24 12:59:43 <maxice8> every arch would be installed into /usr/$CARCH and one would just link it back into /usr
2020-10-24 12:59:46 <insep_> ikke: thanks!
2020-10-24 12:59:59 <ikke> kcool
2020-10-24 13:00:13 <insep_> *kool
2020-10-24 13:00:21 <insep_> it's kde app after all :D
2020-10-24 13:00:55 <ikke> heh
2020-10-24 13:02:39 <maxice8> Opinions ? https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/24 :D
2020-10-24 13:02:45 <mps> I agree with 'everything would be separated I think', though on separate machines :)
2020-10-24 13:03:45 <ikke> maxice8: I'm not really following what it's trying to achieve
2020-10-24 13:04:31 <mps> ikke: iiuc, multiarch on alpine
2020-10-24 13:04:36 <ikke> minor version provides for python packages?
2020-10-24 13:04:47 <ikke> NO, different thign
2020-10-24 13:04:56 <ikke> Was replying on that MR maxice8 referred to
2020-10-24 13:04:56 <insep_> i agree with 'everything would be separated I think', would prevent us from running linker in qemu
2020-10-24 13:04:58 <insep_> maybbe
2020-10-24 13:05:01 <insep_> not sure
2020-10-24 13:05:21 <insep_> not sure how alpine crosscompiles packages either
2020-10-24 13:05:31 <ikke> We don't
2020-10-24 13:06:08 <ikke> Only the toolchain is ininitally cross-compiled when bootstrapping a new arch, but then everything is native
2020-10-24 13:06:40 <insep_> :(
2020-10-24 13:07:50 <mps> cross build will be can of worms for us
2020-10-24 13:08:52 <insep_> welp, we already have some sort of crosscompilation in pmos :D
2020-10-24 13:09:10 <mps> insep_: keep it there! ;P
2020-10-24 13:09:42 <gavodavo[m]> By cross compilation, he means using qemu :p
2020-10-24 13:09:53 <mps> ah
2020-10-24 13:09:54 <insep_> we mount native chroot in foreign chroot, make native compilers available in foreign chroot and run build in it
2020-10-24 13:09:57 <gavodavo[m]> Except in the case of kernels
2020-10-24 13:10:06 <mps> that is right cross build then
2020-10-24 13:10:15 <insep_> not as fast as it could be nor it's reliable
2020-10-24 13:10:35 <gavodavo[m]> Yeah, it's slow af
2020-10-24 13:11:01 <insep_> some packages can't be crosscompiled using this thanks to qemu bugs, some get stuck somewhere during builds
2020-10-24 13:11:24 <gavodavo[m]> Compiling godot for aarch64 took me about 2 hours :(
2020-10-24 13:12:00 <insep_> in first case build doesn't get stuck, but resulting binary doesn't work
2020-10-24 13:12:14 <insep_> gavodavo: it's still faster than running full build in qemu ;)
2020-10-24 13:12:29 <mps> gavodavo[m]: build first firefox for aarch64 when they switch to rust took me more than 10 hours natively
2020-10-24 13:12:59 <gavodavo[m]> mps: Lol
2020-10-24 13:13:14 <gavodavo[m]> I wonder how long will it take on qemu
2020-10-24 13:18:02 <gavodavo[m]> > Cogitri: Oh, so binaries would be separated too?
2020-10-24 13:18:02 <gavodavo[m]> If this is the case, then we should symlink the binaries, or add usr/multiarch/bin to $PATH
2020-10-24 13:18:34 <gavodavo[m]> One is more cleaner and less error prone, the other is easier
2020-10-24 13:18:44 <gavodavo[m]> >one is more cleaner
2020-10-24 13:18:44 <gavodavo[m]> Imo
2020-10-24 13:20:38 <gavodavo[m]> * >one is more cleaner
2020-10-24 13:20:38 <gavodavo[m]> Imo
2020-10-24 13:22:09 <mps> building x86 on x864_64 is easy and fast, same is for armhf and armv7 on aarch64
2020-10-24 13:22:39 <ikke> yes, because you don't need to emulate, right?
2020-10-24 13:22:45 <ikke> Those CPU's support it
2020-10-24 13:22:54 <mps> yes
2020-10-24 13:23:15 <mps> you know better than me, you care for builders
2020-10-24 13:24:12 <ikke> nod
2020-10-24 13:24:32 <ikke> armhf and armv7 are both built on aarch64 hosts
2020-10-24 13:26:28 <mps> and I built and fixed (a lot) packages for x86 in lxc on x86_64 with 6GB RAM
2020-10-24 14:25:41 <Hello71> regarding msr-tools, I think there is no rush to package it, because it is being deprecated in linux kernel
2020-10-24 14:26:34 <mps> Hello71: yes I know, but it is still in linux-next
2020-10-24 14:27:18 <mps> and alpine will use old kernel for more than a 3 years
2020-10-24 14:27:45 <mps> maybe 4 years
2020-10-24 14:28:14 <mps> and msr-tools don't need much works, I hope
2020-10-24 14:42:02 <gavodavo[m]> Hmm, should $CHOST be set by APKBUILD or abuild?
2020-10-24 14:42:41 <ikke> abuild
2020-10-24 14:43:20 <gavodavo[m]> Ok
2020-10-24 14:43:43 <ikke> It's set by the user even
2020-10-24 14:44:00 <ikke> They are env variables set by the user when cross-compiling
2020-10-24 14:44:05 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L2629
2020-10-24 14:44:38 <gavodavo[m]> Oh, ok
2020-10-24 14:45:00 <gavodavo[m]> However, for multilib packages we may want to set it without user input
2020-10-24 14:45:53 <gavodavo[m]> For example, if ARCH=arm64, set CHOST to x86_64-musl-whatever
2020-10-24 14:47:52 <ikke> gavodavo[m]: if it's a dedicated builder that builds these, than you could add it to /etc/abuild.conf
2020-10-24 14:49:57 <gavodavo[m]> I think I can integrate it into abuild without separating it
2020-10-24 14:50:10 <gavodavo[m]> But that could work too
2020-10-24 14:51:43 <gavodavo[m]> I have an idea
2020-10-24 14:52:04 <gavodavo[m]> Create a property in APKBUILD for enabling multilib
2020-10-24 14:52:37 <gavodavo[m]> multilib=1?
2020-10-24 14:53:30 <gavodavo[m]> Maybe I need to think this more
2020-10-24 14:53:41 <ikke> options="multilib"
2020-10-24 14:54:32 <ikke> What would that do then exactly?
2020-10-24 14:54:57 <ikke> I gather the source would have to be built twice if there is not a dedicated builder, correct?
2020-10-24 15:05:51 <gavodavo[m]> ikke: It's just that I was thinking about having the arch variable be the original one(for example, i386) but, with that option enabled, make abuild check whether the building arch is compatible with that one.
2020-10-24 15:06:00 <Ariadne> i'm not interested in supporting multilib
2020-10-24 15:06:14 <Ariadne> please let us solve this correctly with multiarch
2020-10-24 15:06:23 <gavodavo[m]> However, now that I think about it, I find it simpler to just have arch be the target one
2020-10-24 15:06:33 <gavodavo[m]> Ariadme: oops, mixed terms
2020-10-24 15:06:37 <gavodavo[m]> I mean multiarch
2020-10-24 15:07:03 <Ariadne> if you want to support multiarch, all it requires is adjusting --libdir on all APKBUILDs and adjusting musl's library search paths
2020-10-24 15:07:14 <Ariadne> and some mild toolchain adjustments
2020-10-24 15:07:20 <gavodavo[m]> This will have completely separated include/, lib/, and potentially usr/
2020-10-24 15:07:53 <Ariadne> other than that, it should not be something packages opt in or opt out of
2020-10-24 15:08:00 <gavodavo[m]> > if you want to support multiarch, all it requires is adjusting --libdir on all APKBUILDs and adjusting musl's library search paths
2020-10-24 15:08:00 <gavodavo[m]> Not all APKBUILDs if we make a separate repo called multiarch
2020-10-24 15:08:09 <Ariadne> yes i am against that
2020-10-24 15:08:21 <gavodavo[m]> Why?
2020-10-24 15:08:33 <Ariadne> because i want all APKBUILDs to behave the same
2020-10-24 15:09:14 <Ariadne> the only multiarch approach i will support is one that is universal
2020-10-24 15:09:24 <Ariadne> we either do this properly, or we do not do it at all
2020-10-24 15:10:31 <gavodavo[m]> Hmm, so the idea is:
2020-10-24 15:10:53 <Ariadne> you're not going to convince me, don't even bother
2020-10-24 15:11:31 <gavodavo[m]> I'm not gonna, just seeing what we should do if we go that way
2020-10-24 15:11:35 <gavodavo[m]> Wait, brb
2020-10-24 15:12:07 <gavodavo[m]> By that way I mean the universal approach
2020-10-24 15:12:31 <Ariadne> i want true multiarch, where apk is aware of what archs are enabled, and can install packages for each arch
2020-10-24 15:12:37 <Ariadne> and you can install qemu-user for those archs
2020-10-24 15:12:41 <Ariadne> and run programs
2020-10-24 15:12:53 <Ariadne> that would make my life as an embedded dev much easier
2020-10-24 15:13:06 <Ariadne> a partial solution will make my life harder, not easier
2020-10-24 15:13:32 <Ariadne> because then to make use of it, i will have to incrementally convert apkbuilds to support multiarch and move them to this "multiarch" repo
2020-10-24 15:13:51 <Ariadne> which is unnecessarily complicated
2020-10-24 15:14:20 <Ariadne> what we should do is implement support for loading multiarch ELFs, by adjusting toolchain and musl
2020-10-24 15:14:45 <Ariadne> and then we can incrementally move to the new way (which can largely be automated)
2020-10-24 15:14:53 <gavodavo[m]> >i want true multiarch, where apk is aware of what archs are enabled, and can install packages for each arch
2020-10-24 15:14:53 <gavodavo[m]> So if I want to run, for example, box86(which is only compatible with armhf), I can run it on, say, aarch64, right?
2020-10-24 15:15:16 <Ariadne> box86 won't run on qemu
2020-10-24 15:15:30 <Ariadne> what i need is the ability to do things like
2020-10-24 15:15:37 <gavodavo[m]> Exactly, I want to run it natively
2020-10-24 15:15:38 <Ariadne> clang --target aarch64-alpine-linux-musl
2020-10-24 15:15:48 <Ariadne> and then run that binary as a quick test
2020-10-24 15:16:04 <Ariadne> ight now, what you can do is use tools like dabuild
2020-10-24 15:16:24 <Ariadne> but if i can just install aarch64 toolchain on my x86 machine
2020-10-24 15:16:31 <Ariadne> i can cross compile on the spot
2020-10-24 15:16:49 <Ariadne> and clang doesnt have to run on qemu-user, so you don't get performance hit of emulation there
2020-10-24 15:17:12 <gavodavo[m]> I think we have different purposes for multiarch
2020-10-24 15:17:30 <gavodavo[m]> I want to be able to run programs that are 32 bit on 64 bit machines
2020-10-24 15:17:38 <Ariadne> multiarch can solve that too
2020-10-24 15:17:47 <Ariadne> proper multiarch solves ALL problems
2020-10-24 15:17:52 <gavodavo[m]> Without qemu?
2020-10-24 15:18:06 <Ariadne> if the silicon can run both archs yes
2020-10-24 15:18:14 <Ariadne> if the silicon can't, then obviously you need emulation
2020-10-24 15:18:28 <gavodavo[m]> Then perfect, I think we're on the same page
2020-10-24 15:18:31 <Ariadne> so if your aarch64 can also run armv7, it will work
2020-10-24 15:18:41 <Ariadne> (some aarch64 cannot run armv7 though, watch out for that)
2020-10-24 15:19:05 <ikke> And I think in a couple of years, none will support it anymore
2020-10-24 15:19:13 <ikke> I've read that the stop supporting it
2020-10-24 15:19:23 <Ariadne> box86 doesn't really give you anything over qemu anyway
2020-10-24 15:19:37 <Ariadne> qemu is probably faster for emulating x86 code on aarch64
2020-10-24 15:20:06 <Ariadne> just something to think about :)
2020-10-24 15:20:07 <gavodavo[m]> >box86 doesn't really give you anything over qemu anyway
2020-10-24 15:20:07 <gavodavo[m]> It's much faster
2020-10-24 15:20:15 <Ariadne> according to whom?
2020-10-24 15:20:26 <gavodavo[m]> And even then, box86 is just an example
2020-10-24 15:20:28 <Ariadne> for x86 to armv7, i might believe
2020-10-24 15:20:43 <Ariadne> but x86 to aarch64, TCG has lots of opportunities it wouldn't have on armv7
2020-10-24 15:22:02 <Ariadne> anyway, point is
2020-10-24 15:22:19 <Ariadne> if we move to multiarch, let us move to multiarch correctly
2020-10-24 15:22:59 <Ariadne> moving to multiarch with some additional repo is just going to screw everything up
2020-10-24 15:23:36 <gavodavo[m]> >if we move to multiarch, let us move to multiarch correctly
2020-10-24 15:23:36 <gavodavo[m]> I don't mind whatever approach we use
2020-10-24 15:24:13 <gavodavo[m]> What would I need to do for multiarch?
2020-10-24 15:24:46 <Ariadne> the first step would be to adjust the toolchain and musl to have arch-dependent search paths
2020-10-24 15:25:01 <Ariadne> debian use /usr/[triplet] for their multiarch sysroots
2020-10-24 15:25:31 <Ariadne> so presumably, we want to wind up in a situation where gcc on aarch64 is searching
2020-10-24 15:25:31 <Cogitri> Yes, /usr/$CBUILD would work
2020-10-24 15:25:39 <Ariadne> /usr/$CBUILD/lib before /usr/lib
2020-10-24 15:25:51 <Ariadne> and /usr/$CBUILD/include before /usr/include
2020-10-24 15:26:32 <Ariadne> then its a matter of adjusting packages
2020-10-24 15:26:42 <Ariadne> musl also needs its search paths adjusted
2020-10-24 15:26:52 <gavodavo[m]> > the first step would be to adjust the toolchain and musl to have arch-dependent search paths
2020-10-24 15:26:52 <gavodavo[m]> By toolchain you mean abuild, gcc, etc. right?
2020-10-24 15:26:55 <Ariadne> ys
2020-10-24 15:26:57 <Ariadne> yes
2020-10-24 15:28:18 <gavodavo[m]> Hmm, abuild seems the easier to start with
2020-10-24 15:29:01 <Ariadne> gcc has to come before abuild
2020-10-24 15:29:06 <gavodavo[m]> gcc, clang, and other compilers could probably be the hardest part regarding toolchain
2020-10-24 15:29:30 <gavodavo[m]> >gcc has to come before abuild
2020-10-24 15:29:30 <gavodavo[m]> Oh
2020-10-24 15:30:10 <gavodavo[m]> Then when I get to my PC I'll start looking what Debian modifies from gcc so that we can implement it here
2020-10-24 15:30:38 <Ariadne> also this wont happen until after 3.13 release
2020-10-24 15:31:02 <gavodavo[m]> Understandable
2020-10-24 15:31:24 <Ariadne> this will likely take a year to implement, so i suggest carefully planning, breaking it down into a series of system changes, proposing them and following them to implementation
2020-10-24 15:32:33 <dalias> ariadne, musl is easy to adjust with .path files
2020-10-24 15:32:43 <Ariadne> yes, i know its easy
2020-10-24 15:32:53 <Ariadne> i was just identifying it as something that needs to be done :)
2020-10-24 15:33:03 <dalias> but you may need logic for users who already have path files
2020-10-24 15:33:19 <dalias> e.g. one containing the default paths plus /opt/something/lib or whatever
2020-10-24 15:34:10 <dalias> probably the upgrade workflow should offer (default) to sed-replace all the standard paths in the existing .path file with the new multiarch location
2020-10-24 15:34:56 <Ariadne> i would agree
2020-10-24 15:35:44 <gavodavo[m]> >this will likely take a year to implement, so i suggest carefully planning, breaking it down into a series of system changes, proposing them and following them to implementation
2020-10-24 15:35:44 <gavodavo[m]> Correct me if I'm wrong, but I'd have to submit all or nothing of the changes I do, preferrably to another branch right? Else stuff could get messy.
2020-10-24 15:36:31 <dalias> ariadne, i'm looking at my long queue-to-push now, so i can get back to fork topic
2020-10-24 15:36:46 <Ariadne> gavodavo[m]: no.  it will have to be done in incremental changes
2020-10-24 15:37:00 <Ariadne> stop-the-world switch to multiarch is unrealistic
2020-10-24 15:37:07 <Ariadne> we didnt even stop the world to switch to musl from uclibc
2020-10-24 15:41:41 <dalias> i dont think i realized that, wow
2020-10-24 15:42:52 <Ariadne> (uclibc alpine and musl alpine are indeed abi-incompatible though.  that migration required installing busybox-static and apk-tools-static)
2020-10-24 15:52:44 <dalias> ariadne, at least one of the patches in my queue is wrong enough i need to fix some stuff before pushing
2020-10-24 15:52:57 <Ariadne> thats fine :)
2020-10-24 15:53:19 <dalias> holding abort lock across posix_spawn child execution is not valid :-p
2020-10-24 15:53:33 <Ariadne> i just am hopeful that we can get back to using X without it locking up every day
2020-10-24 15:53:34 <Ariadne> ;)
2020-10-24 15:53:47 <Ariadne> and yes
2020-10-24 15:53:54 <Ariadne> programs shouldn't do all this shit after fork
2020-10-24 15:53:57 <Ariadne> but
2020-10-24 15:54:23 <Ariadne> other libcs have given them permission to commit crimes ;/
2020-10-24 15:54:37 <dalias> well now the tables are turned *eg*
2020-10-24 15:55:15 <dalias> glibc does this half-ass and just makes malloc work, which leads programmers to think everything does because all the other stuff is called so infrequently the chance of deadlock is near-zero
2020-10-24 15:55:29 <Ariadne> so does freebsd
2020-10-24 15:55:39 <dalias> so if musl actually makes the child environment safe...
2020-10-24 15:55:57 <dalias> it will be programs which work on musl deadlocking once a decade on glibc etc :)
2020-10-24 16:06:14 <gavodavo[m]> >gavodavo: no.  it will have to be done in incremental changes
2020-10-24 16:06:15 <gavodavo[m]> Ok
2020-10-24 16:07:40 <gavodavo[m]> Then I have to make sure my changes are also compatible with the current state
2020-10-24 16:42:45 <dalias> ariadne, ah n/m i was wrong about my abort lock patch, lock is not held anywhere near as long as i remembered
2020-10-24 18:43:32 <ikke> Interesting: https://lists.gnu.org/archive/html/info-gnu/2020-10/msg00009.html gdb 10.1 supports symbol servers
2020-10-24 18:44:42 <ikke> "Support for debuginfod, an HTTP server for distributing ELF/DWARF
2020-10-24 18:44:45 <ikke>   debugging information as well as source code.
2020-10-24 18:44:47 <ikke> "
2020-10-24 18:44:59 <Cogitri> Huh, curious what's that used for
2020-10-24 18:46:11 <ikke> "This is huge! Microsoft's symbol servers have long made it easier to deal with PDBs. This will finally help with the annoyingness of -debuginfo and -debug Linux packages."
2020-10-24 18:46:43 <Cogitri> Oh neat
2020-10-24 18:59:24 <mps> and got BPF debug
2020-10-24 19:03:51 <Cogitri> Isn't eBPF the new hotness by now
2020-10-24 19:04:46 <mps> yes
2020-10-24 19:12:26 <gavodavo[m]> So I found this
2020-10-24 19:12:29 <gavodavo[m]> http://gcc.gnu.org/onlinedocs/gccint/Target-Fragment.html
2020-10-24 19:12:53 <gavodavo[m]> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/DPaRaVDHoLYtlmuUxaiQzxEY/message.txt >

2020-10-24 19:15:31 <gavodavo[m]> So it's just a matter of adding `MULTIARCH_DIRNAME=$CHOST`?
2020-10-24 19:15:46 <Ariadne> i don't know, but
2020-10-24 19:15:51 <Ariadne> don't plan on this happening anytime soon
2020-10-24 19:16:12 <gavodavo[m]> Noted that
2020-10-24 19:16:29 <gavodavo[m]> However if we want it to happen we have to at least set the basics
2020-10-24 19:16:50 <Ariadne> sure.  i am just saying i have no intention to even start working on this until after 3.13 release
2020-10-24 19:18:03 <gavodavo[m]> Still, I want to have the APKBUILDs(of the toolchain) ready for when that release happens
2020-10-24 19:18:24 <gavodavo[m]> Or at least as far as I can go
2020-10-24 19:43:10 <gavodavo[m]> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/TifTQaNsIIbOlozNEmHqnarz/message.txt >

2020-10-24 19:43:23 <gavodavo[m]> This should be good enough in theory, right?
2020-10-25 05:16:32 <user____> Hello! Is possible persistence in alpine live standar like slax, with savechanges you can save data from ram to e.g 02.xorg.sb module. thanks
2020-10-25 06:24:03 <tmlind> mps: fyi, firefox works again on armv7 :) well at least non-esr version, the alignment faults with javascript pages are gone, maybe with recent update of mozjs78
2020-10-25 06:25:37 <tmlind> hmm not seeing mozjs78 as firefox dependency though, so probably actually just firefox got updated
2020-10-25 06:29:54 <tmlind> argh, not so, still seeing firefox alignment exceptions on armv7, it's just less often now :(
2020-10-25 06:31:26 <mps> tmlind: thanks for info
2020-10-25 06:32:27 <mps> I'm not sure but think it is related to some 'low level' change in firefox
2020-10-25 06:33:17 <mps> maybe even in gcc on armv7
2020-10-25 06:35:12 <mps> tmlind: do you run tests on 3.12 or edge?
2020-10-25 06:38:31 <tmlind> mps: just running edge here
2020-10-25 06:39:04 <tmlind> mps: firefox starts fine, but then crashes on opening a javascript using page
2020-10-25 06:40:14 <mps> alignment bug 'must be' somewhere in low level
2020-10-25 06:40:55 <mps> I doubt it is in javascript, but who knows nowadays
2020-10-25 06:42:56 <tmlind> yes weird
2020-10-25 06:43:30 <mps> maybe even 'bug' in musl on armv7
2020-10-25 06:45:13 <tmlind> mps: yes did not notice debian carrying any related looking patches
2020-10-25 06:46:19 <mps> I don't have any armv7 box where I can run firefox for about 3 months and I can't test it
2020-10-25 06:49:28 <mps> but again, no one reported alignment bug on armv7 for any other pkg on armv7 edge, so I really don't know where bug is
2020-10-25 06:49:45 <tmlind> mps: ok bummer, seems like you could use some armv7 box with ethernet, sata and lots of cores and ram
2020-10-25 06:50:39 <tmlind> mps: hmm or maybe one of the 4 core samsung chromebooks, i gues those would work with linux-edge
2020-10-25 06:51:27 <mps> yes, but I gave this box to my son
2020-10-25 06:52:23 <tmlind> heh ok, have to wait few years then :)
2020-10-25 06:56:00 <mps> who knows, maybe this bug will appear on some other pkgs when more people start to use edge
2020-10-25 06:56:19 <mps> and then it will be easier to find 'suspect'
2020-10-25 06:56:57 <Cogitri> tmlind: fwiw mozjs78 is just a standalone version of Firefox' JS engine, it's not shared with FF itself
2020-10-25 06:57:28 <Cogitri> It's probably in the JS engine itself
2020-10-25 06:58:24 <mps> Cogitri: do you know if JS engine use some ASM code
2020-10-25 06:58:39 <mps> s/some/any/
2020-10-25 06:58:39 <alpine-meetbot> mps meant to say: Cogitri: do you know if JS engine use any ASM code
2020-10-25 06:59:24 <Cogitri> I haven't really looked at Spidermonkey but it'd surprise me if it didn't
2020-10-25 06:59:54 <mps> heh
2020-10-25 07:00:04 <Cogitri> Anyone wants to get something merged before the builders are busy for a few hours w/ new chromium?
2020-10-25 07:01:18 <mps> sunday morning is good for building such monster :)
2020-10-25 07:02:49 <mps> Cogitri: imo, go ahead
2020-10-25 07:15:52 <tmlind> Cogitri: ok yeah i figured thanks
2020-10-25 07:16:40 <tmlind> Cogitri, mps: if the alignment issue was a missing packed in some firefox header struct, it would show up also on debian.. maybe some missing compiler flag?
2020-10-25 07:16:56 <tmlind> anyways, gotta go catch a train now, bbl
2020-10-25 07:19:33 <mps> tmlind: and sorry, I don't have much free time in last months (who have) to work and debug 'high' level pkgs
2020-10-25 07:20:49 <mps> tmlind: maybe someone can look at kiss linux if they manage to make it working on armv7
2020-10-25 09:49:53 <tmlind> mps: no worries, i may end up doing it at some point
2020-10-25 11:26:29 <gavodavo[m]> Ariadne: Ik you said that you have no intention on working on this for now, but I need a suggestion. But should we symlink base(I mean, the actual architecture) $CHOST's files into /usr/include, /usr/lib, etc.?
2020-10-25 11:30:52 <Ariadne> yes
2020-10-25 11:31:35 <gavodavo[m]> Should it be done by abuild, apk, or APKBUILDs?
2020-10-25 11:33:55 <maxice8> alpine-baselayout ?
2020-10-25 11:36:58 <ikke> gavodavo[m]: I think we want to avoid as much as possible to have to do things in each and every APKBUILD
2020-10-25 11:37:31 <ikke> (Though, we don't want to add too much abstraction either)
2020-10-25 11:59:05 <gavodavo[m]> >alpine-baselayout ?
2020-10-25 11:59:05 <gavodavo[m]> Ahh, right
2020-10-25 11:59:21 <gavodavo[m]> > gavodavo: I think we want to avoid as much as possible to have to do things in each and every APKBUILD
2020-10-25 11:59:22 <gavodavo[m]> Yeah, makes sense
2020-10-25 12:00:36 <gavodavo[m]> Oh, and I don't think I have to link every file, I just need to ln -s usr/$CHOST/whatever usr/whatever
2020-10-25 12:01:44 <gavodavo[m]> An exception would be usr/bin, since we'll probably want to symlink from other $CHOSTs
2020-10-25 12:03:27 <gavodavo[m]> Also, if gcc, APKBUILD, and others are correctly set, the multiarch binaries would just work™(as long as they're arch compatible), right?
2020-10-25 12:05:47 <mps> maxice8: do you plan to update aports githooks with your ones
2020-10-25 12:06:00 <maxice8> no
2020-10-25 12:06:22 <mps> ok
2020-10-25 12:18:30 <Hello71> mps: I don't think you can implement jit without asm
2020-10-25 12:23:32 <mps> Hello71: yes, in nowadays systems, but my question was more of rhetorical ones
2020-10-25 12:24:18 <Hello71> uh... even s/rhetorical/historical/ I don't understand
2020-10-25 12:26:04 <mps> huh, I asked if JS engine have ASM code, that was what I expected and asked because thought that Cogitri already know, and I don't need to look for it
2020-10-25 12:32:33 <Hello71> uh... never mind then
2020-10-25 12:56:43 <Ariadne> gadodavo[m]: i think instead of trying to write code this is something that we need to discuss and implement in steps
2020-10-25 12:57:04 <Ariadne> gavodavo[m]: ^
2020-10-25 13:16:36 <gavodavo[m]> Ariadne: Hmm, ok
2020-10-25 13:19:16 <gavodavo[m]> The first step I think has already been done(which is setting gcc to prioritize usr/$CHOST), but I haven't tested it yet. When I get the time I'll start compiling it and testing it in a chroot
2020-10-25 13:28:48 <mps> hmm, is it 'allowed' by (unwritten) policy to move pkg without asking maintainer
2020-10-25 13:32:39 <ikke> I think it's common courtecy to ask it
2020-10-25 13:33:59 <mps> also I thought so, even for big or important update
2020-10-25 13:35:23 <mps> (ncopa's pkgs are exception because he wrote once when I answered that it is ok for developers)
2020-10-25 13:35:38 <mps> when I asked*
2020-10-25 13:35:49 <ikke> Yeah, and ncopa by default owns a lot of packacges
2020-10-25 13:35:55 <ikke> s/owns/maintains
2020-10-25 13:35:55 <alpine-meetbot> ikke meant to say: Yeah, and ncopa by default maintains a lot of packacges
2020-10-25 13:37:40 <mps> I upgrade/fix some of his pkgs but for big/important chnages always ask or assign MR to him
2020-10-25 16:47:11 <PureTryOut[m]2> Could anyone merge !13976? It's just a pkgrel bump to rebuild against latest kpmcore version
2020-10-25 16:54:23 <PureTryOut[m]2> ikke: ooh woops, I just assumed it would build. I'll check it out
2020-10-25 17:05:31 <PureTryOut[m]2> ikke: it needed a package upgrade instead, fixed. Would be nice if it could be merged after CI is done as currently it can't be installed at all
2020-10-25 17:15:00 <PureTryOut[m]2> CI succeeded
2020-10-25 17:17:48 <ikke> rebase is still stuck though
2020-10-25 17:17:56 <ikke> Working on it
2020-10-25 17:19:25 <PureTryOut[m]2> Yeah it seems to get stuck sometimes
2020-10-25 17:19:44 <ikke> Has to do with the malloc after fork issue
2020-10-25 17:20:12 <ikke> https://bugs.ruby-lang.org/issues/17189
2020-10-25 17:20:39 <PureTryOut[m]2> Ah ok, annoying
2020-10-25 17:22:09 <ikke> Ok, succeeded now :)
2020-10-25 17:22:16 <PureTryOut[m]2> Yay
2020-10-25 17:22:24 <ikke> 
ACTION just killed all ssh-gitaly processes :P

2020-10-25 17:23:00 <ikke> will merge now after pipeline succeeds again
2020-10-25 17:23:25 <PureTryOut[m]2> Thanks!
2020-10-25 17:26:32 <ikke> merged
2020-10-25 17:26:39 <PureTryOut[m]2> Awesome, thanks!
2020-10-25 17:28:29 <Ariadne> doing some experiments involving utmps :)
2020-10-25 17:30:01 <Ariadne> ERROR: plasma-workspace-5.20.1.1-r0: trying to overwrite usr/share/kservices5/fontinst.desktop owned by plasma-desktop-5.19.5-r0.
2020-10-25 17:30:13 <Ariadne> plasma-workspace needs replaces=plasma-desktop<5.20
2020-10-25 17:30:49 <Ariadne> PureTryOut[m]2: any objection ?
2020-10-25 17:32:58 <PureTryOut[m]2> Oh yeah noticed that but didn't have time to look into that, no that's fine to me
2020-10-25 17:33:08 <PureTryOut[m]2> I didn't even realize replaces also allows versions
2020-10-25 17:34:20 <Ariadne> replaces is a dependency description like any other :)
2020-10-25 17:36:22 <Ariadne> testing upgrade with fixed package and will then push
2020-10-25 17:36:22 <Ariadne> :)
2020-10-25 17:39:17 <Ariadne> utmps-0.0.3.2-r0 contains:
2020-10-25 17:39:18 <Ariadne> bin/utmps-wtmpd
2020-10-25 17:39:18 <Ariadne> bin/utmps-utmpd
2020-10-25 17:39:23 <Ariadne> hmm, this should be in sbin i think?
2020-10-25 18:10:42 <Ariadne> hmm
2020-10-25 18:10:53 <Ariadne> the musl symbols get preferred over utmps one
2020-10-25 18:11:06 <Ariadne> i wonder how i can convince the linker to prefer the utmps
2020-10-25 18:11:40 <dalias> link utmps first
2020-10-25 18:12:07 <Ariadne> i do
2020-10-25 18:12:17 <dalias> first first ?
2020-10-25 18:12:26 <Ariadne> well
2020-10-25 18:12:30 <dalias> like -lutmps -lfoo -lbar [implicit -lc]
2020-10-25 18:12:31 <Ariadne> that i dont know for sure
2020-10-25 18:12:31 <dalias> or
2020-10-25 18:12:36 <Ariadne> oh
2020-10-25 18:12:38 <dalias> -lfoo -lbar -lutmps [implicit -lc]
2020-10-25 18:12:39 <Ariadne> you need implicit -lc
2020-10-25 18:12:49 <Ariadne> ok
2020-10-25 18:12:49 <dalias> -lc is always there implciitly thus i said implicit
2020-10-25 18:12:51 <dalias> you dont need it
2020-10-25 18:13:00 <Ariadne> well -lutmps is in $LIBS
2020-10-25 18:13:11 <dalias> but maybe something else is in LIBS first
2020-10-25 18:13:11 <Ariadne> also utmp.h has a bug
2020-10-25 18:13:57 <Ariadne> it unconditionally remaps e_termination and such without __GNU_SOURCE
2020-10-25 18:14:02 <dalias> if -lfoo is before -lutmps, libfoo surely depends on libc, so libc is before libutmps
2020-10-25 18:14:09 <Ariadne> ok
2020-10-25 18:14:46 <dalias> hmm no i dont think that's how it works...
2020-10-25 18:14:50 <dalias> let me look again at the spec
2020-10-25 18:15:22 <Ariadne> well either way i had to hack utmps headers to be compatible with musl utmp.h
2020-10-25 18:15:25 <Ariadne> i'm not sure the solution there
2020-10-25 18:15:57 <Ariadne> i wonder if it makes sense to just remove the symbols from musl
2020-10-25 18:16:13 <dalias> no, you can't remove symbols
2020-10-25 18:16:39 <Ariadne> hmm, true
2020-10-25 18:16:58 <Ariadne> what i want is to wind up with a situation where utmpx functions are *always* provided by utmps
2020-10-25 18:16:59 <dalias> whatever you're hitting has a correct solution in terms of link order semantics
2020-10-25 18:17:38 <Ariadne> but the header thing is a problem
2020-10-25 18:17:53 <Ariadne> i'm not sure where to fix that (either musl or utmps)
2020-10-25 18:18:05 <dalias> i thought we already said to -I/usr/include/utmps
2020-10-25 18:18:15 <Ariadne> yes
2020-10-25 18:18:20 <Ariadne> but that does not provide a utmp.h
2020-10-25 18:18:24 <dalias> oh
2020-10-25 18:18:25 <Ariadne> only utmpx
2020-10-25 18:18:33 <Ariadne> maybe solution is to provide a utmp.h
2020-10-25 18:18:35 <dalias> could one be added there?
2020-10-25 18:18:45 <Ariadne> i don't see why not
2020-10-25 18:18:56 <dalias> imo you should not mix the musl version of the header, which expects the musl utmpx.h, with utmps's version of utmpx.h
2020-10-25 18:19:04 <Ariadne> i agree
2020-10-25 18:19:10 <dalias> even if we fix it now it's sure to break again someday
2020-10-25 18:19:31 <Ariadne> screen's build system prepends -lncurses
2020-10-25 18:19:33 <Ariadne> that's why
2020-10-25 18:19:33 <dalias> so just adding a version of utmp.h suitable for use with utmps should be the right fix
2020-10-25 18:19:45 <dalias> let's check with skarnet to make sure
2020-10-25 18:19:55 <dalias> ariadne, ahh
2020-10-25 18:19:59 <dalias> i still wonder why it breaks tho
2020-10-25 18:20:09 <Ariadne> i'm using screen as proof of concept
2020-10-25 18:20:22 <Ariadne> to make sure that utmps implementation still works as expected without utmpd running
2020-10-25 18:20:48 <dalias> symbol resolution order is load order which aiui is breadth-first
2020-10-25 18:21:06 <Ariadne> i'm not sure
2020-10-25 18:21:09 <dalias> so if screen has DT_NEEDED for ncurses and utmps and libc...
2020-10-25 18:21:13 <Ariadne> i just know libutmps doesn't show up in DT_NEEDED
2020-10-25 18:21:20 <Ariadne> because libc provides the symbols
2020-10-25 18:21:29 <Ariadne> so the linker doesn't consider it needed
2020-10-25 18:21:36 <dalias> ncurses and utmps should both get loaded before any of their----
2020-10-25 18:21:43 <dalias> ok somewhere -Wl,--as-needed was added then maybe
2020-10-25 18:21:46 <Ariadne> we're using -Wl,--as-needed yes
2020-10-25 18:21:51 <dalias> ok you can't do that ;)
2020-10-25 18:22:03 <Ariadne> i could if i replace libc.so with linker script
2020-10-25 18:22:23 <Ariadne> but that seems rude
2020-10-25 18:22:44 <dalias> are you trying to inject this into build of all packages rather than just utmp-using ones?
2020-10-25 18:22:45 <Ariadne> and would break third-party use of the toolchain to build binaries that target generic musl environment instead of alpine
2020-10-25 18:22:55 <Ariadne> just into utmp-using ones
2020-10-25 18:23:07 <Ariadne> but -Wl,--as-needed is injected everywhere
2020-10-25 18:23:13 <dalias> i mean are you trying to do it with a global rule
2020-10-25 18:23:15 <Ariadne> that's part of builder config
2020-10-25 18:23:17 <dalias> hm, why?
2020-10-25 18:23:37 <dalias> i would put -Wl,--no-as-needed -lutmps -Wl,--as-needed
2020-10-25 18:23:39 <Ariadne> because this is something distros do to reduce dependency graph size
2020-10-25 18:23:42 <Ariadne> okay
2020-10-25 18:23:44 <Ariadne> i'll try that
2020-10-25 18:24:02 <dalias> because if you really want to force the lib to be linked, which is the whole point here, i think you need that
2020-10-25 18:24:09 <dalias> imo this is --as-needed misbehaving tho
2020-10-25 18:24:21 <Ariadne> agreed
2020-10-25 18:24:23 <dalias> it should not drop the lib if *later* libs have a definition to satisfy it
2020-10-25 18:24:38 <dalias> only if the symbol is already defined at the point in link order where it's hit
2020-10-25 18:24:42 <dalias> ahhhhh now i bet i know..
2020-10-25 18:24:54 <dalias> wow this is probably ld and ldso disagreeing on the order
2020-10-25 18:25:00 <Ariadne> -lcurses -Wl,--no-as-needed -lutmps -Wl,--as-needed
2020-10-25 18:25:04 <dalias> ld probably does a depth-first search of deps of each -l
2020-10-25 18:25:09 <Ariadne>         so:libutmps.so.0.0
2020-10-25 18:25:10 <dalias> so it sees -lc from -lcurses
2020-10-25 18:25:12 <Ariadne> ok
2020-10-25 18:25:13 <Ariadne> cool
2020-10-25 18:25:15 <dalias> and then already has a definition
2020-10-25 18:25:59 <dalias> i wonder if this has other consequences
2020-10-25 18:26:11 <dalias> and if musl's behavior here agrees with other implementations
2020-10-25 18:26:18 <dalias> imo musl ldso's behavior is the better behavior here
2020-10-25 18:26:27 <dalias> otherwise it's hard to override definitions like you're trying to do
2020-10-25 18:26:48 <dalias> if you had two libraries that both want to override some symbols from libc it'd be impossible
2020-10-25 18:26:57 <dalias> because as soon as one is pulled in, libc is pulled in and the other won't get seen
2020-10-25 18:28:27 <Ariadne> hmm
2020-10-25 18:28:40 <Ariadne> the utmps functions still donot appear to be called
2020-10-25 18:28:53 <Ariadne> strace shows no attempt to connect to utmpd
2020-10-25 18:28:54 <dalias> can you strace the dynamic linker loading it ?
2020-10-25 18:29:18 <dalias> also readelf -d the binary
2020-10-25 18:30:19 <Ariadne> strace shows libutmps.so being opened
2020-10-25 18:30:44 <dalias> what order relative to other libs?
2020-10-25 18:30:47 <Ariadne> https://tpaste.us/raox
2020-10-25 18:30:49 <dalias> ldd would also possibly be useful to look at
2020-10-25 18:31:36 <Ariadne> https://tpaste.us/6P59
2020-10-25 18:32:02 <dalias> hmm, all looks right
2020-10-25 18:32:15 <Ariadne> https://tpaste.us/V7ae
2020-10-25 18:33:11 <dalias> you could put a breakpoint in do_relocs and then print find_sym(head, "getutxline")
2020-10-25 18:33:21 <Ariadne> ok
2020-10-25 18:33:37 <dalias> you might have to continue on the first break
2020-10-25 18:33:48 <dalias> since i think it'll be just the dynamic linker itself
2020-10-25 18:33:52 <dalias> before libraries are loaded
2020-10-25 18:34:02 <dalias> the second call should be the one where you can do the print
2020-10-25 18:34:22 <Ariadne> ok
2020-10-25 18:34:51 <dalias> ok the ldd shows what's expected: all direct deps in order first, then indirect deps last
2020-10-25 18:35:24 <Ariadne> (gdb) p find_sym(head, "getutxline")
2020-10-25 18:35:25 <Ariadne> Too few arguments in function call.
2020-10-25 18:35:26 <Ariadne> :)
2020-10-25 18:35:31 <dalias> ahh yes add a 1
2020-10-25 18:35:48 <dalias> (btw i wonder if it would make sense to package libutmps with libskarnet linked into it statically, to reduce namespace impact and number of mmaps)
2020-10-25 18:36:02 <Ariadne> Program received signal SIGSEGV, Segmentation fault.
2020-10-25 18:36:02 <Ariadne> 0x00007ffff7f8bdb6 in get_random_secret () at src/malloc/mallocng/glue.h:41
2020-10-25 18:36:02 <Ariadne> (gdb) p find_sym(head, "getutxline", 1)
2020-10-25 18:36:05 <Ariadne> :)
2020-10-25 18:36:19 <dalias> lol what? :-p
2020-10-25 18:36:20 <Ariadne> dalias: yes, it makes sense.  just have not gotten to that yet.
2020-10-25 18:36:33 <dalias> ohhhh
2020-10-25 18:36:37 <dalias> gdb calls malloc to make the argument
2020-10-25 18:36:40 <dalias> and malloc isn't ready to run yet
2020-10-25 18:36:56 <Ariadne> big oof, as they say
2020-10-25 18:37:41 <dalias> i should add if (libc.auxv) in there
2020-10-25 18:37:49 <dalias> just so gdb works early
2020-10-25 18:38:10 <dalias> but actually n/m this is so early that relocs haven't been performed for libc, so it's not safe to call malloc anyway
2020-10-25 18:38:12 <Ariadne> i have another idea
2020-10-25 18:38:17 <Ariadne> what if i just add some printfs
2020-10-25 18:38:19 <dalias> did you continue to the next call to do_relocs?
2020-10-25 18:38:22 <Ariadne> to utmps :P
2020-10-25 18:38:26 <Ariadne> yes
2020-10-25 18:38:59 <dalias> how about just a breakpoint on the last line of __dls3 in dynlink.c ?
2020-10-25 18:39:06 <dalias> (you can do breakpoint by file and line number
2020-10-25 18:39:20 <Ariadne> (gdb) p getutxline
2020-10-25 18:39:21 <Ariadne> $1 = {<text variable, no debug info>} 0x7ffff7f87aa8 <getutxline>
2020-10-25 18:39:21 <dalias> like on the errno = 0 line
2020-10-25 18:39:30 <Ariadne> the lack of debug info likely means its libutmps
2020-10-25 18:39:34 <dalias> yeah
2020-10-25 18:39:44 <dalias> but that's gdb's resolution of the symbol
2020-10-25 18:39:46 <dalias> not ldso's
2020-10-25 18:39:49 <Ariadne> true
2020-10-25 18:40:11 <dalias> at that point (errno = 0 line) it should be safe to do the find_sym print
2020-10-25 18:40:30 <Ariadne> (gdb) p find_sym(head, "getutxline", 1)
2020-10-25 18:40:30 <Ariadne> $3 = {sym = 0x7ffff7f71d70, dso = 0x7ffff7ffd940 <ldso>}
2020-10-25 18:40:32 <Ariadne> big oof
2020-10-25 18:41:20 <Ariadne> lets see if utmps-static gives us more love
2020-10-25 18:44:05 <Ariadne> wtf
2020-10-25 18:44:09 <Ariadne> even that didnt work
2020-10-25 18:45:19 <Ariadne> oh
2020-10-25 18:45:22 <Ariadne> as-needed again
2020-10-25 18:46:30 <dalias> hmm so why is that happening?
2020-10-25 18:47:02 <dalias> can you print head, head->next, head->next->next, etc. (maybe *'s before them)
2020-10-25 18:47:07 <dalias> to look at the list of libraries
2020-10-25 18:47:15 <Ariadne> i already staticly linked it
2020-10-25 18:47:17 <Ariadne> but yes
2020-10-25 18:47:19 <Ariadne> give me a minute
2020-10-25 18:48:32 <Ariadne> static linking libutmps.a, the linker doesn't put it in the binary ;/
2020-10-25 18:50:06 <dalias> yes because again ld thinks libc already provided it
2020-10-25 18:50:11 <dalias> because of -lcurses first
2020-10-25 18:50:25 <dalias> hmm reading dynlink.c i found an unrelated bug
2020-10-25 18:50:41 <Ariadne> o...oh
2020-10-25 18:50:58 <Ariadne> screen uses getutline and pututline
2020-10-25 18:51:08 <dalias> :-P
2020-10-25 18:51:20 <Ariadne> which is not implemented in utmps
2020-10-25 18:51:22 <dalias> so utmp.h needs to remap them
2020-10-25 18:51:31 <dalias> or something
2020-10-25 18:51:38 <Ariadne> yes
2020-10-25 18:52:21 <dalias> oh no i was wrong about the other bug. it's already handled right :)
2020-10-25 18:52:24 <Ariadne> so maybe it is fine afterall
2020-10-25 18:52:51 <dalias> i thought temporary-RTLD_GLOBAL wasn't reverted right on failure but it is
2020-10-25 18:52:59 <dalias> anyway
2020-10-25 18:53:08 <dalias> the find_sym wrong result is still troubling
2020-10-25 18:55:47 <Ariadne> ok, so i guess next step is to implement utmp stub in utmps
2020-10-25 18:55:54 <dalias> it can just be a define
2020-10-25 18:56:12 <Ariadne> oh i can just provide a utmp.h with defines?
2020-10-25 18:56:15 <dalias> i think
2020-10-25 18:56:16 <dalias> yeah
2020-10-25 18:56:29 <Ariadne> #define getutline getutxline?
2020-10-25 18:56:31 <Ariadne> i see
2020-10-25 19:01:39 <dalias> i did a minimal test case for the idea here and it worked
2020-10-25 19:02:05 <dalias> -lz ./fakelib.so (-lz so there's an earlier lib depending on libc)
2020-10-25 19:02:06 <dalias> and it worked
2020-10-25 19:06:17 <dalias> hmm maybe as-needed does work but screen doesn't use getutx* :-p
2020-10-25 19:06:31 <dalias> and thus it wasn't needed
2020-10-25 19:29:05 <Ariadne> yes seems to be the case
2020-10-25 19:39:41 <dalias> it's working now ? without no-as-needed ?
2020-10-25 19:41:19 <Ariadne> no i mean the theory
2020-10-25 19:41:25 <Ariadne> i am working on writing a stub utmp.h
2020-10-25 19:41:46 <Ticho> has something changed with package builds recently? I'm getting ">>> ERROR: packagename: builddeps failed" when I try to build any package with abuild -r
2020-10-25 19:41:50 <Ticho> even those in main/
2020-10-25 19:42:20 <Ticho> I have fully updated edge system
2020-10-25 19:43:57 <Ariadne> `apk fix` and see if there are errors
2020-10-25 19:44:25 <Ticho> oh, that helped, thanks
2020-10-25 19:46:37 <dalias> ah ok
2020-10-25 19:46:51 <dalias> ariadne, can you just test with a package that uses utmpx api rather than utmp?
2020-10-25 19:47:03 <Ariadne> don't know of one
2020-10-25 19:47:24 <dalias> busybox maybe?
2020-10-25 19:48:19 <[[sroracle]]> this is screen that isn't working with utmps?
2020-10-25 19:51:13 <dalias> screen uses the legacy utmp.h functions rather than utmpx.h ones
2020-10-25 19:51:18 <dalias> so they need to be redirected
2020-10-25 19:51:35 <[[sroracle]]> we have a patch for this
2020-10-25 19:51:42 <dalias> oh?
2020-10-25 19:51:54 <dalias> i think it's easier to just shim it to make it work
2020-10-25 19:52:01 <dalias> so it works for other programs too
2020-10-25 19:52:20 <[[sroracle]]> yeah in the long run probably
2020-10-25 19:52:38 <[[sroracle]]> but for reference this is what we did
2020-10-25 19:52:40 <[[sroracle]]> https://code.foxkit.us/adelie/packages/-/raw/master/user/screen/utmpx.patch
2020-10-25 19:52:56 <Ariadne> yeah im just shimming it
2020-10-25 19:53:20 <Ariadne> what is login_tty?
2020-10-25 19:53:57 <mps> [[sroracle]]: and I applied this patch in my local repo some time ago :)
2020-10-25 19:57:40 <Ariadne> /usr/include/utmps/utmp.h:25:18: error: static declaration of 'getutxent' follows non-static declaration
2020-10-25 19:57:40 <Ariadne>    25 | #define getutent getutxent
2020-10-25 19:57:40 <Ariadne>       |                  ^~~~~~~~~
2020-10-25 19:57:40 <Ariadne>    92 | static struct utmp *getutent __P((void));
2020-10-25 19:57:41 <Ariadne> utmp.c:92:21: note: in expansion of macro 'getutent'
2020-10-25 19:57:44 <Ariadne> are you fucking kidding me
2020-10-25 19:57:45 <Ariadne> grrr
2020-10-25 19:58:06 <dalias> wtf why is there a static definition ?
2020-10-25 19:58:11 <Ariadne> fuck it
2020-10-25 19:58:17 <Ariadne> i'll just import the adelie patch
2020-10-25 19:58:17 <Ariadne> :D
2020-10-25 19:58:48 <mps> good, I can delete my local
2020-10-25 19:58:51 <dalias> i think something is wrong if this code was reached
2020-10-25 19:59:12 <Ariadne> no, screen is just spaghetti code
2020-10-25 19:59:29 <Ariadne> my stub is just using #define
2020-10-25 20:00:08 <Ariadne> nanabozho:~/aports/main/screen$ screen
2020-10-25 20:00:08 <Ariadne> /run/utmps/utmp: No such file or directory
2020-10-25 20:00:08 <Ariadne> /etc/ttys: No such file or directory
2020-10-25 20:00:09 <Ariadne> amazing
2020-10-25 20:00:11 <dalias> yeah i mean it looks like screen's configure chose some dummy-out-utmp code or something
2020-10-25 20:00:27 <Ariadne> it still does not try to connect to utmpd
2020-10-25 20:00:34 <dalias> screen may need specific patching to make utmps work
2020-10-25 20:00:43 <Ariadne> i applied the adelie patch
2020-10-25 20:00:45 <dalias> it probably does its own ridiculous direct access things
2020-10-25 20:01:01 <Ariadne> humm
2020-10-25 20:01:19 <[[sroracle]]> it seems to be working here
2020-10-25 20:01:34 <[[sroracle]]> i get a new w entry when starting screen
2020-10-25 20:01:44 <[[sroracle]]> mcrees   pts/1     16:03   22.00s  0.06s  0.00s SCREEN
2020-10-25 20:01:56 <dalias> screen was a really bad test case to start on :-p
2020-10-25 20:02:05 <dalias> dropbear or openssh might have been better
2020-10-25 20:02:15 <Ariadne> [[sroracle]]: yes, but is it connecting to utmpd
2020-10-25 20:02:23 <[[sroracle]]> how do i determine that
2020-10-25 20:02:26 <dalias> ariadne, if not it wouldn't show up
2020-10-25 20:02:31 <dalias> no?
2020-10-25 20:02:41 <Ariadne> strace
2020-10-25 20:02:44 <dalias> on a utmpd-based system access via legacy files shouldn't work
2020-10-25 20:02:56 <dalias> unless i misunderstand
2020-10-25 20:02:58 <Ariadne> you would think, but
2020-10-25 20:03:00 <Ariadne> let us make sure
2020-10-25 20:03:12 <dalias> maybe the files still provide RO access and just RW needs the daemon
2020-10-25 20:03:42 <Ariadne> i'm not sure :)
2020-10-25 20:03:52 <[[sroracle]]> 3846  connect(3, {sa_family=AF_UNIX, sun_path="/run/utmps/.utmpd-socket"}, 110) = 0
2020-10-25 20:04:46 <[[sroracle]]> ah i see
2020-10-25 20:04:58 <[[sroracle]]> i think we needed to add libutempter to this to make it work
2020-10-25 20:05:26 <Ariadne> oh
2020-10-25 20:05:27 <[[sroracle]]> but i'm not sure since i didn't work on this
2020-10-25 20:05:32 <Ariadne> yes
2020-10-25 20:05:34 <Ariadne> that makkes sense
2020-10-25 20:06:25 <Ariadne> what a mess
2020-10-25 20:06:27 <[[sroracle]]> i think screen was the nastiest case that had to be worked around
2020-10-25 20:06:34 <Ariadne> yes
2020-10-25 20:06:35 <[[sroracle]]> the rest was just minor patching and adding -lutmps
2020-10-25 20:06:38 <Ariadne> thats why i figured start there
2020-10-25 20:07:00 <Ariadne> utmp.c:659:7: error: 'utmpfd' undeclared (first use in this function); did you mean 'utmpok'?
2020-10-25 20:07:02 <Ariadne> wtf
2020-10-25 20:07:47 <Ariadne> hmm
2020-10-25 20:07:49 <Ariadne> 	export CFLAGS="-DNONETHACK -DGETUTENT"
2020-10-25 20:07:52 <Ariadne> there is also this
2020-10-25 20:14:25 <Ariadne> hmm
2020-10-25 20:14:36 <Ariadne> screen still doesn't try to connect to utmpd
2020-10-25 20:14:43 <Ariadne> conclusion: delete screen
2020-10-25 20:15:06 <Ariadne> oh wait
2020-10-25 20:15:14 <Ariadne> i have to patch libutempter duh
2020-10-25 20:16:07 <Ariadne> what the fuck
2020-10-25 20:16:11 <Ariadne> who moved libutempter to community
2020-10-25 20:16:23 <Ariadne> oh
2020-10-25 20:16:27 <Ariadne> it was never part of main duh
2020-10-25 20:38:32 <Ariadne> ok got screen working
2020-10-25 20:38:34 <Ariadne> with shared libutmps
2020-10-25 20:40:48 <dalias> :)
2020-10-25 20:52:24 <Ariadne> utmpifying coreutils next
2020-10-25 20:52:39 <dalias> it should just require the -l right ?
2020-10-25 20:53:45 <Ariadne> yes
2020-10-25 20:53:48 <Ariadne> hmm
2020-10-25 20:53:55 <Ariadne> who(1) does not pick up the screen session
2020-10-25 20:56:08 <Ariadne> grr
2020-10-25 20:56:13 <Ariadne> now screen isnt connecting again
2020-10-25 20:56:40 <Ariadne> thats weird
2020-10-25 20:56:45 <Ariadne> it connects to end the session
2020-10-25 20:56:47 <Ariadne> but not to begin
2020-10-25 20:58:12 <Ariadne> conclusion: screen sucks
2020-10-25 20:59:48 <Ariadne> nanabozho:~/aports/main/screen$ who
2020-10-25 20:59:49 <Ariadne> kaniini  pts/9        2020-10-25 14:59 (:pts/7:S.0)
2020-10-25 20:59:50 <Ariadne> there we go
2020-10-25 21:00:32 <Ariadne> dalias: to answer your question, utmpd must be running to read, not just write
2020-10-25 21:01:24 <dalias> ok thats actually good because it provides some access control capability if you want
2020-10-25 21:03:57 <Ariadne> well when we sat down in #musl like X years ago and specced this out, i am pretty sure we intended it to work that way
2020-10-25 21:05:07 <dalias> *nod*
2020-10-25 21:08:08 <Ariadne> 
ACTION sends it

2020-10-25 21:24:01 <Ariadne> nanabozho:~$ who
2020-10-25 21:24:01 <Ariadne> kaniini  pts/9        Dec 31 17:00
2020-10-25 21:24:03 <Ariadne> with openssh
2020-10-25 21:24:04 <Ariadne> hmm
2020-10-25 21:25:08 <[[sroracle]]> odd
2020-10-25 21:25:52 <Ariadne> that's ssh to localhost
2020-10-25 21:26:03 <Ariadne> can you check if adelie behaves the same way
2020-10-25 21:26:36 <[[sroracle]]> yeah sec
2020-10-25 21:27:02 <[[sroracle]]> nope
2020-10-25 21:27:06 <[[sroracle]]> mcrees   pts/1        2020-10-25 17:28 (::1)
2020-10-25 21:27:17 <[[sroracle]]> we are on an older openssh version so that could be part of the problem
2020-10-25 22:24:58 <Ariadne> yes, possibly.
2020-10-25 22:25:04 <Ariadne> you have a fix-utmpx patch too
2020-10-25 22:25:06 <Ariadne> maybe relevant
2020-10-26 00:16:04 <dalias> ariadne, if you want to experiment with fork on top of just-pushed git master, here is the draft patch: http://ix.io/2C0f
2020-10-26 01:45:18 <Ariadne> dalias: i'll give it a go this week
2020-10-26 07:43:27 <indy> hi all, how to add of dependency to subpackage (pkgname-blabla for example) on main package? i tried set depends_blabla="$pkgname" but abuild do not process that
2020-10-26 07:45:18 <[[sroracle]]> you need to add depends="$pkgname" inside of the subpackage's function
2020-10-26 07:45:42 <[[sroracle]]> the depends_xyz is only available for specific built-in subpackages (like -dev, -static, -libs, or whatever)
2020-10-26 07:51:32 <indy> [[sroracle]], thank already found example in commons-daemon :)
2020-10-26 14:10:37 <Ariadne> one thing i plan to add to ifupdown-ng after 3.13 is health checking
2020-10-26 14:10:55 <Ariadne> this is intended to enable the admin to build failover and other things :)
2020-10-26 14:42:05 <crashoverride> hey, is the main official repo the one on gitlab?
2020-10-26 14:42:49 <Hello71> yes
2020-10-26 14:42:51 <crashoverride> danke.
2020-10-26 17:33:48 <mps> I like my intuition, https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.10-LTS-Kernel
2020-10-26 17:34:13 <mps> ncopa: ^ :)
2020-10-26 17:34:41 <ikke> :)
2020-10-26 17:34:45 <mps> some time ago I told that, math doesn't always work in real life
2020-10-26 17:34:53 <ikke> So better news than this morning
2020-10-26 17:35:09 <mps> what?
2020-10-26 17:35:48 <mps> uname -a => Linux zarya 5.10.0-rc1-3-gru #2 SMP PREEMPT Sun Oct 25 23:53:30 UTC 2020 aarch64 GNU/Linux
2020-10-26 17:36:09 <ikke> oh, was last night
2020-10-26 17:36:22 <mps> uptime => 17:31
2020-10-26 17:36:24 <ikke> 20:45:12         mps │ it's a pity it will not be -lts in alpine 3.13
2020-10-26 17:36:35 <ikke> or is that still the case?
2020-10-26 17:37:12 <mps> yes, that I wanted to ad, and because that I would like that my intuition doesn't work in this case
2020-10-26 17:37:20 <insep_> 
ACTION is still sad that 4.20 wasn't lts release

2020-10-26 17:37:40 <mps> add*
2020-10-26 17:38:46 <mps> ikke: when I wrote 'it's a pity it will not be -lts in alpine 3.13' I think ncopa will not accept -rc for 3.13
2020-10-26 17:39:14 <ikke> When is it scheduled for release?
2020-10-26 17:39:50 <mps> 8 weeks from now, and if there is luck maybe 7
2020-10-26 17:40:15 <ikke> Would be pretty tight
2020-10-26 17:40:19 <mps> so second half of december
2020-10-26 17:40:21 <ikke> not a lot of time for testing
2020-10-26 17:42:04 <mps> hey, I'm testing it on two chromebooks, rk3399 and mt816x
2020-10-26 17:42:25 <mps> :)
2020-10-26 17:42:30 <ikke> :)
2020-10-26 17:42:57 <mps> if it works on such niche machines it will be better on mainstreams
2020-10-26 20:12:25 <mps> ikke: https://people.kernel.org/gregkh/next-long-term-supported-kernel-release
2020-10-26 20:12:55 <mps> "I've been saying for a few years now that I would pick the “last released” kernel of the year to be the next LTS release."
2020-10-26 20:16:11 <ikke> "unless something really bad happens in that release, such as people throwing in loads of crud because they “need” it for the LTS release.  If that happens again, I'll just have to pick a different release..."
2020-10-26 20:16:14 <ikke> :D
2020-10-26 20:16:53 <ikke> Such a nice LTS release you got there, would be a shame if something hapened to it :P
2020-10-26 20:18:15 <mps> :)
2020-10-26 20:19:13 <mps> yes, only missing announced paragon ntfs driver (which is not important to me) which would be nice to have in next -lts
2020-10-26 20:19:50 <Hello71> isn't that terrible anyways
2020-10-26 20:20:06 <Hello71> if wireguard took like three cycles to get in i doubt ntfs will be faster
2020-10-26 20:20:19 <Hello71> unless they rebrand it as a gpu driver
2020-10-26 20:21:01 <mps> iirc, wireguard took more than 3 cycles
2020-10-26 20:22:21 <mps> and wireguard changed some important crypto subsystem while this ntfs doesn't
2020-10-26 22:29:52 <Hello71> wireguard didn't change anything, that was the point
2020-10-26 22:29:58 <Hello71> it bypassed the crypto subsystem
2020-10-26 22:35:10 <mps> ah, yes, I forgot what was it. and nice that you have big library
2020-10-27 08:19:20 <mps> how to name this new pkg, https://github.com/bbonev/yascreen? yascreen or libyascreen, or maybe even 'libyascreen0' (zero at end) as it is named in arch linux, https://aur.archlinux.org/packages/libyascreen0/
2020-10-27 08:20:26 <ikke> https://repology.org/projects/?search=yascreen&maintainer=&category=&inrepo=&notinrepo=&repos=&families=&repos_newest=&families_newest=
2020-10-27 08:22:12 <mps> I see, but don't understand.
2020-10-27 08:22:32 <mps> imo, maybe follow ncurses naming scheme
2020-10-27 08:23:08 <mps> i.e. yascreen and yascreen-dev subpkg?
2020-10-27 08:24:29 <ikke> The project itself is just called yascreen
2020-10-27 08:24:41 <mps> yes
2020-10-27 08:24:47 <ikke> So not sure where the 0 comes from
2020-10-27 08:25:17 <mps> I already asked upstream author, waiting for mail reply
2020-10-27 11:58:06 <maxice8> ping ikke, don't we have a file for shellcheck to read that has loads of exclusions ?
2020-10-27 11:59:53 <ikke> maxice8: https://gitlab.alpinelinux.org/alpine/infra/docker/apkbuild-lint-tools/-/blob/master/overlay/usr/local/bin/apkbuild-shellcheck ?
2020-10-27 12:00:44 <maxice8> yes, that APKBUILD_SHIM
2020-10-27 12:01:04 <maxice8> thanks
2020-10-27 12:01:23 <ikke> RIght
2020-10-27 12:03:32 <ikke> Hmm, should we add SAMUFLAGS to that? Though we are not using that in any APKBUILD
2020-10-27 13:17:13 <yZ5vlALg86lP> good news, with my patches against erlang and ejabberd, the latest ejabberd works reliably and is now running in production, it could even be moved from testing to community: https://tpaste.us/ZEgz - i would be obliged if someone would apply these patches.
2020-10-27 13:19:03 <mps> yZ5vlALg86lP: did you contacted maintainer? I think he is here
2020-10-27 13:19:04 <ikke> yZ5vlALg86lP: If you want, you could submit a merge request
2020-10-27 13:31:11 <yZ5vlALg86lP> do you happen to know their nicks here mps?
2020-10-27 13:31:45 <ikke> danieli maintains erlang
2020-10-27 13:31:57 <ikke> but he's not very active lately
2020-10-27 13:32:33 <ikke> Don't know for ejabberd
2020-10-27 13:33:33 <mps> maintainer is unknown to me but see fcolista as contributor
2020-10-27 13:33:44 <mps> and rnalrd
2020-10-27 13:34:42 <yZ5vlALg86lP> ah, thanks, i hope these hilites will be sufficient, as a backup i sent the patch also to the maintainers email addresses.
2020-10-27 13:37:05 <fcolista> what's up?
2020-10-27 13:40:30 <mps> fcolista: buon giorno mio amico :)
2020-10-27 13:40:37 <fcolista> LOL
2020-10-27 13:40:42 <fcolista> Ciao mps, come stai?
2020-10-27 13:40:59 <mps> non ce male, grazie
2020-10-27 13:41:07 <mps> e tu?
2020-10-27 13:41:25 <fcolista> Tutto bene...stai usando google translator oppure parli davvero italiano?
2020-10-27 13:41:44 <ikke> I think mps speaks a bit Itallian
2020-10-27 13:41:46 <mps> huh, google
2020-10-27 13:41:53 <ikke> or not?
2020-10-27 13:42:03 <fcolista> aaaah :) you are cheating! :)
2020-10-27 13:42:05 <mps> ikke: forgot too much
2020-10-27 13:42:12 <fcolista> hehe
2020-10-27 13:42:43 <mps> 30 years ago I was quite fine with lingua italiana
2020-10-27 13:42:49 <ikke> I could at least follow that reasonably well
2020-10-27 13:42:56 <fcolista> how old are you mps ?
2020-10-27 13:43:53 <mps> eh, earth moved sixty times around sun from time when my eyes first time seen this world
2020-10-27 13:44:08 <yZ5vlALg86lP> ohio fcolista maybe you would be so kind and take care of my patch?
2020-10-27 13:44:10 <mps> and one time plus :)
2020-10-27 13:44:21 <ikke> :)
2020-10-27 13:44:23 <fcolista> I didn't know that, mps!
2020-10-27 13:44:43 <fcolista> yZ5vlALg86lP, let me check
2020-10-27 13:45:09 <ikke> I suspected it from our converstatins :)
2020-10-27 13:45:11 <mps> fcolista: don't worry, my hair is still black and I don't wear glasses :)
2020-10-27 13:45:23 <fcolista> :D
2020-10-27 13:46:32 <fcolista> yZ5vlALg86lP, I'm fine with your patch
2020-10-27 13:47:13 <yZ5vlALg86lP> as said i run ejabber in production, so it could also be moved out of testing
2020-10-27 13:47:19 <fcolista> ok
2020-10-27 13:48:26 <fcolista> erlang is quite a sensitive topic :D is Daniel Isaken fine with your patch as well?
2020-10-27 13:49:04 <ikke> fcolista: Daniel has been absent for a while
2020-10-27 13:49:18 <fcolista> ikke, to me the patch looks fine. What do you think?
2020-10-27 13:50:03 <ikke> I see a superfluous set -x
2020-10-27 13:51:17 <mps> yZ5vlALg86lP: maybe remove commented lines from prepare, and explain in git commit msg
2020-10-27 13:51:29 <ikke> I think part of the logic in -static can be replaced by amove
2020-10-27 13:51:59 <ikke> (amove basically move a file + parent dir structure to a subpkg)
2020-10-27 13:52:12 <ikke> Or directory
2020-10-27 13:52:42 <mps> huh, amove is not documented or I'm wrong?
2020-10-27 13:53:11 <ikke> I thought it was documented somewhere (tm)
2020-10-27 13:53:16 <fcolista> never seen amove before...looking at APKBUILDs is used several times
2020-10-27 13:53:25 <ikke> It's relatively new
2020-10-27 13:53:28 <fcolista> this kind of utilities pops-up like mushrooms..
2020-10-27 13:53:36 <mps> :)
2020-10-27 13:53:42 <fcolista> But i never seen them "announced" or explained
2020-10-27 13:54:11 <ikke> We need to work on the developers documentation on docs.a.o
2020-10-27 13:54:12 <mps> because it is not
2020-10-27 13:55:15 <fcolista> quite often happens "why here you dont use $tool?" where $tool is something never seen before :D
2020-10-27 13:55:16 <ikke> ncopa does not want too many of these 'magic' functions, but apparently amove made the cut
2020-10-27 13:55:23 <mps> and till it declared 'official' I don't use it, and don't like to see it pkgs
2020-10-27 13:55:45 <ikke> Isn't it being added to abuild not official enough?
2020-10-27 13:56:02 <mps> ikke: no, imo
2020-10-27 13:56:52 <mps> official is when it is announced properly, and possibly documented
2020-10-27 13:56:56 <ikke> It's just a helper function that makes a common, but involved task easier
2020-10-27 13:57:11 <ikke> I don't these smaller helper functions will be announced
2020-10-27 13:57:38 <mps> hm, /o\
2020-10-27 13:57:38 <ikke> You are not required to use them, but at least to me, it makes the intent more clear
2020-10-27 13:57:55 <ikke> Now I see a loop with complex logic and need to think about what it does exactly, and if it's done correctly
2020-10-27 13:58:12 <ikke> if someone uses amove, I know exactly what the goal is, and that the code has been tested properly
2020-10-27 13:58:20 <ikke> so easier for review
2020-10-27 13:59:34 <mps> for me it harder because I don't know what (and how) it does
2020-10-27 13:59:49 <mps> only intent is clear :)
2020-10-27 14:00:22 <fcolista> yeah I would not say "don't use it until is official", but is good to know that $tools exists and how can be used
2020-10-27 14:07:02 <yZ5vlALg86lP> here's an updated patch without the set-x and the commentedout lines, and also in the orig patch a new patch was missing, it is in this one included: https://tpaste.us/49yZ
2020-10-27 14:13:42 <yZ5vlALg86lP> btw the commented out deps in ejabberd are legacy subpkgs from a time when this was not packaged directly in erlang i believe.
2020-10-27 14:14:14 <ikke> Yes, most likely
2020-10-27 14:14:33 <ikke> the modules were bundled again because of circular dependencies
2020-10-27 14:14:52 <yZ5vlALg86lP> it was a guess, glad to hear my guess was close
2020-10-27 14:54:28 <gavodavo[m]> Welp, I have the package compiled and the chroot ready
2020-10-27 14:54:38 <gavodavo[m]> But no idea how to test it ;-;
2020-10-27 14:54:47 <gavodavo[m]> By package I mean gcc with multiarch
2020-10-27 17:15:07 <danieli> ikke: I still maintain it? I thought someone else took over maintainership there
2020-10-27 17:15:37 <ikke> https://pkgs.alpinelinux.org/package/edge/community/x86_64/erlang
2020-10-27 17:15:44 <ikke> Apparently that didn't get through
2020-10-27 17:15:49 <ikke> danieli: nice to see you alive :)
2020-10-27 17:16:01 <danieli> but yes, I received an email about fixes to erlang and ejaberd relating to adding erlang-static so ejabberd can be built
2020-10-27 17:16:23 <danieli> ikke: I still have IRC open / idle at all times, and I occasionally read the backlog :)
2020-10-27 17:21:53 <danieli> SPF failed on the email by the way, it landed in my spambox
2020-10-27 17:22:25 <ikke> yZ5vlALg86lP: ^
2020-10-27 17:37:45 <yZ5vlALg86lP> danieli: thanks for the spf note, i just moved parts of my mail arch, so that indeed still needs testing/fixing, i just did so. anyway there's an updated patch here: https://tpaste.us/49yZ
2020-10-27 17:43:19 <danieli> I'll give it a spin when I can and push it once tested
2020-10-27 17:43:25 <danieli> or MR it rather
2020-10-27 17:46:43 <yZ5vlALg86lP> thx
2020-10-27 19:31:44 <mps> please review !14032 it is library only pkg and I'm not sure of name, yascreen or split to yascreen-libs and yascreen-dev (which is already) or something else
2020-10-27 19:35:21 <ikke> Looks good as it's now, I guess
2020-10-27 19:36:10 <ikke> I think -libs is used in the case where some application has separate libs that can be used by others
2020-10-27 19:39:49 <mps> aha, thanks
2020-10-27 19:40:07 <maxice8> yes
2020-10-27 19:40:16 <maxice8> $pkgname-libs or lib$pkgname:libs (like libelogind)
2020-10-27 19:44:52 <mps> ok, thanks
2020-10-27 19:45:32 <mps> I will merge it, need it for bpfmon pkg, which will follow
2020-10-27 19:46:20 <ikke> I did something like that for ssdeep
2020-10-27 19:46:31 <ikke> which is a program, but also has a library, libfuzzy
2020-10-27 19:46:41 <ikke> https://git.alpinelinux.org/aports/tree/testing/ssdeep/APKBUILD
2020-10-27 19:47:09 <mps> yes, but yascreen is pure lib, no executables
2020-10-27 19:47:34 <ikke> nod, but as a case where you would have a lib-like subpackage
2020-10-27 19:47:50 <mps> aha, ofc
2020-10-27 19:47:59 <mps> just wanted to note
2020-10-27 19:48:37 <ikke> I see now I could also have done libfuzzy2:libs, like maxice8 suggested
2020-10-27 19:48:44 <mps> huh, a lot of kde stuffs keep builders
2020-10-27 19:48:50 <ikke> ahuh
2020-10-27 20:26:22 <maxice8> Good news for maintainers that use vim
2020-10-27 20:27:04 <ikke> You mean ale integration?
2020-10-27 20:27:12 <maxice8> yes
2020-10-27 20:27:16 <ikke> :)
2020-10-27 20:27:54 <maxice8> not upstream (yet, I have to figure out how to integrate it)
2020-10-27 20:32:02 <mps> hmm, looked at it but didn't found it useful to me
2020-10-27 20:33:48 <mps> hope it will not 'integrated' in vim, but somehow separate add-on
2020-10-27 21:00:56 <Cogitri> It's a plugin
2020-10-27 21:02:03 <mps> yes, I know
2020-10-27 21:02:29 <mps> but someone could include it in vim apk
2020-10-27 21:06:34 <ikke> mps: It would be distributed with ALE, which is a separate plugin you install manually (or through a vim plugin manager)
2020-10-27 21:06:39 <ikke> not via aports
2020-10-27 21:08:33 <maxice8> most likely via Plug 'maxice8/vim-apkbuild'
2020-10-27 21:08:52 <mps> aha, that's good then
2020-10-27 21:09:01 <maxice8> if I'm writing a linter for APKBUILD might as well write its own filetype instead of relying on 'sh' and hacking around it
2020-10-27 21:09:03 <ikke> maxice8: that would work as well
2020-10-27 21:10:46 <mps> maxice8: you mean linter in vim script?
2020-10-27 21:11:13 <maxice8> mps: linter is in shell (apkbuild-lint) or lua (secfixes-check)
2020-10-27 21:11:23 <maxice8> but I need to write a few functions in vimscript to interface with ALE
2020-10-27 21:11:43 <maxice8> I basically define in ALE terms how to handle the output of our linters and it does the rest
2020-10-27 21:11:50 <mps> yes, I use apkbuild-lint (when I don't forget)
2020-10-27 21:11:59 <maxice8> put it in your githooks
2020-10-27 21:12:42 <mps> btw, how can I use your githooks script out of aports tree
2020-10-27 21:13:13 <mps> maybe some gitconfig options?
2020-10-27 21:15:26 <maxice8> no clue
2020-10-27 21:15:31 <maxice8> I just copy-paste
2020-10-27 21:17:04 <mps> bit if I put then in aports/.githooks, then git says I have unstaged changes and refuses 'git pull ...'
2020-10-27 21:17:12 <mps> but*
2020-10-27 21:20:20 <ikke> You need to put them in .git/hooks
2020-10-27 21:20:55 <ikke> aports/.githooks is just meant to distribute them
2020-10-27 21:22:35 <mps> aha, thanks
2020-10-27 21:23:33 <maxice8> ikke: can you make public ? https://gitlab.alpinelinux.org/Leo/apkbuild.vim
2020-10-27 21:24:37 <ikke> done
2020-10-27 21:25:41 <maxice8> ty
2020-10-27 22:57:10 <maxice8> If anyone is feeling like fixing stuff in vim https://gitlab.alpinelinux.org/Leo/apkbuild.vim/-/blob/master/TODO
2020-10-27 23:06:30 <mps> maxice8: yes, coloring as it is now should be fixed
2020-10-28 00:58:26 <maxice8> Is there a document detailing valid pkgname and pkgver ?
2020-10-28 07:08:46 <Cogitri> maxice8: I think only abuild's src is the source of truth here
2020-10-28 07:33:00 <ikke> And by extension, apk version -c
2020-10-28 07:39:27 <maxice8> vim is really weird with syntax sometimes
2020-10-28 11:11:41 <ikke> Cogitri: bear fails to build
2020-10-28 11:12:07 <ikke> PureTryOut[m]2: there are a number of kde related packages failing on various arches, would you be able to take a look?
2020-10-28 11:13:07 <ikke> krdc, ki18n, kcoreaddons, kbounce, plasma-sdk and more
2020-10-28 11:19:22 <PureTryOut[m]2> Just ppc64le and s390x no? ppc64le is due to the 128-bit thing
2020-10-28 11:19:44 <PureTryOut[m]2> s390x just needs more disabled I guess, missing deps because they got disabled for that arch
2020-10-28 11:20:03 <ikke> yeah, correct, and one on mips64
2020-10-28 11:22:20 <PureTryOut[m]2> Oh, yeah also missing deps so just needs stuff disabled
2020-10-28 11:25:55 <maxice8> oh vim is fancy
2020-10-28 11:26:24 <maxice8> syn match ValidArch /\v(!)?x86(|_64)/ doesn't work
2020-10-28 11:26:31 <maxice8> it will not find x86_64 but will find x86
2020-10-28 11:26:54 <ikke> hmm, does (|..) even make sense?
2020-10-28 11:26:58 <maxice8> but, syn match ValidArch /\v(!)?x86(_64|)/ will work and find both x86_64 an x86
2020-10-28 11:27:12 <ikke> Why the |
2020-10-28 11:27:31 <ikke> or is that part of the syntax
2020-10-28 11:27:32 <maxice8> OR
2020-10-28 11:28:10 <ikke> Shouldn't that be (_64)?
2020-10-28 11:28:15 <ikke> including question mark
2020-10-28 11:28:56 <maxice8> could also be
2020-10-28 11:31:23 <maxice8> /\v(!)?(aarch64|arm(el|hf|v7)|mips(el)?(64(el)?)?|ppc(64(le)?)?|s390x|x86(_64)?)/
2020-10-28 11:31:26 <maxice8> beautiful
2020-10-28 11:45:46 <ikke> Do you also account for noarch?
2020-10-28 11:45:50 <ikke> and all
2020-10-28 11:47:17 <maxice8> yes they are separate
2020-10-28 11:48:13 <ikke> ok
2020-10-28 11:58:19 <Cogitri> Ugh, bear worked on CI
2020-10-28 11:58:57 <ikke> Anoying
2020-10-28 12:03:50 <Cogitri> I'll try to look into it later today
2020-10-28 12:04:14 <ikke> Can we disable it for now?
2020-10-28 12:04:40 <Cogitri> I suppose so, yes
2020-10-28 12:09:50 <ikke> hmm, is sys_unit_test that fails to link
2020-10-28 12:10:13 <ikke> but later also the executable
2020-10-28 12:14:28 <ikke> Created an issue for it
2020-10-28 13:04:03 <ikke> Seems like another package manager in the ecosystem. Qt 6 will start using Conan (conan.io)
2020-10-28 13:04:52 <tehcloud> oi bruv
2020-10-28 13:05:12 <tehcloud> Qt already too complicated :\
2020-10-28 13:06:56 <Cogitri> Conan is somewhat common for C++ development AFAICS though
2020-10-28 13:07:18 <Cogitri> And it's not meant for distribution packaging, it's only meant for develop
2020-10-28 13:07:21 <Cogitri> ment
2020-10-28 13:07:34 <Cogitri> at least that's what they told me at the last Meeting C++ where I talked to them
2020-10-28 13:07:52 <ikke> That's how it starts :P
2020-10-28 13:08:09 <tehcloud> well, what I mean to say is that I see this is a solution to growing complexity, where the real solution to growing complexity should be to start chopping things down to size
2020-10-28 13:08:14 <Cogitri> Yeaaah :/
2020-10-28 13:08:55 <tehcloud> <-- unix greybeard :p
2020-10-28 13:31:32 <mps> everything (nearly) fail on s390x builder
2020-10-28 13:31:45 <ikke> yes, mostly due to dependencies
2020-10-28 13:31:53 <mps> aha
2020-10-28 13:32:27 <ikke> We should probably just disable the entire revdep chain of certain packages
2020-10-28 13:33:08 <mps> tehcloud: yes, perfection is not when you don't have anything to add but when you don't have anything to remove
2020-10-28 13:33:38 <ikke> "I wish I could have written a shorted letter, but I simply did not have the time"
2020-10-28 13:33:48 <mps> ikke: yes, but I don't dare to take this action
2020-10-28 13:37:08 <ikke> PureTryOut[m]2 already said that they should be disabled, so.. :)
2020-10-28 13:39:13 <mps> not sure if they should be disabled or removed :P
2020-10-28 13:39:48 <mps> I told you that I'm bad in english ;)
2020-10-28 13:40:02 <ikke> disabled on those specific arches
2020-10-28 13:40:39 <ikke> some widely used depency has issues and was disabled, but not all depending packages
2020-10-28 13:41:04 <ikke> (I guess with the hope the issue would be fixed before it thse packages would be rebuilt)
2020-10-28 13:42:17 <mps> if they will not be forgotten, as usual
2020-10-28 13:42:43 <ikke> I usually make issues for these
2020-10-28 13:42:48 <ikke> and assign it to the maintainer
2020-10-28 13:43:34 <mps> not all people are careful as you
2020-10-28 13:48:52 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12050 linux 2.6.34 :D
2020-10-28 13:54:34 <mps> heh
2020-10-28 13:57:21 <insep_> an ordinary day in #postmarketos-porting, nothing new /s
2020-10-28 13:57:51 <ikke> heh
2020-10-28 15:57:04 <dalias> ariadne, had any chance to look at fork patch?
2020-10-28 16:01:45 <mps> dalias: patch from musl ML?
2020-10-28 16:03:53 <mps> mt-fork.diff
2020-10-28 16:10:42 <ncopa> dalias: i wonder if it would make sense to create a git branch for the fork patch
2020-10-28 16:11:08 <ncopa> so we get the bugfixes you mentioned in the ML
2020-10-28 16:25:08 <dalias> mps, with the fixes in replies
2020-10-28 16:25:42 <dalias> just posting the updated patch makes more sense if you want it
2020-10-28 16:26:27 <dalias> and there's no way you can apply this on top of 1.2.1 without a lot of other patches first. i would suggest just testing with a drop-in replacement of libc from out-of-apk
2020-10-28 16:26:47 <dalias> and if it works, planning to go to 1.2.2 soon
2020-10-28 16:28:36 <mps> dalias: aha, thank for explanation. I was not sure just because these replies
2020-10-28 16:29:48 <mps> so, safest idea is to use git repo and apply patch from ML, iiuc
2020-10-28 16:30:15 <mps> git master, I mean
2020-10-28 16:34:26 <dalias> well it just won't apply without a lot of other patches already in git master
2020-10-28 16:35:19 <mps> understand
2020-10-28 19:12:27 <mps> is there a method/way to download https://git.musl-libc.org/cgit/musl/ current master branch as tarball. would be simpler to build with APKBUILD and abuild
2020-10-28 19:14:24 <ikke> https://git.musl-libc.org/cgit/musl/snapshot/master.tar.gz
2020-10-28 19:14:43 <mps> ikke: thanks
2020-10-28 19:16:40 <maxice8> apk versions are funny
2020-10-28 19:17:07 <maxice8> You can have any letter as long as it is alone
2020-10-28 19:17:20 <maxice8> 1a2b3c4d5e is valid
2020-10-28 19:17:55 <ikke> heh
2020-10-28 19:19:05 <code-witch_> Hello
2020-10-28 19:19:15 <code-witch_> I am trying to install alpine linux on virtual box
2020-10-28 19:19:18 <ikke> likely due to openssl
2020-10-28 19:19:27 <code-witch_> i am using the standard one
2020-10-28 19:19:33 <ikke> code-witch_: No need to cross-post
2020-10-28 19:19:37 <code-witch_>  i get the error that sfdisk and syslinux is missing
2020-10-28 19:20:20 <code-witch_> ikke I don't understand
2020-10-28 19:20:33 <code-witch_> what due to openssl?
2020-10-28 19:20:55 <code-witch_> ikke:
2020-10-28 19:21:19 <ikke> That was not a reply to you
2020-10-28 19:21:50 <code-witch_> ok, sorry
2020-10-28 19:26:06 <mps> ikke: if I install musl with mt-fork patch on one of lxc container and make it non working because of that, can you downgrade musl in that case
2020-10-28 19:26:57 <ikke> if you install apk-tools static :)
2020-10-28 19:27:44 <mps> aha, ok
2020-10-28 19:28:11 <ikke> makes it easier to restore :)
2020-10-28 19:28:12 <mps> I think that is first thing I do on installations
2020-10-28 19:31:17 <mps> look like mt-forks works
2020-10-28 19:31:30 <mps> mt-fork patch*
2020-10-28 19:32:10 <mps> ikke: what need to be tested
2020-10-28 19:32:25 <mps> build something?
2020-10-28 19:37:26 <mps> dalias: ^
2020-10-28 19:37:54 <ikke> need to recall what projects were affected
2020-10-28 19:38:13 <mps> aha, ok. I'm not in a hurry :)
2020-10-28 19:38:25 <mps> sorry for annoyance
2020-10-28 19:39:15 <mps> maybe run something which can run in lxc
2020-10-28 19:40:42 <mps> restarted postgresql without problem
2020-10-28 19:41:31 <dalias> mps, :)
2020-10-28 19:42:57 <mps> I can't run firefox there :)
2020-10-28 19:45:20 <ikke> mps: https://bugs.ruby-lang.org/issues/17189
2020-10-28 19:46:13 <mps> is it in aports
2020-10-28 19:46:26 <ikke> what?
2020-10-28 19:46:36 <mps> ruby with this bug
2020-10-28 19:47:02 <ikke> I think so
2020-10-28 19:47:45 <mps> so abuild check should trigger it
2020-10-28 19:47:49 <mps> lets see
2020-10-28 19:48:25 <ikke> The example mentions aports, so that's a good indication
2020-10-28 19:51:12 <mps> uh, check is disabled
2020-10-28 19:51:33 <ikke> yes, most likely due to this
2020-10-28 19:52:38 <mps> will go 'by hand'
2020-10-28 19:57:01 <mps> PASS all 1409 tests
2020-10-28 19:57:05 <mps> \o/
2020-10-28 19:58:03 <ikke> Can you get the deadlock again with the musl-1.2.1?
2020-10-28 19:58:30 <mps> how to test?
2020-10-28 19:59:02 <ikke> downgrade musl again?
2020-10-28 19:59:16 <mps> aha, could try.
2020-10-28 19:59:28 <mps> 
ACTION wonders how forgot that :)

2020-10-28 19:59:45 <ikke> Lesson I learned from my father, who's a electricion
2020-10-28 19:59:55 <ikke> first verify that your tools work before you rely on their results
2020-10-28 20:00:37 <mps> heh, your father is wise men
2020-10-28 20:18:43 <mps> ikke: with current musl in repo 'test_thread.rb          FAIL 1/48'
2020-10-28 20:20:37 <mps> here is patch for musl if you want to try https://tpaste.us/qgKe
2020-10-28 20:20:57 <ikke> But nothing hanging?
2020-10-28 20:21:36 <mps> no, it didn't hangs
2020-10-28 20:22:21 <mps> apk version musl => musl-1.2.1-r2
2020-10-28 20:27:38 <ikke> So no good reproduction of the original issue
2020-10-28 20:27:40 <ikke> let me try
2020-10-28 20:47:55 <ikke> mps: same for me, 1 test failing, but no hang, strange
2020-10-28 20:48:45 <ikke> But I noticed the bug mentioned 2.7.1, while aports is already on 2.7.2
2020-10-28 20:49:54 <mps> yes, I noticed same
2020-10-28 20:50:35 <ikke> and you say with the musl patch, all tests succeed
2020-10-28 20:50:38 <ikke> ?
2020-10-28 20:52:43 <mps> yes
2020-10-28 20:52:49 <ikke> interesting
2020-10-28 20:53:08 <ikke> oh, maybe because the hang->crash patch that Ariadne pushed
2020-10-28 20:53:22 <mps> you can 'upgrade' musl with patch I pasted here and check
2020-10-28 20:53:36 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/musl/convert-hangs-to-crashes.patch
2020-10-28 20:53:51 <mps> yes, probably
2020-10-28 20:54:10 <mps> we can try by removing it
2020-10-28 20:54:17 <ikke> So then it seems the fix is working
2020-10-28 20:54:20 <ikke> yes, that's a good test
2020-10-28 20:54:33 <mps> ok will start now
2020-10-28 21:00:58 <mps> ikke: 'test_thread.rb          -' and stays at it
2020-10-28 21:01:18 <ikke> 'nice'
2020-10-28 21:01:37 <ikke> sounds like good news
2020-10-28 21:02:08 <mps> it hanging
2020-10-28 21:03:40 <mps> and 'it hanging' is good news :)
2020-10-28 21:03:46 <ikke> yes
2020-10-28 21:04:45 <mps> ok, I will upgrade musl to master with mt-fork patch and continue to use it
2020-10-28 21:05:07 <mps> will see if something will not work with it
2020-10-28 21:05:50 <mps> dalias: what you think?
2020-10-28 21:06:18 <ikke> I can try it in our testing gitlab instance, I guess
2020-10-28 21:06:33 <ikke> though, I need to fix it first
2020-10-28 21:07:10 <mps> we have to use master for now
2020-10-28 21:07:19 <ikke> nod
2020-10-28 21:07:43 <mps> maybe I should report this to musl ML
2020-10-28 21:08:24 <mps> (but first to prepare one tea of plants)
2020-10-28 21:08:34 <ikke> :)
2020-10-29 01:51:57 <maxice8> so '=' in pkgname triggers Bad Specifier, @ is considered pinning and '%' and '&' mess with shell
2020-10-29 05:08:43 <craftyguy> if I have a subpackage that was pulled in by an 'install_if' condition that was met, but now no longer want that subpackage to be installed (e.g. what it provided is no longer needed), what options do I have to cause that subpackage to get uninstalled?
2020-10-29 05:10:17 <craftyguy> apk del won't remove it, but there must be some way to cause it to be removed in apkbuild? maybe using 'replaces=<subpackage>' in the main package?
2020-10-29 05:40:27 <maxice8> guess you can add a virtual package ?
2020-10-29 05:41:19 <maxice8> also, https://gitlab.alpinelinux.org/Leo/APKBUILD.vim is now mostly ready (sans a few bugs)
2020-10-29 06:33:58 <ncopa> morning
2020-10-29 06:35:27 <maxice8> morning
2020-10-29 07:27:02 <mps> morning
2020-10-29 07:27:47 <mps> ikke: I tested building zig lang with mt-fork patch, worked fine
2020-10-29 07:28:25 <mps> also tested crystal lang, it builds fine but resulting binary hangs
2020-10-29 07:29:31 <mps> what is interesting it doesn't hang always, but sometimes it works
2020-10-29 07:30:06 <mps> I posted short report to musl ML
2020-10-29 07:31:09 <mps> for now I didn't noticed any problem with upgraded musl
2020-10-29 07:31:25 <mps> both lxc works fine
2020-10-29 07:33:02 <mps> I'm not sure but maybe you can try to upgrade ruby with this musl mt-fork git patch I posted
2020-10-29 07:33:57 <mps> crystal was buggy even before that patch
2020-10-29 09:11:03 <Cogitri> Do we have a podman-abuild for using podman instead of docker for abuild?
2020-10-29 09:11:26 <PureTryOut[m]2> You should be able to use docker-abuild with podman, it has some environment variable for that
2020-10-29 09:11:38 <Cogitri> Oh neat
2020-10-29 09:36:46 <Cogitri> Hm, for some reason docker-abuild doesn't like to work for me any more, during the build it aborts with: `abuild-apk: User builder is not a member of group abuild`
2020-10-29 12:05:57 <ikke> mps: seems like abuild is no longer going to warn about static libraries in -dev
2020-10-29 12:06:02 <ikke> http://dup.pw/alpine/abuild/4c38544a
2020-10-29 12:13:19 <mps> ikke: yes, I noticed. thanks maxice8 :)
2020-10-29 12:15:16 <ikke> (context in the commit message would've been nice)
2020-10-29 12:24:14 <Cogitri> ikke: Do you use docker-abuild (so on non-alpine)?
2020-10-29 12:24:21 <ikke> no
2020-10-29 12:24:22 <Cogitri> I'm currently trying to get it running on Fedora
2020-10-29 12:24:31 <ikke> I always use by alpine lxc container
2020-10-29 12:24:34 <ikke> s/by/my
2020-10-29 12:24:34 <alpine-meetbot> ikke meant to say: I always use my alpine lxc container
2020-10-29 12:24:52 <ikke> Or sometimes directly in an alpine docker container
2020-10-29 12:25:01 <Cogitri> And for some reason abuild-apk thinks builder isn't in the abuild group when `cat /etc/group` clearly says it is
2020-10-29 12:25:14 <Cogitri> Hmmm, okay, I guess I should give that a try, thanks for the tip, ikke
2020-10-29 12:39:04 <PureTryOut[m]2> Is there a helper script for autotools just like there is abuild-meson? E.g. abuild-configure or something like that?
2020-10-29 12:49:47 <Cogitri> Nope
2020-10-29 12:49:56 <Cogitri> I think Ariadne worked on some thingie for that
2020-10-29 12:51:03 <PureTryOut[m]2> Hmm ok
2020-10-29 12:59:41 <Cogitri> https://gitlab.alpinelinux.org/kaniini/autoconf-policy
2020-10-29 13:28:16 <PureTryOut[m]2> Cogitri: I see you responded to some Mono PR fixing things on Musl/Alpine. Do you know a bit about Mono by any chance? I'm giving updating Mono a shot but with both the latest version of Mono 5 _and_ Mono 6 it fails with `make[6]: mono: No such file or directory`. I can't seem to figure out why that is though
2020-10-29 13:28:52 <insep_> gavodavo: was it you who tried to run mono on armv7?
2020-10-29 13:29:34 <Cogitri> PureTryOut[m]2: Nope, not a clue about mono unfortunately
2020-10-29 13:29:47 <PureTryOut[m]2> Darn
2020-10-29 13:30:07 <PureTryOut[m]2> Sadly abuild-rootbld doesn't keep the build directory around otherwise I could check what's up with that binary
2020-10-29 13:30:29 <gavodavo> insep:  No
2020-10-29 13:30:43 <insep_> who was it then
2020-10-29 13:30:50 <gavodavo> ¯\_(ツ)_/¯
2020-10-29 13:31:30 <insep_> oh it was nergzd723
2020-10-29 13:31:33 <insep_> i guess
2020-10-29 13:31:52 <PureTryOut[m]2> I guess I'll try without rootbld for now...
2020-10-29 13:34:27 <gavodavo> Btw I think I told earlier but I have a problem with the gcc APKBUILD. I think it's supposed to work now but I have no idea for testing it other than chroot :/
2020-10-29 13:35:51 <Cogitri> PureTryOut[m]2: Not even with -K ?
2020-10-29 13:36:17 <PureTryOut[m]2> Tried that before, didn't seem so no
2020-10-29 13:36:41 <gavodavo> >Btw I think I told earlier but I have a problem with the gcc APKBUILD. I think it's supposed to work now but I have no idea for testing it other than chroot :/
2020-10-29 13:36:42 <gavodavo> I mean the multiarch stuff
2020-10-29 13:38:02 <PureTryOut[m]2> What's the problem with chrooting?
2020-10-29 13:38:38 <mps> doesn't mono looks similar to vala, by syntax
2020-10-29 13:40:34 <insep_> mono is .net interpreter
2020-10-29 13:41:21 <insep_> and c# is a programming language <del>which is a copycat of java</del> that compiles to .net
2020-10-29 13:41:31 <mps> insep_: yes, but syntax is similar iirc
2020-10-29 13:41:44 <insep_> and vala is a language that is inspired by c# in a lot of ways
2020-10-29 13:44:44 <Hello71_> https://en.wikipedia.org/wiki/Vala_(programming_language): "Vala is syntactically similar to C#"
2020-10-29 14:58:53 <gavodavo> ```
2020-10-29 14:58:53 <gavodavo> LIBRARY_PATH=/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.0/:/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.0/../../../../x86_64-alpine-linux-musl/lib/../lib/:/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.0/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.0/../../../../x86_64-alpine-linux-musl/lib/:/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.0/../../../:/lib/:/usr/lib/
2020-10-29 14:59:03 <gavodavo> so I guess the APKBUILD is working?
2020-10-29 15:00:31 <gavodavo> This is from gcc --verbose hello-world.c btw
2020-10-29 15:06:48 <Cogitri> Seems to me like it still uses /usr/lib and not /usr/lib/$CHOST
2020-10-29 15:17:52 <ncopa> i pushed abuild 3.7.0_rc1
2020-10-29 15:18:00 <ncopa> please test that it does not break anything
2020-10-29 15:18:20 <mps> what's for lib64?
2020-10-29 15:18:57 <ikke> https://git.alpinelinux.org/abuild/commit/?id=b6a80729
2020-10-29 15:19:14 <ncopa> https://gitlab.alpinelinux.org/alpine/abuild/-/commit/cd004c0232e5129a1559d876d45a3024ae02317a
2020-10-29 15:19:55 <ncopa> abuild will give error if there is any /lib64 or /usr/lib64 unless options=lib64 is set
2020-10-29 15:20:22 <mps> hmm, never seen it
2020-10-29 15:20:27 <mps> or I forgot
2020-10-29 15:20:34 <ncopa> its a new feature in abuild 3.7.0
2020-10-29 15:20:56 <mps> I mean, never seen error ODODODODODODthis
2020-10-29 15:21:03 <mps> uh
2020-10-29 15:21:19 <mps> I mean, never seen this error
2020-10-29 15:21:42 <ncopa> because we didnt error on this until now
2020-10-29 15:22:14 <mps> aha
2020-10-29 15:22:18 <ncopa> what i find most exciting is the testsuite :)
2020-10-29 15:22:35 <ncopa> hopefully we now will create testcases for any new bugs
2020-10-29 15:22:35 <ikke> Yes, that's a nice improvement
2020-10-29 15:22:42 <ncopa> or any new features
2020-10-29 15:22:50 <ncopa> i actually detected a bug today
2020-10-29 15:22:56 <ncopa> abuild cleanpkg all
2020-10-29 15:23:32 <ncopa> would fail to set the SOURCE_DATE_EPOC which means that the build ws no longer reproducible
2020-10-29 15:33:49 <ncopa> i think the only thing left now before I start the 3.13 builders is to upgrade isl
2020-10-29 15:34:20 <ncopa> its a shame python 3.9 didnt make it
2020-10-29 15:36:12 <mps> you wouldn't wait for musl 1.2.2
2020-10-29 15:40:45 <minimal> ncopa: is there a freeze now for 3.13?
2020-10-29 15:46:48 <ollieparanoid[m]> hey all!
2020-10-29 15:47:10 <ollieparanoid[m]> I've filed a bug for apk, it doesn't remove subpackages dragged in from install_if: https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10720
2020-10-29 15:47:21 <ollieparanoid[m]> and it would be great if somebody could look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14093
2020-10-29 16:54:36 <ncopa> minimal: not yet. I think the toolchain freeze will happen next week. (eg no changes in abuild, compilers like go, clang, rust, etc)
2020-10-29 16:55:01 <ncopa> then i'd guess it'd be another week for the hard freeze
2020-10-29 16:55:35 <ncopa> i think we should probably avoid ABI breakages too after that. exceptions will need good reasons
2020-10-29 17:07:57 <minimal> ncopa: ok. Just concerned that currently MRs can be slow to be actually merged and could miss the freeze.
2020-10-29 17:17:16 <c705> mps: i guess the builders going for 5.9.2?
2020-10-29 17:22:55 <mps> c705: it is blocked because some builders failed on some other pkgs
2020-10-29 17:23:12 <c705> cool
2020-10-29 17:23:18 <mps> I think armv7 version is already on mirrors
2020-10-29 17:23:29 <c705> yeah, it is
2020-10-29 17:24:18 <mps> ah, telegraf is blocker
2020-10-29 17:45:47 <mps> 'gdb -p 17316' on developrs lxc says 'ptrace: Operation not permitted'
2020-10-29 17:47:22 <Cogitri> Try running it as root
2020-10-29 17:47:40 <Cogitri> You probably can't set the sysctl values for running it unprivileged
2020-10-29 17:48:23 <mps> yes, ptrace probably is not enabled on these lxcs
2020-10-29 17:49:56 <mps> ikke: ?
2020-10-29 18:10:42 <ikke> Yeah, containers don't have CAP_SYS_PTRACE as far as I know
2020-10-29 18:12:23 <mps> ok, will try to build and test crystal on my local machine
2020-10-29 18:13:01 <mps> I already installed musl with mt-fork patch on local machine \o/
2020-10-29 18:13:47 <insep_> \o/
2020-10-29 18:14:36 <insep_> i wonder what would happen if we add another bot that replies with \o/ to every \o/...
2020-10-29 18:18:18 <c705> \o/
2020-10-29 18:30:04 <PureTryOut[m]2> \o/
2020-10-29 18:30:27 <mps> huh
2020-10-29 18:56:37 <PureTryOut[m]2> !14059 fails only on the ppc64le 128-bit thing, it's ready otherwise
2020-10-29 19:04:34 <maxice8> I can merge after the storm stops
2020-10-29 19:05:06 <PureTryOut[m]2> You have a storm going on? 🤔
2020-10-29 19:11:35 <maxice8> Yes, lights going in / out
2020-10-29 19:12:36 <PureTryOut[m]2> Oh interesting. Stay safe!
2020-10-29 20:11:27 <maxice8> merged plasma
2020-10-29 20:23:39 <PureTryOut[m]2> Awesome, thanks!
2020-10-29 21:42:30 <nergzd723[m]> <insep_ "oh it was nergzd723"> It was hacker420
2020-10-29 21:42:48 <nergzd723[m]> I was trying to build it but you need mono to build mono xD
2020-10-30 04:07:24 <craftyguy> should apk clean up/remove /lib/apk/db/lock when it is done/
2020-10-30 04:09:53 <craftyguy> I'm trying to find some way to determine if apk is actively installing/upgrading a package or doing any other thing in the database that might be bad news if the system decided it wanted to power off right then
2020-10-30 04:10:20 <craftyguy> and it seems like /lib/apk/db/lock always exists, even when apk isn't running, which seems weird
2020-10-30 06:04:31 <ikke> craftyguy: I think it just tries to open the file exclusively when trying to obtain the lock
2020-10-30 06:04:58 <ikke> so there is no real need to remove it
2020-10-30 06:41:31 <ncopa> craftyguy: https://linux.die.net/man/2/flock
2020-10-30 06:41:35 <ncopa> morning!
2020-10-30 06:42:08 <mps> \o
2020-10-30 06:44:46 <mps> nearly all pkgs which depends on gc-dev for build have tests disabled
2020-10-30 06:57:07 <ncopa> is gc broken?
2020-10-30 06:58:57 <mps> I think yes
2020-10-30 06:59:54 <craftyguy> ikke, ncopa: thanks!
2020-10-30 07:00:26 <mps> looking on https://github.com/ivmai/bdwgc/issues
2020-10-30 07:04:08 <mps> and dalias comment on musl ML about bug report
2020-10-30 07:50:13 <mps> ncopa: sorry to annoy here, but should we merge !13924
2020-10-30 07:51:55 <mps> I think we should because cypress is upstreamed anyway. if we see bug reports we can then know what to do. waiting is not good, imo. it is on edge at the end
2020-10-30 08:06:50 <Cogitri> Is it just me or is Gitlab 503'ing?
2020-10-30 08:07:01 <Cogitri> While opening an MR
2020-10-30 08:07:47 <ikke> Don't see it
2020-10-30 08:07:48 <ikke> link?
2020-10-30 08:08:08 <Cogitri> Ah seems like it loaded after a few reloads
2020-10-30 08:11:29 <Cogitri> Also, first package installing things under lib64 caught by the new abuild check already https://gitlab.alpinelinux.org/Cogitri/aports/-/jobs/236980#L1272 :D
2020-10-30 08:51:39 <ncopa> nice!
2020-10-30 08:52:10 <ncopa> mps, re !13924 is you think its ready to merge then please remove the WIP prefix
2020-10-30 09:01:35 <mps> merged
2020-10-30 12:26:43 <mps> looks like I found fix for 'gc'
2020-10-30 12:28:13 <ikke> dalias: We were just discussing this in #alpine-infra, we seem to have mt-fork related issues on our gitlab instance, but that's running on alpine 3.12, so still on musl-1.1.24. Can it still be the same issue, or is it more likely something else?
2020-10-30 12:43:26 <dalias> mps, hm?
2020-10-30 12:45:03 <mps> dalias: followed your advice and added --disable-parallel-mark to gc make
2020-10-30 12:45:28 <mps> it doesn't block crystal now
2020-10-30 12:45:48 <mps> hangs*
2020-10-30 12:46:05 <mps> and also w3m doesn't hangs
2020-10-30 13:21:00 <Ariadne> dalias: with mt-fork-v2, things known to reliably freeze KDE (such as clicking links in quassel) no longer crash KDE
2020-10-30 13:21:09 <Ariadne> well, lock up KDE
2020-10-30 13:21:15 <Ariadne> i think it is good
2020-10-30 13:26:40 <mps> dalias: I'm running my aarch64 box with mt-fork-v2, works fine
2020-10-30 13:27:04 <mps> no serious issues
2020-10-30 13:27:22 <dalias> mps, was crystal hanging with 1.2.1?
2020-10-30 13:27:42 <mps> no with just updated gc
2020-10-30 13:27:51 <dalias> oh. :-p
2020-10-30 13:27:59 <mps> ah, you mean without patch?
2020-10-30 13:28:09 <dalias> i mean without mt-fork patch
2020-10-30 13:28:25 <mps> no, it didn't hanged
2020-10-30 13:28:28 <dalias> it's slightly possible 2d0bbe6c788938d1332609c014eeebc1dff966ac broke something
2020-10-30 13:28:39 <dalias> since fork does not seem to be involved
2020-10-30 13:28:47 <Ariadne> its boehm gc
2020-10-30 13:28:51 <dalias> can you try current musl with mt-fork patch applied but 2d0bbe6c788938d1332609c014eeebc1dff966ac reverted?
2020-10-30 13:29:05 <dalias> ariadne, is there an upstream bug report for it?
2020-10-30 13:29:16 <mps> dalias: as Ariadne wrote, gc was problem
2020-10-30 13:29:17 <Ariadne> i don't think so, but we just disabled parallel mark
2020-10-30 13:30:12 <dalias> well what i'm asking is if you know it's actually a bug/regression in gc, or if it could plausibly be musl's fault
2020-10-30 13:30:59 <mps> I see a lot of bug reports for boehm gc on github
2020-10-30 13:31:03 <Ariadne> i don't know that for sure, but i would say it is likely gc
2020-10-30 13:31:10 <mps> not sure how to find related one
2020-10-30 13:31:12 <dalias> because if it's musl i'd like to know so we can get that fixed
2020-10-30 13:31:14 <Ariadne> gc does wacky stuff
2020-10-30 13:31:20 <dalias> gc is 100% ub
2020-10-30 13:31:49 <Ariadne> i will test if it means that it being musl's fault won't block 1.2.2
2020-10-30 13:31:50 <dalias> the only gc implementation that's not is the null one (collect = nop :)
2020-10-30 13:31:50 <Ariadne> (:
2020-10-30 13:32:17 <mps> i installed fixed gc about hour ago, now all what come to my mind work
2020-10-30 13:32:19 <dalias> ariadne, you really don't want a bug like that left in musl if there is one; it'll make other apps start hanging too
2020-10-30 13:33:13 <Ariadne> true, but the fact that musl 1.2.1 caused tons of apps to break already is one of the main reasons 3.13 is not branched yet
2020-10-30 13:33:25 <dalias> right
2020-10-30 13:33:46 <dalias> but you dont want the same thing again :)
2020-10-30 13:33:51 <dalias> if there is a bug it'll be quickly fixed
2020-10-30 13:33:56 <Ariadne> okay
2020-10-30 13:34:02 <Ariadne> will do the test in a moment
2020-10-30 13:34:42 <Ariadne> mps: how did you reliably trigger gc hang?
2020-10-30 13:35:05 <mps> with w3m
2020-10-30 13:35:27 <mps> sometimes it hangs but sometimes not, before fixed gc installed
2020-10-30 13:35:37 <mps> and crystal lang
2020-10-30 13:35:49 <Ariadne> invoking w3m how
2020-10-30 13:35:50 <mps> just run 'crystal' few times
2020-10-30 13:36:01 <mps> w3m $url
2020-10-30 13:36:26 <mps> whatever url
2020-10-30 13:37:05 <Ariadne> ok pinned broken gc
2020-10-30 13:37:22 <Ariadne> crystal hangs reliably
2020-10-30 13:37:31 <mps> and as dalias say, gc is UB
2020-10-30 13:38:10 <mps> 
ACTION wonders who come to idea to auto garbage collection in programs

2020-10-30 13:39:20 <Ariadne> 2d0bbe6c788938d1332609c014eeebc1dff966ac
2020-10-30 13:39:21 <Ariadne> ok
2020-10-30 13:42:55 <Ariadne> dalias: with 2d0bbe6c reverted, crystal does not hang
2020-10-30 14:06:59 <dalias> ick. so now i need a testcase to find out what was wrong with it..
2020-10-30 14:25:33 <dalias> ok i can reproduce it with an old basic functionality check program i have, but the place it's hanging doesn't make sense
2020-10-30 14:29:14 <ikke> mps: humans are bad at cleaning up after themselves :)
2020-10-30 14:30:17 <mps> ikke: you are talking about my desk? ;P
2020-10-30 14:34:00 <oneinsect> hola everyone
2020-10-30 14:34:03 <oneinsect> long time
2020-10-30 14:40:57 <mps> oneinsect: namaste!
2020-10-30 14:44:15 <oliv3r[m]> Hey all, for the last few months, I've seen packages move the .so into the -dev package, and only keep the .so.* in the library package. What I'm strugling with right now (with meson) is how do I get the final application to link properly? Right now, i install the -dev package, meson and the .pc file cause it to be linked all happily, but then on target, it complains about the missing .so; so how is that supposed to
2020-10-30 14:44:15 <oliv3r[m]> be done? I know that when you do 'gcc -lmylib' it will link to libmylib.so, but i want it to link against libmylib.so.0
2020-10-30 14:47:29 <afontain_> I find it weird to move only the .so to -dev, and not .so.X
2020-10-30 14:47:46 <afontain_> do you think that was the intended behaviour?
2020-10-30 14:57:35 <dalias> yes it was the intended behavior. obviously the .so.X doesn't belong in -dev because it's a runtime need
2020-10-30 14:57:58 <dalias> for a library using sonames, -lfoo does not produce a runntime dep on libfoo.so
2020-10-30 14:58:04 <dalias> but on libfoo.so.X
2020-10-30 14:58:13 <Cogitri> -Wl,-soname, has to be set on libfoo's link though
2020-10-30 14:58:32 <Cogitri> If that's missing then it will depend on libfoo.so, but that's incorrect
2020-10-30 14:58:36 <dalias> if libfoo isn't using sonames, then libfoo.so is the runtime link abi, and the .so belongs in the main package not the dev one
2020-10-30 14:59:48 <oliv3r[m]> so how do we do this? i'm not sure
2020-10-30 15:00:58 <Cogitri> mylib.so needs to be linked with the right linker flags
2020-10-30 15:01:02 <dalias> in any case i think moving the .so's is wrong
2020-10-30 15:01:07 <dalias> it breaks dlopen
2020-10-30 15:01:23 <dalias> the .so's should be in the main packages not dev
2020-10-30 15:01:29 <dalias> dev should just be headers and static libs
2020-10-30 15:01:42 <Cogitri> daliad: But we don't want applications to ever link against non versioned libs
2020-10-30 15:01:52 <Cogitri> abuild doesn't have any other means for detecting ABI breakages
2020-10-30 15:02:07 <dalias> there's really nothing at all gained by omitting a trivial symlink in the main package
2020-10-30 15:02:24 <dalias> use of non versioned lib is a contract never to break ABI :)
2020-10-30 15:02:34 <dalias> or to switch to a versioned one if you do
2020-10-30 15:21:00 <dalias> ok i identified the problem with condvar commit, fixing it
2020-10-30 15:53:21 <dalias> ariadne, condvar fix pushed
2020-10-30 16:15:17 <oliv3r[m]> while i understand and I agree; I also see the advantage of removing the main .so from the package; breaking dlopen is an interesting point though; in terms of 'plugin behavior' though I guess for plugins you can handle this specifically
2020-10-30 16:15:54 <oliv3r[m]> but cogitri what would be the correct linker flags, and is this somethin meson would do automatically? Or is this so alpine specific, nobody else thought about it decently?
2020-10-30 16:25:38 <Cogitri> It's not alpine specific
2020-10-30 16:25:58 <Cogitri> https://www.man7.org/conf/lca2006/shared_libraries/slide4b.html
2020-10-30 16:26:42 <Cogitri> See https://stackoverflow.com/questions/12637841/what-is-the-soname-option-for-building-shared-libraries-for for a simpler explanation
2020-10-30 16:27:02 <Cogitri> Mylib needs to set -Wl,soname,mylib.so.ACTUALVERSION
2020-10-30 16:27:15 <Cogitri> afterwards your project will link to the right thing
2020-10-30 18:31:03 <z3ntu> Hi, I'm looking at the apk-tools tests at the moment, specifically the file `installif1.repo` and I'm wondering what the `C:` values are. The docs say it's "Pull Checksum", but if I add a new "package" there what can/should I set that value to?
2020-10-30 20:19:39 <mps> hm, pkg cannot makedepends on self, or I'm wrong?
2020-10-30 20:20:25 <ikke> correct
2020-10-30 20:21:05 <ikke> THat's why some packages depend on a virtual -bootstrap package
2020-10-30 20:21:08 <mps> any trick to 'override' this?
2020-10-30 20:21:26 <mps> adding version?
2020-10-30 20:21:31 <mps> exact one?
2020-10-30 20:24:26 <mps> no :(
2020-10-30 20:25:13 <mps> in PKBUILD it works
2020-10-30 20:25:27 <mps> PKGBUILD*
2020-10-30 20:26:52 <ikke> you mean from archlinux?
2020-10-30 20:27:36 <mps> yes
2020-10-30 20:28:27 <mps> https://github.com/archlinux/svntogit-community/blob/packages/crystal/trunk/PKGBUILD
2020-10-30 20:28:47 <mps> crystal PKGBUILD have self in makedepends
2020-10-30 20:28:49 <ikke> yes
2020-10-30 20:29:29 <mps> we cannot install pkg in prepare?
2020-10-30 20:29:50 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/ghc/APKBUILD#L29
2020-10-30 20:29:57 <ikke> that's how haskell does it
2020-10-30 20:29:59 <ikke> ghc
2020-10-30 20:30:31 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/ghc/APKBUILD#L37
2020-10-30 20:30:44 <mps> yes, but they create -bootstrap subpkg
2020-10-30 20:31:11 <mps> which is not needed for crystal, previous version could be used
2020-10-30 20:31:22 <ikke> there is a provides
2020-10-30 20:31:26 <ikke> it's a virtual packae
2020-10-30 20:31:29 <ikke> package
2020-10-30 20:31:50 <mps> ah, yes
2020-10-30 20:32:20 <ikke> TH
2020-10-30 20:32:50 <mps> actually I worked on this a year ago but never finished and forgot details
2020-10-30 20:33:04 <mps> what 'TH' means?
2020-10-30 20:33:21 <ikke> I wanted to type something, but my keyboard was not cooporating
2020-10-30 20:33:36 <mps> ah
2020-10-30 20:34:03 <ikke> I remember having this same discussion with you :)
2020-10-30 20:34:51 <mps> yes, also I remember :)
2020-10-30 20:35:07 <mps> now looking at it and I see 'provides="$pkgname"' there
2020-10-30 20:36:12 <ikke> sadly my laptop kb is acting up
2020-10-30 20:36:20 <mps> ikke: thanks for reminding me
2020-10-30 20:36:29 <ikke> there is one 'column' that is barely working
2020-10-30 20:37:06 <mps> uh, sometimes I fix similar issues with strong vacuum cleaner
2020-10-30 20:37:37 <mps> and sometimes have to open box and clean keys
2020-10-30 21:14:25 <Ariadne> dalias: built updated gcc
2020-10-30 21:14:28 <Ariadne> dalias: err
2020-10-30 21:14:33 <Ariadne> dalias: built updated musl + gc
2020-10-30 21:14:54 <Ariadne> dalias: and no hangs running `while true; do crystal env; done` for a few minutes
2020-10-30 21:17:07 <Ariadne> dalias: also no hang with parallelized gc
2020-10-30 21:17:39 <mps> Ariadne: good news
2020-10-30 21:18:15 <Ariadne> i am considering pushing this to edge as 1.2.2_pre0
2020-10-30 21:19:38 <mps> does this pkgver works?
2020-10-30 21:19:44 <Ariadne> yes
2020-10-30 21:19:52 <mps> good to know
2020-10-30 21:26:54 <Ariadne> yolo
2020-10-30 21:27:17 <Ariadne> edge is edge, time to live life on the edge
2020-10-30 21:27:18 <Ariadne> :)
2020-10-30 21:29:03 <mps> yes
2020-10-30 21:29:21 <mps> I see you pushed
2020-10-30 21:29:56 <ikke> :)
2020-10-30 21:30:21 <andypost[m]> Anyone has access to builders? telegraf fails only on builders and maintainer posted it https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14094#note_121313
2020-10-30 21:30:40 <ikke> can check
2020-10-30 21:32:22 <Ariadne> mps: way i see it is, it can't be any more broken than what is presently in edge :)
2020-10-30 21:32:32 <Ariadne> or what was presently in edge
2020-10-30 21:33:19 <mps> well, we will see
2020-10-30 21:33:34 <mps> will be interesting weekend :)
2020-10-30 21:33:53 <ikke> andypost[m]: so that file does exist
2020-10-30 21:34:34 <mps> but seriously, I expect more pkgs broken expose by change with new malloc and other things in musl
2020-10-30 21:38:18 <andypost[m]> ikke, thank you!
2020-10-30 21:38:34 <Ariadne> mps: we've had new malloc for a while
2020-10-30 21:38:40 <Ariadne> mps: 1.2.1 shipped with new malloc
2020-10-30 21:39:55 <mps> yes, I know, but 1.2.1 exposed all this bugs which mt-fork patch trying to solve
2020-10-30 21:44:10 <Ariadne> Cogitri: we really need to work on making rust cross-compileable
2020-10-30 21:44:39 <Ariadne> the fact that rust is missing on s390x and mips64 is now blocking thousands of packages that would otherwise be fine on those archs
2020-10-30 21:44:52 <Ariadne> since polkit -> mozjs
2020-10-30 21:47:34 <ikke> andypost[m]: so if I read it correctly, if we'd remove that file, it should work for now?
2020-10-30 21:48:30 <Ariadne> ikke: can you add -mlong-double-128 to CFLAGS on ppc64le builder
2020-10-30 21:48:54 <ikke> Ariadne: didn't dalias say that was wrongA
2020-10-30 21:49:03 <Ariadne> if its wrong who cares
2020-10-30 21:49:10 <Ariadne> we need to get the builder moving again
2020-10-30 21:49:12 <Ariadne> its stalled for weeks
2020-10-30 21:49:16 <ikke> also https://gitlab.alpinelinux.org/alpine/aports/-/issues/12045
2020-10-30 21:51:48 <ikke> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97543
2020-10-30 21:52:31 <Ariadne> oh i see
2020-10-30 21:54:32 <ikke> Ah, you just commented on the MR
2020-10-30 21:57:28 <Ariadne> investigating it further, it seems appropriate
2020-10-30 21:57:32 <Ariadne> lets give it a shot
2020-10-30 21:57:55 <ikke> the mlong-double?
2020-10-30 22:02:31 <Cogitri> Ariadne: Well, I'm still blocked on not having a clue how to setup a cross env
2020-10-30 22:02:44 <Cogitri> So yeah 🤷‍♂️
2020-10-30 22:02:47 <Ariadne> what do you mean by crossenv here
2020-10-30 22:03:30 <Cogitri> The things I need to do to make abuild crossvuild things
2020-10-30 22:03:42 <Ariadne> run bootstrap.sh to get toolchain
2020-10-30 22:03:46 <Ariadne> install the toolchain
2020-10-30 22:04:06 <Ariadne> CBUILD=aarch64 abuild ...
2020-10-30 22:04:23 <Ariadne> apkbuilds need to be split into makedepends_build/makedepends_host
2020-10-30 22:04:48 <Ariadne> for rust, we need to create a rust-bootstrap
2020-10-30 22:05:06 <Ariadne> and then rust itself provides rust-bootstrap
2020-10-30 22:05:08 <Ariadne> like ghc
2020-10-30 22:05:32 <Ariadne> then we can introduce community/rust-bootstrap that uses a trusted build for x86_64 to bootstrap the other rust-bootstrap packages
2020-10-30 22:05:52 <Ariadne> the part i don't know is how to realize that with rust's build system
2020-10-30 22:06:17 <Ariadne> but ghc is basically the approach we need to duplicate for rust
2020-10-30 22:06:37 <Ariadne> i can cross-build the rust binaries once the machinery is actually there
2020-10-30 22:10:11 <Hello71_> I feel like it'd be easier to rip out mozjs from polkit
2020-10-30 22:10:34 <Cogitri> Duktape isn't upstream yet tho
2020-10-30 22:10:37 <Hello71_> hell, alpine doesn't even have pam, you could cut the interpreter out entirely
2020-10-30 22:10:51 <Cogitri> What
2020-10-30 22:10:53 <Cogitri> No
2020-10-30 22:11:01 <Cogitri> that'd break polkit entirely
2020-10-30 22:11:16 <Ariadne> Hello71_: today it's mozjs
2020-10-30 22:11:20 <Ariadne> Hello71_: tomorrow it will be something else
2020-10-30 22:11:31 <Ariadne> we need to just make rust a first-class citizen and call it a day
2020-10-30 22:11:55 <Ariadne> the sooner this is done, the sooner we don't have to worry about it anymore
2020-10-30 22:12:46 <Ariadne> we already block on librsvg
2020-10-30 22:14:51 <Hello71_> true
2020-10-30 22:15:16 <Ariadne> for 3.14 i am planning to introduce riscv64 support
2020-10-30 22:15:23 <Ariadne> this means even more pain fo me
2020-10-30 22:15:29 <Ariadne> also ppc64 big-endian
2020-10-30 22:15:33 <Ariadne> again, more pain for me
2020-10-30 22:15:49 <Ariadne> i rather work to solve the bootstrap problem, then we have no more pain
2020-10-30 22:16:45 <Ariadne> i want to see a world where rust dependencies can be arch=all
2020-10-30 22:16:54 <Ariadne> or a world where rust does not exist
2020-10-30 22:17:12 <mps> second one ;P
2020-10-30 22:17:24 <Ariadne> unfortunately, i do not have a time machine and thus cannot go back in time to 2010 with a lead pipe to discuss the situation with graydon hoare
2020-10-30 22:17:29 <Ariadne> so
2020-10-30 22:17:47 <Ariadne> let us work on fixing rust so we do not have this problem anymore :)
2020-10-30 22:17:47 <Cogitri> I'll try to look into it soon-ish
2020-10-30 22:18:03 <Cogitri> Can I run the bootstrapping stuff on non Alpine?
2020-10-30 22:18:20 <Ariadne> yes but that is not the correct solution
2020-10-30 22:18:34 <mps> yesterday I saw news about new riscv64 with 8GB ram for $665
2020-10-30 22:18:55 <Ariadne> what we need is the ability to do
2020-10-30 22:19:00 <Ariadne> CBUILD=mips64 abuild -r
2020-10-30 22:19:05 <Ariadne> in community/rust
2020-10-30 22:19:11 <Ariadne> and have it produce a rust-bootstrap
2020-10-30 22:19:31 <Ariadne> then we provide a trusted rust-bootstrap for *one* arch= based on the void linux one
2020-10-30 22:19:55 <Ariadne> i just don't know how to do the rust side of this
2020-10-30 22:20:10 <Ariadne> maybe i will just go pay some rust person to figure this mess out for me
2020-10-30 22:31:10 <Ariadne> ikke: can you manually upgrade ppc64le edge
2020-10-30 22:31:37 <ikke> system upgrade?
2020-10-30 22:37:37 <Ariadne> yes
2020-10-30 22:37:40 <Ariadne> apk upgrade :)
2020-10-30 22:37:49 <Ariadne> the builder won't do it itself
2020-10-30 22:37:54 <Ariadne> until all packages build successfully
2020-10-30 22:38:31 <ikke> nod
2020-10-30 22:38:53 <ikke> hmm
2020-10-30 22:39:08 <ikke> did not upgrade anything
2020-10-30 22:39:20 <Ariadne> hmm?
2020-10-30 22:39:24 <Ariadne> can you do
2020-10-30 22:39:27 <Ariadne> apk info gcc
2020-10-30 22:39:33 <Ariadne> i'm talking about in the container
2020-10-30 22:39:38 <Ariadne> it should be gcc 10.2-r6
2020-10-30 22:39:44 <ikke> yes, i'm in the container
2020-10-30 22:40:06 <ikke> \gcc-10.2.0-r6 description
2020-10-30 22:40:17 <Ariadne> hmm
2020-10-30 22:40:28 <Ariadne> guess IBM gets to try something else
2020-10-30 22:40:29 <Ariadne> ;)
2020-10-30 22:47:20 <Ariadne> one possible solution to this binutils issue
2020-10-30 22:47:31 <Ariadne> could be to revert the https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=a8acd6eeb6dc2cc5460ece90f90ebe36b56b20ba;hp=6b728d3286a6e073e8cbdb63600e421de4f32dad
2020-10-30 22:51:09 <Ariadne> i'll work on that
2020-10-30 22:52:57 <ikke> +1
2020-10-30 22:53:48 <Ariadne> i will also
2020-10-30 22:53:50 <Ariadne> fix rust myself
2020-10-30 22:53:56 <Ariadne> because i am so tired of this
2020-10-30 22:56:00 <Ariadne> i feel like some people don't care if the builders are red
2020-10-30 22:56:29 <Ariadne> or if some archs cannot even use critical packages like polkit
2020-10-30 22:56:33 <Ariadne> it is somewhat frustrating
2020-10-30 23:02:32 <Cogitri> Well, the workloads of devs just keeps increasing with new arches being added and some of those arches are so niche that devs feel like the work put in isn't worth ir, I suppose
2020-10-30 23:03:25 <ikke> Problem is that most devs do not even have access to all these arches (except through our CI)
2020-10-30 23:03:28 <Ariadne> the people who do not care about s390x, power and mips can at least take steps to *not* make life miserable for the people who do
2020-10-30 23:03:48 <Ariadne> if you know mozjs depends on rust, and you know rust is not available everywhere, you can choose to not upgrade it
2020-10-30 23:04:04 <Ariadne> until we work on fixing that
2020-10-30 23:04:20 <Cogitri> Uhhh, and make all other arches have tons of CVEs until potentially forever?
2020-10-30 23:04:39 <Cogitri> There was plenty of time to act on Rust or mozjs before that
2020-10-30 23:05:35 <Cogitri> Saying we'll keep 99.9% of the user base with vulnerable packages because 0.1% can't upgrade because no one has put in the work for that (yet) doesn't sound like a great way to handle it
2020-10-30 23:05:49 <Ariadne> no, but communication is important
2020-10-30 23:05:56 <Ariadne> with mozjs we could have fixed the CVEs in the meantime
2020-10-30 23:06:09 <Ariadne> there are people here who are capable of backporting security patches
2020-10-30 23:07:59 <Ariadne> and i have asked several times for help with learning the rust side of bootstrapping
2020-10-30 23:08:22 <Ariadne> right now, our bootstrap is "download something void linux built and use that"
2020-10-30 23:08:40 <Ariadne> that is... not an appropriate way to bootstrap rust except initially
2020-10-30 23:08:59 <Ariadne> ppc64le is fixed
2020-10-30 23:09:12 <ikke> cool
2020-10-30 23:10:08 <Ariadne> Cogitri: and i appreciate all the work you do for alpine.  i'm not trying to attack you with this
2020-10-30 23:10:36 <Ariadne> i am just saying, it is frustrating that we are in this mess with rust and the problem gets worse and worse
2020-10-30 23:10:49 <Ariadne> it is indeed also my fault for trying to ignore rust for as long as possible
2020-10-30 23:10:51 <Ariadne> (:
2020-10-30 23:11:58 <ikke> Too many things starting to depend on rust while it's not even 'stable' yet
2020-10-30 23:12:18 <Ariadne> when i packaged mozjs to begin with, i versioned the package so that newer ones could be introduced.  the old mozjs could have kept around for the archs that are rustless
2020-10-30 23:12:24 <Ariadne> (we could have done the same with rsvg)
2020-10-30 23:12:31 <Ariadne> i do agree that the real fix is to get rust everywhere
2020-10-30 23:13:19 <Cogitri> I don't think keeping old packages around and having different versions of different arches works that nicely though?
2020-10-30 23:13:30 <Cogitri> But yes, getting Rust on all arches would be nice
2020-10-30 23:13:31 <Ariadne> it works fine, actually
2020-10-30 23:13:44 <Ariadne> we have gcc 9 on mips because gcc 10 is broken
2020-10-30 23:14:02 <Ariadne> i put a lot of work into making sure that would work a long time ago :)
2020-10-30 23:14:19 <Cogitri> Ah yes, but for mozjs we'd have a `case $CARCH` and then pull in the right version
2020-10-30 23:14:25 <Ariadne> nope :D
2020-10-30 23:14:30 <Ariadne> you just use provides=
2020-10-30 23:14:36 <Cogitri> anyway, now that I know how to bootstrap I can look into rust in a bit
2020-10-30 23:14:54 <Ariadne> well
2020-10-30 23:15:05 <Ariadne> i can do a lot of it
2020-10-30 23:15:12 <Ariadne> the first thing we need to do
2020-10-30 23:15:13 <Cogitri> Ariadne: So different mozjsXX would provide mozjs on different arches?
2020-10-30 23:15:18 <Ariadne> yes
2020-10-30 23:15:37 <Ariadne> anyway.
2020-10-30 23:15:48 <ikke> But isn't there an issue with virtual packages in makedepends because ap does not take them into account for the build orderA
2020-10-30 23:15:50 <Ariadne> the first thing we need to do is make rust build itself using *our* rust package
2020-10-30 23:16:18 <Ariadne> ikke: hmm, maybe.
2020-10-30 23:16:21 <Ariadne> but that's fixable
2020-10-30 23:16:35 <Cogitri> Ariadne: Well, it already does that?
2020-10-30 23:17:00 <Ariadne> #   The last revision of this abuild that does not depend on itself (uses
2020-10-30 23:17:00 <Ariadne> #   prebuilt rustc and cargo) is 2e6769eb39eaff3029d8298fc02856623c563cd8.
2020-10-30 23:17:02 <Ariadne> nce!
2020-10-30 23:17:03 <Ariadne> nice*
2020-10-30 23:17:16 <Ariadne> provides="rust-bootstrap=$pkgver-r$pkgrel"
2020-10-30 23:17:22 <Ariadne> that's not a hack though, its intentional
2020-10-30 23:17:30 <Cogitri> Yes, it already builds with itseld
2020-10-30 23:17:34 <Ariadne> because when you crossbuild you generate a real rust-bootstrap apkbuild
2020-10-30 23:17:36 <Ariadne> er, apk
2020-10-30 23:17:56 <Ariadne> ok that is really fantastic
2020-10-30 23:18:01 <Cogitri> We just have to put in makedepends_* and add a few patches to Rust
2020-10-30 23:18:04 <Ariadne> you've done a lot of the work needed already :)
2020-10-30 23:18:16 <Cogitri> and set --build=$CBUILD if we don't  already do that I think
2020-10-30 23:18:33 <Ariadne> yes and override pkgname
2020-10-30 23:19:36 <Ariadne> but ppc64le is now green at least
2020-10-30 23:19:51 <ikke> \o/
2020-10-30 23:28:06 <Ariadne> the other thing i want to say is that CVEs are contextual
2020-10-30 23:28:51 <Ariadne> a webpage being able to gain code execution through JIT spraying, for example, is a CVE concern, but only to something containing an HTML engine
2020-10-30 23:29:09 <Ariadne> for polkit, it could link against mozjs60 and be totally fine
2020-10-30 23:29:36 <Ariadne> marketing for security audit tools have wildly misinformed the public (and even developers) about the nature of CVEs
2020-10-30 23:30:01 <Ariadne> so "having a ton of CVEs" is not really as severe as it sounds in reality
2020-10-30 23:30:15 <Ariadne> it depends on what CVEs are in what components
2020-10-30 23:30:39 <Ariadne> polkit does not run untrusted javascript in its javascript engine
2020-10-30 23:30:53 <Ariadne> therefore, CVE yes, actual vulnerability no
2020-10-30 23:31:04 <Ariadne> i'm more concerned about the holistic situation
2020-10-30 23:32:16 <Ariadne> industrial focus on CVEs (and especially # of CVEs a system has as a metric) has resulted in an unhealthy way of handling security triage -- patching as the default response without proper analysis of the situation
2020-10-30 23:40:44 <dalias> ariadne, you cannot add -mlong-double-128 to ppc64 to fix the problem. all that will do is produce a bunch of broken frankenstein-abi binaries
2020-10-30 23:40:54 <Ariadne> dalias: yes yes, i fixed it correctly
2020-10-30 23:41:07 <dalias> revert whatever broken change in binutils or gcc is making it error out linking libgcc_s
2020-10-30 23:41:23 <dalias> how did you fix it?
2020-10-30 23:43:50 <Ariadne> i reverted the binutils change
2020-10-30 23:44:14 <Ariadne> after rememberng that musl requires 64-bit long double only
2020-10-30 23:46:58 <dalias> what was the binutils change?
2020-10-30 23:47:44 <dalias> ok i see
2020-10-30 23:47:51 <dalias> this needs to be reported upstream as a bug too
2020-10-30 23:48:08 <dalias> and mcm will need it when adding binutils 2.35
2020-10-30 23:48:19 <Ariadne> yep
2020-10-30 23:49:32 <Ariadne> well
2020-10-30 23:49:33 <Ariadne> no
2020-10-30 23:49:36 <Ariadne> the bug is in gcc
2020-10-30 23:49:51 <Ariadne> gcc is generating a libgcc_s which advertises multiple ABIs
2020-10-30 23:50:00 <Ariadne> binutils was just not validating
2020-10-30 23:50:07 <Ariadne> what i did was revert the change which makes it validate
2020-10-30 23:50:09 <Ariadne> :)
2020-10-30 23:50:23 <dalias> found it
2020-10-30 23:50:53 <dalias> the ppl reviving glibc ld64 support will be harmed by this change too
2020-10-30 23:51:13 <dalias> there, libgcc and glibc both need to keep exporting double-double abi as well
2020-10-30 23:51:23 <dalias> but will compile and link new programs as ld64
2020-10-30 23:51:38 <dalias> https://sourceware.org/bugzilla/show_bug.cgi?id=25882#c7
2020-10-30 23:51:45 <Ariadne> yes
2020-10-30 23:51:54 <Ariadne> i've just done what fixes it for us right now
2020-10-30 23:52:00 <dalias> your fix is the right fix
2020-10-30 23:52:09 <dalias> the binutils change is wrong. gcc is not wrong
2020-10-30 23:52:23 <dalias> ability to support both ABIs from a single .so was a feature
2020-10-30 23:52:24 <Ariadne> it could be that the validation is faulty, yes
2020-10-30 23:52:33 <dalias> and the "validation" breaks that
2020-10-30 23:59:04 <Ariadne> i personally think validation is probably a good thing to have, even if this instance of it is broken
2020-10-31 00:01:25 <dalias> have you really thought about it?
2020-10-31 00:01:52 <dalias> there's really no way mismatched libraries even end up in the same place unless you're actively *trying* to do something unusual
2020-10-31 00:02:16 <dalias> and in that case, the historical design *intentionally* allowed for shared libraries that support both (like glibc does)
2020-10-31 00:47:35 <Ariadne> true
2020-10-31 02:03:27 <andypost[m]> Any idea what's wrong with CI? every job fails with - make: /bin/sh: Operation not permitted
2020-10-31 02:06:10 <andypost[m]> and now error 127 even in docker for any package
2020-10-31 02:25:04 <dalias> :/
2020-10-31 06:03:35 <maxice8> Unfortunately doesn't happen with musl=1.2.1-r2
2020-10-31 08:14:23 <mps> huh, musl 1.2.2_pre0 is buggy
2020-10-31 08:19:31 <mps> hmmm, how it is possible that Ariadne gc commit I've seen on #alpine-commits is not aports repo
2020-10-31 08:20:13 <ikke> which one?
2020-10-31 08:21:05 <ikke> I see a commit has been reverted
2020-10-31 08:21:15 <mps> sorry, it is
2020-10-31 08:21:19 <ikke> 10b83865787d52b0017cd5b31afa15b9306d7ac9
2020-10-31 08:21:26 <mps> I forgot rebase
2020-10-31 08:22:09 <mps> but also pkgrel is reverted :)
2020-10-31 08:22:24 <ikke> yup
2020-10-31 08:23:00 <mps> it should be incremented instead of decremented
2020-10-31 08:24:11 <ikke> https://tpaste.us/K5gq
2020-10-31 08:25:51 <ikke> I could also just purge cdn
2020-10-31 08:26:20 <mps> yes, do it please, I'm out now
2020-10-31 08:26:49 <ikke> Hmm, no issues getting the package though
2020-10-31 08:26:57 <ikke> h
2020-10-31 08:26:59 <ikke> wrong version
2020-10-31 08:28:54 <ikke> done\
2020-10-31 08:30:09 <mps> hmhm, I don't see gc pkgrel fix push on #a-commits
2020-10-31 08:30:25 <ikke> I purged cdn
2020-10-31 08:30:32 <mps> aha
2020-10-31 08:31:34 <ikke> although, people who have -r2 won't go back to r1
2020-10-31 08:32:24 <mps> that is problem
2020-10-31 08:32:33 <ikke> ok, will bump r3
2020-10-31 08:32:42 <mps> thanks
2020-10-31 08:35:39 <ikke> done
2020-10-31 08:36:03 <mps> :)
2020-10-31 08:36:58 <ikke> Though, curious why it was reverted. The commit message doesn't mention
2020-10-31 08:37:48 <mps> some people thinks that the featurism is more important than stability
2020-10-31 08:38:03 <ikke> it's a tough choice
2020-10-31 08:38:07 <ikke> a trade-off
2020-10-31 08:38:50 <ikke> A stable system that does nothing is not very use-full :)
2020-10-31 08:38:51 <mps> no, it is not, if you don't work for company selling features
2020-10-31 08:39:34 <ikke> Depends if all you care is about your own usecases or not
2020-10-31 08:39:40 <mps> a system that does 'wrong things' is worse than do nothing
2020-10-31 08:40:14 <detha> stability trumps features for anything less than couple of thousand servers scale
2020-10-31 08:40:23 <ikke> If your own usecases are covered, everything extra is 'bloated'
2020-10-31 08:41:12 <mps> take analogy with cars, do anyone wants car which crashes because they are shiny ;P
2020-10-31 08:41:26 <ikke> mps: probably :P
2020-10-31 08:41:35 <mps> or ugly one but safe
2020-10-31 08:42:22 <mps> yes, I know some people will risk their life and lives of other just to have shiny car
2020-10-31 08:43:10 <mps> else who will buy these AI driven cars ;)
2020-10-31 08:44:30 <detha> Statistically, AI driven cars would be safer. If all cars on the road were AI driven, and there were no cyclists or pedestrians.
2020-10-31 08:44:59 <mps> :D
2020-10-31 08:45:52 <mps> and 'there are lies, damned lies and statistic', old saying
2020-10-31 08:46:37 <skarnet> computers would work so well if there were no users
2020-10-31 08:47:18 <mps> and no electric supply, I would add
2020-10-31 08:47:38 <ikke> They would work as well as a brick
2020-10-31 08:48:12 <mps> and bricks are one of most stable human inventions
2020-10-31 08:51:00 <detha> brick beats car. Especially when dropped from an overpass on a car doing 120km/h
2020-10-31 08:53:55 <mps> properly used bricks beat nearly everything :)
2020-10-31 08:54:48 <ikke> a slice of bread beats a brick when you're hungry :P
2020-10-31 08:56:07 <detha> bricks can be used to build ovens. Give a man a fish versus teach a man to fish ;)
2020-10-31 08:56:13 <mps> a brick used to 'kill food' when you are hungry is better
2020-10-31 08:56:37 <ikke> depends on how good you are at hunting
2020-10-31 08:57:19 <ikke> hunting with a brick does not sound so easy
2020-10-31 08:58:10 <mps> make few fractions of one brick and chances are better
2020-10-31 08:58:18 <detha> 'hungry', adj.: Old english word for 'having a lousy aim when throwing bricks'
2020-10-31 08:58:31 <mps> detha: :)
2020-10-31 08:58:57 <ikke> :D
2020-10-31 10:29:25 <PureTryOut[m]2> Firefox is completely broken for me since that Musl rebuild
2020-10-31 10:29:33 <PureTryOut[m]2> Tabs are constantly crashing, they literally won't load because of it
2020-10-31 10:29:39 <PureTryOut[m]2> Is anyone else experiencing this?
2020-10-31 10:30:00 <Cogitri> I think fabled already pushed a fix
2020-10-31 10:30:14 <Cogitri> Apparently something in musl changed that keeps ABI compatibility but breaks seccomp
2020-10-31 10:30:16 <fabled> Yes, just needed a rebuild
2020-10-31 10:30:21 <fabled> works for me now
2020-10-31 10:30:26 <fabled> just do upgrade
2020-10-31 10:30:33 <PureTryOut[m]2> No I got that rebuild
2020-10-31 10:30:36 <PureTryOut[m]2> It's broken
2020-10-31 10:30:54 <PureTryOut[m]2> Like I said, it's broken for me since that Musl rebuild
2020-10-31 10:31:05 <PureTryOut[m]2> I'm running 82.0-r1 currently
2020-10-31 10:31:13 <fabled> huh. it works for me just fine
2020-10-31 10:31:18 <fabled> but -r0 was broken
2020-10-31 10:31:51 <PureTryOut[m]2> Well -r1 still is 🤷‍♂️
2020-10-31 10:32:05 <PureTryOut[m]2> Still complains about the sandbox violation
2020-10-31 10:32:15 <PureTryOut[m]2> "Sandbox: seccomp violation:"
2020-10-31 10:32:44 <insep_> <Cogitri "Apparently something in musl cha"> oh, sshd also was broken on 3.10 because of seccomp, i wonder if it also was affected
2020-10-31 10:33:03 <insep_> although it still works on non 3.10 kernels, like 3.4
2020-10-31 10:33:32 <Cogitri> Huh? 😅
2020-10-31 10:33:46 <PureTryOut[m]2> He is talking about devices using 3.10 kernels, postmarketOS probably
2020-10-31 10:33:58 <PureTryOut[m]2> Not Alpine 3.10 😉
2020-10-31 10:34:18 <PureTryOut[m]2> But yeah what can I do now to fix Firefox?
2020-10-31 10:34:30 <PureTryOut[m]2> A reinstall (just to make sure I have the correct version) did not do the trick either
2020-10-31 10:35:10 <Cogitri> Hm, maybe that seccomp patch we're already carrying needs to have another exception added
2020-10-31 10:35:17 <Cogitri> But weird that it works for fabled and not you
2020-10-31 10:35:24 <PureTryOut[m]2> Magic
2020-10-31 10:35:27 <Cogitri> maxice8: I think you also had problems with FF, does it work for you now?
2020-10-31 10:35:46 <PureTryOut[m]2> I don't dare upgrade my laptop atm...
2020-10-31 10:36:41 <PureTryOut[m]2> Why was Musl upgraded to a pre-release anyway?
2020-10-31 10:37:13 <fabled> to help test the fixes before release. and the current release has breakage in the fork/execve with several apps. so it was considered to be an improvement
2020-10-31 10:37:25 <fabled> rebooting
2020-10-31 10:37:35 <PureTryOut[m]2> Hmm
2020-10-31 10:37:39 <insep_> oh, you are talking about recent musl upgrade
2020-10-31 10:37:45 <Cogitri> Yup
2020-10-31 10:37:57 <insep_> then nvm my comment about sshd, it was broken long before this upgrade
2020-10-31 10:39:25 <mps> it is edge and it sometimes break
2020-10-31 10:40:11 <mps> and musl need to be tested with these added workarounds for a lot of buggy pkgs
2020-10-31 10:41:59 <mps> I wrote last this weekend will be 'interesting'
2020-10-31 10:45:46 <PureTryOut[m]2> I'm doing a local rebuild now, see if it helps
2020-10-31 10:46:43 <mps> not sure
2020-10-31 10:47:09 <mps> musl should be fixed
2020-10-31 11:10:53 <nmeum> mps: can we merge !14144? this release includes an important bug fix for a stack overflow
2020-10-31 11:11:05 <nmeum> otherwise I would just backport the patch for the stack overflow in the meantime
2020-10-31 11:16:17 <mps> nmeum: yes, I tested locally and on devs lxc
2020-10-31 11:17:05 <mps> I think it could be merged but not sure will it work with latest musl push
2020-10-31 11:17:47 <nmeum> PureTryOut[m]: firefox-esr -r1 is also broken for me
2020-10-31 11:17:59 <nmeum> puh, that's annoying
2020-10-31 11:17:59 <mps> I'm preparing backport for 3.12, hope will finish it today
2020-10-31 11:18:13 <nmeum> for tmux?
2020-10-31 11:18:23 <mps> yes
2020-10-31 11:18:39 <mps> but if you want right now please do
2020-10-31 11:18:50 <nmeum> can do anything right now because my firefox doesn't work :D
2020-10-31 11:18:52 <nmeum> *can't
2020-10-31 11:19:03 <mps> heh
2020-10-31 11:20:07 <mps> because that before every upgrade of base 'things' I do backup
2020-10-31 11:20:30 <nmeum> could also use an older btrfs snapshot, but don't really want to do that
2020-10-31 11:21:56 <PureTryOut[m]2> nmeum: good that I'm not the only one at least
2020-10-31 11:22:00 <nmeum> does that musl upgrade include any new syscalls in the stuff used by firefox? if so we probably just need to change the firefox sandbox systemcall whitelist I guess?
2020-10-31 11:22:10 <mps> ok, in a half an hour i will make tmux MR for 3.12
2020-10-31 11:22:32 <nmeum> I would just backport the openbsd errata patch I linked in the comment though
2020-10-31 11:23:22 <mps> nmeum: not needed, tmux in 3.12 is 3.1b, safer and simple is just upgrade to 3.1c
2020-10-31 11:23:38 <nmeum> ah, yeah I agree then
2020-10-31 11:26:32 <nmeum> > Sandbox: seccomp sandbox violation: pid 14036, tid 14036, syscall 16
2020-10-31 11:26:35 <nmeum> what is syscalls 16? ioctl?
2020-10-31 11:27:07 <Ariadne> mps: i reverted it because we no longer needed to disable it since musl was fixed
2020-10-31 11:27:21 <nmeum> if syscalls 16 is ioctl, the problem might be https://git.musl-libc.org/cgit/musl/commit/?id=4d5786544bb52c62fc1ae84d91684ef2268afa05 ?
2020-10-31 11:28:52 <mps> Ariadne: what about you wrote?
2020-10-31 11:28:52 <Ariadne> #define __NR_ioctl                              16
2020-10-31 11:29:27 <nmeum> so if that code from the linked commit is triggered by firefox that would explain the sandbox violation I guess
2020-10-31 11:29:31 <Ariadne> mps: yes, i think --disable-parallel-mark is a better bet *but* i don't want to deal with complaints if the underlying problem itself is fixed
2020-10-31 11:29:52 <mps> aha
2020-10-31 11:30:27 <Ariadne> the users i support commercially do not care either way, gc is not part of our image or default package set
2020-10-31 11:30:56 <mps> I'm not moaning about that revert, people who want feature^Wperfomance will be hapy
2020-10-31 11:31:32 <Ariadne> with mallocng i doubt that there is any performance improvement really
2020-10-31 11:34:16 <mps> but I will keep 'gc' with --disable-parallel-mark for me
2020-10-31 11:39:22 <nmeum> I would assume we need to add a case for __NR_ioctl (or update the exsting one) in security/sandbox/linux/SandboxFilter.cpp in the firefox source?
2020-10-31 11:41:13 <mps> nmeum: !14148 it was really simple
2020-10-31 11:41:28 <nmeum> sweet :)
2020-10-31 11:41:55 <mps> merged
2020-10-31 11:47:50 <Ariadne> nmeum: yes
2020-10-31 11:48:04 <ikke> So make is broken on edge?
2020-10-31 11:48:59 <ikke> I guess with the latest musl
2020-10-31 11:49:08 <mps> hmm, /usr/include/bits/syscall.h:#define __NR_ioctl 29
2020-10-31 11:49:09 <nmeum> Ariadne: problem is: firefox already seems to have some complex logic for allowing certain ioctls in certain circumstances (if I understand the code correctly) will take some tinkering to handle this case I guess…
2020-10-31 11:49:32 <nmeum> mps: on x86_64?
2020-10-31 11:49:43 <mps> aarch64
2020-10-31 11:49:50 <nmeum> syscall numbers differ between architectures
2020-10-31 11:50:20 <mps> yes, I see
2020-10-31 11:53:43 <ikke> latest musl version breaks make:
2020-10-31 11:53:45 <ikke> https://tpaste.us/oPaR
2020-10-31 11:54:23 <nmeum> https://tpaste.us/jnXq this patch *might* fix the firefox issue, my build server is currently down so I can't really test though :/
2020-10-31 11:55:24 <nmeum> maybe time to revert the musl upgrade then?
2020-10-31 11:55:42 <nmeum> why did we upgrade to an unreleased musl version in the first place?
2020-10-31 11:56:11 <ikke> I guess to find issues like this
2020-10-31 11:57:07 <Ariadne> nmeum: because its about to be released, and it has fixes we need
2020-10-31 11:58:09 <nmeum> well
2020-10-31 11:58:16 <nmeum> time to fix make first then I guess, if it is really broken
2020-10-31 11:58:33 <Ariadne> lets see musl changelog
2020-10-31 11:58:39 <Ariadne> or perhaps strace :)
2020-10-31 11:58:48 <ikke> I was working on an strace
2020-10-31 11:58:58 <ikke> but, as always
2020-10-31 11:59:11 <ikke> when I run docker in privileged mode, I don't get any issue
2020-10-31 11:59:20 <ikke> so perhaps libseccomp issue?
2020-10-31 11:59:31 <Ariadne> yes, likely
2020-10-31 12:00:48 <Cogitri> nmeum: Since CI is currently broken, could we merge bear w/o re-enabling s390x for now (if it works for you)?
2020-10-31 12:01:00 <Cogitri> Would be nice to get my CI pipeline going again
2020-10-31 12:01:20 <Ariadne> https://git.musl-libc.org/cgit/musl/commit/?id=b8b729bd22c28c9116c2fce65dce207a35299c26
2020-10-31 12:01:22 <Ariadne> possibly this
2020-10-31 12:02:17 <nmeum> Cogitri: sure, problem is just: this reminds me to fix the s390x thing and if we don't test this with the new release now I will just forget about it ':)
2020-10-31 12:02:51 <nmeum> I also can't test the PR atm due to firefox breakage :D
2020-10-31 12:02:57 <Cogitri> We could open an issue and assign you to it if that does the trick :P
2020-10-31 12:03:01 <Cogitri> Oh, fair
2020-10-31 12:03:47 <nmeum> if it's urgent for you just merge it and open an s390x ticket for me I guess…but as I said: can't test it currently
2020-10-31 12:03:49 <Ariadne> we could revert the ioctl stuff
2020-10-31 12:03:54 <nmeum> I tried that
2020-10-31 12:04:08 <nmeum> or to be more specific I just replaced that ioctl call with `return 0`
2020-10-31 12:04:15 <nmeum> but that didn't fix firefox for me
2020-10-31 12:04:18 <Ariadne> hmm
2020-10-31 12:04:22 <Ariadne> probably unrelated then
2020-10-31 12:04:28 <Cogitri> nmeum: Nop, it's not that urgent :)
2020-10-31 12:05:06 <Ariadne> https://git.musl-libc.org/cgit/musl/commit/?id=55fb9a177316aa46c639d93dd0323d9a9a8c160c
2020-10-31 12:05:10 <Ariadne> ikke: ^^^
2020-10-31 12:05:19 <Ariadne> ikke: i am pretty sure this is what the problem is :)
2020-10-31 12:05:25 <ikke> Ariadne: https://tpaste.us/BEoY
2020-10-31 12:05:27 <ikke> strace output
2020-10-31 12:05:44 <Ariadne> 53    faccessat2(AT_FDCWD, "/bin/sh", X_OK, AT_EACCESS) = -1 EPERM (Operation not permitted)
2020-10-31 12:05:45 <Ariadne> yep
2020-10-31 12:06:00 <nmeum> Ariadne: re: ioctl and firefox, I don't think its unrelated if you diff musl HEAD with 1.2.1 using `git diff v1.2.1..HEAD`, the commit I linked above is the only new ioctl invocation in musl that comes up
2020-10-31 12:06:16 <Ariadne> nmeum: but is firefox working on musl 1.2.1?
2020-10-31 12:06:49 <nmeum> yes, 100% I still have it working on my other laptop
2020-10-31 12:06:57 <nmeum> musl-1.2.1-r2 there
2020-10-31 12:07:12 <Ariadne> downgrade musl on the same machine and check?
2020-10-31 12:07:56 <nmeum> good idea, firefox shouldn't need a rebuild. right?
2020-10-31 12:08:06 <nmeum> after downgrading musl that is
2020-10-31 12:08:12 <Ariadne> yes
2020-10-31 12:08:32 <Ariadne> ikke: i think docker needs to be aware of SYS_faccessat2
2020-10-31 12:08:59 <ikke> Ariadne: So it needs to be added to the seccomp profile?
2020-10-31 12:09:05 <Ariadne> yes
2020-10-31 12:09:25 <Ariadne> although, containerd has
2020-10-31 12:09:25 <Ariadne> contrib/seccomp/seccomp_default.go:                             "faccessat2",
2020-10-31 12:09:43 <ikke> I think docker has its own seccomp profile
2020-10-31 12:10:21 <ikke> https://github.com/moby/moby/blob/master/profiles/seccomp/default.json
2020-10-31 12:10:36 <ikke> but faccessat2 is in there
2020-10-31 12:10:53 <nmeum> Ariadne: downgraded musl and that works
2020-10-31 12:10:59 <ikke> https://github.com/moby/moby/commit/a18139111d8a203bd211b0861c281ebe77daccd9
2020-10-31 12:11:04 <ikke> Was added 3 months ago
2020-10-31 12:11:08 <Ariadne> components/engine/profiles/seccomp/default.json:                                "faccessat",
2020-10-31 12:11:09 <nmeum> Ariadne: very very certain that it is the ioctl commit I referenced
2020-10-31 12:11:12 <Ariadne> not in the one we are shipping
2020-10-31 12:11:29 <Ariadne> nmeum: i can revert it for now
2020-10-31 12:11:35 <Ariadne> (that commit)
2020-10-31 12:11:46 <Ariadne> lets revert faccessat2 for the moment too
2020-10-31 12:11:50 <nmeum> I think the firefox change I linked should also work
2020-10-31 12:11:58 <nmeum> that would imho be the way to go
2020-10-31 12:12:01 <Ariadne> let me see
2020-10-31 12:12:23 <Ariadne> yes
2020-10-31 12:12:26 <Ariadne> that should work
2020-10-31 12:12:38 <nmeum> we just have to tell the firefox sandbox to allow ioctl with TIOCSWINSZ should be that simple
2020-10-31 12:12:42 <Ariadne> go ahead and push it and lets see
2020-10-31 12:13:08 <nmeum> without checking if it compiles first? :D
2020-10-31 12:14:08 <Ariadne> it looks like it would compile to me :)
2020-10-31 12:14:18 <nmeum> ok, let's see then
2020-10-31 12:15:38 <ikke> Ariadne: I could temporarily add the latest seccomp profile to our CI hosts
2020-10-31 12:15:50 <Ariadne> ikke: yes, that will work
2020-10-31 12:16:07 <Ariadne> ikke: the problem isthe one we are shipping is outdated
2020-10-31 12:16:24 <Ariadne> i have no idea how to update it though (:
2020-10-31 12:17:52 <ikke> Ariadne: https://github.com/moby/moby/blob/v19.03.13/profiles/seccomp/default.json
2020-10-31 12:17:56 <ikke> it's missing from the latest docker release
2020-10-31 12:18:00 <nmeum> checking if the patch applies cleanly alones takes ages with firefox aport ufff
2020-10-31 12:18:11 <nmeum> shitty bloatware
2020-10-31 12:18:21 <ikke> Ariadne: so we could backport it to docker
2020-10-31 12:19:06 <mps> nmeum: imagine doing that on mmc fs
2020-10-31 12:19:55 <nmeum> https://gitlab.alpinelinux.org/alpine/aports/-/commit/ff0f7f796a5435509f6af0382c2d4d89e016c7c3
2020-10-31 12:20:01 <nmeum> let's see how it goes :D
2020-10-31 12:21:50 <ikke> Ariadne: :(
2020-10-31 12:22:26 <PureTryOut[m]2> Please fix regular Firefox too, I don't use firefox-esr myself
2020-10-31 12:22:45 <nmeum> sure, as the commit messages says: didn't test this locally yet
2020-10-31 12:23:03 <nmeum> so lets first make sure the build passes for firefox-esr and actually works
2020-10-31 12:23:19 <nmeum> afterwards we can apply the same patch for firefox
2020-10-31 12:23:21 <ikke> Ariadne: running docker with the latest seccomp profile that has faccessat2 added does not fix it
2020-10-31 12:23:48 <Ariadne> are you sure it is actually applying the changed profile
2020-10-31 12:23:57 <Ariadne> lets just revert the faccessat2 for now
2020-10-31 12:24:11 <ikke>  /usr/bin/dockerd -p /run/docker.pid --seccomp-profile /etc/docker/seccomp.json
2020-10-31 12:24:11 <Ariadne> i think that is the better way to go
2020-10-31 12:24:30 <ikke> I explicitly run docker with the seccomp profile
2020-10-31 12:24:37 <ikke> ok
2020-10-31 12:24:57 <Ariadne> i think point releases of software should not introduce changes like these, but musl is not my project :P
2020-10-31 12:25:08 <ikke> :)
2020-10-31 12:25:30 <nmeum> we could also try to simply backport https://github.com/containerd/containerd/commit/6a915a1453a5bfd859664679e1ac478a7022c7f6
2020-10-31 12:26:01 <ikke> reverted the seccomp profile again
2020-10-31 12:29:39 <Ariadne> nmeum: my patience for this has been exceeded right now
2020-10-31 12:29:50 <Ariadne> my patience for musl in general is starting to be exceeded
2020-10-31 12:30:14 <Ariadne> at least 1.2.x
2020-10-31 12:30:27 <Ariadne> every musl 1.2 release has had fallout
2020-10-31 12:30:42 <nmeum> I don't really think that musl is to blame for firefox stupid syscall filter
2020-10-31 12:30:55 <nmeum> which is only tested with some glibc ubuntu version by the firefox devs
2020-10-31 12:30:59 <Ariadne> no, but switching to new syscalls
2020-10-31 12:31:03 <Ariadne> inside musl
2020-10-31 12:31:16 <Ariadne> without giving time for seccomp filters to be adjusted
2020-10-31 12:31:23 <Ariadne> is not really ideal
2020-10-31 12:31:33 <ikke> How would you give time for seccomp profiles to be updated?
2020-10-31 12:31:50 <Ariadne> simple: linux 5.8 added sys_faccessat2
2020-10-31 12:31:58 <ikke> aha
2020-10-31 12:32:00 <Ariadne> wait until linux 5.12 to start using it
2020-10-31 12:32:19 <Ariadne> by then, seccomp profile updates should have trickled down
2020-10-31 12:32:37 <nmeum> that wouldn't fix the ioctl issue though :p
2020-10-31 12:32:43 <nmeum> s/fix/mitigate/
2020-10-31 12:32:44 <alpine-meetbot> nmeum meant to say: that wouldn't mitigate the ioctl issue though :p
2020-10-31 12:32:47 <ikke> dalias says the issue is that it's returning the wrong exit code
2020-10-31 12:32:53 <ikke> or error code
2020-10-31 12:32:54 <Ariadne> no, i am more annoyed about the sys_faccessat2
2020-10-31 12:33:00 <ikke> EPERM instead of ENOSYS
2020-10-31 12:33:35 <Ariadne> yes
2020-10-31 12:33:45 <Ariadne> because thats what the seccomp filters do
2020-10-31 12:33:55 <Ariadne> they return EPERM when an unknown syscall is requested
2020-10-31 12:34:15 <Ariadne> yes, that is likely wrong
2020-10-31 12:34:49 <Ariadne> but i do not have the time today (or, really any day -- i think seccomp is absolutely moronic) to fix those :P
2020-10-31 12:35:02 <ikke> heh
2020-10-31 12:35:16 <nmeum> well just revert the sys_faccessat2 thingy then
2020-10-31 12:35:24 <Ariadne> i did
2020-10-31 12:35:45 <ikke> I'll test it once it lands
2020-10-31 12:35:47 <Ariadne> we will do that for now and revisit faccessat2 later
2020-10-31 12:36:13 <Ariadne> in the case of CI, doesnt gitlab-runner
2020-10-31 12:36:15 <Ariadne> embed its own docker
2020-10-31 12:36:19 <nmeum> > build-edge-armv7: failed to build firefox-esr:
2020-10-31 12:36:20 <nmeum> hmhmhm
2020-10-31 12:36:22 <ikke> Ariadne: no
2020-10-31 12:36:50 <ikke> the runner uses the host docker daemon
2020-10-31 12:37:13 <nmeum> time to play the "find the error message in the 10 MiB build log"-game
2020-10-31 12:38:33 <ikke> also on aarch64
2020-10-31 12:39:22 <Cogitri> nmeum: At least 10 MiB is something less can handle somewhat well still :D
2020-10-31 12:39:23 <nmeum> love how the build log is full with warnings
2020-10-31 12:39:33 <Cogitri> It starts to get annoying with 100MiB logs :^)
2020-10-31 12:39:44 <Cogitri> Yeah, especially the Rust stuff is full of warnings
2020-10-31 12:39:58 <nmeum> actually it's 61.1 MiB :3
2020-10-31 12:40:06 <Cogitri> Because Rust deprecates stuff relatively often compared to other langs and FF is slow ti update its deps
2020-10-31 12:40:19 <ikke> nmeum: https://tpaste.us/by4M
2020-10-31 12:40:22 <Cogitri> Oh, searching in that is no fun :D
2020-10-31 12:40:39 <ikke> less does a pretty good job
2020-10-31 12:40:42 <Cogitri> Oh wait, you're talking about FF-esr <78.5?
2020-10-31 12:40:47 <nmeum> yes
2020-10-31 12:40:50 <Cogitri> That's broken with rustc >=1.47
2020-10-31 12:40:53 <nmeum> this doesn't look related to my patch
2020-10-31 12:40:53 <Cogitri> Known upstream
2020-10-31 12:40:56 <nmeum> wow that too m)
2020-10-31 12:40:59 <nmeum> well fuck
2020-10-31 12:41:03 <Cogitri> Patch will land in firefox-esr 78.5
2020-10-31 12:41:22 <Cogitri> See https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/13787
2020-10-31 12:41:28 <nmeum> so...how do I test the musl ioctl fix then? ':)
2020-10-31 12:41:40 <Cogitri> There's a patch mentioned in that MR
2020-10-31 12:41:50 <Cogitri> But it's a few thousand LOC
2020-10-31 12:42:02 <nmeum> yikes
2020-10-31 12:42:25 <Cogitri> Yeah :/
2020-10-31 12:42:33 <Cogitri> The patch is backporting an upgrade to a dependency
2020-10-31 12:42:40 <Cogitri> And that dependency apparently changed A LOT recently
2020-10-31 12:42:48 <Cogitri> So it's basically rewriting itself :D
2020-10-31 12:43:13 <nmeum> does community/firefox still build?
2020-10-31 12:43:32 <Cogitri> Non esr builds I think
2020-10-31 12:43:35 <Cogitri> Haven't tested
2020-10-31 12:44:02 <ikke> So now what?
2020-10-31 12:44:03 <nmeum> should I try my ioctl patch with community/firefox instead of community/firefox-esr then? ':)
2020-10-31 12:44:06 <ikke> revert ff-esr?
2020-10-31 12:44:12 <nmeum> even if we revert it it doesn't buidl
2020-10-31 12:44:21 <Cogitri> Yes
2020-10-31 12:44:30 <ikke> Well, it should stop trying to build it
2020-10-31 12:44:37 <ikke> I guess
2020-10-31 12:44:40 <Cogitri> Either we wait for 78.5 to land or apply that patch
2020-10-31 12:44:49 <nmeum> idk what do you prefer?
2020-10-31 12:44:53 <Cogitri> Unfortunately I'm pretty busy due to uni right now so  I can't look into that right now :/
2020-10-31 12:44:56 <nmeum> we could just disable it, i don't know what's best here
2020-10-31 12:44:58 <ikke> I'd prefer to get the builders green
2020-10-31 12:45:12 <nmeum> hehe, don't we all?
2020-10-31 12:45:21 <Cogitri> Apparently 78.5 is scheduled for November 17
2020-10-31 12:45:25 <ikke> I certainly do hope so :)
2020-10-31 12:45:29 <nmeum> well that's a while
2020-10-31 12:45:32 <Cogitri> So  I guess backporting the patch would be good
2020-10-31 12:45:34 <Cogitri> Yeah
2020-10-31 12:45:39 <ikke> But it has been a while since the builders have been completely green
2020-10-31 12:47:07 <nmeum> regarding firefox: as I said before: my build server is down, I can't build it on my laptop and the ci is broken too so I can't really work on backporting the rust patch for firefox-esr
2020-10-31 12:47:27 <ikke> nmeum: I think we should be able to get you an lxc container
2020-10-31 12:47:57 <ikke> nmeum: interested?
2020-10-31 12:47:59 <nmeum> ure
2020-10-31 12:48:00 <nmeum> sure
2020-10-31 12:48:14 <nmeum> if I can just ssh into it
2020-10-31 12:48:58 <ikke> I can add a port forward
2020-10-31 12:49:29 <ikke> Can I use one of these keys? https://gitlab.alpinelinux.org/nmeum.keys
2020-10-31 12:49:45 <nmeum> > It will probably be less painful to just downgrade rust until this is fixed upstream.
2020-10-31 12:49:51 <nmeum> uff
2020-10-31 12:50:22 <Ariadne> :D :D :D :D
2020-10-31 12:50:26 <Ariadne> just backport the patch
2020-10-31 12:50:33 <nmeum> ikke: yes
2020-10-31 12:50:47 <nmeum> i hate computers
2020-10-31 12:50:50 <nmeum> especially firefox
2020-10-31 12:50:53 <Ariadne> me too
2020-10-31 12:52:05 <Cogitri> Although downgrading rust wouldn't be less painful since bootstrapping Rust of $pkgver with $pkgver + 0.1 probably wont work :D
2020-10-31 12:52:10 <Cogitri> Rust devs only test with $pkgver - 0,1
2020-10-31 12:52:24 <nmeum> oh boy
2020-10-31 12:52:30 <Cogitri> So we'd have to steal the Rust tarballs from 3.12 and bootstrap from that
2020-10-31 12:52:40 <Ariadne> :D :D :D :D :D
2020-10-31 12:52:44 <Cogitri> Bumping version by version until 1.45
2020-10-31 12:52:51 <Ariadne> i hate computers, especially rust
2020-10-31 12:52:52 <nmeum> how about we just disable firefox-esr for two weaks?
2020-10-31 12:52:55 <Cogitri> Which is even more painful for us because of our downstream patches
2020-10-31 12:52:57 <nmeum> *weeks
2020-10-31 12:53:07 <Cogitri> Not a great solution, but we can disable it for now to get the builders green
2020-10-31 12:53:14 <nmeum> I don't see myself spending a weekend to backport a firefox-esr patch that is obselete in two weeks
2020-10-31 12:53:25 <Ariadne> downgrade the pkgrel if you do that
2020-10-31 12:53:31 <Ariadne> so it doesn't delete the pre-existing build
2020-10-31 12:53:43 <nmeum> hm?
2020-10-31 12:53:54 <Ariadne> if you disable
2020-10-31 12:54:01 <Ariadne> with incremented pkgrel
2020-10-31 12:54:10 <Ariadne> the builders will purge the current firefox-esr packages
2020-10-31 12:54:19 <nmeum> https://tpaste.us/7gKB like this?
2020-10-31 12:54:29 <Ariadne> yes
2020-10-31 12:54:54 <nmeum> but the last succesfully build firefox esr version is 78.3.1-r0
2020-10-31 12:54:56 <nmeum> that won't be purged then?
2020-10-31 12:54:57 <Ariadne> with some luck, we will have rust on s390x and mips by the end of next week
2020-10-31 12:55:05 <Ariadne> no
2020-10-31 12:55:08 <Ariadne> it will be left alone
2020-10-31 12:55:11 <Ariadne> its a bug
2020-10-31 12:55:16 <nmeum> hahaha
2020-10-31 12:55:20 <nmeum> ok......
2020-10-31 12:55:24 <nmeum> I guess we do that then?
2020-10-31 12:55:27 <Cogitri> Ariadne: Feel free to ping me if there's something I can help with the Rust
2020-10-31 12:55:45 <Ariadne> Cogitri: i just need help with the apkbuild + rust itself side
2020-10-31 12:56:09 <Ariadne> Cogitri: if we can get to a point where CBUILD=aarch64 abuild -r generates an aarch64 rust on x86, i can take it from there
2020-10-31 12:56:48 <insep_> Ariadne: you mean rust is a bug or purge is a bug?
2020-10-31 12:56:55 <Ariadne> ikke: yes
2020-10-31 12:56:58 <Ariadne> insep_: yes
2020-10-31 12:57:21 <ikke> nmeum: can you try root@147.75.32.21 -p 22029
2020-10-31 12:57:38 <nmeum> works
2020-10-31 12:57:41 <ikke> cool
2020-10-31 12:57:42 <ikke> enjoy
2020-10-31 12:57:48 <nmeum> hehe
2020-10-31 12:57:49 <nmeum> thanks
2020-10-31 12:57:56 <Ariadne> my plan is basically
2020-10-31 12:58:02 <Ariadne> cross-compile s390x and mips64 rust
2020-10-31 12:58:08 <nmeum> ikke: would you be ok with disabling firefox-esr in the way Ariadne suggested though?
2020-10-31 12:58:18 <Ariadne> get ikke to install the cross-compiled s390x rust on the builder
2020-10-31 12:58:22 <Ariadne> i do likewise for mips64
2020-10-31 12:58:23 <Ariadne> :)
2020-10-31 12:58:35 <Ariadne> voila, we have rust on s390x and mips64
2020-10-31 12:58:46 <Ariadne> and can use that rust to build a new rust
2020-10-31 12:59:29 <ikke> nmeum: ariadne suggested to revert it again, right?
2020-10-31 12:59:34 <ikke> to the version that alreayd exists
2020-10-31 12:59:39 <nmeum> basically, yes
2020-10-31 12:59:43 <Ariadne> if you revert it
2020-10-31 12:59:49 <Ariadne> it will stop building it
2020-10-31 12:59:51 <ikke> yes
2020-10-31 12:59:53 <Ariadne> you dont actually need to disable
2020-10-31 12:59:56 <nmeum> ah
2020-10-31 12:59:57 <Ariadne> i think
2020-10-31 13:00:03 <nmeum> so just decrementing the pkgrel should be sufficient?
2020-10-31 13:00:03 <ikke> Ariadne: that's my understanding as well
2020-10-31 13:00:12 <Ariadne> nmeum: no, git revert is needed because mtime
2020-10-31 13:00:17 <ikke> aha
2020-10-31 13:00:22 <Ariadne> abuild will rebuild if mtime changes
2020-10-31 13:00:34 <nmeum> ok, someone go ahead and do that
2020-10-31 13:00:46 <ikke> I can do that
2020-10-31 13:00:48 <nmeum> thank youk
2020-10-31 13:01:18 <Ariadne> ikke: will you have time this week to install a cross-compiled rustc onto the s390x builder and kick off a rebuild by hand?
2020-10-31 13:01:21 <nmeum> I will test my ioctl musl patch with community/firefox on the lxc you gave me in the meantime
2020-10-31 13:01:25 <insep_> 
ACTION wonders what are the chances of rust crosscompiling successfully using pmbootstrap

2020-10-31 13:01:45 <Ariadne> insep_: same chances as dabuild
2020-10-31 13:01:52 <ikke> Ariadne: yeah, I think so
2020-10-31 13:02:04 <Ariadne> insep_: rust has to be patched to support each new alpine target (because reasons)
2020-10-31 13:02:35 <insep_> Ariadne: is musl one of those reasons?
2020-10-31 13:02:40 <Ariadne> insep_: pmbootstrap does not actually crosscompile, but uses qemu-user
2020-10-31 13:02:58 <Ariadne> insep_: yes.  rust assumes musl = static
2020-10-31 13:03:11 <Ariadne> so we add our own targets for dynamically linked musl
2020-10-31 13:03:36 <ikke> nmeum: reason is incompattibility with rust, correct?
2020-10-31 13:03:41 <insep_> Ariadne: not really, we have some minimal rustc support that is able to compile hello world and fails at more compleх stuff, see https://gitlab.com/postmarketOS/pmbootstrap/-/issues/1901
2020-10-31 13:03:47 <ikke> 1.47?
2020-10-31 13:04:03 <Ariadne> insep_: weird
2020-10-31 13:04:25 <nmeum> ikke: looks like it https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/13787#note_120229
2020-10-31 13:04:38 <nmeum> maybe just reference that MR thread in the commit
2020-10-31 13:04:51 <insep_> the way how we crosscompile stuff is create chroot with $target arch and make native compilers available in it
2020-10-31 13:05:04 <ikke> nmeum: thanks, will do
2020-10-31 13:05:13 <insep_> also wtf i didn't eхpect matriх=>irc bridge to have such low lag
2020-10-31 13:07:03 <ikke> ok, that worked
2020-10-31 13:08:20 <nmeum> yeah, finally something that does work :)
2020-10-31 13:08:33 <ikke> now clean-up KDE stuff
2020-10-31 13:09:11 <Ariadne> errrrrrrrrr
2020-10-31 13:09:16 <Ariadne> ikke
2020-10-31 13:09:19 <Ariadne> you reverted wrong one
2020-10-31 13:09:31 <Ariadne> ff0f7f796a5435509f6af0382c2d4d89e016c7c3
2020-10-31 13:09:34 <Ariadne> is the one needing revert
2020-10-31 13:09:44 <ikke> ugh
2020-10-31 13:09:49 <ikke> I thought I had that one selected :(
2020-10-31 13:10:35 <Ariadne> honestly
2020-10-31 13:10:46 <Ariadne> i think we should keep kde red on s390x/mips and just fix rust
2020-10-31 13:10:57 <ikke> hmm
2020-10-31 13:11:06 <Ariadne> because once rust is fixed
2020-10-31 13:11:13 <Ariadne> we can just unblock basically everything
2020-10-31 13:11:27 <Ariadne> and mips and s390x can even have gnome
2020-10-31 13:11:37 <Ariadne> (not that anyone is going to really run gnome or kde on these devices but :P)
2020-10-31 13:14:58 <ikke> https://tpaste.us/1JO0
2020-10-31 13:15:07 <ikke> That should be correct now, right?
2020-10-31 13:15:54 <ikke> ah, you alreayd pushed it
2020-10-31 13:17:30 <Ariadne> lets target s390x first for rust
2020-10-31 13:18:08 <Cogitri> Yes, that'd be handy so we can have polkit in libvirt
2020-10-31 13:18:14 <Cogitri> and libvirt on s390x
2020-10-31 13:18:20 <Cogitri> about GNOME: not sure about that :P
2020-10-31 13:19:20 <ikke> 02ffa8ab629d058984297340b0a689bbf7ccde10
2020-10-31 13:19:50 <ikke> increased the hash length that algitbot uses for abbreviated commits
2020-10-31 13:20:50 <ikke> Lots of links didn't work because of ambiguous hashes
2020-10-31 13:21:24 <Cogitri> Ah neat
2020-10-31 13:22:30 <nmeum> sweet
2020-10-31 13:26:37 <Ariadne> grr
2020-10-31 13:26:45 <Ariadne> my laptop ran out of space
2020-10-31 13:27:52 <ikke> Ariadne: ugh, happened to me as well
2020-10-31 13:28:24 <Ariadne> its ok
2020-10-31 13:28:26 <Ariadne> i have
2020-10-31 13:28:32 <Ariadne> power9 server still :)
2020-10-31 13:34:21 <Ariadne> doing this with makeflags -j160 is more pleasant anyway
2020-10-31 13:34:23 <Ariadne> :)
2020-10-31 13:35:23 <ikke> haha :D
2020-10-31 13:37:57 <Ariadne> hmmm
2020-10-31 13:38:02 <Ariadne> i have, actually
2020-10-31 13:38:18 <Ariadne> a second cabinet as part of my free colo for network engineering deal
2020-10-31 13:38:33 <Ariadne> maybe i can buy an IBM multiprise system for s390x porting
2020-10-31 13:38:44 <Ariadne> they are pretty cheap these days on government auction
2020-10-31 13:45:01 <Ariadne> make -j160 makes this a lot more pleasant really
2020-10-31 13:45:07 <Ariadne> bootstrap.sh is already almost done
2020-10-31 13:53:18 <ikke> for rust?
2020-10-31 13:54:17 <Ariadne> for s390x toolchain
2020-10-31 13:54:22 <Ariadne> next stop: rust
2020-10-31 13:54:46 <Ariadne> i have 7.4kW of power left, i wonder if that is enough for an s390x system
2020-10-31 13:57:47 <nmeum> ok, firefox builds succesfully with my patch on the lxc
2020-10-31 13:57:54 <nmeum> community/firefox that is
2020-10-31 13:58:56 <Ariadne> cool
2020-10-31 13:59:01 <Ariadne> send it
2020-10-31 13:59:46 <nmeum> will test if it has the intended effect first ;)
2020-10-31 14:01:12 <nmeum> well
2020-10-31 14:01:16 <nmeum> looks like it works
2020-10-31 14:02:39 <Ariadne> LOLZ
2020-10-31 14:02:55 <nmeum> ?
2020-10-31 14:08:30 <nmeum> ok, tbh community/firefox also works fine without the patch here, cc: PureTryOut[m]
2020-10-31 14:08:46 <nmeum> contrary to firefox-esr it does not complain about syscall 16
2020-10-31 14:10:37 <nmeum> PureTryOut[m]: what error message are you getting on your firefox, are you sure you are using -r1?
2020-10-31 14:11:17 <Ariadne> >>> ERROR: apk-tools-static*: Split function set arch="x86_64" for apk-tools-static, use subpackages=pkg:split:arch format instead
2020-10-31 14:11:19 <Ariadne> oh wtf
2020-10-31 14:15:28 <Ariadne> >>> ERROR: apk-tools-static*: Split function set arch="x86_64" for apk-tools-static, use subpackages=pkg:split:arch format instead [compared to all]
2020-10-31 14:15:32 <Ariadne> ?????
2020-10-31 14:16:07 <Ariadne> this check is bogus
2020-10-31 14:17:08 <Ariadne> b217bbb2 abuild.in (Timo Teräs            2016-07-23 06:18:27 +0000 1047)               local msg="Split function set arch=\"$arch\" for $name, use subpackages=pkg:split:arch format instead"
2020-10-31 14:17:12 <Ariadne> ok
2020-10-31 14:17:16 <Ariadne> what the hell has happened
2020-10-31 14:17:48 <Ariadne> haha my bad
2020-10-31 14:18:10 <ikke> :)
2020-10-31 14:20:56 <Ariadne> i have some weird stuff in my abuild.conf
2020-10-31 14:21:04 <Ariadne> because i sign mips packages with a different key :P
2020-10-31 14:36:21 <PureTryOut[m]2> nmeum: yes I'm 100% sure I'm using -r1
2020-10-31 14:36:40 <PureTryOut[m]2> I'm getting seccomp sandbox violation syscall 16
2020-10-31 14:37:20 <Ariadne> fixed firefox hasn't been pushed yet.
2020-10-31 14:37:23 <PureTryOut[m]2> `apk list -I | grep firefox` > `firefox-82.0-r1`
2020-10-31 14:37:41 <Ariadne> fixed firefox will be -r2
2020-10-31 14:38:00 <PureTryOut[m]2> Awesome thanks, but I responded to nmeum which asked if I was sure I was using -r1 as it works for him
2020-10-31 14:39:32 <Ariadne> ... that's ncie
2020-10-31 14:39:39 <Ariadne> libcap detects if go is installed
2020-10-31 14:39:42 <Ariadne> and tries to build go crap
2020-10-31 14:39:53 <Ariadne> going to have to investigate that
2020-10-31 14:42:27 <nmeum> PureTryOut[m]2: i can't reproduce it, can you test if this patches fixes it for you https://tpaste.us/W7RR
2020-10-31 14:42:47 <nmeum> can also give you a pre-built version if you want to trust me ;)
2020-10-31 14:42:50 <PureTryOut[m]2> If someone tells me how to make abuild use more than 1 job to compile stuff, sure
2020-10-31 14:42:55 <ikke> CI should work again as well, right?
2020-10-31 14:42:56 <PureTryOut[m]2> I'll trust you for now 😜
2020-10-31 14:43:06 <ikke> PureTryOut[m]2: adjust JOBS in /etc/abuild.conf
2020-10-31 14:43:41 <dalias> ikke, ariadne, fix the broken seccomp filters. this should have been done the first time the issue came up.
2020-10-31 14:43:41 <mps> or export them before abuild run
2020-10-31 14:44:01 <dalias> grep -r EPERM, find the code that's doing it, and change it
2020-10-31 14:44:08 <nmeum> PureTryOut[m]2: https://files.8pit.net/tmp/firefox-82.0-r2.apk if you want the prebuilt one
2020-10-31 14:44:18 <Ariadne> dalias: unfortunately it is go
2020-10-31 14:44:31 <Ariadne> dalias: so, i'm not really enthusiastic about digging into that at this time
2020-10-31 14:45:17 <Ariadne> checking whether SysV IPC message queues are actually working on the host... configure: error: in `/home/kaniini/aports/main/fakeroot/src/fakeroot-1.25.3':
2020-10-31 14:45:17 <Ariadne> See `config.log' for more details
2020-10-31 14:45:17 <Ariadne> configure: error: cannot run test program while cross compiling
2020-10-31 14:45:19 <Ariadne> oh my fucking god
2020-10-31 14:46:26 <Ariadne> --with-ipc=tcp i guess
2020-10-31 14:50:00 <dalias> ariadne, what's the repo? i'll find it
2020-10-31 14:50:10 <Ariadne> that's the other problem
2020-10-31 14:50:23 <ikke> containerd / docker?
2020-10-31 14:50:35 <Ariadne> docker is a mess of subrepos
2020-10-31 14:50:45 <Ariadne> all of whch have seccomp stuff in them
2020-10-31 14:50:51 <PureTryOut[m]2> nmeum: still lots of complaints about the seccomp violation in the terminal, but yeah your build works
2020-10-31 14:51:12 <dalias> hmm is the fakeroot failure new in 1.25[.3] ?
2020-10-31 14:52:25 <Ariadne> yes
2020-10-31 14:52:28 <Ariadne> for cross compile
2020-10-31 14:52:41 <Ariadne> they added new SysV IPC mode
2020-10-31 14:52:52 <Ariadne> i fixed it by switching back to old TCP IPC mode
2020-10-31 14:53:08 <timlegge> perl-b-debug was moved to community two days a go but still has not built for ppc64le, s390x or mips64 on pkgs.alpinelinux.org - anything need to be done to trigger it?
2020-10-31 14:53:49 <ikke> timlegge: no
2020-10-31 14:54:06 <ikke> timlegge: there are some build failures on those arches that is keeping the builders stuck
2020-10-31 14:54:14 <ikke> mostly to do with rust missing, which Ariadne is working on
2020-10-31 14:54:33 <Ariadne> ppc64le is already fixed
2020-10-31 14:55:38 <timlegge> thanks
2020-10-31 14:56:30 <nmeum> PureTryOut[m]: what kind of violations do you still get?
2020-10-31 14:56:37 <nmeum> like…new ones compared to the old musl?
2020-10-31 14:58:10 <PureTryOut[m]2> nmeum: they seem the same
2020-10-31 15:00:13 <Ariadne> okay
2020-10-31 15:00:29 <Ariadne> Cogitri: ping
2020-10-31 15:03:17 <Ariadne> Cogitri: next step is to split makedepends based on makedepends_build and makedepends_host
2020-10-31 15:03:51 <Ariadne> Cogitri: i need to know what rust needs in sysroot (makedepends_host) vs what it needs in build machine
2020-10-31 15:05:16 <ikke> ppc64le is continuing now
2020-10-31 15:06:30 <Cogitri> Ariadne: https://github.com/void-linux/void-packages/blob/master/srcpkgs/rust/template#L14
2020-10-31 15:07:27 <Ariadne> great, thank you
2020-10-31 15:11:45 <Ariadne> damn
2020-10-31 15:11:52 <Ariadne> we're going to have to work on a few dependencies
2020-10-31 15:11:57 <Ariadne> to cross-enable rust
2020-10-31 15:12:13 <Ariadne> such is life i guess
2020-10-31 15:21:03 <Hello71_> seems inconsistent with https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-lang/rust/rust-1.46.0.ebuild, which says that cmake is only required if not using system llvm, and curl is a host dep, not build
2020-10-31 15:21:12 <Hello71_> could be the gentoo one is wrong though
2020-10-31 15:22:57 <Hello71_> at least the cmake part should be right though
2020-10-31 15:31:21 <Hello71> that should cut out a decent chunk of the dep tree, especially that cmake curl cycle if that's a problem
2020-10-31 15:32:51 <Cogitri> The CMake thingie probably is right, but I think libcurl is probably needed for build+host
2020-10-31 15:32:54 <nmeum> PureTryOut[m]2: the same compared to the errors you usually get?
2020-10-31 15:33:16 <PureTryOut[m]2> Well to the ones I got before using your build with the latest musl anyway. Not sure if I got these errors before all these problems
2020-10-31 15:33:41 <nmeum> paste the errors?
2020-10-31 15:33:46 <nmeum> that is: the error message
2020-10-31 15:34:24 <nmeum> lets move this discussion to an MR
2020-10-31 15:36:03 <nmeum> PureTryOut[m]2: !14152
2020-10-31 15:41:13 <Ariadne> Hello71: we need to build llvm though
2020-10-31 15:44:06 <Ariadne> lets find out
2020-10-31 15:44:10 <Ariadne> i'll do non-cross build
2020-10-31 15:46:12 <Cogitri> Ariadne: We use system llvm so we shouldn't need to build rust's llvm
2020-10-31 15:46:31 <Ariadne> yes but we need to build system llvm as part of bootstrap is what i mean
2020-10-31 15:46:40 <Cogitri> Ah, but we do need cmake for llvm before building rust, yes
2020-10-31 15:48:08 <Ariadne> its ok
2020-10-31 15:48:12 <Ariadne> rust builds very fast
2020-10-31 15:48:16 <Ariadne> when you have 160 cpus
2020-10-31 15:49:07 <Cogitri> Does it? It's still dog slow on 32 x86_64 cores :D
2020-10-31 15:49:18 <Cogitri> Because the final link takes forever
2020-10-31 15:49:28 <Ariadne> well that part is slow
2020-10-31 15:49:49 <Ariadne>     Finished dev [unoptimized + debuginfo] target(s) in 1m 29s
2020-10-31 15:49:50 <Ariadne> hmm
2020-10-31 15:50:00 <Ariadne> is there a reason we aren't building with optimize enabled ?
2020-10-31 15:51:04 <Ariadne> anyway we don't have to cross-compile cmake
2020-10-31 15:53:13 <Cogitri> Ariadne: That's from rustc ?
2020-10-31 15:53:20 <Cogitri> And that's the last stage?
2020-10-31 15:53:42 <Cogitri> I think it might not compile stage 1+2 in optimized mode so it doesn't take even longer
2020-10-31 15:54:07 <Ariadne> yeah final one was optimized
2020-10-31 15:54:19 <Cogitri> 👍
2020-10-31 16:09:57 <Newbyte> do you guys know which package provides the Python gi module (I presume it's gobject-introspection)?
2020-10-31 16:10:04 <Newbyte> is it packaged in Alpine?
2020-10-31 16:10:25 <Cogitri> py3-gobject3
2020-10-31 16:10:30 <Newbyte> thank you
2020-10-31 16:12:36 <dalias> ariadne, how does fakeroot ipc check fail?
2020-10-31 16:12:46 <dalias> do you have a config.log ?
2020-10-31 16:12:53 <Ariadne> dalias: it wants to compile and run code
2020-10-31 16:13:01 <Ariadne> dalias: you can't do that if you're cross compiling ...
2020-10-31 16:14:07 <dalias> ohh i see
2020-10-31 16:14:22 <dalias> anyway why are they using sysvipc instead of a unix socket ?!
2020-10-31 16:14:44 <Ariadne> dalias: basically ther autotools crap does not let you bypass the code compilation check.  we could patch out the check i guess.  i'd rather just write a replacement for fakeroot that is ... sane anyway
2020-10-31 16:14:48 <dalias> tcp and sysvipc are about the two worst ways you could do this..
2020-10-31 16:14:56 <dalias> you can byass it
2020-10-31 16:15:16 <Ariadne> you can't do so without patching their configure script is what i mean
2020-10-31 16:15:38 <dalias> oh is it broken? configure scripts should cache results
2020-10-31 16:15:40 <Ariadne> because you can't just supply a config var
2020-10-31 16:15:42 <Ariadne> yeah
2020-10-31 16:15:44 <Ariadne> its broken :)
2020-10-31 16:15:49 <dalias> and you can just pass the cache result as an arg
2020-10-31 16:15:52 <dalias> *sigh*
2020-10-31 16:16:12 <Ariadne> yes, i know -- their script does everything by hand and so it doesnt use cache
2020-10-31 16:16:14 <Ariadne> ;/
2020-10-31 16:16:25 <dalias> i'm waiting til there's a real fakeroot replacement using seccomp
2020-10-31 16:16:33 <Ariadne> that was my plan yes
2020-10-31 16:16:57 <Ariadne> unfortunately i am going to have to write a wayland compositor that uses only framebuffer drawing to prove a point first
2020-10-31 16:17:20 <dalias> :(
2020-10-31 16:18:08 <Ariadne> there is some idea that wayland compositors MUST use opengl
2020-10-31 16:18:24 <Ariadne> so i intend to write a simple compositor demonstrating that to be false ;)
2020-10-31 16:18:57 <Ariadne> almost have the rust dependency tree cross-compileable
2020-10-31 16:19:04 <dalias> ah
2020-10-31 16:19:13 <dalias> why would anyone have a ridiculous idea like that??
2020-10-31 16:19:26 <mps> dalias: Ariadne: there was try with 'pseudo' but don't know how good it is
2020-10-31 16:19:30 <Ariadne> because all the popular compositors use opengl
2020-10-31 16:20:17 <mps> pseudo as fakeroot replacement, I mean
2020-10-31 16:21:17 <Ariadne> well my $dayjob provides alpine and debian development services
2020-10-31 16:21:22 <Ariadne> so i am sure it will come up eventually
2020-10-31 16:21:24 <Ariadne> :)
2020-10-31 16:21:55 <Ariadne> since, you know, alpine and debian are the primary consumers of fakeroot
2020-10-31 16:22:02 <Ariadne> and everyone involved agrees fakeroot is shit
2020-10-31 16:22:04 <Ariadne> :P
2020-10-31 16:22:04 <dalias> the whole idea of "compositor" as fundamental primitive rather than silly eye candy gimmick is so infuriating
2020-10-31 16:22:33 <Ariadne> dalias: well, that is why mine is going to be state of the 1980s and have the visual stylings of TWM
2020-10-31 16:22:55 <dalias> there was also fakeroot-ng but it's deadend-ish because it's using ptrace rather than seccomp (it started before seccomp was a viable replacement)
2020-10-31 16:22:59 <Ariadne> and probably not even support alpha channel
2020-10-31 16:23:02 <dalias> ariadne, :)
2020-10-31 16:24:26 <Ariadne> our journey is almost to the big elephant in the room: llvm
2020-10-31 16:24:36 <Ariadne> open to suggestions on how to cross-compile llvm
2020-10-31 16:24:48 <Ariadne> otherwise, i will just head to the liquor store and find some inspiration there
2020-10-31 16:25:53 <dalias> :/
2020-10-31 16:26:05 <dalias> btw what's going on with cross compiling?
2020-10-31 16:26:13 <dalias> is alpine moving to doing most/everything as cross?
2020-10-31 16:26:16 <Ariadne> hell no
2020-10-31 16:26:22 <Newbyte> I'm not super familiar with Python, is there any way of telling which package a module comes from? Are they all named <pyversion>-<modulename>?
2020-10-31 16:26:28 <Newbyte> can't seem to find "mistune"
2020-10-31 16:26:36 <Ariadne> i am just doing all of this so we can have rust on all architectures
2020-10-31 16:26:36 <Newbyte> in Alpine's repos
2020-10-31 16:26:45 <Hello71> https://pkgs.alpinelinux.org/contents
2020-10-31 16:26:55 <Ariadne> Newbyte: apk list py:mistune
2020-10-31 16:26:57 <Newbyte> yeah but I don't really know how Python modules look in the filesystem
2020-10-31 16:27:21 <Newbyte> seems I'll have to package mistune myself
2020-10-31 16:27:37 <Ariadne> or do we not have py3: dependency generators
2020-10-31 16:27:39 <Ariadne> i dont remember
2020-10-31 16:28:18 <Newbyte> I'm too new to this to know :(
2020-10-31 16:28:33 <Newbyte> but I think I remember reading something like that?
2020-10-31 16:28:52 <Ariadne> treefort:~/aports/scripts$ apk list -P pc:Qt5Widgets
2020-10-31 16:28:52 <Ariadne> <pc:Qt5Widgets> qt5-qtbase-dev-5.15.1-r0 ppc64le {qt5-qtbase} (LGPL-2.1-only AND LGPL-3.0-only AND GPL-3.0-only AND Qt-GPL-exception-1.0)
2020-10-31 16:29:03 <Ariadne> yeah we do not have py3: dep gens
2020-10-31 16:29:04 <Ariadne> sorry
2020-10-31 16:29:06 <Ariadne> :(
2020-10-31 16:29:26 <Ariadne> but apk list -P can find tons of stuff
2020-10-31 16:29:27 <Newbyte> also, curious, are you kaniini on Telegram?
2020-10-31 16:29:33 <Ariadne> yes
2020-10-31 16:30:08 <Newbyte> shouldn't be too hard to mimic a different python package I imagine
2020-10-31 16:33:58 <Cogitri> Ariadne: LLVM provides a pretty decent "how to build llvm" tutorial
2020-10-31 16:34:16 <Ariadne> Cogitri: but it does not suggest alcoholic pairings
2020-10-31 16:34:31 <Ariadne> and trust me, one does not go into building LLVM sober
2020-10-31 16:34:32 <Ariadne> :D
2020-10-31 16:35:50 <Ariadne> dalias: basically, i just need to make rust's dependencies (and rust itself) cross compilable.  then we get rust on any arch we want it on.
2020-10-31 16:36:17 <Ariadne> because we can supply cross-compiled rust as rust-bootstrap
2020-10-31 16:36:34 <Ariadne> and we start from a trusted compiler (our own rustc on a different arch)
2020-10-31 16:38:27 <Newbyte> I presume newapkbuild -y would be applicable if you're creating a package for a python package?
2020-10-31 16:38:35 <Newbyte> library/package
2020-10-31 16:40:30 <Newbyte> as for pkgdesc, can I put whatever I want or should I put upstream's description?
2020-10-31 16:41:02 <mps> Newbyte: read CodingStyle.md in aports
2020-10-31 16:41:24 <mps> CODINGSTYLE.md
2020-10-31 16:42:46 <Newbyte> found it, thanks
2020-10-31 16:43:59 <Newbyte> I don't see anything about pkgdesc though
2020-10-31 16:44:44 <mps> heh, should be added
2020-10-31 16:45:25 <mps> simle one line sentence which describe package, max len 80 chars
2020-10-31 16:45:48 <mps> without 'A ', 'The ' and similar
2020-10-31 16:46:08 <mps> use lower case whenever possible
2020-10-31 16:46:13 <Newbyte> if the package calls itself "fast yet powerful", should I bother including that?
2020-10-31 16:46:18 <Newbyte> oh, so no capitalisation of the first letter?
2020-10-31 16:46:32 <mps> and id doesn't must repeat upstrem description
2020-10-31 16:46:43 <Newbyte> got it, thanks
2020-10-31 16:48:06 <mps> instead of such lies^Wattibutes fast, powerful, clean-your-room try to describe what package actually do
2020-10-31 16:54:05 <Ariadne> ../../bin/llvm-tblgen: line 1: syntax error: unexpected word (expecting ")")
2020-10-31 16:54:06 <Ariadne> okay
2020-10-31 16:54:17 <Ariadne> we're kinda getting there :D
2020-10-31 17:02:06 <Ariadne> haha fuck yeah
2020-10-31 17:02:10 <Ariadne> llvm10 is cross compiling
2020-10-31 17:10:23 <Newbyte> now, this might not entirely be the right place to ask this, but if Gio/Glib complains about some operation not being supported, could that be due to a missing dependency?
2020-10-31 17:10:24 <Newbyte> https://gitlab.gnome.org/World/giara/-/blob/master/giara/__main__.py#L158
2020-10-31 17:10:27 <Newbyte> failing on this line
2020-10-31 17:10:50 <Newbyte> not very familiar with Gio/Glib
2020-10-31 17:11:23 <mps> like I'm not with python
2020-10-31 17:11:47 <Cogitri> Newbyte: Could you send the error message?
2020-10-31 17:12:07 <Newbyte> one moment
2020-10-31 17:12:30 <Ariadne> Cogitri: i am moments away from having llvm10 cross compiled :)
2020-10-31 17:12:32 <Cogitri> That opens the link like xdg-open does, so I guess it might fail to open if you don't have any application that handles HTTP(S) links (so no webbrowser)
2020-10-31 17:12:50 <Newbyte> also, Cotgitri, you maintain a bunch of GNOME pacakges, yes? do you want to be the maintainer of this?
2020-10-31 17:13:02 <Newbyte> yeah, I don't have a browser installed. I'll install one
2020-10-31 17:13:19 <Newbyte> should probably make an issue about that upstream as right now it doesn't really tell the user it failed to open one
2020-10-31 17:13:58 <Newbyte> installed Firefox, still same thing. maybe it needs to be Epiphapy or something like that
2020-10-31 17:14:03 <Newbyte> Firefox-esr though
2020-10-31 17:14:05 <Cogitri> No, FF should work
2020-10-31 17:14:27 <Cogitri> I use the same functionality in an application of mine (although via Vala) and that works just fine
2020-10-31 17:14:33 <Ariadne>         so:libLLVM-10.so
2020-10-31 17:14:33 <Ariadne>         so:libc.musl-s390x.so.1
2020-10-31 17:14:35 <Ariadne> hot damn
2020-10-31 17:15:20 <Newbyte> could it be that I don't have dbus?
2020-10-31 17:15:30 <Newbyte> wait, I do have dbus running
2020-10-31 17:15:39 <Newbyte> apparently
2020-10-31 17:17:26 <Newbyte> created !14170 if you want to take a lot at it yourself
2020-10-31 17:17:32 <Ariadne> holy
2020-10-31 17:17:32 <Ariadne> fucking shit
2020-10-31 17:17:57 <Ariadne> configure: build.build          := x86_64-alpine-linux-musl
2020-10-31 17:17:57 <Ariadne> configure: build.target         := ['s390x-alpine-linux-musl']
2020-10-31 17:17:57 <Ariadne> configure: build.host           := ['s390x-alpine-linux-musl']
2020-10-31 17:17:58 <Ariadne> whoa
2020-10-31 17:20:12 <dalias> ariadne, i see (re: rust)
2020-10-31 17:20:40 <dalias> it's working?
2020-10-31 17:20:51 <Ariadne> almost :D
2020-10-31 17:23:47 <Ariadne> its compiling stuff
2020-10-31 17:23:51 <Ariadne> this is taking forever
2020-10-31 17:23:59 <Ariadne> i'll do this on the power9 directly instead of distcc
2020-10-31 17:24:01 <Ariadne> ;/
2020-10-31 17:25:22 <Cogitri> Nice
2020-10-31 17:26:45 <Ariadne> hmm
2020-10-31 17:26:58 <Ariadne> it isn't quite figuring out that this is a cross build
2020-10-31 17:29:59 <Ariadne> its trying to mix host assembly into target binary
2020-10-31 17:30:00 <Ariadne> lol
2020-10-31 17:34:26 <Hello71> Newbyte: did you try xdg-open
2020-10-31 17:35:39 <Newbyte> seems I don't have xdg-open installed
2020-10-31 17:36:52 <dalias> :/
2020-10-31 17:37:23 <Newbyte> I installed xdg-utils. xdg-open <URL> works, but giara still doesn't do its thing
2020-10-31 17:39:09 <Ariadne> ok try 2
2020-10-31 17:39:31 <Ariadne> looking at void's rust stuff i figured out i think what to tell it :)
2020-10-31 17:40:15 <Cogitri> 👍
2020-10-31 17:46:11 <Ariadne> it wont finish building because i need to add the targets first right?
2020-10-31 17:55:52 <Cogitri> You have to patch in the tripletd, yes
2020-10-31 17:55:58 <Cogitri> should be trivial tho
2020-10-31 17:57:52 <maxice8> @Ariadne: I have an MR for pyX.Y:module dependency generators but it is still WIP
2020-10-31 17:58:20 <maxice8> https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/24
2020-10-31 17:59:32 <ikke> maxice8: what is the goal of that MR?
2020-10-31 17:59:34 <ikke> I miss context
2020-10-31 17:59:53 <maxice8> Create a generator of pyX.Y provides like pc: and so:
2020-10-31 18:00:00 <ikke> but why?
2020-10-31 18:00:08 <maxice8> so that people can install them instead of hunting for modules
2020-10-31 18:00:18 <ikke> Add that to the MR / commits
2020-10-31 18:00:25 <maxice8> sure
2020-10-31 18:03:25 <Ariadne> (also cmd:)
2020-10-31 18:05:06 <maxice8>  ok pushed with another paragraph
2020-10-31 18:26:33 <Ariadne> running non-cross build with triplets added before pushing to builders
2020-10-31 18:28:55 <maxice8> Ikke makes a good point
2020-10-31 18:29:44 <maxice8> if we add pyX.Y people will start using them and whenever we do a python upgrade that changes the path in /usr/lib/python* it will cause lots of upgrades to fail
2020-10-31 18:31:24 <ikke> yup
2020-10-31 18:32:31 <Ariadne> thats why i am asking for pyX:
2020-10-31 18:32:37 <Ariadne> not pyX.Y
2020-10-31 18:32:52 <Ariadne> the idea is for the provides to be informational
2020-10-31 19:14:41 <Ariadne> ikke: will you be around tomorrow to do the rust stuff on the s390x builder?  i think i should have a repo by then
2020-10-31 19:17:49 <ikke> Ariadne: yes
2020-10-31 19:18:04 <ikke> mostly afternoon / evening CET
2020-10-31 19:18:24 <Ariadne> okay great
2020-10-31 19:27:56 <maxice8> Ok updated to pyX instead
2020-10-31 19:31:17 <maxice8> https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/24
2020-10-31 19:51:29 <Ariadne> Cogitri: i've noticed that package() causes cargo to rebuild some dependencies.  i don't know what is up with that.
2020-10-31 20:06:31 <minimal> Hi folks. Found the FreeRadius package won't install as it has broken dependancy - #12056, guess it just needs a rebuild. Simple as just a MR with incremented pkgrel?
2020-10-31 20:08:27 <c705> so chromium and firefox both have musl 1.2 problems. what browser am I supposed to use?
2020-10-31 20:09:24 <mps> w3m works for me
2020-10-31 20:09:51 <ikke> minimal: yes, that should work
2020-10-31 20:10:17 <Ariadne> c705: chromium --no-sandbox
2020-10-31 20:10:56 <c705> Ariadne: thanks. obviously this is a workaround
2020-10-31 20:11:02 <Ariadne> yes
2020-10-31 20:11:14 <Ariadne> one that works great for me anyway :P
2020-10-31 20:11:43 <c705> I really don't like the fact that tabs have access to the whole browser stack, but sure
2020-10-31 20:12:10 <c705> Is this a musl problem, or another case of bad code in chromium
2020-10-31 20:12:30 <Ariadne> its a case of seccomp filters being badly written
2020-10-31 20:13:49 <c705> and this is only an issue on edge I imagine, I just made a v3.12 build, is it worth booting into that?
2020-10-31 20:14:38 <Ariadne> chromium has been broken for a long while
2020-10-31 20:14:43 <Ariadne> since before 1.2
2020-10-31 20:15:02 <c705> firefox was fine for me until yesterday
2020-10-31 20:15:16 <c705> last build was oct 19, so sometime between 19 and now became a problem
2020-10-31 20:15:37 <Ariadne> firefox also has broken seccomp filters
2020-10-31 20:15:42 <Ariadne> nmeum has an updated package
2020-10-31 20:15:47 <Ariadne> dunno why he has not pushed it yet
2020-10-31 20:16:17 <Ariadne> [08:44:07] <nmeum> PureTryOut[m]2: https://files.8pit.net/tmp/firefox-82.0-r2.apk if you want the prebuilt one
2020-10-31 20:16:35 <c705> i'll boot 3.12 and see if musl 1.1 works
2020-10-31 20:22:12 <maxice8> Can I get a few more OKs for https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/24 ?
2020-10-31 20:33:13 <minimal> any chance someone could look at merging !14045 for me? Its been almost 4 days since I submitted it, I'm the package maintainer and I'm worried it might miss the 3.13.0 freeze
2020-10-31 20:35:52 <c705> welp, v3.12 is fine
2020-10-31 20:36:01 <c705> guess i'll stay here until 1.2 is ironed out
2020-10-31 20:36:05 <c705> thanks Ariadne
2020-10-31 20:36:51 <Ariadne> yes musl 1.2 has been a little rocky
2020-10-31 20:38:07 <ikke> minimal: our preference (or policy) is not to use post-install to show messages
2020-10-31 20:39:40 <Ariadne> now building s390x rustc
2020-10-31 20:41:28 <minimal> ikke: Argh! About 1 or so months ago there was a policy discussion as I'd put rc-update commands in post-install. I then moved them to a separate setup script. I've since had 1 person raise an issue that was due to them not running the setup script - hence this post-install message
2020-10-31 20:42:03 <minimal> during that discussion the objector to me code said I should put a message in postinstall instead!
2020-10-31 20:42:08 <ikke> heh
2020-10-31 20:42:29 <mps> minimal: there are some pkgs which display messages in install/upgrade
2020-10-31 20:43:10 <mps> so it is not 'set in stone', just preference as ikke say
2020-10-31 20:43:53 <ikke> the idea is that these messages can easily be missed
2020-10-31 20:44:06 <minimal> mps: realise that but if there's nothing set in stone its hard to ensure something won't be objected to
2020-10-31 20:44:16 <minimal> ikke: so what would you suggest then?
2020-10-31 20:45:06 <mps> find -name "*post-install" | xargs grep echo
2020-10-31 20:45:16 <ikke> minimal: well, that's why I mentioned it here
2020-10-31 20:46:03 <mps> I think we should not prefer that
2020-10-31 20:46:33 <minimal> so I should remove the post-install?
2020-10-31 20:47:03 <mps> I'm not judge
2020-10-31 20:47:20 <ikke> minimal: Archlinux has these kinds of instructions in their wiki
2020-10-31 20:47:36 <mps> if you think it must be there then left it, imo
2020-10-31 20:48:31 <mps> would be nice if it doesn't have prompt for waiting on user response
2020-10-31 20:49:04 <minimal> mps: it doesn't wait, its just using echo
2020-10-31 20:49:08 <ikke> nod
2020-10-31 20:50:43 <mps> minimal: I quite understand you, I wanted few times to add 'echo' in some packages but resisted somewhat (as a developer I can't break rules even unwritten ones)
2020-10-31 20:51:00 <mps> somehow*
2020-10-31 20:51:54 <mps> if you add this to package I will be quiet, I promise :)
2020-10-31 20:52:22 <minimal> sorry if I sound frustrated but I am - so if I don't run rc-update and I don't add a message to tell people to run the setup script then its likely they will either raise issues or email me direct. The simple message this adds to post-install seems like the most practical way to address the situation.
2020-10-31 20:52:56 <minimal> mps: this is the MR to add only echos to the post-install
2020-10-31 20:53:01 <mps> I'm not against
2020-10-31 20:53:26 <mps> but also will not advocate it, sorry
2020-10-31 20:54:15 <mps> there are already exceptions, so one more ......
2020-10-31 20:56:09 <minimal> so from this discussion its still unclear if this is likely to be merged or not
2020-10-31 20:56:42 <ikke> minimal: I'm about to merge it
2020-10-31 20:57:12 <maxice8> actually
2020-10-31 20:57:15 <maxice8> the pyX still needs more work
2020-10-31 20:57:36 <mps> ikke: +1
2020-10-31 21:02:37 <minimal> ikke: Thanks. I fully understand and respect the need for packaging standards and policies, its just at time it feels that there's inconsistency with how the (unwritten) policies are enforced. Its something that may put off potential Alpine contributors
2020-10-31 21:05:00 <ikke> Yes, I understand that
2020-10-31 21:05:28 <mps> nice :)
2020-10-31 21:05:43 <ikke> I already advocated for a single coding style among aports just to avoid that
2020-10-31 21:06:32 <minimal> Having said that, there's also a need to understand that sometimes there are corner cases, the exceptions that prove the rule ;-)
2020-10-31 21:06:34 <mps> every policy usually ends with exceptions
2020-10-31 21:06:37 <ikke> minimal: merged
2020-10-31 21:07:13 <nmeum> Ariadne: have not pushed the firefox thingy because I am unsure if it solves the issue in its entirety there are still some sandbox error left it seems https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14152#note_121452
2020-10-31 21:07:22 <minimal> ikke: thanks. Think that's the package ready now for 3.13.0
2020-10-31 21:07:44 <nmeum> the annoying thing is: I can't reproduce the firefox issue with community/firefox which is weird
2020-10-31 21:08:24 <ikke> nmeum: Cogitri had the same with the pulse issues
2020-10-31 21:08:47 <nmeum> in what way?
2020-10-31 21:09:09 <ikke> That he could not reproduce the issues that others had
2020-10-31 21:09:18 <Cogitri> Yup
2020-10-31 21:09:24 <nmeum> was it also a sandbox issue?
2020-10-31 21:09:29 <Cogitri> didn't hang for me for some reason
2020-10-31 21:10:56 <nmeum> c705: btw #14152 is where you find more information on the firefox issue
2020-10-31 21:11:11 <c705> nmeum: thanks, i read that already
2020-10-31 21:11:22 <nmeum> with that patch it doesn't seem to crash anymore I am told, but the error message still seem to appear?
2020-10-31 21:11:42 <c705> tabs crash and a segfault gets logged
2020-10-31 21:12:16 <nmeum> without that patch?
2020-10-31 21:12:28 <nmeum> or with that patch applied?
2020-10-31 21:12:34 <c705> is the patch applied in edge?
2020-10-31 21:12:37 <nmeum> no
2020-10-31 21:12:40 <nmeum> it's not
2020-10-31 21:12:40 <c705> then no
2020-10-31 21:13:39 <nmeum> hmhm
2020-10-31 21:13:45 <nmeum> I think I have an idea how to revise the patch
2020-10-31 21:21:06 <Ariadne> harrumph
2020-10-31 21:21:20 <Ariadne> rust fails to link in stage1 (which isn't even cross) while crossing
2020-10-31 21:21:57 <Cogitri> Log?
2020-10-31 21:25:20 <Ariadne> Cogitri: https://tpaste.us/ejvV
2020-10-31 21:27:34 <ikke> maxice8: why the 2>/dev/null in the find command btw?
2020-10-31 21:28:22 <maxice8> to avoid printing errors
2020-10-31 21:29:41 <ikke> btw, how long should mgmr take to merge?
2020-10-31 21:31:39 <maxice8> inconsistent
2020-10-31 21:31:47 <ikke> ok
2020-10-31 21:35:32 <Cogitri> Ariadne: Huh
2020-10-31 21:38:15 <Cogitri> Yeah, sometimes Gitlab takes very long to rebase a MR or sometimes even fails to do it at all
2020-10-31 21:38:46 <ikke> yes, that's known, but afaik, mgmr doesn't wait for the rebase to finish
2020-10-31 21:39:20 <ikke> and I see in the interface the rebase already finished, while mgmr still says it's waiting
2020-10-31 21:40:00 <Cogitri> I guess the API didn't refresh it then?
2020-10-31 21:40:06 <ikke> I guess s
2020-10-31 21:40:17 <Cogitri> Would be neat to see what mgmr receives
2020-10-31 21:49:28 <Ariadne> Cogitri: yeah i'm not sure whats up
2020-10-31 21:57:40 <Ariadne> i went to the rust zulip server
2020-10-31 21:57:44 <Ariadne> lets see what they have to say
2020-10-31 21:57:58 <Cogitri> I think their Discord is a lot more active
2020-10-31 22:05:52 <Ariadne> discord ;/
2020-10-31 22:05:54 <Ariadne> ok
2020-10-31 22:09:21 <Ariadne> website says compiler team uses zulip
2020-10-31 22:10:01 <Cogitri> Hm, Discord seemed very active
2020-10-31 22:11:39 <Cogitri> Not sure if the website isn't updated or if they use both
2020-10-31 22:18:32 <Ariadne> they use both
2020-10-31 22:19:21 <Ariadne> comparing what we do to what void linux does
2020-10-31 22:19:36 <Ariadne> I can't see any notable difference
2020-10-31 22:33:37 <Hello71> tried dropping --as-needed just to test?
2020-10-31 22:59:44 <Ariadne> hmm
2020-10-31 22:59:54 <Ariadne> we could
2020-10-31 23:08:50 <maxice8> GitLab API doesn't have an option like GitHub to rebase+merge so we have to rebase, which is not good because you can't wait on it, you have to constantly GET with include_rebase_in_progress to check.
2020-10-31 23:09:03 <maxice8> It all could be solved if it had an option like GitHub to rebase and merge at the same time
2020-10-31 23:23:05 <maxice8> or an option to wait on a rebase until it either is successful or fails
2020-10-31 23:28:51 <Ariadne> Cogitri: found something weird void does
2020-10-31 23:28:54 <Ariadne> Cogitri: may be related
2020-10-31 23:29:35 <maxice8> what it does ?
2020-10-31 23:30:35 <Ariadne> local-rebuild = true when crossing