Re: [Bug-apl] [Reproducible builds] add support for SOURCE_DATE_EPOCH
Hi Santiago, I will look into this. Would it be acceptable to have a ./configure option that prevents the setting of the build date (so the build date would be roughly the time when the GNU APL sources were checked in rather than the time when GNU APL was ./configure'd)? I suppose this issue will come up for other projects as well, so maybe a common solution would be worthwhile to be investigated. Best Regards, Jürgen Sauermann GNU APL On 12/04/2017 11:53 PM, Santiago Torres-Arias wrote: Hi, I'm a member of the Arch Linux Security team working on the reproducible builds initiative. Right now, apl compiles almost reproducibly, with the only caveat of embedding some time-based information into a header file. It would be nice if this could be overriden with an environment variable (or stripped out whatsoever). I'm attaching a patch on how I believe this could be achieved. Thanks! -Santiago.
Re: [Bug-apl] I'm curious about how will react APL compiled with ...
Hi Xtian, normally a DOMAIN ERROR is raised when a function is used for which the libraries were not installed when GNU APL was compiled. /// Jürgen On 12/05/2017 06:44 AM, Christian Robert wrote: I am curious about how will react APL compiled with say the right PCRE and the right FFT library available when ran on a machine who has neither of thoses lib*.so availble? will it refuse to start or just "disable" the corrosponding quad-functions ? Xtian.
[Bug-apl] Crash when trying to run illegal code
I made a typo and was presented with an APL stack trace which suggests a bug in GNU APL. The reduced test case is as follows: * (2 2⍴1) +⍤1 0 1 1* Which presents the following: Incomplete value at Symbol.cc:128 Addr:0x55891db89770 Rank:1 Shape: ⊏1⊐ Flags: -- First: 1 Dynamic: DynamicObject: 0x55891db89778 (Value: 0x55891db89778) : prev: 0x55891db89948 next: 0x55891db895a8 allocated: Bif_OPER2_RANK.cc:403 value history disabled == Assertion failed: 0 in Function: assign in file: Symbol.cc:131 Call stack: -- Stack trace at Symbol.cc:131 0x7FCC546B1F6A __libc_start_main 0x55891BD3B595 main 0x55891BEBE96D Workspace::immediate_execution(bool) 0x55891BD917AFCommand::process_line() 0x55891BD92057 Command::do_APL_expression(UCS_string&) 0x55891BD91867 Command::finish_context() 0x55891BD9D39D Executable::execute_body() const 0x55891BE57764StateIndicator::run() 0x55891BDE0E6E Prefix::reduce_statements() 0x55891BDDBAA8 Prefix::reduce_A_F_B_() 0x55891BDA6543 DerivedFunction::eval_AB(Value_P, Value_P) 0x55891BD6C03ABif_OPER2_RANK::eval_ALRB(Value_P, Token&, Token&, Value_P) 0x55891BD6A9C2 Bif_OPER2_RANK::do_ALyXB(Value_P, int, Token&, Value_P, Value_P, int) 0x55891BEA228D UserFunction::eval_ALXB(Value_P, Token&, Value_P, Value_P) 0x55891BE67C55 Symbol::push_value(Value_P) 0x55891BE6A301Symbol::assign(Value_P, bool, char const*) 0x55891BD4F82C do_Assert(char const*, char const*, char const*, int) SI stack: Depth: 21 Exec: 0x55891db4c920 Safe exec: 0 Pmode: ∇ μ-Z__A_LO_RANK_X7_B[1] PC: 0 (114) 'μ-X7 Stat: (X7 LA rho_A LB rho_B LZ rho_Z)←X7 err_code: 0x0 Depth: 20 Exec: 0x55891db79e70 Safe exec: 0 Pmode: ◊ (2 2⍴1) +⍤1 0 1 1 PC: 8 (10) ENDL Stat: (2 2⍴1) +⍤1 0 1 1 err_code: 0x0 Depth: 19 Exec: 0x55891db683c0 Safe exec: 0 Pmode: ◊ (2 2⍴1) +⍤1 0 1 PC: 9 (10) RETURN_STATS Stat: (2 2⍴1) +⍤1 0 1 err_code: 0x20002 thrown at: Prefix.cc:1780 e_msg_1:'SYNTAX ERROR' e_msg_2:' (2 2⍴1)+⍤1 0 1' e_msg_3:' ^ ^' Depth: 18 Exec: 0x55891db4c920 Safe exec: 0 Pmode: ∇ μ-Z__A_LO_RANK_X7_B[1] PC: 0 (114) 'μ-X7 Stat: (X7 LA rho_A LB rho_B LZ rho_Z)←X7 err_code: 0xA01 thrown at: Symbol.cc:131 e_msg_1:'Assertion failed' e_msg_2:'' e_msg_3:'' Depth: 17 Exec: 0x55891db6dcc0 Safe exec: 0 Pmode: ◊ (2 2⍴1) +⍤1 0 1 2 PC: 8 (10) ENDL Stat: (2 2⍴1) +⍤1 0 1 2 err_code: 0x0 Depth: 16 Exec: 0x55891db4c920 Safe exec: 0 Pmode: ∇ μ-Z__A_LO_RANK_X7_B[1] PC: 0 (114) 'μ-X7 Stat: (X7 LA rho_A LB rho_B LZ rho_Z)←X7 err_code: 0xA01 thrown at: Symbol.cc:131 e_msg_1:'Assertion failed' e_msg_2:'' e_msg_3:'' Depth: 15 Exec: 0x55891db7fda0 Safe exec: 0 Pmode: ◊ (2 2⍴1) +⍤1 0 1 2 3 PC: 8 (10) ENDL Stat: (2 2⍴1) +⍤1 0 1 2 3 err_code: 0x0 Depth: 14 Exec: 0x55891db75660 Safe exec: 0 Pmode: ◊ (2 2⍴1) +⍤1 1 1 PC: 9 (10) RETURN_STATS Stat: (2 2⍴1) +⍤1 1 1 err_code: 0x20002 thrown at: Prefix.cc:1780 e_msg_1:'SYNTAX ERROR' e_msg_2:' (2 2⍴1)+⍤1 1 1' e_msg_3:' ^ ^' Depth: 13 Exec: 0x55891db6b970 Safe exec: 0 Pmode: ◊ (2 2⍴1) +⍤1 2 3 PC: 9 (10) RETURN_STATS Stat: (2 2⍴1) +⍤1 2 3 err_code: 0x20002 thrown at: Prefix.cc:1780 e_msg_1:'SYNTAX ERROR' e_msg_2:' (2 2⍴1)+⍤1 2 3' e_msg_3:' ^ ^' Depth: 12 Exec: 0x55891db74ee0 Safe exec: 0 Pmode: ◊ (2 2⍴1) +⍤1 2 3 4 5 PC: 8 (10) ENDL Stat: (2 2⍴1) +⍤1 2 3 4 5 err_code: 0x50002 thrown at: ScalarFunction.cc:315 e_msg_1:'RANK ERROR' e_msg_2:' (2 2⍴1)+⍤1 2 3 4 5' e_msg_3:' ^ ^' Depth: 11 Exec: 0x55891db4c920 Safe exec: 0 Pmode: ∇ μ-Z__A_LO_RANK_X7_B[1] PC: 0 (114) 'μ-X7 Stat: (X7 LA rho_A LB rho_B LZ rho_Z)←X7 err_code: 0xA01 thrown at: Symbol.cc:131 e_msg_1:'Assertion failed' e_msg_2:'' e_msg_3:'' Depth: 10 Exec: 0x55891db79fd0 Safe exec: 0 Pmode: ◊ z +⍤1 0 2 1 (⊢ 100 200 300) PC: 8 (10) ENDL Stat: z +⍤1 0 2 1 (⊢ 100 200 300) err_code: 0x0 Depth: 9 Exec: 0x55891db7fe80 Safe exec: 0 Pmode: ◊ z +⍤(1 0 ⊢ 100 200 300) PC: 9 (10) RETURN_STATS Stat: z +⍤(1 0 ⊢ 100 200 300) err_code: 0x20002 thrown at: Prefix.cc:1780 e_msg_1:'SYNTAX ERROR' e_msg_2:' z+⍤(1 0⊢100 200 300)' e_msg_3:' ^^' Depth: 8 Exec: 0x55891db4c920 Safe exec: 0 Pmode:
Re: [Bug-apl] Crash when trying to run illegal code
Hi Elias, thanks, fixed in SVN 1025. Best Regards, /// Jürgen On 12/05/2017 11:46 AM, Elias Mårtenson wrote: I made a typo and was presented with an APL stack trace which suggests a bug in GNU APL. The reduced test case is as follows: (2 2⍴1) +⍤1 0 1 1 Which presents the following: Incomplete value at Symbol.cc:128 Addr: 0x55891db89770 Rank: 1 Shape: ⊏1⊐ Flags: -- First: 1 Dynamic: DynamicObject: 0x55891db89778 (Value: 0x55891db89778) : prev: 0x55891db89948 next: 0x55891db895a8 allocated: Bif_OPER2_RANK.cc:403 value history disabled == Assertion failed: 0 in Function: assign in file: Symbol.cc:131 Call stack: -- Stack trace at Symbol.cc:131 0x7FCC546B1F6A __libc_start_main 0x55891BD3B595 main 0x55891BEBE96D Workspace::immediate_execution(bool) 0x55891BD917AF Command::process_line() 0x55891BD92057 Command::do_APL_expression(UCS_string&) 0x55891BD91867 Command::finish_context() 0x55891BD9D39D Executable::execute_body() const 0x55891BE57764 StateIndicator::run() 0x55891BDE0E6E Prefix::reduce_statements() 0x55891BDDBAA8 Prefix::reduce_A_F_B_() 0x55891BDA6543 DerivedFunction::eval_AB(Value_P, Value_P) 0x55891BD6C03A Bif_OPER2_RANK::eval_ALRB(Value_P, Token&, Token&, Value_P) 0x55891BD6A9C2 Bif_OPER2_RANK::do_ALyXB(Value_P, int, Token&, Value_P, Value_P, int) 0x55891BEA228D UserFunction::eval_ALXB(Value_P, Token&, Value_P, Value_P) 0x55891BE67C55 Symbol::push_value(Value_P) 0x55891BE6A301 Symbol::assign(Value_P, bool, char const*) 0x55891BD4F82C do_Assert(char const*, char const*, char const*, int) SI stack: Depth: 21 Exec: 0x55891db4c920 Safe exec: 0 Pmode: ∇ μ-Z__A_LO_RANK_X7_B[1] PC: 0 (114) 'μ-X7 Stat: (X7 LA rho_A LB rho_B LZ rho_Z)←X7 err_code: 0x0 Depth: 20 Exec: 0x55891db79e70 Safe exec: 0 Pmode: ◊ (2 2⍴1) +⍤1 0 1 1 PC: 8 (10) ENDL Stat: (2 2⍴1) +⍤1 0 1 1 err_code: 0x0 Depth: 19 Exec: 0x55891db683c0 Safe exec: 0 Pmode: ◊ (2 2⍴1) +⍤1 0 1 PC: 9 (10) RETURN_STATS Stat: (2 2⍴1) +⍤1 0 1 err_code: 0x20002 thrown at: Prefix.cc:1780 e_msg_1: 'SYNTAX ERROR' e_msg_2: ' (2 2⍴1)+⍤1 0 1' e_msg_3: ' ^ ^' Depth: 18 Exec: 0x55891db4c920 Safe exec: 0 Pmode: ∇ μ-Z__A_LO_RANK_X7_B[1] PC: 0 (114) 'μ-X7 Stat: (X7 LA rho_A LB rho_B LZ rho_Z)←X7 err_code: 0xA01 thrown at: Symbol.cc:131 e_msg_1: 'Assertion failed' e_msg_2: '' e_msg_3: '' Depth: 17 Exec: 0x55891db6dcc0 Safe exec: 0 Pmode: ◊ (2 2⍴1) +⍤1 0 1 2 PC: 8 (10) ENDL Stat: (2 2⍴1) +⍤1 0 1 2 err_code: 0x0 Depth:
Re: [Bug-apl] [Reproducible builds] add support for SOURCE_DATE_EPOCH
Hi, thanks for getting back to me! I think a ./configure option could be an alternative. I'll CC the rest of the reproducible-builds ML in case they want to jump in and call me out :) And yes, I think this has come up for other projects too, hence the proposal of the S_D_E environment variable (for both setting a build date and to indicate that this build should be reproducible). Thanks again! -Santiago. On Tue, Dec 05, 2017 at 11:27:07AM +0100, Juergen Sauermann wrote: > Hi Santiago, > > I will look into this. Would it be acceptable to have a ./configure option > that > prevents the setting of the build date (so the build date would be roughly > the > time when the GNU APL sources were checked in rather than the time when > GNU APL was ./configure'd)? > > I suppose this issue will come up for other projects as well, so maybe a > common solution would be worthwhile to be investigated. > > Best Regards, > Jürgen Sauermann > GNU APL > > > On 12/04/2017 11:53 PM, Santiago Torres-Arias wrote: > > Hi, > > > > I'm a member of the Arch Linux Security team working on the reproducible > > builds initiative. Right now, apl compiles almost reproducibly, with the > > only caveat of embedding some time-based information into a header file. > > It would be nice if this could be overriden with an environment variable > > (or stripped out whatsoever). > > > > I'm attaching a patch on how I believe this could be achieved. > > > > Thanks! > > -Santiago. > signature.asc Description: PGP signature
Re: [Bug-apl] [Reproducible builds] add support for SOURCE_DATE_EPOCH
Ugh, forgot to link to the specification of S_D_E: https://reproducible-builds.org/specs/source-date-epoch/ Cheers! -Santiago. signature.asc Description: PGP signature
Re: [Bug-apl] [Reproducible builds] add support for SOURCE_DATE_EPOCH
Hi Santiago, I have adopted the environment variable approach, which is now contained in *SVN 1026*. (and therefore also in the next GNU APL release). I took the freedom to change your patch from: + BUILD_DATE=`date -u "%F %R:%S %Z" --date=@$SOURDCE_DATE_EPOCH` to: + BUILD_DATE=`date -u "+%F %R:%S %Z" --date=$SOURCE_DATE_EPOCH` Best Regards, /// Jürgen Sauermann On 12/05/2017 06:50 PM, Santiago Torres-Arias wrote: Hi, thanks for getting back to me! I think a ./configure option could be an alternative. I'll CC the rest of the reproducible-builds ML in case they want to jump in and call me out :) And yes, I think this has come up for other projects too, hence the proposal of the S_D_E environment variable (for both setting a build date and to indicate that this build should be reproducible). Thanks again! -Santiago. On Tue, Dec 05, 2017 at 11:27:07AM +0100, Juergen Sauermann wrote: Hi Santiago, I will look into this. Would it be acceptable to have a ./configure option that prevents the setting of the build date (so the build date would be roughly the time when the GNU APL sources were checked in rather than the time when GNU APL was ./configure'd)? I suppose this issue will come up for other projects as well, so maybe a common solution would be worthwhile to be investigated. Best Regards, Jürgen Sauermann GNU APL On 12/04/2017 11:53 PM, Santiago Torres-Arias wrote: Hi, I'm a member of the Arch Linux Security team working on the reproducible builds initiative. Right now, apl compiles almost reproducibly, with the only caveat of embedding some time-based information into a header file. It would be nice if this could be overriden with an environment variable (or stripped out whatsoever). I'm attaching a patch on how I believe this could be achieved. Thanks! -Santiago.
Re: [Bug-apl] [rb-general] [Reproducible builds] add support for SOURCE_DATE_EPOCH
> > > I'm a member of the Arch Linux Security team working on the reproducible > > > builds initiative. Right now, apl compiles almost reproducibly, with the > > > only caveat of embedding some time-based information into a header file. > > > It would be nice if this could be overriden with an environment variable > > > (or stripped out whatsoever). If the header file really doesn't need to have the build time in it (it's just "nice to have"), then the simplest solution, which is portable to all platforms and needs no further configuration, is to just stop putting the time into the generated header file. This would apparently make the build fully reproducible. If there is some reason that that timestamp is really needed, then you can make it arbitrarily more complicated. Many build environments are noticing the presence of the SOURCE_DATE_EPOCH environment variable, and using the date/time embedded in it. John Gilmore PS: My first "real" computer job was working on APL*PLUS on an IBM mainframe in 1972. I'm glad to see that APL is still around.
