Re: A question about stack alignment in C language

2019-04-05 Thread Matthew Fernandez


> On Apr 5, 2019, at 19:08, Mo Zhou  wrote:
> 
> Hi mentors,
> 
> This question tightly associates with my ongoing work for Debian's
> BLAS/LAPACK packages, specifically the 32-bit and 64-bit variants.
> I encountered a problem that I don't fully understand so I think I
> need some help at this point.
> 
> Assume we have the following library "libfoo.c":
> 
>   #include 
>   float sasum64(size_t N, const float *X, size_t incX)
>   {
>   float asum = 0.;
>   for (size_t i = 0; i < N; i++) {
>   asum += (X[i*incX] > 0.) ? X[i*incX] : -X[i*incX];
>   }
>   return asum;
>   }
>   float sasum32(int N, const float *X, int incX)
>   {
>   float asum = 0.;
>   for (int i = 0; i < N; i++) {
>   asum += (X[i*incX] > 0.) ? X[i*incX] : -X[i*incX];
>   }
>   return asum;
>   }
> 
> compiled as libfoo.so: gcc -shared -fPIC libfoo.c -o libfoo.so
> And we have the following application "app.c" which **deliberately**
> misuse the index type:
> 
>   #include 
>   #include 
>   float sasum64(int N, const float *X, int incX);
>   float sasum32(size_t N, const float *X, size_t incX);
> 
>   int main(void)
>   {
>   float a[] = {1., 2., -3.};
>   printf("%f, %f\n", sasum32(3, a, 1), sasum64(3, a, 1));
>   return 0;
>   }
> 
> Then we compile and run the program:
> 
>   gcc app.c -fPIC -lfoo -L.
>   LD_LIBRARY_PATH=. ./a.out   
>  2:00:56
 6.00, 6.00
> 
> My questions are:
> 
>   1. Why doesn't the application segfault, since it has already
>   misused the index (N and incX) type?
> 
>   2. Did we avoid SIGSEGV because the arguments used to call
>   sasum32 or sasum64 are aligned in 64-bits? But that's still
>   strange due to little-endianess...
> 
>   3. How can I make the app.c segfault?
> 
> Thanks in advance :-)
> 

I do not know why this question was addressed to Debian and Gentoo as it seems 
to have nothing specific to do with either, but let me attempt a response. With 
nothing further to go on, I am taking a guess that your platform is x86-64. The 
32-bit values passed to the mis-prototyped sasum64 as N and incX will be zero 
extended to 64-bit values as per the ABI. I know neither why nor where you 
expect this program to segfault, so unfortunately I can’t comment further. You 
might want to try Stack Overflow for something like this.


Bug#919743: RFS: rumur/2019.01.12-1 [ITP]

2019-02-01 Thread Matthew Fernandez
Hello mentors,

I posted an RFS a little while ago, but didn’t realise I was allowed to deviate 
from the template and add a little “hot spice” as the FAQ suggests. With that 
in mind, here’s a snippet from my package’s d/control that may entice some 
potential sponsors:

Rumur is a model checker for use in the formal verification of finite state
machines specified in the Murphi modelling language. It is based on a previous
tool, CMurphi, and attempts to provide an approximate drop-in replacement for
CMurphi. In comparison to CMurphi, Rumur generates a verifier that runs 
significantly
faster and uses less memory on large input problems.

Any and all feedback welcome. Thank you for your time.

Matthew

> On Jan 18, 2019, at 18:43, Matthew Fernandez  
> wrote:
> 
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "rumur"
> 
> * Package name: rumur
>  Version     : 2019.01.12-1
>  Upstream Author : Matthew Fernandez 
> * URL : https://github.com/Smattr/rumur
> * License : The Unlicense
>  Section : devel
> 
> It builds those binary packages:
> 
>   rumur - model checker for the Murphi language
> 
> To access further information about this package, please visit the following 
> URL:
> 
> https://mentors.debian.net/package/rumur
> 
> 
> Alternatively, one can download the package with dget using this command:
> 
>  dget -x 
> https://mentors.debian.net/debian/pool/main/r/rumur/rumur_2019.01.12-1.dsc
> 
> More information about rumur can be obtained from 
> https://github.com/Smattr/rumur.
> 
> Changes since the last upload:
> 
> Initial release. Closes #919220.
> 
> 
> Regards,
> Matthew Fernandez



Bug#919743: RFS: rumur/2019.01.12-1 [ITP]

2019-01-20 Thread Matthew Fernandez


> On Jan 19, 2019, at 17:29, Adam Borowski  wrote:
> 
> On Fri, Jan 18, 2019 at 06:43:13PM -0800, Matthew Fernandez wrote:
>> * Package name: rumur
>>  Version : 2019.01.12-1
> 
>>  dget -x 
>> https://mentors.debian.net/debian/pool/main/r/rumur/rumur_2019.01.12-1.dsc
> 
>> Changes since the last upload:
>> 
>> Initial release. Closes #919220.
> 
> The package is marked as "UNRELEASED" -- ie, marked as not meant for
> uploading.  Generally, RFS bugs are requests for actual uploads, there's no
> need to file a bug if all you want is review of a WIP state.  I guess the
> marking was left accidentally…

Thanks for the review, Adam!

This was my own misunderstanding. I thought packages were intended to be marked 
“UNRELEASED” right up until when they were approved. I’ll fix that.

