Bug#962959: Agda version in Debian bullseye
Dear Ilias Tsitsimpis, does your intention to remove haskell-edison-api mean that Agda 2.6.1 will be packaged for Debian bullseye? -- Regards, Marko Dimjašević https://dimjasevic.net/marko Mastodon: https://mamot.fr/@mdimjasevic PGP key ID: 056E61A6F3B6C9323049DBF9565EE9641503F0AA Learn email self-defense! https://emailselfdefense.fsf.org signature.asc Description: This is a digitally signed message part
Bug#914691: RFA: agda-stdlib -- standard library for Agda
Hello everyone, On Mon, 2018-11-26 at 10:26 +, Iain Lane wrote: > > I'm not involved in this area any more. I've been basically ignoring > the > package and people from the Haskell team have been kindly uploading > it > in my absence. > > I'd like it if someone were to take it off my hands. That will > probably > be the Haskell team, but Sean points out to me that there would be no > human uploaders if the team were to take it over directly. So ideally > someone in the team would sign up to be an Uploader and make pkg- > haskell > the Maintainer. Let me know if there is a process to follow in applying, but I'd like to contribute with maintaining this library package. So far I had a few attempts about two years ago in creating a C++ package or two, but none in Haskell or Agda. I use Haskell professionally and I've been learning Agda. -- Regards, Marko Dimjašević https://dimjasevic.net/marko PGP key ID: 056E61A6F3B6C9323049DBF9565EE9641503F0AA Learn email self-defense! https://emailselfdefense.fsf.org signature.asc Description: This is a digitally signed message part
Bug#639910: Packaging sbt
Hi Frederic, On Thu, 2016-12-08 at 14:38 +0100, Frederic Bonnard wrote: > Sorry to ping you on that again. > Any one having feedback on the validity of that bootstrap process ? Mehdi ? > Emmanuel ? :) Sorry, I didn't try to understand the details of your latest effort, but just to give you a heads up - I was/have been working on packaging SBT too. A couple of months ago or so I started reviving the effort to get SBT into Debian: https://osdir.com/ml/general/2016-10/msg31364.html In a nutshell, Emmanuel packaged Scala 2.10 because it's a dependency for SBT, and the scala package moved to 2.11.8 in the meantime. Me being a newbie wrt Debian packaging had a hard time using it in the form he made it available in (it is not in the official Debian repos, but in a Java Debian team repo) to continue working on packaging SBT, and due to me being busy at school and overwhelmed with issues in packaging SBT, I silently drifted away. Nevertheless, it'd be great if there was a group of us and if we could dust this effort off and make more progress. I don't know if it's just me, but I find it hard to contribute in the current setting - there are just so many things to do to package SBT, there is so much I don't know about, then what is probably a simple and quick task for experienced developers takes a whole eternity for me, and I have a feeling as if most of the time I'm just moving around with a blindfold over my eyes. This is not to say I don't appreciate what others have helped with (it was mostly Emmanuel); I do appreciate it! The way I see it, it would be most effective if we made a clear list of things to do, splitted it into small tasks, and then a few of us got together online (e.g., IRC) and worked on this for a couple of hours. Of course, with someone experienced on board to guide those of us that are less experienced. -- Regards, Marko Dimjašević <ma...@dimjasevic.net> https://dimjasevic.net/marko PGP key ID: 1503F0AA Learn email self-defense! https://emailselfdefense.fsf.org signature.asc Description: This is a digitally signed message part
Bug#639910: ITP: simple-build-tool -- for scala and java projects
Control: retitle -1 ITP: simple-build-tool -- for scala and java projects Control: owner -1 ! Dear all, In accordance with the Debian Java team (predominantly Emmanuel Bourg), I started working on packaging SBT. As suggested before, I'll use a strategy that involves the non-free archive because SBT build-depends on itself. -- Regards, Marko Dimjašević <ma...@dimjasevic.net> https://dimjasevic.net/marko PGP key ID: 1503F0AA Learn email self-defense! https://emailselfdefense.fsf.org signature.asc Description: This is a digitally signed message part
Bug#829010: hostname: memory error: reading data from uninitialized memory
Dear all, My apologies for a clumsy bug report. It's the first time I'm submitting one. Beside details about my OS in the initial email, here is what I wanted to write. Package: hostname Version: 3.15 and 3.17 When hostname is invoked with an argument "-F/" (without quotes), it reads from uninitialized memory. I found this bug together with professors Cristian Cadar and Zvonimir Rakamaric while working on a project that aims to analyze programs from Debian GNU/Linux with a tool called KLEE: https://klee.github.io/ In particular, Cristian Cadar described the error in hostname as follows (line numbers are for version 3.15): "I have debugged "hostname -F/" and it is indeed a bug in hostname, a rather interesting one which could cause hostname to perform an unbounded number of out-of-bound reads. Here is what happens: 1) On line 413, a buf is allocated using malloc(): buf = (char *) malloc(st.st_size + 1) 2) Nothing is ever written into this buffer 3) set_name(enum type_t type, char *name) is invoked with buf as the second argument 4) On line 220 in set_name, strlen(name) is called. Since the memory to which name points was allocated but _never_ initialized, the entire buffer could have no NUL characters inside, in which case strlen will continue to dereference invalid memory. It will keep doing this until it encounters a NUL character. Depending on when this happens, the program could segfault." The bug can be fixed if the call to malloc from step 1) is replaced with: buf = (char *) calloc(st.st_size + 1, sizeof(char)) -- Kind regards, Marko Dimjašević <ma...@cs.utah.edu> . University of Utah https://dimjasevic.net/marko . PGP key ID: 1503F0AA Learn email self-defense! https://emailselfdefense.fsf.org signature.asc Description: This is a digitally signed message part
Bug#814680: RFS: stp/2.1.2+dfsg-1 [ITP] -- Simple theorem prover
Hi all, On Fri, 2016-02-26 at 17:42 -0800, Afif Elghraoui wrote: > That's alright, you can go ahead. I would just add that the source for > the second tarball be documented somewhere or configured to be > downloaded in debian/watch with a second uscan line. Something like > the > following: > > version=4 > > opts="dversionmangle=s/\+dfsg\d*$//" \ > https://github.com/stp/stp/tags \ > (?:.*/)?v?(\d[\d\.]*)\.tar\.gz \ > debian > > opts="dversionmangle=s/\+dfsg\d*$//,component=outputcheck" \ > https://github.com/stp/OutputCheck/tags \ > (?:.*/)?v?(\d[\d\.]*)\.tar\.gz \ > ignore uupdate Thank you Afif for this! I am not sure what is the cause (maybe incorrect paths in debian/rules), but when I try to build with gbp like this: $ BUILDER=pbuilder gbp buildpackage --git-pbuilder -us -uc -j8 it fails because it can't find a helper binary I build along the way (needed to execute tests): lit.py: lit.cfg:117: fatal: Cannot find OutputCheck executable: /build/stp-2.1.2+dfsg/utils/OutputCheck/bin/OutputCheck However, it does work in a plain pbuilder instance. Anyhow, I pushed to the repo your version of d/watch to a separate branch called 'mut-test': https://anonscm.debian.org/git/debian-science/packages/stp.git/log/?h=mut-test You can confirm for yourself it fails by e.g. switching to the mut-test branch and running this: $ BUILDER=pbuilder gbp buildpackage --git-ignore-branch --git-pbuilder -us -uc -j8 Any clue what went wrong? I looked at the tests/query-files/lit.cfg config file/script in question, but I don't see why it would fail. -- Regards, Marko Dimjašević <ma...@cs.utah.edu> . University of Utah https://dimjasevic.net/marko . PGP key ID: 1503F0AA Learn email self-defense! https://emailselfdefense.fsf.org signature.asc Description: This is a digitally signed message part
Bug#814680: RFS: stp/2.1.2+dfsg-1 [ITP] -- Simple theorem prover
Hi Afif, On Wed, 2016-02-24 at 21:16 -0800, Afif Elghraoui wrote: > Thanks for working on this package. Thank you for taking a look at the package! > I took a look at it and found some issues. The first is the requirement > of the additional file stp_2.1.2+dfsg.orig-outputcheck.tar.gz. You > should not be directly using anything outside the packaging directory. The archive corresponds to OutputCheck, a build dependency that runs STP's regression tests. OutputCheck doesn't have a Debian package, and based on my discussion with upstream developers and a Debian developer that sponsored the first upload of STP to New, this was the proposed approach. OutputCheck is, to the best of our knowledge, used only by STP, and the upstream developers have a plan of re-basing STP tests on a different testing framework soon. Furthermore, OutputCheck is not actively developed any more. I also found examples of other Debian packages being done in the same way - having a small build dependency shipped as an archive. I don't have a reference supporting that, but my memory tells me I saw an example with a Debian Perl package. > There's at least one other issue--in debian/control, the Vcs URLs should > be pointing to the packaging repository rather than upstream. Ok, I didn't know this about the Vcs URL! Recently I added a Git repo for STP on Alioth. Should I put the repo's URL to d/control? > I didn't check further because the package currently doesn't build. Can you clarify this? It builds in pbuilder with defaults settings. > Most such problems can be found by running lintian, but we first need > the package to build in a minimal environment. I haven't seen the Vcs problem in a report by Lintian. Usually I use the "-i -I" options. Can you be specific, i.e. which other options should I use that reveal issues you are talking about? -- Regards, Marko Dimjašević <ma...@cs.utah.edu> . University of Utah https://dimjasevic.net/marko . PGP key ID: 1503F0AA Learn email self-defense! https://emailselfdefense.fsf.org signature.asc Description: This is a digitally signed message part
Bug#814680: RFS: stp/2.1.2+dfsg-1 [ITP] -- Simple theorem prover
Dear all, Let me know if I can do something to get you interested in sponsoring this package for the Simple theorem prover. I am desperately looking for a sponsor. The package has been in the New queue before. Its details are given below. The package is also available on Alioth: git.debian.org/git/debian-science/packages/stp.git -- Regards, Marko Dimjašević <ma...@cs.utah.edu> . University of Utah https://dimjasevic.net/marko . PGP key ID: 1503F0AA Learn email self-defense! https://emailselfdefense.fsf.org On Sat, 2016-02-13 at 17:41 -0700, Marko Dimjašević wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "stp" > > * Package name: stp > Version : 2.1.2+dfsg-1 > Upstream Author : STP developers > * URL : https://stp.github.io/ > * License : Expat and others > Section : science > > It builds those binary packages: > > python-stp - Simple theorem prover library bindgings for Python > stp - Simple theorem prover > > To access further information about this package, please visit the > following URL: > > http://mentors.debian.net/package/stp > > > Alternatively, one can download the package with dget using this > command: > > dget -x http://mentors.debian.net/debian/pool/main/s/stp/stp_2.1.2 > +dfsg-1.dsc > > More information about STP can be obtained from https://stp.github.io/. > > Changes since the last upload: > > - new upstream release > - added copyright for the OutputCheck archive per Thorsten Alteholz's > instructions (ftp-master) > > signature.asc Description: This is a digitally signed message part
Bug#814680: RFS: stp/2.1.2+dfsg-1 [ITP] -- Simple theorem prover
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "stp" * Package name: stp Version : 2.1.2+dfsg-1 Upstream Author : STP developers * URL : https://stp.github.io/ * License : Expat and others Section : science It builds those binary packages: python-stp - Simple theorem prover library bindgings for Python stp - Simple theorem prover To access further information about this package, please visit the following URL: http://mentors.debian.net/package/stp Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/s/stp/stp_2.1.2 +dfsg-1.dsc More information about STP can be obtained from https://stp.github.io/. Changes since the last upload: - new upstream release - added copyright for the OutputCheck archive per Thorsten Alteholz's instructions (ftp-master) -- Kind regards, Marko Dimjašević https://dimjasevic.net/marko signature.asc Description: This is a digitally signed message part
Bug#814680: RFS: stp/2.1.2+dfsg-1 [ITP] -- Simple theorem prover
On Sat, 2016-02-13 at 17:41 -0700, Marko Dimjašević wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "stp" Just to clarify this... With the sponsorship of the ITP's [1] owner I uploaded a first version of STP back in October last year [2]. The package got rejected a few days ago, and I fixed issues with it in this submission. I would ask the owner to sponsor this submission too, but I haven't heard from him since last year and there was no reply to my emails in the meantime. Let me know if someone could directly sponsor the submission or if a different approach is needed. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789055 [2] https://web.archive.org/web/20151027054349/https://ftp-master.debian.org/new/stp_2.1.1+dfsg-1.html -- Regards, Marko https://dimjasevic.net/marko signature.asc Description: This is a digitally signed message part
Bug#805525: ITP: jpf - Java Pathfinder virtual machine for Java
Package: wnpp Severity: wishlist * Package name: jpf Version : 29 Upstream author : The National Aeronautics and Space Administration * URL : http://babelfish.arc.nasa.gov/trac/jpf/ * License : Apache 2.0 Programming Lang: Java Description : Java Pathfinder virtual machine for Java Java Pathfinder is a virtual machine for Java bytecode. It is a customizable execution environment for verification of Java bytecode programs. Its main application is in software model checking. The tool can find and explain defects, collect "deep" runtime information like coverage metrics, deduce interesting test vectors and create corresponding test drivers, and other. signature.asc Description: This is a digitally signed message part
