Bug#1057879: RFS: rumur/2023.11.27-1 -- model checker for the Murphi language

[Matthew Fernandez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : rumur
Version : 2023.11.27-1
Upstream contact : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : Unlicense
* Vcs : https://github.com/Smattr/rumur.git
Section : devel

The source builds the following 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, you can download the package with 'dget' using this command:

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


Changes since the last upload:

rumur (2023.11.27-1) unstable; urgency=medium
.
* New upstream release.

Regards,
Matt

Bug#980900: New watch file for Graphviz package v2

[Matthew Fernandez]

It didn’t occur to me to mention before, but the Graphviz download web 
page is also driven programmatically from some JSON files: 
https://gitlab.com/graphviz/graphviz.gitlab.io/-/tree/main/data/releases?ref_type=heads. 
Another option may be for the watch file to refer to JSON files in this 
Gitlab repo. Though perhaps it is required for a watch file to refer to 
a source tarball, not something indirect.


The Graphviz repo at https://gitlab.com/graphviz/graphviz also has Git 
tags for every release.

Bug#1018205: (no subject)

[Matthew Fernandez]

For the latest upload (v2023.05.21-1), the QA page linked above once 
again indicates build and test passed for both arm64 and armel, so I’m 
still unsure how to repro/view this bug.

Bug#1041679: RFS: rumur/2023.05.21-1 [RC] -- model checker for the Murphi language

[Matthew Fernandez]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

* Package name : rumur
Version : 2023.05.21-1
Upstream contact : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : Unlicense
* Vcs : https://github.com/Smattr/rumur.git
Section : devel

The source builds the following 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, you can download the package with 'dget' using this command:

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


Changes since the last upload:

rumur (2023.05.21-1) unstable; urgency=medium
.
* New upstream release.
* Fix build failures with GCC-13. Closes: #1037851.
* Update Standards-Version from 4.6.0.1 to 4.6.2.
* Relicense debian/ as Unlicense instead of GPL-3+.

Regards,
Matt

Bug#1037851: (no subject)

[Matthew Fernandez]

Btw, why does this bug not appear when searching for bugs against the 
package? https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=rumur

Bug#1018205: rumur: possible missing linking to latomic

[Matthew Fernandez]

On 8/26/22 23:53, Tobias Frost wrote:

On Fri, Aug 26, 2022 at 05:23:20PM -0700, Matthew Fernandez wrote:

What I see is that the test program that fails to link is not linked against 
latomic:

+ rumur --output checker.c model.m
+ cc -std=c11 checker.c -lpthread

(from 
https://ci.debian.net/data/autopkgtest/unstable/arm64/r/rumur/25034806/log.gz)



This actually puzzles me further. What I’ve looked at in the past to 
evaluate a package’s success post submission is the QA buildd page.¹ 
This one indicates both arm64 and armel passed and installed 
successfully. So is the CI page you linked somehow building the package 
differently?


¹ https://buildd.debian.org/status/package.php?p=rumur

Bug#1018205: rumur: possible missing linking to latomic

[Matthew Fernandez]

On 8/26/22 15:57, Tobias Frost wrote:

Source: rumur
Version: 2020.12.20-1
Severity: important

Looking at the autopkgtest results for arm64 and armel:

/usr/bin/ld: /tmp/ccbniKRN.o: in function `atomic_read':
checker.c:(.text+0x3b90): undefined reference to `__atomic_load_16'
/usr/bin/ld: /tmp/ccbniKRN.o: in function `atomic_write':
checker.c:(.text+0x3bb8): undefined reference to `__atomic_store_16'
/usr/bin/ld: /tmp/ccbniKRN.o: in function `atomic_cas':
checker.c:(.text+0x3bf0): undefined reference to `__atomic_compare_exchange_16'
/usr/bin/ld: /tmp/ccbniKRN.o: in function `atomic_cas_val':
checker.c:(.text+0x3c2c): undefined reference to `__atomic_compare_exchange_16'

This could be missing linking to libatomic. (Did not check if it is actually 
the case, just by looking at the symbols)



I thought this was fixed in 620e514c1d322e05a9e67bb09cd0dc68cb810d38¹ 
that made it into 2020.05.27-1, but it seems not. Am I expected to fix 
this in a patch release to 2020.12.20-1? Because I’m also the upstream 
maintainer and this package has a relatively small community of users 
who upgrade frequently, I usually just roll fixes into the next upstream 
release. So if this is not reproducible on the latest (2022.08.20-1) is 
there anything to be done?


¹ 
https://github.com/Smattr/rumur/commit/620e514c1d322e05a9e67bb09cd0dc68cb810d38

Bug#1018202: rumur: VCS-* pointing to upstream repository

[Matthew Fernandez]

On 8/26/22 15:48, Tobias Frost wrote:

Source: rumur
Version: 2020.12.20-1
Severity: normal

Dear Maintainer,

d/control VCS-* fields are pointing to the upstream repository, however, they 
are
reserverd for the VCS of the packaging. (See Policy 5.6.26) [1]

[1] 
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-vcs-fields


I’m sorry, I don’t understand what’s being objected to here. d/control 
lists:


  Vcs-Git: https://github.com/Smattr/rumur.git -b packaging/debian

Yes, this is the upstream repository. But it is also the repository 
where packaging happens. Specifically the branch indicated here 
(`packaging/debian`) is where I do the Debian packaging. I’m the 
upstream maintainer as well. Is this not how I should list this?

Bug#1017815: RFS: rumur/2022.08.20-1 [RC] -- model checker for the Murphi language

[Matthew Fernandez]

On 8/21/22 00:32, Tobias Frost wrote:

Package: sponsorship-requests
Followup-For: Bug #1017815

Hi Matthew,

thanks for the updated package fixing an RC bug!

Thanks for sponsoring!

I have is some feedback regarding it:
- The format of d/changelog is a bit unusual, usually there are no
   blank lines between entries.
Ah I did not realise this was non-standard. Should I adjust the entire 
d/changelog in the next release? Or should I just omit blank lines from 
now on?

- d/changelog should document every change to the Debian packaging,
   there are many changes that are not documented:
   - update watch file
   - update Standard-Version
   - updates to d/control, versions of depdendencies.
I did not realise details of the packaging itself was relevant to the 
changelog. Though apparently past me did, as I see entries in previous 
releases about Standards-Version. In the next release, I'll try to be 
more comprehensive.

- d/copyright needs updating, at least some years.
   A remark on the copyright for debien/*: You've choosen
   a different license here than the upstream license. This
   is of course your choice, but if the license differ this could
   make it difficult to include stuff (like patches) to upstream,
   as GPL-3 and unlicense are not compatible in the GPL…
   As you are the only person working on the package and upstream,
   that be easily fixed by relicensing the debian directory to
   unlicense as well…
I did not realise is was permissible to license debian/* anything other 
than a GPL license. Will fix in the next release.

- There are a lots of tests skipped due to missing xmllint…
   Is there a missing B-D on libxml2-utils?
The test suite for this package is pretty long running, even without the 
XML tests, and I didn't think they were critical (it's pretty hard to 
break this functionality without the problem being obvious upstream 
first). I can certainly add libxml2-utils to enable them though if you 
think it's advisable. Another optional thing is the presence of an SMT 
solver like Z3 which would enable some other optional tests.

Those are not critcial issues, but please consider them for later
revisions of your package. So I'm going to upload your package soon.

Thanks for your contribution to Debian!

Bug#1017815: RFS: rumur/2022.08.20-1 [RC] -- model checker for the Murphi language

[Matthew Fernandez]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

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

The source builds the following 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, you can download the package with 'dget' using this command:

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


Changes since the last upload:

rumur (2022.08.20-1) unstable; urgency=medium
.
* New upstream release.
.
* Fix sandbox failures due to getrandom. Closes: #1017199.

Regards,
Matt

Bug#1006969: RFS: rumur/2022.03.05-1 [RC] -- model checker for the Murphi language

[Matthew Fernandez]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

* Package name: rumur
   Version : 2022.03.05-1
   Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : Unlicense
* Vcs : https://github.com/Smattr/rumur.git
   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_2022.03.05-1.dsc

Changes since the last upload:

rumur (2022.03.05-1) unstable; urgency=medium
.
   * New upstream release.
.
   * Fix sandbox failures due to statx. Closes: #1004035.

Regards,
Matt

Bug#1002744: RFS: rumur/2021.12.27-1 [RC] -- model checker for the Murphi language

[Matthew Fernandez]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

* Package name: rumur
   Version : 2021.12.27-1
   Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : Unlicense
* Vcs : https://github.com/Smattr/rumur.git
   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_2021.12.27-1.dsc

Changes since the last upload:

rumur (2021.12.27-1) unstable; urgency=medium
.
   * New upstream release.
.
   * Fix sandbox failures due to newfstatat. Closes: #1002186.

Regards,
Matt

Bug#1002186: rumur: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && make -j4 check ARGS\+=--verbose ARGS\+=-j4 returned exit code 2

[Matthew Fernandez]

Thanks for reporting!

It looks like there are now libc calls to `newfstatat` which is not in Rumur’s 
sandbox’s list of safe allowed syscalls. I’ll fix this upstream and then 
package a new release for Debian.

Bug#997016: RFS: swtpm/0.7.0-rc2-1 [ITA] -- Libtpms-based TPM emulator

[Matthew Fernandez]

> On Nov 3, 2021, at 19:30, Seunghun Han  wrote:
> 
>> I am also not sure if you are allowed to write in /tmp on package building. 
>> I will check that.
> Everyone has write access right to /tmp directory, so I guess the
> package also has it.

I don’t think this is the cause of the failures, but shouldn’t this really be 
using $TMPDIR? AFAIK temporary scratch space is not guaranteed to be /tmp. 
Maybe in Bash you want something like ${TMPDIR:-/tmp}.

Bug#980900: Update from upstream

[Matthew Fernandez]

Hi, I’m one of the upstream maintainers. Apologies for the confusion on this; 
Graphviz has indeed gone through a variety of pretty unorthodox versioning 
schemes.

At present, the situation is much more straightforward: Graphviz follows 
semantic versioning and adds a Git tag for every release. E.g. the latest 
release is tagged “2.49.3”

There’s no more distinction between stable vs development vs experimental. 
Every Graphviz release is considered stable.

I presume the Debian package is consuming the so-called “portable source” 
tarball, for which we’ve had a lot of difficulty maintaining stable URLs, as 
hinted at by prior posts on this bug as well as 
https://gitlab.com/graphviz/graphviz/-/issues/1371. FTR the latest one is 
https://gitlab.com/api/v4/projects/4207231/packages/generic/graphviz-releases/2.49.3/graphviz-2.49.3.tar.xz
 and we expect them to be like this for the foreseeable future, 
https://gitlab.com/api/v4/projects/4207231/packages/generic/graphviz-releases//graphviz-.tar.xz.
 However, we’re sort of at the mercy of Gitlab here.

Please let me know if there’s anything further we (the upstream maintainers) 
can do to ease Debian packaging work.

Bug#995588: RFS: rumur/2021.09.29-1 -- model checker for the Murphi language

[Matthew Fernandez]

> On Oct 2, 2021, at 16:37, Adam Borowski  wrote:
> 
> On Sat, Oct 02, 2021 at 11:26:19AM -0700, Matthew Fernandez wrote:
>> * Package name: rumur
>>   Version : 2021.09.29-1
> 
>> rumur (2021.09.29-1) unstable; urgency=medium
> 
> 
> E: rumur: python3-script-but-no-python3-dep usr/bin/rumur-run python3

Indeed. From the extended description of that error I had thought this package 
perhaps qualified for the exemption described, but wasn’t sure how to indicate 
this. The script lintian is complaining about is rumur-run, a wrapper that 
orchestrates some common options to one of the binaries. This script is not 
necessary for using the package. That is, someone without Python can directly 
run the binary, spelling out all their options.

With the above in mind, do you think it’s acceptable to retain only a Suggests 
for python3? OTOH maybe this package has been wrong from its first release and 
should have always declared a Depends on python3?

Bug#995588: RFS: rumur/2021.09.29-1 -- model checker for the Murphi language

[Matthew Fernandez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: rumur
   Version : 2021.09.29-1
   Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : Unlicense
* Vcs : https://github.com/Smattr/rumur.git
   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_2021.09.29-1.dsc

Changes since the last upload:

rumur (2021.09.29-1) unstable; urgency=medium
.
   * New upstream release.
.
   * Update Standards-Version from 4.5.1 to 4.6.0.1.

Regards,
Matt

Bug#993687: RFS: rumur/2021.08.28-1 -- model checker for the Murphi language

[Matthew Fernandez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: rumur
   Version : 2021.08.28-1
   Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : Unlicense
* Vcs : https://github.com/Smattr/rumur.git
   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_2021.08.28-1.dsc

Changes since the last upload:

rumur (2021.08.28-1) unstable; urgency=medium
.
   * New upstream release.
.
   * A new binary, murphi2uclid, is now included.
.
   * Python build dependency and suggests have been relaxed from 3.6 to 3.4.

Regards,
Matt

Bug#985815: RFS: usermanager/1.0.74+git20210323-1 [ITP] -- Graphical user manager

[Matthew Fernandez]

> On Mar 25, 2021, at 22:12, Adam Borowski  wrote:
> 
> On Wed, Mar 24, 2021 at 01:36:10PM +0100, Gürkan Myczko wrote:
>>> The menu icon for .desktop doesn't show up for me (in XFCE).
>> 
>> probably because it's .gif and fd.o doesn't support it
> 
> And, according to the spec:
> https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
> it's not supposed to.
> 
> Could you thus convert the icon to .png, please?
> 
>>> Some method of su{,do}-to-root should be providen -- as is, the program
>>> fails to start claiming it needs root, and starting it as root manually
>>> involves some bits generally unknown by users who need a clicky-clicky
>>> tool (ie, the intended audience).
>> 
>> for upstream
> 
> Hrm, I then don't quite see what the intended audience for this package
> could be.  The basic instructions how to run a GUI program as root (start a
> shell, find out $DISPLAY, su/sudo, set up display, cp ~user/.Xauthority ~,
> invoke from cmdline) are already far more complex than just running relevant
> adduser/usermod/deluser commands from a shell.
> 
> And besides, running a GUI program as root is not that good an idea,
> compared to separating out the privileged parts (be it to an unreliable dbus
> complexity, or to a simple easily-auditable setuid helper).
> 
> But really, I don't know enough about crossing privilege boundaries in a GUI
> to be comfortable reviewing this bit.


FWIW, upstream seem to have an intent to resolve this,
https://github.com/xen0vas/UserManager/issues/16:

Application usage from users with limited privileges
  - Implement setuid access with privilege control

xen0vas commented on Jun 27, 2020

Application usage from users with limited privileges in order to be able to
use UserManager for changing passwords and have limited access. The
implementation includes setuid setgid privilege checks as well as dropping
and restoring privileges as needed due to elevated functionality when
changing passwords and accessing system files.

Gürkan, maybe you could work with them to deal with this prior to packaging?

Bug#977937: RFS: rumur/2020.12.20-1 -- model checker for the Murphi language

[Matthew Fernandez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: rumur
   Version : 2020.12.20-1
   Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : Unlicense
* Vcs : https://github.com/Smattr/rumur.git
   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_2020.12.20-1.dsc

Changes since the last upload:

rumur (2020.12.20-1) unstable; urgency=medium
.
   * New upstream release.
.
   * Update Standards-Version from 4.5.0 to 4.5.1.

Regards,
Matthew

Bug#969759: RFS: rumur/2020.09.06-1 [RC] -- model checker for the Murphi language

[Matthew Fernandez]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

* Package name: rumur
   Version : 2020.09.06-1
   Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : Unlicense
* Vcs : https://github.com/Smattr/rumur.git
   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_2020.09.06-1.dsc

Changes since the last upload:

rumur (2020.09.06-1) unstable; urgency=medium
.
   * New upstream release.
.
   * Fix armel, armhf, mipsel, mips64el sandboxing. Closes: #969156.

Regards,
Matthew

Bug#969156: rumur FTBFS on armel/armhf/mipsel/mips64el: test failures

[Matthew Fernandez]

Thanks for reporting this, Adrian. I noticed this some time after upload and 
fixed it upstream: 
https://github.com/Smattr/rumur/commit/68683c4742b380421936a703c4b9262dac1e68dc 


I hadn’t uploaded a fixed version to Debian because Rumur’s release cadence is 
so frequent I expected to release a new upstream version before the fix could 
get into Debian unstable. I hope this is an acceptable strategy.

By the way, is there any way to run the buildd tests prior to upload? I don’t 
have, e.g. armhf, hardware and bringing up a usable armhf qemu environment 
seems non-trivial. The buildd tests only seem to run after an upload is 
accepted, so I end up only being able to run this cross-platform testing once 
per release and only after the fact.

Bug#966585: RFS: rumur/2020.07.28-1 -- model checker for the Murphi language

[Matthew Fernandez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: rumur
   Version : 2020.07.28-1
   Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : Unlicense
* Vcs : https://github.com/Smattr/rumur.git
   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_2020.07.28-1.dsc

Changes since the last upload:

rumur (2020.07.28-1) unstable; urgency=medium
.
   * New upstream release.

Regards,
Matt

Bug#963832: RFS: iotop-c/1.0-1 [ITP] -- iotop-c - simple top-like I/O monitor (implemented in C)

[Matthew Fernandez]

> On Jul 8, 2020, at 19:34, Paul Wise  wrote:
> 
> On Wed, 2020-07-08 at 20:09 +0300, Boian Bonev wrote:
> 
>> That is perfectly safe - all recent (last 20 years) glibc versions
>> allow passing NULL for %s and print (null)... Anyways it is better to
>> check it explicitly and spare some time for the people who are going to
>> look into that some day.
> 
> In theory iotop-c could be used on non-glibc platforms like Alpine
> Linux, but perhaps musl has the same protections?

It does indeed: 
https://git.musl-libc.org/cgit/musl/tree/src/stdio/vfprintf.c#n593 


> I guess there are
> other embedded libcs that don't do that though. Either way being
> explicit is indeed better.

…but I agree with this. Relying on this behavior is risky and non-portable.

Bug#963273: RFS: rumur/2020.06.20-1 -- model checker for the Murphi language

[Matthew Fernandez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: rumur
   Version : 2020.06.20-1
   Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : Unlicense
* Vcs : https://github.com/Smattr/rumur.git
   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_2020.06.20-1.dsc

Changes since the last upload:

   * New upstream release.

Regards,
Matt

Bug#962425: libscrypt-kdf-dev: broken symlink installed

[Matthew Fernandez]

Subject: libscrypt-kdf-dev: broken symlink installed
Package: libscrypt-kdf-dev
Version: 1.3.0-3
Severity: normal

Dear Maintainer,

When installing libscrypt-kdf-dev on amd64, a symlink libscrypt-kdf.so ->
libscrypt-kdf.so.1.0.0 is installed in /usr/lib/x86_64-linux-gnu.
However, libscrypt-kdf.so.1.0.0 itself is not installed. This results in
confusing link failures when you try to compile against it. I think the
problem is that libscrypt-kdf-dev is lacking a dependency on
libscrypt-kdf1 that installs the SO.

Thanks,
Matt

-- System Information:
Debian Release: 10.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-9-amd64 (SMP w/1 CPU core)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information
Report will be sent to Debian Bug Tracking System 

Bug#961429: Subject: RFS: cryptopass/1.0.0-1 [ITP] -- CLI utility for generating long, unguessable passwords.

[Matthew Fernandez]

> On May 31, 2020, at 07:54, Vasyl Gello  wrote:
> 
> Dear Mattia and Matthew!
> 
> First of all I would like to thank you for all the efforts you did to teach 
> me how to do proper Debian packaging.
> Your reviews made me rethink some practices I followed and it already helps 
> me in my activities outside of Debian.
> 
> Yesterday I found out the original Cryptopass Chrome extension is no longer 
> maintained and its repository archived.
> While I fixed the issues spotted in previous reviews and pushed the new 
> upstream version 1.1.0 and corresponding
> Debian repo on Salsa, I would like to withdraw the package from the queue.
> 
> Earlier I mentioned the passwordmaker-cli package I found long after I wrote 
> cryptopass. Its Android app is actively
> maintained, in contrast to the CLI sources, so I will likely propose the 
> fixes incorporating cryptopass scheme into
> Password Maker (https://www.passwordmaker.org 
> ). Once there is new upstream release, I will 
> coordinate with
> Cord Beermann (the pm-cli maintainer) to have it packaged.
> 
> I do still appreciate additional reviews on packaging and security of 
> cryptopass, because I thought it could be a great
> example of "making a small pavkage to learn Debian packaging". Maybe I will 
> even write a series of blog posts about
> Debian packaging and my experience with it.
> 
> Sincerely,
> -- 
> Vasyl Gello

No problem, Vasyl. I hope my comments were helpful. Good luck with your future 
work!

Bug#961883: RFS: rumur/2020.05.27-1 -- model checker for the Murphi language

[Matthew Fernandez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: rumur
   Version : 2020.05.27-1
   Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : Unlicense
* Vcs : https://github.com/Smattr/rumur.git
   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_2020.05.27-1.dsc

Changes since the last upload:

   * New upstream release.

Regards,
Matthew

Bug#961429: RFS: cryptopass/1.0.0-1 [ITP] -- CLI utility for generating long, unguessable passwords.

[Matthew Fernandez]

> On May 27, 2020, at 08:15, Vasyl Gello  wrote:
> 
> Hi Matthew!
> 
> Thanks for the continued review! You read my mind now?)
> 
> >
> >Now that I read the remainder of the main source file, I spotted a 
> >completely separate issue, src/cryptopass.c:375-384 [1]:
> >
> > /* Clean up everything */
> >
> > for (counter = 0; counter < 10; counter++) {
> > memset(derivedpassword, 0, PASSWORD_BUFFER_SIZE);
> > memset(domain, 0, MAX_INPUT_SIZE);
> > memset(masterpassword, 0, MAX_INPUT_SIZE);
> > memset(passlenbuf, 0, PASSWORD_LENGTH_BUFFER_SIZE);
> > memset(salt, 0, SALT_BUFFER_SIZE);
> > memset(username, 0, MAX_INPUT_SIZE);
> > }
> >
> >This does not do what you think it does. Either these duplicated memsets are 
> >redundant or the compiler will optimize them all away observing the targets 
> >are unused after this. The way to erase something in a way the compiler 
> >cannot elide is a single memset_s(). However, the program is about to exit 
> >and be torn down by the operating system, so even this would be redundant.
> >
> >Your intent (I am guessing) is to prevent an attacker reading these values 
> >out of program memory. However, an attacker with this ability can simply 
> >ptrace cryptopass or attach to it with a debugger. I think some thought 
> >should be put into the threat model for this program and it should probably 
> >have a more thorough security review before it is packaged.
> 
> The threat model is obviously not against an attacker with live root or 
> hypervisor access. Rather not to leave unwanted things for possible cold-boot 
> attacks.

The capabilities of a post-reboot userspace attacker are not affected by these 
measures.

> Thanks for mentioning memset_s. I see it is C11-specific so if I target older 
> standard on source level, I will have to do cleanup manually.
> -- 
> Vasyl Gello

Bug#961429: RFS: cryptopass/1.0.0-1 [ITP] -- CLI utility for generating long, unguessable passwords.

[Matthew Fernandez]

> On May 26, 2020, at 23:46, Vasyl Gello  wrote:
> 
> Hi Matthew!
> 
>> I would suggest adding one as well as fuzzing this code before exposing the 
>> downstream public to it.
> 
> Will fix the issues and add testsuite && fuzzcorp ASAP.
> 
> BTW I fixed all the stuff GCC 8.3.0 reported me with FORTIFY_SOURCE=2 before 
> pushing code to GitHub.
> Did you use GCC 10?

I just used manual inspection to identify this.

Now that I read the remainder of the main source file, I spotted a completely 
separate issue, src/cryptopass.c:375-384 [1]:

/* Clean up everything */

for (counter = 0; counter < 10; counter++) {
  memset(derivedpassword, 0, PASSWORD_BUFFER_SIZE);
  memset(domain, 0, MAX_INPUT_SIZE);
  memset(masterpassword, 0, MAX_INPUT_SIZE);
  memset(passlenbuf, 0, PASSWORD_LENGTH_BUFFER_SIZE);
  memset(salt, 0, SALT_BUFFER_SIZE);
  memset(username, 0, MAX_INPUT_SIZE);
}

This does not do what you think it does. Either these duplicated memsets are 
redundant or the compiler will optimize them all away observing the targets are 
unused after this. The way to erase something in a way the compiler cannot 
elide is a single memset_s(). However, the program is about to exit and be torn 
down by the operating system, so even this would be redundant.

Your intent (I am guessing) is to prevent an attacker reading these values out 
of program memory. However, an attacker with this ability can simply ptrace 
cryptopass or attach to it with a debugger. I think some thought should be put 
into the threat model for this program and it should probably have a more 
thorough security review before it is packaged.

  [1]: 
https://github.com/basilgello/cryptopass/blob/master/src/cryptopass.c#L375-L384 

Bug#961429: RFS: cryptopass/1.0.0-1 [ITP] -- CLI utility for generating long, unguessable passwords.

[Matthew Fernandez]

> On May 26, 2020, at 15:10, Mattia Rizzolo  wrote:
> 
>  * building the package shows this "scary" GCC warning:
> |In file included from /usr/include/string.h:495,
> | from cryptopass.c:19:
> |In function 'strncpy',
> |inlined from 'main' at cryptopass.c:200:9:
> |/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: 
> '__builtin___strncpy_chk' specified bound depends on the length of the source 
> argument [-Wstringop-overflow=]
> |  106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos 
> (__dest));
> |  |  
> ^~
> |cryptopass.c: In function 'main':
> |cryptopass.c:191:25: note: length computed here
> |  191 | passlenbuflen = strlen(argv[3]);
> |  | ^~~

This prompted me to take a quick look at the source. There are multiple 
trivially exploitable buffer overflows in this code. E.g. 
src/cryptopass.c:147-149 [0]:

usernamelen = strlen(argv[1]);

memcpy(username, argv[1], usernamelen);

You could argue this program is only intended to receive input from a trusted 
user, but is a user meant to comprehend that passing large command line 
arguments results in memory corruption? Obviously everyone is free to develop 
code how they like, but IMHO security packages should be using fuzz testing, 
that would easily find this issue. AFAICT this code base has no test suite. I 
would suggest adding one as well as fuzzing this code before exposing the 
downstream public to it.

  [0]: 
https://github.com/basilgello/cryptopass/blob/master/src/cryptopass.c#L147-L149

Bug#961180: RFS: rumur/2020.05.18-1 -- model checker for the Murphi language

[Matthew Fernandez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: rumur
   Version : 2020.05.18-1
   Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : Unlicense
* Vcs : https://github.com/Smattr/rumur.git
   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_2020.05.18-1.dsc

Changes since the last upload:

   * New upstream release.
.
   * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository,
 Repository-Browse, thanks to Debian Janitor.

Regards,
Matthew

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

[Matthew Fernandez]

> One small issue... Valgrind recommends -O0 or -O1

TIL :) Thanks, Jeff!

> You can sometimes locate a bus error at build time with -Wcast-align.
> At runtime you can usually locate them with -fsanitize=undefined.

I had previously tried UBSan and, while it turned up a number of shifting and 
strict aliasing violations, it did not find anything that I believe could be 
the cause of the mipsel bus error.

> I can't track the trail any further. The source code is missing for
> pvm_pkdouble and pvm_upkdouble. I would be very suspect of
> pvm_pkdouble and pvm_upkdouble.

Unfortunately I think the reason you can’t find their source is that this code 
is unused. It is inside a ifdef SRE_ENABLE_PVM block and this macro is not 
defined during the build. You can confirm this by deleting these lines and 
recompiling.

AFAICT the code in src/squid is a library taken wholesale from somewhere else 
and then modified (see src/squid/clustalo.README). It contains a lot of code 
that goes unused in Clustal Omega.

Is the priority goal here to simply ship a non-crashing clustalo mipsel binary 
that BioPython can depend on? If so, maybe we can just disable compiler 
optimisation (-O0) and this may avoid provoking the bus error. Of course this 
doesn’t fix the underlying problem(s), but it looks as if debugging this to its 
root cause is going to result in the Debian package carrying a lot of invasive 
dquilt patches on top of upstream. OTOH I don’t know the performance 
requirements of BioPython and maybe an unoptimised clustalo is unacceptable to 
it.

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

[Matthew Fernandez]

> On Apr 30, 2020, at 00:31, Andreas Tille  wrote:
> 
> On Wed, Apr 29, 2020 at 05:51:26PM -0700, Matthew Fernandez wrote:
> 
>> The other option I suggested was Valgrind, but if you can’t run apt-file you 
>> probably can’t install Valgrind either.
> 
> Well, I guess apt-get is permitted for sudo but not apt-file.  So I can
> probably install valgrind inside the chroot environment.  I've never
> worked with valgrind.  What am I supposed to do?

Valgrind, in its default mode, checks for a variety of memory issues 
(use-after-free, write out-of bounds, …). You don’t need any special 
configure/build options, but you probably want to enable debug symbols (`export 
CFLAGS=-g; export CXXFLAGS=-g`). Then you can prefix the test you’re running 
with Valgrind: `valgrind ./src/clustalo -i debian/tests/biopython_testdata/f002 
…`.

Valgrind and ASan serve roughly the same purpose in this scenario, but I 
usually tend to prefer ASan because it is more efficient and tends to give you 
more accurate debugging clues.

> On the other hand:  Is valgrind possibly able to uncover issues also
> on any other architecture?

You mean if we were to use Valgrind to debug this on e.g. x86? In my own 
experiments on amd64, both ASan and Valgrind found multiple issues in both 
Clustal Omega and its dependency, argtable2. However I don’t believe any of the 
remaining ones I was seeing after the last patches I sent you could be causing 
the mipsel bus error; they were all memory leaks.

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

[Matthew Fernandez]

> On Apr 29, 2020, at 09:04, Andreas Tille  wrote:
> 
> On Wed, Apr 29, 2020 at 07:14:30AM -0700, Matthew Fernandez wrote:
> 
>> For those on this thread who have access to mipsel hardware or can shell in 
>> to one of the mipsel build machines, I would suggest running an 
>> ASan-instrumented test there (`export CFLAGS="-g -fsanitize=address"; export 
>> CXXFLAGS="-g -fsanitize=address"`) and see what we learn.
> 
> I tried on real hardware.  Unfortunately I'm running into
> 
> 
> 
> configure:3720: $? = 0
> configure:3709: gcc -v >&5
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/mipsel-linux-gnu/9/lto-wrapper
> Target: mipsel-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Debian 9.3.0-10' 
> --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs 
> --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,gm2 --prefix=/usr 
> --with-gcc-major-version-only --program-suffix=-9 
> --program-prefix=mipsel-linux-gnu- --enable-shared --enable-linker-build-id 
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
> --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug 
> --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new 
> --enable-gnu-unique-object --disable-libitm --disable-libsanitizer 
> --disable-libquadmath --disable-libquadmath-support --enable-plugin 
> --enable-default-pie --with-system-zlib --with-target-system-zlib=auto 
> --enable-multiarch --disable-werror --enable-multilib --with-arch-32=mips32r2 
> --with-fp-32=xx --with-madd4=no --with-lxc1-sxc1=no --enable-targets=all 
> --with-arch-64=mips64r2 --enable-checking=release --build=mipsel-linux-gnu 
> --host=mipsel-linux-gnu --target=mipsel-linux-gnu
> Thread model: posix
> gcc version 9.3.0 (Debian 9.3.0-10) 
> configure:3720: $? = 0
> configure:3709: gcc -V >&5
> gcc: error: unrecognized command line option '-V'
> gcc: fatal error: no input files
> compilation terminated.
> configure:3720: $? = 1
> configure:3709: gcc -qversion >&5
> gcc: error: unrecognized command line option '-qversion'; did you mean 
> '--version'?
> gcc: fatal error: no input files
> compilation terminated.
> configure:3720: $? = 1
> configure:3740: checking whether the C compiler works
> configure:3762: gcc -g -O2 -fdebug-prefix-map=/home/tille/clustalo=. 
> -fstack-protector-strong -Wformat -Werror=format-security -fsanitize=address 
> -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now conftest.c  >&5
> /usr/bin/ld: cannot find libasan_preinit.o: No such file or directory
> /usr/bin/ld: cannot find -lasan
> collect2: error: ld returned 1 exit status
> configure:3766: $? = 1
> configure:3804: result: no
> configure: failed program was:
> 
> 
> 
> I have no idea why libasan_preinit.o and libasan.a are not installed.
> The package libgcc-9-dev is installed for sure and on amd64 both files
> are included here.  It seems the sudo command on eller does not permit
> me executing `apt-file update` in a chroot so I have no idea where these
> files are on mipsel (if they exist at all).
> 
> Any more help from debian-mipsel is really appreciated.

Hm yes, “--disable-libsanitizer” is rather ominous. I guess the mipsel GCC 
package has been built without ASan support. Surprising that it fails so 
messily (the front end seems to think -fsanitize=address is an accepted command 
line option), but libasan does indeed seem not available on mipsel [0]. The 
other option I suggested was Valgrind, but if you can’t run apt-file you 
probably can’t install Valgrind either. If anyone spectating has ideas, please 
chime in.

  [0]: 
https://packages.debian.org/search?searchon=contents=libasan.so=exactfilename=sid=mipsel

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

[Matthew Fernandez]

> On Apr 29, 2020, at 02:12, Andreas Tille  wrote:
> 
> Hi,
> 
> On Wed, Apr 29, 2020 at 10:30:35AM +0800, 黄佳文 wrote:
>> I am a developer from Loongson company (R & D CPU/mip64el), I've been
>> looking at this recently.
> 
> Very nice to see mips developers to care for biological software. :-)
> 
>> I did two experiments, and I found that when I used Python 3,7 to compile
>> python-biopython, Build successfully.
>> In the same environment, I just upgrade Python 3.7 to Python 3.8, and then
>> compile python-biopytho, Build fails, but not bus error.
>> I found through online query that some symbol tables were added and deleted
>> in upgrading Python 3.7 to 3.8. The following are symbol tables:
> 
> Sorry to insist here - I do not think that it is a Python version problem
> at all.  The issue can be reproduced in clustalo only which is pure C code.
> May be you have a look at
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956324#59
> 
> and the following discussion.  Despite Matthew has found some issues inside
> the C code it did not helped to prevent:
> 
> 
> Starting program: /home/tille/clustalo/src/clustalo -i 
> debian/tests/biopython_testdata/f002 --guidetree-out temp_test.dnd -o 
> temp_test.aln --outfmt clustal --force
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/mipsel-linux-gnu/libthread_db.so.1".
> 
> Program received signal SIGBUS, Bus error.
> 0x5556a1b8 in PairDistances (distmat=0x7fff278c, mseq=0x55692a30, 
> pairdist_type=, bPercID=, istart=0, iend=3, 
> jstart=0, jend=3, fdist_in=0x0, 
>fdist_out=0x0) at pair_dist.c:346
> 346 NewProgress(, LogGetFP(, LOG_INFO),
> 
> 
> That's the issue we need to care about here.

To add another data point to this discussion, one other (fruitless) thing I 
tried previously was cross-compiling Clustal Omega. From an amd64 host, it’s 
possible to target mipsel using the GCC cross-compilers in the standard Debian 
repositories. You can then run the resulting binary using Qemu’s user mode. 
Using this technique, the f002 test runs to completion with no bus error. This 
is not really surprising as AFAIK unaligned accesses that would trigger a bus 
error on mipsel hardware would be silently allowed in this configuration (Qemu 
doesn’t faithfully emulate this hardware behaviour and amd64 allows unaligned 
access).

Unfortunately the repositories’ cross-compilers have been built without ASan 
enabled and you can’t attach to an emulated mipsel process with a native 
Valgrind. So debugging memory safety issues is not straightforward. To go 
further with this approach, you would have to build a mipsel-targeting 
cross-compiler with ASan enabled or cross-compile Valgrind to mipsel. For a 
true masochist, it may be possible to attach to the process with GDB or rr and 
reverse-step from the location Andreas has quoted, but I wouldn’t trust the 
debugger not to crash in this configuration. Even then the issue may not be 
reproducible because it may be dependent on transformations/optimizations only 
performed by the particular version of the native mipsel compiler called during 
packaging.

For those on this thread who have access to mipsel hardware or can shell in to 
one of the mipsel build machines, I would suggest running an ASan-instrumented 
test there (`export CFLAGS="-g -fsanitize=address"; export CXXFLAGS="-g 
-fsanitize=address"`) and see what we learn.

Bug#959011: RFS: rumur/2020.04.26-1 -- model checker for the Murphi language

[Matthew Fernandez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: rumur
   Version : 2020.04.26-1
   Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : Unlicense
* Vcs : https://github.com/Smattr/rumur.git
   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_2020.04.26-1.dsc

Changes since the last upload:

   * New upstream release.

Regards,
Matthew

Bug#958228: RFS: rumur/2020.04.05-1 -- model checker for the Murphi language

[Matthew Fernandez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: rumur
   Version : 2020.04.05-1
   Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : Unlicense
* Vcs : https://github.com/Smattr/rumur.git
   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_2020.04.05-1.dsc

Changes since the last upload:

   * New upstream release.
.
   * Add some autopkgtests for new binary, murphi2murphi.

Regards,
Matthew

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

[Matthew Fernandez]

> On Apr 17, 2020, at 22:39, Andreas Tille  wrote:
> 
> Hi Matthew,
> 
> thanks a lot for your detailed investigation.
> 
> On Fri, Apr 17, 2020 at 04:28:23PM -0700, Matthew Fernandez wrote:
>>> Program received signal SIGBUS, Bus error.
>>> 0x5556a1b8 in PairDistances (distmat=0x7fff278c, mseq=0x55692a30, 
>>> pairdist_type=, bPercID=, istart=0, iend=3, 
>>> jstart=0, jend=3, fdist_in=0x0, 
>>>   fdist_out=0x0) at pair_dist.c:346
>>> 346 NewProgress(, LogGetFP(, LOG_INFO),
>> 
>> OK, let me try a little harder :)
>> 
>>$ # enable debugging symbols and Address Sanitizer
>>$ CFLAGS="-g -fsanitize=address" CXXFLAGS="-g -fsanitize=address" 
>> ./configure
>>…
>>$ make clean && make
>>…
>>$ ./src/clustalo -i debian/tests/biopython_testdata/f002 --guidetree-out 
>> temp_test.dnd -o temp_test.aln --outfmt clustal --force
>>=
>>==30264==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on 
>> address 0x7ffcfcbf5784 at pc 0x5620f0aa478c bp 0x7ffcfcbf56c0 sp 
>> 0x7ffcfcbf56b8
>>WRITE of size 4 at 0x7ffcfcbf5784 thread T0
>>#0 0x5620f0aa478b in PairDistances 
>> /home/matthew/clustal-omega-1.2.4/src/clustal/pair_dist.c:336
>>#1 0x5620f0a91d9f in AlignmentOrder 
>> /home/matthew/clustal-omega-1.2.4/src/clustal-omega.c:835
>>#2 0x5620f0a95c04 in Align 
>> /home/matthew/clustal-omega-1.2.4/src/clustal-omega.c:1221
>>#3 0x5620f0a90d76 in MyMain 
>> /home/matthew/clustal-omega-1.2.4/src/mymain.c:1192
>>#4 0x5620f0a88ca2 in main 
>> /home/matthew/clustal-omega-1.2.4/src/main.cpp:469
>>#5 0x7f3773d9009a in __libc_start_main ../csu/libc-start.c:308
>>#6 0x5620f0a89ad9 in _start 
>> (/home/matthew/clustal-omega-1.2.4/src/clustalo+0x2dad9)
>> 
>>Address 0x7ffcfcbf5784 is located in stack of thread T0
>>SUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow 
>> /home/matthew/clustal-omega-1.2.4/src/clustal/pair_dist.c:336 in 
>> PairDistances
>>Shadow bytes around the buggy address:
>>  0x10001f976aa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>  0x10001f976ab0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>  0x10001f976ac0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>  0x10001f976ad0: 00 00 00 00 00 00 00 00 00 00 00 00 ca ca ca ca
>>  0x10001f976ae0: 04 cb cb cb cb cb cb cb 00 00 00 00 ca ca ca ca
>>=>0x10001f976af0:[04]cb cb cb cb cb cb cb 00 00 00 00 00 00 00 00
>>  0x10001f976b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>  0x10001f976b10: f1 f1 f1 f1 00 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2
>>  0x10001f976b20: f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 f2 f2 f2
>>  0x10001f976b30: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
>>  0x10001f976b40: 00 00 00 00 00 00 f1 f1 f1 f1 00 f2 f2 f2 f2 f2
>>Shadow byte legend (one shadow byte represents 8 application bytes):
>>  Addressable:   00
>>  Partially addressable: 01 02 03 04 05 06 07
>>  Heap left redzone:   fa
>>  Freed heap region:   fd
>>  Stack left redzone:  f1
>>  Stack mid redzone:   f2
>>  Stack right redzone: f3
>>  Stack after return:  f5
>>  Stack use after scope:   f8
>>  Global redzone:  f9
>>  Global init order:   f6
>>  Poisoned by user:f7
>>  Container overflow:  fc
>>  Array cookie:ac
>>  Intra object redzone:bb
>>  ASan internal:   fe
>>  Left alloca redzone: ca
>>  Right alloca redzone:cb
>>==30264==ABORTING
>> 
>> Looking at line 336 of pair_dist.c, it looks like the bound on the 
>> containing loop is wrong. So let’s try adjusting that:
>> 
>>$ vim src/clustal/pair_dist.c
>>$ git diff src/clustal/pair_dist.c
>>diff --git a/src/clustal/pair_dist.c b/src/clustal/pair_dist.c
>>index e6dbdc3..bb79e61 100644
>>--- a/src/clustal/pair_dist.c
>>+++ b/src/clustal/pair_dist.c
>>@@ -321,7 +321,7 @@ PairDistances(symmatrix_t **distmat, mseq_t *mseq, 
>> int pairdist_type, bool bPerc
>> 
>> /* FIXME: can get rid of iChunkStart, iChunkEnd now that we're 
>> using the arrays */
>> iChunkStart = iend;
>>-for(iChunk = 0; iChunk <= iNumberOfThreads; iChunk++)
>>+for(iChunk = 0;

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

[Matthew Fernandez]

> On Apr 17, 2020, at 13:18, Andreas Tille  wrote:
> 
> Hi Matthew,
> 
> On Fri, Apr 17, 2020 at 08:18:29AM -0700, Matthew Fernandez wrote:
>>> Thanks for the patch which I applied to packaging Git.  I assume you
>>> want to express that while these fixes are definitely good coding
>>> practice the bus error problem is not fixed by it, right?
>> 
>> Thanks, Andreas. It may fix the bus error, but I don’t have a MIPS machine
>> to test on. Some of those logging calls had the potential to leave you with
>> a misaligned stack pointer. IIUC unaligned loads on MIPS could cause such a
>> bus error.
> 
> I tried with hope ... but failed:
> 
> (sid_mipsel-dchroot)tille@eller:~/clustalo$ gdb --args src/clustalo -i 
> debian/tests/biopython_testdata/f002 --guidetree-out temp_test.dnd -o 
> temp_test.aln --outfmt clustal --force
> GNU gdb (Debian 9.1-3) 9.1
> ...
> Reading symbols from src/clustalo...
> (gdb) run
> Starting program: /home/tille/clustalo/src/clustalo -i 
> debian/tests/biopython_testdata/f002 --guidetree-out temp_test.dnd -o 
> temp_test.aln --outfmt clustal --force
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/mipsel-linux-gnu/libthread_db.so.1".
> 
> Program received signal SIGBUS, Bus error.
> 0x5556a1b8 in PairDistances (distmat=0x7fff278c, mseq=0x55692a30, 
> pairdist_type=, bPercID=, istart=0, iend=3, 
> jstart=0, jend=3, fdist_in=0x0, 
>fdist_out=0x0) at pair_dist.c:346
> 346 NewProgress(, LogGetFP(, LOG_INFO),

OK, let me try a little harder :)

$ # enable debugging symbols and Address Sanitizer
$ CFLAGS="-g -fsanitize=address" CXXFLAGS="-g -fsanitize=address" 
./configure
…
$ make clean && make
…
$ ./src/clustalo -i debian/tests/biopython_testdata/f002 --guidetree-out 
temp_test.dnd -o temp_test.aln --outfmt clustal --force
=
==30264==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 
0x7ffcfcbf5784 at pc 0x5620f0aa478c bp 0x7ffcfcbf56c0 sp 0x7ffcfcbf56b8
WRITE of size 4 at 0x7ffcfcbf5784 thread T0
#0 0x5620f0aa478b in PairDistances 
/home/matthew/clustal-omega-1.2.4/src/clustal/pair_dist.c:336
#1 0x5620f0a91d9f in AlignmentOrder 
/home/matthew/clustal-omega-1.2.4/src/clustal-omega.c:835
#2 0x5620f0a95c04 in Align 
/home/matthew/clustal-omega-1.2.4/src/clustal-omega.c:1221
#3 0x5620f0a90d76 in MyMain 
/home/matthew/clustal-omega-1.2.4/src/mymain.c:1192
#4 0x5620f0a88ca2 in main 
/home/matthew/clustal-omega-1.2.4/src/main.cpp:469
#5 0x7f3773d9009a in __libc_start_main ../csu/libc-start.c:308
#6 0x5620f0a89ad9 in _start 
(/home/matthew/clustal-omega-1.2.4/src/clustalo+0x2dad9)

Address 0x7ffcfcbf5784 is located in stack of thread T0
SUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow 
/home/matthew/clustal-omega-1.2.4/src/clustal/pair_dist.c:336 in PairDistances
Shadow bytes around the buggy address:
  0x10001f976aa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10001f976ab0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10001f976ac0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10001f976ad0: 00 00 00 00 00 00 00 00 00 00 00 00 ca ca ca ca
  0x10001f976ae0: 04 cb cb cb cb cb cb cb 00 00 00 00 ca ca ca ca
=>0x10001f976af0:[04]cb cb cb cb cb cb cb 00 00 00 00 00 00 00 00
  0x10001f976b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10001f976b10: f1 f1 f1 f1 00 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2
  0x10001f976b20: f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 f2 f2 f2
  0x10001f976b30: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
  0x10001f976b40: 00 00 00 00 00 00 f1 f1 f1 f1 00 f2 f2 f2 f2 f2
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==30264==ABORTING

Looking at line 336 of pair_dist.c, it looks like the bound on the containing 
loop is wrong. So let’s try adjusting that:

$ vim src/clustal/pair_dist.c
$ git diff src/clustal/pair_dist.c
diff --git a/src/clustal/pair_dist.c b/src/clustal/pair_dist.c
index e6dbdc3..bb79e61 1

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

[Matthew Fernandez]

On Fri, 17 Apr 2020 at 08:09, Andreas Tille  wrote:

> Hi Matthew,
>
> On Fri, Apr 17, 2020 at 07:40:54AM -0700, Matthew Fernandez wrote:
> >
> > As a jumping off point, the attached patch fixes some issues with
> logging calls in the upstream 1.2.4 source release.
>
> Thanks for the patch which I applied to packaging Git.  I assume you
> want to express that while these fixes are definitely good coding
> practice the bus error problem is not fixed by it, right?


Thanks, Andreas. It may fix the bus error, but I don’t have a MIPS machine
to test on. Some of those logging calls had the potential to leave you with
a misaligned stack pointer. IIUC unaligned loads on MIPS could cause such a
bus error.

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

[Matthew Fernandez]

> On Apr 17, 2020, at 04:20, Andreas Tille  wrote:
> 
> Control: tags -1 help
> 
> Hi,
> 
> as it can be seen on the recent build log of clustalo on mips[1] the
> build fails with
> 
> 
> # Run additional test from python-biopython package to verify that
> # this will work as well
> src/clustalo -i debian/tests/biopython_testdata/f002 --guidetree-out 
> temp_test.dnd -o temp_test.aln --outfmt clustal --force
> make[1]: *** [debian/rules:25: override_dh_auto_test-arch] Bus error
> 
> 
> I injected that extra test since this very test failed inside the
> python-biopython package.  To track it down I logged in to
> eller.debian.org tried to build the package and was able to reproduce
> the error.  Thus I fired up gdb in this session and got:
> 
> 
> (sid_mipsel-dchroot)tille@eller:~/clustalo-1.2.4$ gdb --args src/clustalo -i 
> debian/tests/biopython_testdata/f002 --guidetree-out temp_test.dnd -o 
> temp_test.aln --outfmt clustal --force
> GNU gdb (Debian 9.1-3) 9.1
> ...
> Reading symbols from src/clustalo...
> (gdb) run
> Starting program: /home/tille/clustalo-1.2.4/src/clustalo -i 
> debian/tests/biopython_testdata/f002 --guidetree-out temp_test.dnd -o 
> temp_test.aln --outfmt clustal --force
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/mipsel-linux-gnu/libthread_db.so.1".
> 
> Program received signal SIGBUS, Bus error.
> 0x5556a188 in PairDistances (distmat=0x7fff278c, mseq=0x55692a38, 
> pairdist_type=, bPercID=, istart=0, iend=3, 
> jstart=0, jend=3, fdist_in=0x0, fdist_out=0x0) at pair_dist.c:346
> 346 NewProgress(, LogGetFP(, LOG_INFO),
> (gdb)
> 
> 
> So it seems the bus error occures somehow here:
> 
>   
> https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/pair_dist.c#L346
> 
> 
> I have no idea how to continue from here.  I'm hoping that someone with
> some more detailed knowledge might have a clue how to fix this issue on
> mipsel.  Otherwise I personally do not see any better solution than to
> remove clustalo from mipsel architecture.

As a jumping off point, the attached patch fixes some issues with logging calls 
in the upstream 1.2.4 source release.



clustalo-log-format-calls.patch
Description: Binary data

Bug#951497:

[Matthew Fernandez]

Just an update on some things relevant to this bug:
 * a new version of Rumur I uploaded, v2020.03.12-1, was just approved by Adam
 * Rumur v2020.01.27-2, my attempted final resolution to this bug, was removed 
from mentors due to the more recent upload

For anyone following this bug at home or trying to comprehend it in the future, 
we had an out-of-band email thread with Adam, Anatoly and myself, the relevant 
last part of which is:

>> On Mar 3, 2020, at 11:08, Matthew Fernandez  
>> wrote:
>> On Tue, 3 Mar 2020 at 07:22, Adam Borowski  wrote:
>> On Tue, Mar 03, 2020 at 06:59:14AM -0800, Matthew Fernandez wrote:
>> > > On Mar 3, 2020, at 05:57, Debian Bug Tracking System 
>> > >  wrote:
>> > > #951881: RFS: rumur/2020.01.27-2 -- model checker for the Murphi language
>> > > 
>> > > It has been closed by Adam Borowski .
>> 
>> > Sorry, I don’t understand the rationale here.  Is submitting an older -2
>> > to unstable not the way to do this?
>> 
>> Any version numbers in a release must be monotonic.  Once 2020.02.17-1 is
>> in unstable, there's no way to upload 2020.01.27-2 there.
>> 
>> ...
>> 
>> Ah I see. Thanks for the explanation, Adam. 
>> 
>> Anatoly, does that mean we can close #951497?

Adam/Anatoly, I think there’s nothing left for me to do in relation to this 
issue, but please let me know if I’m mistaken. I’ll leave it to you to adjust 
the bug status as relevant.

Bug#954015: RFS: rumur/2020.03.12-1 -- model checker for the Murphi language

[Matthew Fernandez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: rumur
   Version : 2020.03.12-1
   Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : Unlicense
* Vcs : https://github.com/Smattr/rumur.git
   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_2020.03.12-1.dsc

Changes since the last upload:

   * New upstream release.
.
   * Add some autopkgtests for new binary, murphi2c.

Regards,
Matthew

Bug#951497: I can't reproduce

[Matthew Fernandez]

You’re definitely testing v2020.01.27-1 right, Adam? I would think you probably 
are, but I ask because the version you uploaded for me last week 
(v2020.02.17-1) is not the problem one. v2020.02.17-1 should not reproduce this 
issue as I also made the fix there before uploading it. The problems Anatoly 
encountered were with v2020.01.27-1.

This is the first time I’ve had to make an updated release for a non-current 
version of a package, so it’s possible I did something unorthodox or confusing 
in my v2020.02.17-2 upload as well.

FWIW the situation Anatoly identified is a genuine problem for both the Debian 
package and the upstream native repo. The build system didn’t pass the test 
suite any parallelism constraints and the test suite tries to monopolise all 
cores in this scenario. Note that even after the fix you may see brief periods 
of multicore load because some of the test cases themselves do parallel work.

Bug#951881: RFS: rumur/2020.01.27-2 -- model checker for the Murphi language

[Matthew Fernandez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: rumur
   Version : 2020.01.27-2
   Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : Unlicense
* Vcs : https://github.com/Smattr/rumur.git
   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_2020.01.27-2.dsc

Changes since the last upload:

   * The build test suite now runs single threaded. Closes: #951497.
.
   * Correct watch file to only scan for upstream releases, instead of also
 matching Debian tags.

Regards,
Matthew

Bug#951628: RFS: rumur/2020.02.17-1 -- model checker for the Murphi language

[Matthew Fernandez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: rumur
   Version : 2020.02.17-1
   Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : Unlicense
* Vcs : https://github.com/Smattr/rumur.git
   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_2020.02.17-1.dsc

Changes since the last upload:

   * New upstream release.
.
   * The installed binary that was previously called rumur-ast-dump is now 
called
 murphi2xml, due to an upstream change.
.
   * Update autopkgtest tests to now reference murphi2xml instead of
 rumur-ast-dump.
.
   * The build test suite now runs single threaded, due to an upstream change,
 partially addressing #951497.
.
   * Correct watch file to only scan for upstream releases, instead of also
 matching Debian tags.

Regards,
Matthew

Bug#951497: rumur: building from sources makes machine un-usable or OOM/kills kernel

[Matthew Fernandez]

> On Feb 17, 2020, at 13:54, Anatoly Pugachev  wrote:
> 
> On Mon, Feb 17, 2020 at 11:12 PM Matthew Fernandez
>  wrote:
>> 
>> Yikes, sorry.
>> 
>> The test suite for this package auto-detects the number of CPUs and 
>> parallelises across all of them. This is not very well behaved when calling 
>> it from the outer build system, as it doesn’t pay attention to any -j flag 
>> you’ve passed there. To compound the situation, some of the individual test 
>> cases themselves are also multithreaded.
>> 
>> I think the simplest solution is to force the test suite to always run 
>> single-threaded when called via ctest. Can I close this bug by making this 
>> change when packaging the next upstream release? Or do I also need to upload 
>> new packages for the existing versions in Debian?
> 
> 
> Matthew,
> 
> being "Version: 2020.01.27-1" is available in the repository , is it
> possible to fix test suite to run single-threaded (or maybe -j2) via
> debian package patch and bump version to "2020.01.27-2" and upload?
> 
> Thanks.

Yes, good point, fair enough. I was midway through cutting a new upstream 
release when the first report arrived, so I’ll make the fix there and package 
that, and then backport it to a 2020.01.27-2 upload.

The new test suite responsible for this hammering was actually added several 
upstream releases back, but it looks like 2020.01.27-1 is the only package to 
make it through to unstable so far, so I assume I don’t need to backport this 
change to -2 uploads for older packages that only ever existed in testing.

Bug#951497: rumur: building from sources makes machine un-usable or OOM/kills kernel

[Matthew Fernandez]

Yikes, sorry.

The test suite for this package auto-detects the number of CPUs and 
parallelises across all of them. This is not very well behaved when calling it 
from the outer build system, as it doesn’t pay attention to any -j flag you’ve 
passed there. To compound the situation, some of the individual test cases 
themselves are also multithreaded.

I think the simplest solution is to force the test suite to always run 
single-threaded when called via ctest. Can I close this bug by making this 
change when packaging the next upstream release? Or do I also need to upload 
new packages for the existing versions in Debian?

Bug#950124: RFS: rumur/2020.01.27-1 -- model checker for the Murphi language

[Matthew Fernandez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: rumur
   Version : 2020.01.27-1
   Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : Unlicense
* Vcs : https://github.com/Smattr/rumur.git
   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_2020.01.27-1.dsc

Changes since the last upload:

   * New upstream release.
.
   * Add strace as a build dependency.
.
   * Update Standards-Version from 4.4.1 to 4.5.0.
.
   * Some robustness improvements to the autopkgtests.
.
   * RUMUR_VERSION variable in rules is now set automatically from the changelog
 using pkg-info.mk support.

Regards,
Matthew

Bug#937254: C++ help needed for pbdagcon

[Matthew Fernandez]

> On Jan 22, 2020, at 11:56, Andreas Tille  wrote:
> 
> Control: tags -1 help
> 
> I have fixed Python2->Python3 migration as well as the FTBFS with
> pbseqlib 5.3.3+dfsg-1 issue in Git[1].  Unfortunately there is another
> build issue in the C++ code which I have no idea how to fix:
> 
> 
> ...
> g++ -g -O2 -fdebug-prefix-map=/build/pbdagcon-0.3+git20180411.c14c422+ds=. 
> -fstack-protector-strong -Wformat -Werror=format-security -O3 -std=c++14 
> -Wall -Wuninitialized -pedantic -Wdate-time -D_FORTIFY_SOURCE=2 -MMD -MP 
> -I/build/pbdagcon-0.3+git20180411.c14c422+ds/DAZZ_DB 
> -I/build/pbdagcon-0.3+git20180411.c14c422+ds/DALIGNER 
> -I/usr/include/pbseq/alignment -I/usr/include/pbseq/pbdata 
> -I/usr/include/pbseq/hdf -I/usr/include/pbseq -isystem.//third-party   -c -o 
> DazAlnProvider.o DazAlnProvider.cpp
> In file included from DazAlnProvider.cpp:10:
> DazAlnProvider.hpp:97:19: error: expected ')' before '&' token
>   97 | Target(DAZZ_DB& db, int tspace, int small);
>  |   ~   ^
>  |   )
> DazAlnProvider.hpp:122:5: error: 'DAZZ_DB' does not name a type
>  122 | DAZZ_DB db_;
>  | ^~~
> DazAlnProvider.hpp:161:5: error: 'DAZZ_DB' does not name a type
>  161 | DAZZ_DB db_;
>  | ^~~
> DazAlnProvider.cpp: In constructor 'DazAlnProvider::DazAlnProvider(const 
> ProgramOpts&)':
> DazAlnProvider.cpp:34:33: error: 'db_' was not declared in this scope
>   34 | int status = Open_DB(path, _);
>  | ^~~
> DazAlnProvider.cpp: In destructor 'virtual DazAlnProvider::~DazAlnProvider()':
> DazAlnProvider.cpp:74:15: error: 'db_' was not declared in this scope
>   74 | Close_DB(_);
>  |   ^~~
> DazAlnProvider.cpp: In member function 'virtual bool 
> DazAlnProvider::nextTarget(std::string&, std::vector&)':
> DazAlnProvider.cpp:125:25: error: 'db_' was not declared in this scope
>  125 | seq = Load_Subread(_, trg_->id, 0, trg_->length, targSeqBuf_, 
> 0);
>  | ^~~
> DazAlnProvider.cpp: At global scope:
> DazAlnProvider.cpp:225:15: error: expected constructor, destructor, or type 
> conversion before '(' token
>  225 | Target::Target(DAZZ_DB& db, int tspace, int small) :
>  |   ^
> DazAlnProvider.cpp: In member function 'void Target::firstRecord(Record&, 
> bool)':
> DazAlnProvider.cpp:246:14: error: 'db_' was not declared in this scope
>  246 | length = db_.reads[id].rlen;
>  |  ^~~

Just taking some educated guesses here, but the way this variable is used 
indicates to me that the code expects it to be a HITS_DB, declared in 
DAZZ_DB/DB.h. The DAZZ_DB subdirectory looks like a copy of upstream project 
https://github.com/thegenemyers/DAZZ_DB 
. The latest revision of this calls 
this type DAZZ_DB, not HITS_DB. So maybe the solution is to pull in the latest 
revision of this?

Bug#939506: expected primary-expression before ‘{’ token (Was: Bug#939506: unanimity ftbfs in unstable)

[Matthew Fernandez]

> On Jan 15, 2020, at 02:13, Andreas Tille  wrote:
> 
> Hi again,
> 
> I forgot to mention that I bounced your mail to the bug log of #939506
> and I also CC this one to make sure there is some publicly visible
> record of the discussion.

Good idea for a future audience.

> On Wed, Jan 15, 2020 at 09:27:16AM +0100, Andreas Tille wrote:
>> Hi Matthew,
>> 
>> On Tue, Jan 14, 2020 at 07:00:02PM -0800, Matthew Fernandez wrote:
>>> 
>>> Offhand I don’t know the fix to the error message you quoted, but I just 
>>> tried to reproduce the build error on Debian 10.2. This repository has 
>>> multiple build systems in the root directory and no build instructions in 
>>> the README, so I guessed CMake. However, this doesn’t work:
>>> 
>>>$ mkdir build
>>>$ cd build
>>>$ cmake ..
>>>-- The CXX compiler identification is GNU 8.3.0
>>>-- The C compiler identification is GNU 8.3.0
>>>-- Performing Test HAS_NO_UNUSED_LOCAL_TYPEDEFS - Success
>>>-- Configuring incomplete, errors occurred!
>>>See also "/home/matthew/unanimity/build/CMakeFiles/CMakeOutput.log".
>>>See also "/home/matthew/unanimity/build/CMakeFiles/CMakeError.log”.
>>> 
>>> Unfortunately without further context I don’t know how to build this 
>>> program.
>> 
>> Ahhh, I assumed you would know how to build a Debian package from Git.
>> Well, here is some short introduction.  The best idea is to use
>> git-buildpackage.  If you have installed it you can do
>> 
>>   gbp clone https://salsa.debian.org/med-team/unanimity
>>   cd unanimity
>>   gbp buildpackage
>> 
>> This will call the build system that is used in Debian.  BTW, gbp needs
>> some configuration like:
>> 
>> ~> cat ~/.gbp.conf
>> [DEFAULT]
>> builder = ~/bin/git-pbuilder
>> 
>> # Might lead to problems because it tries to use non-patched makefiles
>> # cleaner = fakeroot debian/rules clean
>> cleaner = /bin/true
>> pristine-tar = True
>> export=WC
>> 
>> [buildpackage]
>> # use this for more svn-buildpackage like behaviour:
>> export-dir = ../build-area/
>> tarball-dir = ../tarballs/
>> pbuilder = True
>> pbuilder-options=--source-only-changes
>> 
>> 
>> The builder script can be used to control that the build is done using
>> cowbuilder which is a clean chroot system.  My bin/git-pbuilder has
>> basically this line:
>> 
>>  /usr/bin/pdebuild --pbuilder cowbuilder --buildresult `dirname \$PWD` 
>> --debbuildopts "-i\.git -I.git $*"
>> 
>> Before you can use cowbuilder you need to do
>> 
>>  sudo cowbuilder --create
>> 
>> 
>> Sorry for writing instructions bottom up - but I don't know what you
>> know about Debian package building.
>> 
>> Hope that you might find some time to reproduce any may be suggest a
>> patch.  If not you might have learned at least something about Debian
>> packaging. ;-)

Despite using git-buildpackage in my own packaging attempts, I am basically a 
GBP noob. All of the above was new information to me, so thank you for 
educating me :) Following your steps, I can now reproduce this error. I’ll try 
to  investigate but given the complexity of this build system and dependencies 
I would not hold my breath. If someone else reading can offer more help, please 
do.

Bug#948752: RFS: rumur/2020.01.11-1 -- model checker for the Murphi language

[Matthew Fernandez]

> On Jan 15, 2020, at 10:33, Adam Borowski  wrote:
> 
> On Tue, Jan 14, 2020 at 08:07:05PM -0800, Matthew Fernandez wrote:
>> OK, uploaded a new version with this fix. Please let me know if you have a 
>> chance to take another look.
> 
> Alas, still fails:
> 
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/librumur.a(parser.yy.cc.o):
>  in function `rumur::VarDecl::~VarDecl()':
> (.text._ZN5rumur7VarDeclD0Ev[_ZN5rumur7VarDeclD5Ev]+0x14): undefined 
> reference to `__gmpz_clear'
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/librumur.a(parser.yy.cc.o):
>  in function `void 
> rumur::parser::semantic_type::move, 
> std::allocator > > 
> >(rumur::parser::semantic_type&&)':
> (.text._ZN5rumur6parser13semantic_type4moveISt6vectorINS_3PtrINS_7VarDeclEEESaIS6_vOS1_[_ZN5rumur6parser13semantic_type4moveISt6vectorINS_3PtrINS_7VarDeclEEESaIS6_vOS1_]+0x89):
>  undefined reference to `__gmpz_clear'
> [...]
> /usr/bin/ld: (.text+0xf2e): undefined reference to `__gmpz_add'
> /usr/bin/ld: (.text+0xf36): undefined reference to `__gmpz_clear'
> /usr/bin/ld: (.text+0xf3e): undefined reference to `__gmpz_clear'
> 
> 
> Full log at http://ix.io/27tY <http://ix.io/27tY>
The riddle continues. I think this is a link order problem. I managed to 
reproduce something like this error and then subsequently fixed it by 
reordering the libraries. I’ve uploaded a new version with this fix. Can I beg 
you to take yet another look at the latest upload?

Bug#939506: expected primary-expression before ‘{’ token (Was: Bug#939506: unanimity ftbfs in unstable)

[Matthew Fernandez]

Hi Andreas,

This is not related to aghermann, correct? Offhand I don’t know the fix to the 
error message you quoted, but I just tried to reproduce the build error on 
Debian 10.2. This repository has multiple build systems in the root directory 
and no build instructions in the README, so I guessed CMake. However, this 
doesn’t work:

$ mkdir build
$ cd build
$ cmake ..
-- The CXX compiler identification is GNU 8.3.0
-- The C compiler identification is GNU 8.3.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Boost version: 1.67.0
CMake Error at cmake/uny-dependencies.cmake:21 (add_subdirectory):
  add_subdirectory given source
  "/home/matthew/unanimity/third-party/pbcopper" which is not an existing
  directory.
Call Stack (most recent call first):
  CMakeLists.txt:38 (include)


-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29")
-- Checking for module 'zlib'
--   Found zlib, version 1.2.11
CMake Error at cmake/uny-dependencies.cmake:45 (add_subdirectory):
  add_subdirectory given source "/home/matthew/unanimity/third-party/pbbam"
  which is not an existing directory.
Call Stack (most recent call first):
  CMakeLists.txt:38 (include)


-- Performing Test HAS_NO_UNUSED_LOCAL_TYPEDEFS
-- Performing Test HAS_NO_UNUSED_LOCAL_TYPEDEFS - Success
-- Configuring incomplete, errors occurred!
See also "/home/matthew/unanimity/build/CMakeFiles/CMakeOutput.log".
See also "/home/matthew/unanimity/build/CMakeFiles/CMakeError.log”.

Unfortunately without further context I don’t know how to build this program.

Thanks,
Matthew

> On Jan 14, 2020, at 12:13, Andreas Tille  wrote:
> 
> Hi Matthew,
> 
> I take the freedom to ping you personally about a bug I was asking
> for help on Debian Mentors before.  My guess is its also not such
> a hard C++ problem.
> 
> (Unfortunately when I compile unanimity from Git[1] right now I'm
> running into a different issue even before:
> 
> ...
> [ 56%] Building CXX object 
> src/CMakeFiles/unanimity.dir/genomicconsensus/experimental/ConsensusModelFactory.cpp.o
> cd /build/unanimity-3.4.1+git20180307.02aa264+dfsg/build/src && /usr/bin/c++  
>  -I/build/unanimity-3.4.1+git20180307.02aa264+dfsg/include 
> -I/build/unanimity-3.4.1+git20180307.02aa264+dfsg/build/generated 
> -I/build/unanimity-3.4.1+git20180307.02aa264+dfsg/src  -g -O2 
> -fdebug-prefix-map=/build/unanimity-3.4.1+git20180307.02aa264+dfsg=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2 -Wall -Wextra -Wno-unused-parameter -Wno-unused-variable 
> -Wno-unused-local-typedefs   -std=c++14 -o 
> CMakeFiles/unanimity.dir/genomicconsensus/experimental/ConsensusModelFactory.cpp.o
>  -c 
> /build/unanimity-3.4.1+git20180307.02aa264+dfsg/src/genomicconsensus/experimental/ConsensusModelFactory.cpp
> In file included from /usr/include/pbcopper/data/ReadId.h:13,
> from /usr/include/pbcopper/data/Read.h:19,
> from /usr/include/pbcopper/data/MappedRead.h:10,
> from /usr/include/pbbam/BamRecord.h:19,
> from 
> /build/unanimity-3.4.1+git20180307.02aa264+dfsg/include/pacbio/genomicconsensus/experimental/IPoaModel.h:8,
> from 
> /build/unanimity-3.4.1+git20180307.02aa264+dfsg/include/pacbio/genomicconsensus/experimental/arrow/ArrowModel.h:5,
> from 
> /build/unanimity-3.4.1+git20180307.02aa264+dfsg/src/genomicconsensus/experimental/ConsensusModelFactory.cpp:8:
> /usr/include/pbcopper/data/Interval.h:24:7: error: redefinition of ‘class 
> PacBio::Data::Interval’
>   24 | class Interval
>  |   ^~~~
> In file included from 
> /build/unanimity-3.4.1+git20180307.02aa264+dfsg/include/pacbio/genomicconsensus/experimental/ReferenceWindow.h:10,
> from 
> /build/unanimity-3.4.1+git20180307.02aa264+dfsg/include/pacbio/genomicconsensus/experimental/Consensus.h:10,
> from 
> /build/unanimity-3.4.1+git20180307.02aa264+dfsg/include/pacbio/genomicconsensus/experimental/WindowResult.h:7,
>   

Bug#948752: RFS: rumur/2020.01.11-1 -- model checker for the Murphi language

[Matthew Fernandez]

> On Jan 14, 2020, at 08:00, Matthew Fernandez  
> wrote:
> 
>> 
>> On Jan 13, 2020, at 19:44, Adam Borowski  wrote:
>> 
>> On Mon, Jan 13, 2020 at 06:24:32PM -0800, Matthew Fernandez wrote:
>>>>> * Package name: rumur
>>>>>  Version : 2020.01.11-1
>> 
>>> OK I think I’ve corrected this now.  Adam (or any other brave soul), do
>>> you have a chance to have another look?
>> 
>> Alas, there's still one test failing:
>> 
>> autopkgtest [04:41:21]: test librumur-api: [---
>> + mkdir -p /tmp/autopkgtest.7g3QC1/autopkgtest_tmp/librumur-api
>> + cd /tmp/autopkgtest.7g3QC1/autopkgtest_tmp/librumur-api
>> + cat -
>> + cat -
>> + c++ -std=c++11 main.cc -lgmp -lgmpxx -lrumur
>> In file included from /usr/include/rumur/rumur.h:22,
>>from main.cc:4:
>> /usr/include/rumur/scanner.h:7:12: fatal error: FlexLexer.h: No such file or 
>> directory
>>   7 |   #include 
>> |^
>> compilation terminated.
>> autopkgtest [04:41:22]: test librumur-api: ---]
>> autopkgtest [04:41:22]: test librumur-api:  - - - - - - - - - - results - - 
>> - - - - - - - -
>> librumur-api FAIL non-zero exit status 1
> 
> Thanks for another review and sorry for occupying yet more of your time.
> 
> Is there a way to run autopkgtest myself? I was expecting pdebuild would do 
> it but I can’t find options for this. Are you running it locally or looking 
> at build server results somewhere? As far as I could tell, the build servers 
> don't run the autopkgtests until a sponsor uploads the package to NEW but 
> maybe I am mistaken.
> 
> As for the present error, it looks like I want libfl-dev instead of libfl2. 
> Will fix.

OK, uploaded a new version with this fix. Please let me know if you have a 
chance to take another look.

Bug#948752: RFS: rumur/2020.01.11-1 -- model checker for the Murphi language

[Matthew Fernandez]

> On Jan 13, 2020, at 19:44, Adam Borowski  wrote:
> 
> On Mon, Jan 13, 2020 at 06:24:32PM -0800, Matthew Fernandez wrote:
>>>> * Package name: rumur
>>>>   Version : 2020.01.11-1
> 
>> OK I think I’ve corrected this now.  Adam (or any other brave soul), do
>> you have a chance to have another look?
> 
> Alas, there's still one test failing:
> 
> autopkgtest [04:41:21]: test librumur-api: [---
> + mkdir -p /tmp/autopkgtest.7g3QC1/autopkgtest_tmp/librumur-api
> + cd /tmp/autopkgtest.7g3QC1/autopkgtest_tmp/librumur-api
> + cat -
> + cat -
> + c++ -std=c++11 main.cc -lgmp -lgmpxx -lrumur
> In file included from /usr/include/rumur/rumur.h:22,
> from main.cc:4:
> /usr/include/rumur/scanner.h:7:12: fatal error: FlexLexer.h: No such file or 
> directory
>7 |   #include 
>  |^
> compilation terminated.
> autopkgtest [04:41:22]: test librumur-api: ---]
> autopkgtest [04:41:22]: test librumur-api:  - - - - - - - - - - results - - - 
> - - - - - - -
> librumur-api FAIL non-zero exit status 1

Thanks for another review and sorry for occupying yet more of your time.

Is there a way to run autopkgtest myself? I was expecting pdebuild would do it 
but I can’t find options for this. Are you running it locally or looking at 
build server results somewhere? As far as I could tell, the build servers don't 
run the autopkgtests until a sponsor uploads the package to NEW but maybe I am 
mistaken.

As for the present error, it looks like I want libfl-dev instead of libfl2. 
Will fix.

Bug#925629: aghermann: ftbfs with GCC-9

[Matthew Fernandez]

Thanks for being clear, Andrei. And thanks for your work building and 
maintaining this package.

I jumped into this thread knowing nothing about this package but merely 
recognizing a compiler error. Now that I look up what it does, I don’t have the 
necessary background to fully understand its functionality. It does look like 
it’s still seeing some usage in Debian though [0]. I’m comfortable with C++, so 
Andreas, if you still want to proceed with the packaging work, I’m happy to 
review your changes.

By the way, what is the canonical upstream source for this project? All the 
repo links on the homepage [1] except SourceForge are broken and I assume no 
one is using SourceForge these days.

  [0]: https://qa.debian.org/popcon.php?package=aghermann 

  [1]: http://johnhommer.com/academic/code/aghermann/

Bug#948752: RFS: rumur/2020.01.11-1 -- model checker for the Murphi language

[Matthew Fernandez]

> On Jan 12, 2020, at 17:14, Matthew Fernandez  
> wrote:
> 
> 
> 
> On Sun, 12 Jan 2020 at 16:56, Adam Borowski  <mailto:kilob...@angband.pl>> wrote:
> On Sun, Jan 12, 2020 at 02:13:18PM -0800, Matthew Fernandez wrote:
> > * Package name: rumur
> >Version : 2020.01.11-1
> 
> > Changes since the last upload:
> > 
> >* New upstream release.
> 
> Hi!
> I'm afraid your package fails autopkgtests, due to a bogus dependency on
> non-existing "libgmp".
> 
> In the test control file, you declare:
> Depends: build-essential, libfl2, libgmp, python3 (>= 3.6), rumur
> 
> on the other hand, the built package already has:
> Depends: libc6 (>= 2.15), libgcc1 (>= 1:3.0), libgmp10, libgmpxx4ldbl, 
> libstdc++6 (>= 9)
> with correct dependencies.
> 
> Ie, you don't need to specify that explicitly, as it's error-prone, and will
> get out of sync the moment libgmp bumps its soname.  Thus, you can just drop
> that dependency -- requiring rumur itself will pull in its deps.
> 
> Thanks for the quick reply. The autopkgtests actually need the GMP headers as 
> well as .so. So I guess I need libgmp-dev? Or does this need an explicit 
> major version in the package name as well?

OK I think I’ve corrected this now. Adam (or any other brave soul), do you have 
a chance to have another look?

Bug#925629: aghermann: ftbfs with GCC-9

[Matthew Fernandez]

Sorry, I didn’t have much context for the original issue and was probably too 
terse in my responses. Some more elaboration inline below.

> On Jan 13, 2020, at 01:14, Andreas Tille  wrote:
> 
> On Sun, Jan 12, 2020 at 02:08:56PM -0800, Matthew Fernandez wrote:
>> 
>>> On Jan 12, 2020, at 12:49, Andreas Tille  wrote:
>>> 
>>> Hi,
>>> 
>>> I'm wondering how this bug
>>> 
>>> 
>>> rk1968/rk1968.cc: In lambda function:
>>> rk1968/rk1968.cc:237:103: error: expected '{' before '->' token
>>> 237 | auto make_error_return = [] ( const char* fmt, ...) 
>>> __attribute__ ((format (printf, 2, 3))) -> int
>>> |   
>>> ^~
>>> 
>>> 
>>> with gcc 9 can be fixed in aghermann.  Any help would be appreciated.
>> 
>> Turning this into a C++11 attribute ([[gnu::format(printf, 2, 3)]]) makes 
>> the parse error go away, but -Wattributes still indicates GCC is ignoring it.
> 
> I admit I do not understand your "but -Wattributes ...".  I can confirm
> that this patch[1] builds the package successfully.

-Wattributes is a flag to GCC to enable warnings about attributes. What I did 
to experiment was extract the code you’d quoted into an isolated context:

$ cat - >test.cc <http://test.cc/> < int
  {
return 0;
  }
}
EOT
$ g++ -std=c++11 -c -Wattributes test.cc

>> You might need to bump that GCC issue with some evidence that the bug still 
>> exists and see what the maintainers say.
> 
> I need to admit that I understand so less from all the gcc issues you
> tried to explain - I do not even have any idea what C++ attributes are.
> I simply cared for that Debian bug since nobody else did. :-(
> So I feel really incompetent to discuss this with gcc maintainers but
> I'd welcome if you bring it up there.

GCC attributes like the __attribute__ example here are a mechanism for 
annotating C/C++ code with things not covered by the ISO standards, but 
supported by compiler extensions. Attributes can be applied to many things 
including variables and functions, and the function attributes are documented 
at https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html 
<https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html>. These days Clang 
also understands many of the GCC attributes.

The particular one in question here is telling the compiler that the lambda 
function being defined has similar behavior to the libc printf function. The 
integer parameters say a printf format string appears as the second argument 
and the first varargs parameter is the third argument. This looks off by one, 
but I think the captured local () counts as the first parameter. The only 
thing the compiler uses this attribute for is to detect calls to this lambda 
with incorrect arguments and emit warnings for them.

The C++11 standard brought in a more commonly supported way of declaring 
attributes using square brackets. Unfortunately the standard does not support 
many common attributes and you still need to use a “gnu::” prefix to access the 
GCC-specific attributes. Hence, “[[gnu::format(printf, 2, 3)]]” being the C++11 
equivalent of this.

>> If you need to bypass this urgently, I would recommend deleting the 
>> attribute as that particular one is only used to aid the compiler in 
>> creating warnings.
> 
> Hmmm, as I said my patch[1] works and I just have the gut feeling (as I
> said I have no competence!) that this might be better than to delete the
> attribute.  If not would you mind sending an alternative patch which is
> better in your opinion?

Lambda functions, which are already being used in this code, are a C++11 
feature as are this style of attributes. So I imagine it would be acceptable to 
upstream to take your patch. Having said that, when I did this in my experiment 
code above the compiler warned that it was ignoring this attribute as it 
thought it was being applied to the trailing “int”.

I re-read the GCC issue and realized I’d misread Jonathan Wakely’s comments. 
The issue is actually still open and Jonathan was just noting that r265787 
introduced the bug, not fixed it. So I think what we’re seeing is consistent 
with the GCC maintainers’ view.

I would suggest proposing your patch upstream. Although its primary purpose is 
working around a compiler bug, it’s also an objective improvement in 
modernizing the code base.

> Thanks again
> 
>   Andreas.
> 
> 
>>  [0]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90333 
>> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90333>
> 
> [1] 
> https://salsa.debian.org/med-team/aghermann/blob/master/debian/patches/workaround_gcc-9_issue.patch
>  
> <https://salsa.debian.org/med-team/aghermann/blob/master/debian/patches/workaround_gcc-9_issue.patch>
> 
> -- 
> http://fam-tille.de <http://fam-tille.de/>

Bug#948752: RFS: rumur/2020.01.11-1 -- model checker for the Murphi language

[Matthew Fernandez]

On Sun, 12 Jan 2020 at 16:56, Adam Borowski  wrote:

> On Sun, Jan 12, 2020 at 02:13:18PM -0800, Matthew Fernandez wrote:
> > * Package name: rumur
> >Version : 2020.01.11-1
>
> > Changes since the last upload:
> >
> >* New upstream release.
>
> Hi!
> I'm afraid your package fails autopkgtests, due to a bogus dependency on
> non-existing "libgmp".
>
> In the test control file, you declare:
> Depends: build-essential, libfl2, libgmp, python3 (>= 3.6), rumur
>
> on the other hand, the built package already has:
> Depends: libc6 (>= 2.15), libgcc1 (>= 1:3.0), libgmp10, libgmpxx4ldbl,
> libstdc++6 (>= 9)
> with correct dependencies.
>
> Ie, you don't need to specify that explicitly, as it's error-prone, and
> will
> get out of sync the moment libgmp bumps its soname.  Thus, you can just
> drop
> that dependency -- requiring rumur itself will pull in its deps.


Thanks for the quick reply. The autopkgtests actually need the GMP headers
as well as .so. So I guess I need libgmp-dev? Or does this need an explicit
major version in the package name as well?

Bug#948752: RFS: rumur/2020.01.11-1 -- model checker for the Murphi language

[Matthew Fernandez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: rumur
   Version : 2020.01.11-1
   Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : Unlicense
* Vcs : https://github.com/Smattr/rumur.git
   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_2020.01.11-1.dsc

Changes since the last upload:

   * New upstream release.
.
   * Update autopkgtest tests to test the installed binaries and library.
 Previously this incorrectly ran the upstream test suite.
.
   * Update RUMUR_VERSION variable in rules from 2019.12.22-1 to 2020.01.11-1.

Regards,
Matthew

Bug#925629: aghermann: ftbfs with GCC-9

[Matthew Fernandez]

> On Jan 12, 2020, at 12:49, Andreas Tille  wrote:
> 
> Hi,
> 
> I'm wondering how this bug
> 
> 
> rk1968/rk1968.cc: In lambda function:
> rk1968/rk1968.cc:237:103: error: expected '{' before '->' token
>  237 | auto make_error_return = [] ( const char* fmt, ...) 
> __attribute__ ((format (printf, 2, 3))) -> int
>  |
>^~
> 
> 
> with gcc 9 can be fixed in aghermann.  Any help would be appreciated.

I think you’re hitting GCC bug #90333 [0]. This claims to have been fixed in 
r265787, but I can still reproduce this issue with GCC 9.2.1 that includes that 
commit. Turning this into a C++11 attribute ([[gnu::format(printf, 2, 3)]]) 
makes the parse error go away, but -Wattributes still indicates GCC is ignoring 
it. You might need to bump that GCC issue with some evidence that the bug still 
exists and see what the maintainers say. If you need to bypass this urgently, I 
would recommend deleting the attribute as that particular one is only used to 
aid the compiler in creating warnings.

  [0]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90333

Bug#946213: RFS: git-delta/0.0.15 -- Syntax-highlighting pager for git and diff output

[Matthew Fernandez]

> On Dec 10, 2019, at 17:44, Adam Borowski  wrote:
> 
> On Tue, Dec 10, 2019 at 08:30:44PM -0500, Dan Davison wrote:
>> On Sun, 8 Dec 2019 at 22:31, Paul Wise  wrote:
>>> On Sat, Dec 7, 2019 at 9:36 PM Dan Davison wrote:
>>> 
 Currently (FreeBSD, Rust Cargo, Arch Linux, Homebrew) the package name
>>> is "git-delta", which installs an executable named "delta". Can it do the
>>> same for Debian?
>>> 
>>> There is one package already using that executable name:
>>> 
>>> $ apt-file search bin/delta
>>> swap-cwm: /usr/bin/delta
> 
>> You might be right that my naming was suboptimal! Indeed, even the
>> git-prefixed package name isn't great because the syntax highlighter works
>> for unified diff in addition to git output. However, I'm not sure I'm ready
>> to make this breaking change for the existing users yet. Is it an option to
>> distribute it for now with the same name as it is currently distributed
>> under in ArchLinux, Homebrew, FreeBSD, Windows and Rust Cargo? I.e.
>> package: "git-delta"
>> executable: "delta"
> 
>> Specifically, are either of the following options?
>> 
>> 1. Package "git-delta" installing executable "delta" (install fail/denied
>> if user has the other package installed)
>> 2. Package "git-delta" installing executables "delta" and alias "git-delta"
>> (only the alias installed if "delta" exists?)
> 
> Sorry, having an executable in $PATH named "delta" is not an option at all.
> Policy §10.1.

I am not involved in this present RFS and §10.1 is perfectly clear, but how 
does this apply to some existing packages? Specifically, I’m thinking about 
ninja and ninja-build. Both install a binary called ‘ninja’ albeit to different 
paths. Is this permissible because one installs to /usr/bin and the other to 
/usr/sbin?

Bug#943705:

[Matthew Fernandez]

Thanks for inadvertently solving a packaging error I was baffled by! I don’t 
know if this affects the priority/relevance of this bug, but FYI I was midway 
through packaging an updated version of Rumur and (guided by this bug report) 
removed my debian/rumur.manpages entirely so this is no longer a blocker for 
me. Mentors upload link for reference:

https://mentors.debian.net/debian/pool/main/r/rumur/rumur_2019.10.27-1.dsc

Bug#935900: RFS: z3 4.8.4-0.1 [NMU]

[Matthew Fernandez]

> On Aug 27, 2019, at 08:48, Fabian Wolff  wrote:
> 
> On 8/27/19 4:00 PM, Matthew Fernandez wrote:
>>> z3 (4.8.4-0.1) unstable; urgency=medium
>> 
>> I am not a z3 dev, but the latest z3 release is 4.8.5. Is there a
>> particular motivation for uploading a 4.8.4-based release?
> 
> Thanks for pointing this out; I did not notice this, because I was
> using uscan, and upstream suddenly changed the tag format on Github for
> tagging new releases:
> 
>  https://github.com/Z3Prover/z3/tags <https://github.com/Z3Prover/z3/tags>

Ah, I was not aware of this either, so we both learned something :)

> In the last hour or so, I have tried to import version 4.8.5, but they
> apparently changed something in the build system so that building with
> Mono no longer works (it fails with 'dotnet: Command not found', and I
> don't know what the Mono equivalent of the dotnet command is, or if one
> exists at all).

I’ve built 4.8.5 before, but not the .net bindings which I guess is what you’re 
dealing with. I can attempt this but unfortunately won’t have time in the short 
term.

> So, I'd say having version 4.8.4 is still better than 4.4.1, and if
> someone else wants to give 4.8.5 another try in the future, they can do
> so after this upload.

Agreed. Having 4.8.4 available would be a significant improvement. Thanks!

Bug#935900: RFS: z3 4.8.4-0.1 [NMU]

[Matthew Fernandez]

> On Aug 27, 2019, at 06:27, Fabian Wolff  wrote:
> 
> Package: sponsorship-requests
> Severity: normal
> X-Debbugs-CC: m...@debian.org
> X-Debbugs-CC: locutusofb...@debian.org
> 
> Dear mentors,
> 
> I am looking for a sponsor for a non-maintainer upload of the z3 package.
> 
> The z3 package is several years out of date (see #909494), and it is 
> maintained in a packaging team anyways, so I think a NMU is warranted here to 
> finally get the package back into shape.
> 
> My changes are summarized in the latest changelog entry:
> 
>  z3 (4.8.4-0.1) unstable; urgency=medium

I am not a z3 dev, but the latest z3 release is 4.8.5. Is there a particular 
motivation for uploading a 4.8.4-based release?

>* Non-maintainer upload.
>* New upstream release (Closes: #909494).
>* Add debian/gbp.conf.
>* Update and reorganize patches.
>* Upgrade to debhelper compat level 12.
>* Upgrade to Standards-Version 4.4.0 (no changes).
>* Remove trailing whitespace from debian/control.
>* Build-Depend on libnum-ocaml-dev (Closes: #934048).
> 
>   -- Fabian Wolff   Tue, 27 Aug 2019 14:30:11 +0200
> 
> 
> My changes can be found on Salsa, and I will create a Merge Request 
> referencing this RFS soon: https://salsa.debian.org/wolff-guest/z3
> 
> The package is also available on Mentors: 
> https://mentors.debian.net/package/z3
> 
> 
> Thanks for your help!
> 
> Best regards,
> Fabian
> 

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

[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]

[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]

[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

Bug#919220: ITP: rumur -- model checker for the Murphi language

[Matthew Fernandez]

Package: wnpp
Severity: wishlist
Owner: Matthew Fernandez 

* Package name: rumur
  Version : 2019.01.12
  Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : The Unlicense
  Programming Lang: C, C++, Python
  Description : model checker for the Murphi language

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.

Rumur works by reading an input file describing a collection of state variables
and transition rules, from which it generates a C program to verify safety and
security properties of this state machine. The generated verifier works by
exhaustively exploring the state space, checking for violation of invariants or
deadlocks.

In comparison to CMurphi, Rumur generates a verifier that runs significantly
faster and uses less memory on large input problems.

The Murphi modelling language has been used extensively for hardware
verification, in particular for analysing cache coherence protocols. Rumur is
able to improve existing users’ work flow by decreasing the time to check these
models. I am not aware of any other Debian packages that provide this
functionality; existing CMurphi users generally build the tool from source.

I am the sole developer and maintainer of this tool and intend to be its
Debian maintainer as well. I have not packaged or maintained a tool for Debian
before, so I am looking for a sponsor.