> The package fails to build:
> .
> In file included from /<>/librumur/src/parse.cc:10:
> /<>/librumur/include/rumur/scanner.h:6:12: fatal error: 
> FlexLexer.h: No such file or directory
>   #include 
> `
> This looks like missing build-dependency on libfl-dev.

I guess I didn’t notice this as I had something else installed that pulled in 
libfl-dev. Is there a page where I can see results from an attempted build of 
my uploaded package? Or maybe you built it yourself locally to discover this?


Bug#919743: RFS: rumur/2019.01.12-1 [ITP]

2019-01-18 Thread Matthew Fernandez
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "rumur"

* Package name: rumur
  Version : 2019.01.12-1
  Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : The Unlicense
  Section : devel

It builds those binary packages:

   rumur - model checker for the Murphi language

To access further information about this package, please visit the following 
URL:

 https://mentors.debian.net/package/rumur


Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/r/rumur/rumur_2019.01.12-1.dsc

More information about rumur can be obtained from 
https://github.com/Smattr/rumur.

Changes since the last upload:

 Initial release. Closes #919220.


Regards,
 Matthew Fernandez


Re: Build-Depends for a Python wrapper

2018-12-25 Thread Matthew Fernandez


> On Dec 25, 2018, at 02:41, Geert Stappers  wrote:
> 
> On Mon, Dec 24, 2018 at 06:09:04PM -0800, Matthew Fernandez wrote:
>> Hello Debian Mentors,
>> 
>> I???m preparing to request a piece of software I maintain be made
>> available on Debian and have been doing my homework trying to package
>> it correctly.
>> 
>> It???s a C++ binary, but comes with a Python wrapper for invoking it
>> [0]. This script should run with either Python 2 or Python 3 and
>> requires no non-standard modules, but I???m having trouble getting
>> lintian to approve of it.
>> 
>> In trying to pacify its warnings, I seem to keep causing new
>> ones. The latest is missing-build-dependency-for-dh-addon which seemed
>> straightforward, but I???m having trouble resolving it.
>> 
>> Is it possible I???m just going about this the wrong way? You can see my
>> current fumblings around in the dark for the light switch at [1]. I have
>> not packaged something for Debian before, so apologies if this question
>> is answered elsewhere and my search skills failed me. If you have any
>> time to point me in the right direction, I would be very grateful.
>> 
>> Thanks, Matthew
>> 
>> [0]: 
>> https://github.com/Smattr/rumur/blob/packaging/debian/rumur/src/rumur-run
>> [1]: https://github.com/Smattr/rumur/blob/packaging/debian/debian/control
> 
> Multiline Build-Depends
> 
> --- a/debian/control
> +++ b/debian/control
> @@ -2,7 +2,13 @@ Source: rumur
> Section: devel
> Priority: optional
> Maintainer: Matthew Fernandez 
> -Build-Depends: debhelper (>= 10), bison (>= 3.0), cmake (>= 3.1), dh-python, 
> flex (>= 2.5.35), libgmp-dev, python (>= 2.7)
> +Build-Depends: debhelper (>= 10)
> +  , bison (>= 3.0)
> +  , cmake (>= 3.1)
> +  , dh-python
> +  , flex (>= 2.5.35)
> +  , libgmp-dev
> +  , python (>= 2.7)
> Standards-Version: 3.9.8
> Homepage: https://github.com/Smattr/rumur
> Vcs-Git: https://github.com/Smattr/rumur.git
> 
> 
> 
> 
> | 
> | $ lintian --info ../rumur_2018.12.20_amd64.changes 
> | E: rumur source: missing-build-dependency-for-dh-addon python3 => 
> python3:any | python3-all:any | python3-dev:any | python3-all-dev:any
> | N: 
> | N:The source package appears to be using a dh addon but doesn't build
> | N:depend on the package that actually provides it. If it uses it, it 
> must
> | N:build depend on it.
> | N:
> | N:Severity: important, Certainty: possible
> | N:
> | N:Check: debhelper, Type: source
> | N: 
> | 
> 
> 
> --- a/debian/control
> +++ b/debian/control
> @@ -9,6 +9,7 @@ Build-Depends: debhelper (>= 10)
>   , flex (>= 2.5.35)
>   , libgmp-dev
>   , python (>= 2.7)
> +  , python3
> Standards-Version: 3.9.8
> Homepage: https://github.com/Smattr/rumur
> Vcs-Git: https://github.com/Smattr/rumur.git
> 
> 
> 
> Find attached two patches that you may apply with `git am  *.patch`
> 
> 
> Groeten
> Geert Stappers

Ah, perfect! It did not occur to me that python and python3 are separate 
packages, and then I misinterpreted lintian’s output. Much appreciated, Geert!


Build-Depends for a Python wrapper

2018-12-24 Thread Matthew Fernandez
Hello Debian Mentors,

I’m preparing to request a piece of software I maintain be made available on 
Debian and have been doing my homework trying to package it correctly. It’s a 
C++ binary, but comes with a Python wrapper for invoking it [0]. This script 
should run with either Python 2 or Python 3 and requires no non-standard 
modules, but I’m having trouble getting lintian to approve of it. In trying to 
pacify its warnings, I seem to keep causing new ones. The latest is 
missing-build-dependency-for-dh-addon which seemed straightforward, but I’m 
having trouble resolving it. Is it possible I’m just going about this the wrong 
way? You can see my current fumblings around in the dark for the light switch 
at [1]. I have not packaged something for Debian before, so apologies if this 
question is answered elsewhere and my search skills failed me. If you have any 
time to point me in the right direction, I would be very grateful.

Thanks,
Matthew

  [0]: https://github.com/Smattr/rumur/blob/packaging/debian/rumur/src/rumur-run
  [1]: https://github.com/Smattr/rumur/blob/packaging/debian/debian/control