https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: sci-calculators/bc-gh-6.7.6 fails tests. Discovered on: amd64 (internal ref: tinderbox_musl) System: MUSL-SYSTEM (https://wiki.gentoo.org/wiki/Project:Tinderbox/Common_Issues_Helper#MUSL) Info about the issue: https://wiki.gentoo.org/wiki/Project:Tinderbox/Common_Issues_Helper#CF0015
Created attachment 898820 [details] build.log build log and emerge --info
Thank you for the build log because it shows the actual problem: ``` Testing NLS... NLS does not work. Disabling NLS... Testing history... History does not work. Disabling history... Testing for FreeBSD... On FreeBSD. Not using _POSIX_C_SOURCE and _XOPEN_SOURCE. Testing for macOS... On macOS. Using _DARWIN_C_SOURCE. Testing for OpenBSD... On OpenBSD. Using _BSD_SOURCE. Cannot use readline on OpenBSD ``` The configure script failed, so no Makefile was generated, so no make check target exists. The root of the problem is that your musl system is somehow causing compile errors in the test compiles that the configure uses to detect the platform. I think that I need to build a musl Gentoo VM in order to figure out the problem. It may take me a few days to do that, but you could try building my bc by hand on that machine and see if the problem exists there too.
(In reply to Gavin D. Howard from comment #2) > Thank you for the build log because it shows the actual problem: > > ``` > Testing NLS... > NLS does not work. > Disabling NLS... > > Testing history... > History does not work. > Disabling history... > > Testing for FreeBSD... > On FreeBSD. Not using _POSIX_C_SOURCE and _XOPEN_SOURCE. > > Testing for macOS... > On macOS. Using _DARWIN_C_SOURCE. > > Testing for OpenBSD... > On OpenBSD. Using _BSD_SOURCE. > > Cannot use readline on OpenBSD > ``` > > The configure script failed, so no Makefile was generated, so no make check > target exists. > Why isn't it exiting 1 on failure? > The root of the problem is that your musl system is somehow causing compile > errors in the test compiles that the configure uses to detect the platform. > > I think that I need to build a musl Gentoo VM in order to figure out the > problem. It may take me a few days to do that, but you could try building my > bc by hand on that machine and see if the problem exists there too. You should be able to use a chroot (just unpack a stage3 in /opt/musl or whatever).
Created attachment 898919 [details] Modified configure.sh script for better debug output
> Why isn't it exiting 1 on failure? Unfortunately, because of an oversight. Fixed in https://git.gavinhoward.com/gavin/bc/commit/7bc8039d4e25 , and I will put out a new release soon with it. Let's not stabilize 6.7.6 because of that. I also have a few changes implemented already. Beyond that, I can't reproduce the compile errors with musl without a hack. I also tried to install the package on a fresh musl install, and that worked, i.e., I could not reproduce the bug. Could you clone my bc, copy in the attached `configure.sh`, and try to build? In commands, please do this: ``` $ # Download the configure.sh attachment into this directory. $ git clone https://git.gavinhoward.com/gavin/bc.git $ cd bc $ cp ../configure.sh . $ ./configure.sh -pGNU -G -T -l -P -r ``` And then can you attach the entire output to a comment?
(In reply to Sam James from comment #3) > Why isn't it exiting 1 on failure? I mean, to be fair, we know the reason: because it is hand-rolling a build system instead of using autoconf or meson. :D
Some quick, obvious issues when looking at the configure script (it is a shame it doesn't log the results to something like config.log, such that one needs a hacked-up script to disable redirection entirely). You perform various checks to see if something optimally compiles, and assume that any compilation failure means truth-y. e.g. you compile the source code file scriptdir/src/vm.c with a define that causes it to error out on non-FreeBSD -- but what it's actually doing is checking the define and emitting an #error in such a case. It's unclear why the entirety of that file needs to be compiled. It also seems fairly broken to check for the operating system like this -- there are much better ways of detecting the operating system that don't require running the compiler. "If this errors, it is probably because of building on Windows" -- surely that can be checked as a distinctive condition?
> I mean, to be fair, we know the reason: because it is hand-rolling a build > system instead of using autoconf or meson. :D Yes, but my bc can be built with a minimum of dependencies: C99 compiler, sh, and a few other POSIX utilities. This makes it easier to build earlier in a Linux bootstrap.
> e.g. you compile the source code file scriptdir/src/vm.c with a define that > causes it to error out on non-FreeBSD -- but what it's actually doing is > checking the define and emitting an #error in such a case. It's unclear why > the entirety of that file needs to be compiled. It also seems fairly broken > to check for the operating system like this -- there are much better ways of > detecting the operating system that don't require running the compiler. What are they? Be sure to suggest ones that do not add any dependencies. To be frank, I think you are being a bit unfair. There is a lot of work in that script, all designed to make it easy-as-pie for users to compile. This is also the first time I remember a user running into trouble with the "compilation error is truthy" system. This is because I build my bc on a lot of platforms, including Windows, and I make sure it builds everywhere, and that it builds without any warnings. Your criticisms of compiling src/vm.c are somewhat fair; I could generate a C file with just the `#ifdef`s and the `#error`, and I will probably do that for the release. But I would still like Agostino to send me some output so I can fix the problem because even if I change the script to use a separate C file, the build will just error anyway, which I would *still* need to fix. This is why "compilation error is truthy" was an okay solution in my eyes: if you're getting compilation errors like that, the build wouldn't work anyway. > "If this errors, it is probably because of building on Windows" -- surely > that can be checked as a distinctive condition? This was a hack from a long time ago, and the comment is out of date. It doesn't work on musl because musl doesn't have gencat. But that's fine because all that does is disable NLS and continue on its merry way.
(In reply to Gavin D. Howard from comment #8) > > I mean, to be fair, we know the reason: because it is hand-rolling a build > > system instead of using autoconf or meson. :D > > Yes, but my bc can be built with a minimum of dependencies: C99 compiler, > sh, and a few other POSIX utilities. This makes it easier to build earlier > in a Linux bootstrap. autoconf has, broadly speaking, the same goal. Granted, bc is a POSIX specified tool and autoconf largely fulfills that goal by requiring nothing beyond a POSIX system -- but autoconf doesn't use bc, so there is no logical dependency cycle.
(In reply to Gavin D. Howard from comment #9) > > e.g. you compile the source code file scriptdir/src/vm.c with a define that > > causes it to error out on non-FreeBSD -- but what it's actually doing is > > checking the define and emitting an #error in such a case. It's unclear why > > the entirety of that file needs to be compiled. It also seems fairly broken > > to check for the operating system like this -- there are much better ways of > > detecting the operating system that don't require running the compiler. > > What are they? Be sure to suggest ones that do not add any dependencies. > > To be frank, I think you are being a bit unfair. There is a lot of work in > that script, all designed to make it easy-as-pie for users to compile. This > is also the first time I remember a user running into trouble with the > "compilation error is truthy" system. This is because I build my bc on a lot > of platforms, including Windows, and I make sure it builds everywhere, and > that it builds without any warnings. > > Your criticisms of compiling src/vm.c are somewhat fair; I could generate a > C file with just the `#ifdef`s and the `#error`, and I will probably do that > for the release. You can take some inspiration from GNU autotools' config.guess, a standalone script included with a ./configure script that guesses the name of the operating system. The first thing it does is run `uname` to derive various bits of information using a POSIX-defined tool that is likely to exist quite early even in a bootstrap! The second thing it does is attempt to narrow certain uname values -- specifically Linux | GNU | GNU/* -- by... well, by generating a small dummy.c fragment and compiling it. But it doesn't use #error to flag results, instead it has the preprocessor parse this: #if defined(__ANDROID__) LIBC=android #else #include <features.h> #if defined(__UCLIBC__) LIBC=uclibc #elif defined(__dietlibc__) LIBC=dietlibc #elif defined(__GLIBC__) LIBC=gnu #elif defined(__LLVM_LIBC__) LIBC=llvm #else #include <stdarg.h> /* First heuristic to detect musl libc. */ #ifdef __DEFINED_va_list LIBC=musl #endif #endif #endif If an error occurs it could detect that as a fatal probe failure, but what it actually does is default to "LIBC=unknown". Note how the check is always expected to return success, and the purpose of the probe is to print out a formatted token assignment, so any erroneous compilation will never set a token assignment at all rather than simply flagging the wrong result. Overall, the script *mainly* exists to take uname and convert it into uniform system triplet values. (In reply to Gavin D. Howard from comment #9) > But I would still like Agostino to send me some output so I can fix the > problem because even if I change the script to use a separate C file, the > build will just error anyway, which I would *still* need to fix. > > This is why "compilation error is truthy" was an okay solution in my eyes: > if you're getting compilation errors like that, the build wouldn't work > anyway. Perhaps, but if the configure stage doesn't error out because it doesn't misdiagnose a compiler error, then you might have gotten a compile-stage error including the exact compile failures in the initial report, which would have made the *cause* of the error a lot clearer than "error: configure.sh was told to use readline but compiler failures say this linux system is OpenBSD, and OpenBSD is incompatible with readline -- aborting". Unfortunately, I sympathize with your desire to get some output but fear you will never get it because this entire report was an automated CI.
> You can take some inspiration from GNU autotools' config.guess, a standalone > script included with a ./configure script that guesses the name of the > operating system. The first thing it does is run `uname` to derive various > bits of information using a POSIX-defined tool that is likely to exist quite > early even in a bootstrap! My bc also needs to cross-compilable. Thus, I cannot take inspiration from that because it assumes that the project is being built for the host system. It cannot test things correctly if the user is cross-compiling. `uname` especially depends on the host system and only returns information about the host system, not the target. The only test that works during cross compilation is compilation with the cross compiler. The cross compiler's config will be the config of the target platform. This is another reason I use the compilation error tests. I consider this a fatal flaw of autoconf on modern systems. Cross compilation should be a first-class supported use case. > Perhaps, but if the configure stage doesn't error out because it doesn't > misdiagnose a compiler error, then you might have gotten a compile-stage > error including the exact compile failures in the initial report, which > would have made the *cause* of the error a lot clearer than "error: > configure.sh was told to use readline but compiler failures say this linux > system is OpenBSD, and OpenBSD is incompatible with readline -- aborting". This is why `configure.sh` does print stuff out. If packagers want to shunt the output to a log file, they can, but it doesn't *require* it either, and that's a feature. Now, if I were to switch to a generated C file to specifically test for preprocessor macros, instead of compiling src/vm.c, then I could have my configure script print compile errors. And also, the build would have gotten to the compile step. This is why I said I will probably implement using such a file. I cannot do any better than that under the requirements I have. I get that you don't like what I have done. It's unfortunate, and I am sorry. But there are reasons that my bc builds the way that it does.
(In reply to Gavin D. Howard from comment #12) > My bc also needs to cross-compilable. Thus, I cannot take inspiration from > that because it assumes that the project is being built for the host system. > It cannot test things correctly if the user is cross-compiling. `uname` > especially depends on the host system and only returns information about the > host system, not the target. > > The only test that works during cross compilation is compilation with the > cross compiler. The cross compiler's config will be the config of the target > platform. This is another reason I use the compilation error tests. > > I consider this a fatal flaw of autoconf on modern systems. Cross > compilation should be a first-class supported use case. ... but you can literally tell it what you're cross compiling for??? --build=XXX --host=XXX And yes, cross compiling at all does require specifying an option to say that you are cross compiling. Even if that option is just pointing to another CC, that is an option. autoconf suggests specifying an option to say you're cross compiling for a given system, and then derives the cross-CC from that. Perhaps not everyone likes that as the optimal way to configure a cross build, but arguing that cross compilation isn't a "first-class supported use case" is simply... uneducated. The fact that vast numbers of people have praised it as the best build system for correctly cross compiling for several decades should be a clue here. Like it or don't like it, that's a personal opinion. In fact, I myself don't like it very much at all. But no FUD, please. > > Perhaps, but if the configure stage doesn't error out because it doesn't > > misdiagnose a compiler error, then you might have gotten a compile-stage > > error including the exact compile failures in the initial report, which > > would have made the *cause* of the error a lot clearer than "error: > > configure.sh was told to use readline but compiler failures say this linux > > system is OpenBSD, and OpenBSD is incompatible with readline -- aborting". > > This is why `configure.sh` does print stuff out. If packagers want to shunt > the output to a log file, they can, but it doesn't *require* it either, and > that's a feature. No they surely cannot shunt the important output to a log file, because the configure script doesn't contain an option to do so and simply unconditionally shunts the desired output to /dev/null. The idea that it is a "feature" that output is shunted to /dev/null rather than a logfile, is... confusing. I am confused how one could come up with such a theory. :) Calling it an obscure feature that hasn't been implemented due to lack of significant usefulness, I could understand. But saying it's philosophically better to not do so is quite odd. > Now, if I were to switch to a generated C file to specifically test for > preprocessor macros, instead of compiling src/vm.c, then I could have my > configure script print compile errors. And also, the build would have gotten > to the compile step. This is why I said I will probably implement using such > a file. I cannot do any better than that under the requirements I have. > > I get that you don't like what I have done. It's unfortunate, and I am > sorry. But there are reasons that my bc builds the way that it does. I'm not saying you don't have reasons for the way you are doing things. I'm saying that anyone who wants to implement a custom build system will inevitably turn out to be someone who didn't really do basic research into how other build systems work. Not because I think they should have used those other build systems. Because I think their build systems are incorrectly designed and don't consider the corpus of knowledge about ***problems that users have encountered, and attempts to solve those problems***. There are valid criticisms of autotools. Lots of them, in fact! I've made a whole bunch of such criticisms myself. But something that people rarely think about is that if one wishes to criticize a thing based on its flaws and produce an alternative that doesn't have its flaws, it is logically inconsistent and a self-disproof to then introduce flaws which the original thing had solved. It's a principle known as "shifting the brokenness over one step to the left". bc-gh isn't special in this regard. It is merely build system number 26,581 that failed to live up to its own promise of being a superior alternative to autoconf, because its designer only knew how to fix the problems of autoconf, but not how to reimplement the valuable parts. Reimplementing the valuable parts doesn't require *using* autotools. Merely knowing what functionality autotools provides. Anyways, I am happy to hear that you're going to implement some of those missing autotools-parity features.
This bug report is getting noisy, so this will be my last comment on the side matter. > ... but you can literally tell it what you're cross compiling for??? > --build=XXX --host=XXX Yes, but you can't run the test programs if you need to in order to get the test result. > And yes, cross compiling at all does require specifying an option to say > that you are cross compiling. Even if that option is just pointing to > another CC, that is an option. > > autoconf suggests specifying an option to say you're cross compiling for a > given system, and then derives the cross-CC from that. Perhaps not everyone > likes that as the optimal way to configure a cross build, but arguing that > cross compilation isn't a "first-class supported use case" is simply... > uneducated. The fact that vast numbers of people have praised it as the best > build system for correctly cross compiling for several decades should be a > clue here. What I mean is that if it requires running a test program to figure out things, it isn't first class. If autoconf requires running a test program when doing a cross compilation, it won't work. True first-class support for cross compilation would be something like what Zig does. > Like it or don't like it, that's a personal opinion. In fact, I myself don't > like it very much at all. But no FUD, please. You are being unfair again. > No they surely cannot shunt the important output to a log file, because the > configure script doesn't contain an option to do so and simply > unconditionally shunts the desired output to /dev/null. It doesn't need an option to do so. You just run it with a redirect in the package definition. Gentoo captures the output of `configure.sh` and puts it into `build.log`, so obviously, it is possible. For the compilation test outputs, you are correct, but I just need to use a dedicated C file for the test compile outputs, and it will be possible for them too. Or won't be necessary. > Calling it an obscure feature that hasn't been implemented due to lack of > significant usefulness, I could understand. But saying it's philosophically > better to not do so is quite odd. You are talking about the compilation tests specifically. I am talking about the configure output. So we are talking past each other on this point. > I'm not saying you don't have reasons for the way you are doing things. > > I'm saying that anyone who wants to implement a custom build system will > inevitably turn out to be someone who didn't really do basic research into > how other build systems work. I have done that research. [1] [2] [1]: https://gavinhoward.com/2024/03/build-system-schism-the-curse-of-meta-build-systems/ [2]: https://git.yzena.com/Yzena/Yc/src/branch/master/docs/rig/design.md > bc-gh isn't special in this regard. It is merely build system number 26,581 > that failed to live up to its own promise of being a superior alternative to > autoconf, because its designer only knew how to fix the problems of > autoconf, but not how to reimplement the valuable parts. I do not intend for other projects to use the build system of bc-gh, so you are being unfair again. The build system for bc-gh is built for one purpose: build bc-gh. Your claim that it has "failed to live up to its own promise of being a superior alternative to autoconf" is not true because there is no such promise. The build system for bc-gh works for bc-gh and no one else. It is only superior to autoconf for bc-gh, and maybe not even then. I only didn't use autotools because I didn't want it as a dependency. Over time, I added cross compilation, but the dependency was the first reason. Also notice that I do not use Rig, my general-purpose build system linked above, for bc-gh. This is on purpose. If I need a general-purpose build system, I'll use Rig. > Reimplementing the valuable parts doesn't require *using* autotools. Merely > knowing what functionality autotools provides. Again, I am not trying to reimplement autotools. I am merely trying to build bc-gh. I have no idea where you got the idea that I am trying to reimplement autotools in bc-gh's build system, but that is a pure assumption on your part, and it is not true. > Anyways, I am happy to hear that you're going to implement some of those > missing autotools-parity features. No, I am not. I am making one file to test certain things in one project. Please do not expect anything more. If you expect more, especially for Gentoo, I think it might be better to delete bc-gh from Gentoo's repository because at this point, it is beginning to appear like the bc-gh package is not meeting expectations. If you want bc-gh to use a general-purpose build system, our desires won't be aligned because I will only add the capability to use Rig, while keeping the bespoke one as a fully-supported alternative. I will keep the bespoke system because Rig has already been rejected from Gentoo repos, and for a good reason: it is source available, not Open Source. So adding Rig wouldn't work for Gentoo. Thus, if the bespoke system won't work for Gentoo, then bc-gh won't work for Gentoo. If you would like me to delete the package, please let me know, and I will do so. Otherwise, you're welcome to maintain a fork that uses autotools, but I am not interested in that.
(In reply to Gavin D. Howard from comment #14) > What I mean is that if it requires running a test program to figure out > things, it isn't first class. If autoconf requires running a test program > when doing a cross compilation, it won't work. (autoconf does not require this; any case where an autoconf rule does try to run a test program when cross compiling is because the author of the configure.ac file decided the only way is to run the program, and this would be a problem regardless of build system) > It doesn't need an option to do so. You just run it with a redirect in the > package definition. Gentoo captures the output of `configure.sh` and puts it > into `build.log`, so obviously, it is possible. > > For the compilation test outputs, you are correct, but I just need to use a > dedicated C file for the test compile outputs, and it will be possible for > them too. Or won't be necessary. > > > Calling it an obscure feature that hasn't been implemented due to lack of > > significant usefulness, I could understand. But saying it's philosophically > > better to not do so is quite odd. > > You are talking about the compilation tests specifically. I am talking about > the configure output. So we are talking past each other on this point. Sure. This bug report was about the compilation test outputs, and the comparison I brought was for autoconf's config.log, which specifically logs test outputs. > > I'm not saying you don't have reasons for the way you are doing things. > > > > I'm saying that anyone who wants to implement a custom build system will > > inevitably turn out to be someone who didn't really do basic research into > > how other build systems work. > > I have done that research. [1] [2] > > [1]: > https://gavinhoward.com/2024/03/build-system-schism-the-curse-of-meta-build- > systems/ > > [2]: https://git.yzena.com/Yzena/Yc/src/branch/master/docs/rig/design.md Okay. I agree that you think you have done the research. I have some observations on the thoroughness of your discoveries but will limit myself to noting that the first (blog) document reads like an "ELI5" and does not possess data sufficient to draw conclusions from, and the second document doesn't compare and contrast build systems anyway. > I do not intend for other projects to use the build system of bc-gh, so you > are being unfair again. The build system for bc-gh is built for one purpose: > build bc-gh. Your claim that it has "failed to live up to its own promise of > being a superior alternative to autoconf" is not true because there is no > such promise. > > The build system for bc-gh works for bc-gh and no one else. It is only > superior to autoconf for bc-gh, and maybe not even then. I only didn't use > autotools because I didn't want it as a dependency. Over time, I added cross > compilation, but the dependency was the first reason. To be clear, that statement of mine was intended to mean "a superior alternative to autoconf for the purpose of building bc". (Most autoconf alternatives are meant to work for a single project.) > No, I am not. I am making one file to test certain things in one project. > Please do not expect anything more. > > If you expect more, especially for Gentoo, I think it might be better to > delete bc-gh from Gentoo's repository because at this point, it is beginning > to appear like the bc-gh package is not meeting expectations. I'd just like to clarify at this point that bc-gc compiles and runs fine for me, on glibc or musl, with all kinds of interesting CFLAGS, multiple versions of both clang and gcc. I have no idea what or how this CI report means, and I suspect we will never be able to reproduce it because it's a total black box. The most likely scenario is that the CI was broken. We just don't know because the configure script is better at producing correct results than at diagnosing incorrect ones. :) I'm very opinionated about build systems, perhaps in part because I... maintain one. Oops... > I will keep the bespoke system because Rig has already been rejected from > Gentoo repos, and for a good reason: it is source available, not Open > Source. So adding Rig wouldn't work for Gentoo. Thus, if the bespoke system > won't work for Gentoo, then bc-gh won't work for Gentoo. > > If you would like me to delete the package, please let me know, and I will > do so. Otherwise, you're welcome to maintain a fork that uses autotools, but > I am not interested in that. I'm not interested in forking and maintaining it -- again, the build works for me and I can't get it to fail other than by artificially introducing gibberish CFLAGS such as CFLAGS="--invalid-flag-please-break". Difficulty in introspecting a failed build isn't the same as the package not working. re: rig, unaware of the context. proprietary software isn't forbidden in the gentoo repos, though it would mean that by extension anything depending on it could not be open source since it could not be built without using ACCEPT_LICENSE to accept a non-open-source license. There is quite a lot of non-OSS software in the gentoo repos already, and no one is shy about adding more in the event of sufficient user demand (subject to the appropriate use of metadata for restricting unauthorized mirroring, distribution, and installation for people that didn't configure the package manager to allow the specific license in use). In general, the real reason why packages would be rejected from the repos is a reluctance to add new leaf (not required as a dependency of something else) packages without a firm popularity story, when https://wiki.gentoo.org/wiki/Project:GURU provides similar packaging availability with less friction and less support burden on the main repos.
I have made a purpose-built file for testing platforms. See https://git.gavinhoward.com/gavin/bc/commit/a5d621a20298f538c806ab1318a307bd986a9132 . I don't know what it will take to close this bug, though; I don't know how to debug this.
I think it's ok if we make sure the version in Gentoo has a configure which exits on failure and has some debug log, then we can close it and investigate if it reappears. Sound ok?
Sounds good. It is done: https://git.gavinhoward.com/gavin/bc/commit/cd4fd0984851a5c274a504ee8a776c7d7a3e6ea9 . However, I think it would be good to wait until 7.0.0 is released with these changes, and the package is updated to it, before closing this. I will release soon after fuzzing.
Thanks! I agree that once this new version is out we should just close the bug unless it reappears later. By the way, I still think you could avoid the "this is kind of ugly" part by redirecting the compiler output to ./config.log and maybe cat'ing that file if configuration fails.
> By the way, I still think you could avoid the "this is kind of ugly" part by redirecting the compiler output to ./config.log and maybe cat'ing that file if configuration fails. I don't think that will work. Configuration could "fail" but still return 0 exit status. The "fail" that triggered this bug was one where the compilation failure happened on all platforms, and if the build hadn't been using editline, `configure.sh` would have "succeeded" and generated a Makefile. Which would then have failed. Granted, that may not be likely to happen with the purpose-built test file, but I'd rather not have anyone complain about debuggability again.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7ddff7fe0d7817e30215be831f49737b52181bd4 commit 7ddff7fe0d7817e30215be831f49737b52181bd4 Author: Gavin D. Howard <gavin@gavinhoward.com> AuthorDate: 2024-08-23 03:29:40 +0000 Commit: Eli Schwartz <eschwartz@gentoo.org> CommitDate: 2024-08-23 04:09:53 +0000 sci-calculators/bc-gh: add 7.0.0 Closes: https://bugs.gentoo.org/937152 Signed-off-by: Gavin D. Howard <gavin@gavinhoward.com> Signed-off-by: Eli Schwartz <eschwartz@gentoo.org> sci-calculators/bc-gh/Manifest | 1 + sci-calculators/bc-gh/bc-gh-7.0.0.ebuild | 77 ++++++++++++++++++++++++++++++++ 2 files changed, 78 insertions(+)
