Bug#1041675: lintian: missing-dep-for-interpreter does not recognize lua5.4 as lua

2023-07-21 Thread Phil Hagelberg
Package: lintian
Version: 2.116.3
Severity: normal
X-Debbugs-Cc: p...@hagelb.org

Hello!

I have a package which declares a dependency on "lua5.4 | lua" and is
compatible with every version of Lua which is included in Debian. When
I build my package, lintian complains:

E: fennel: missing-dep-for-interpreter lua (does not satisfy lua:any | 
lua40:any | lua50:any | lua5.1:any | lua5.2:any) [usr/bin/fennel]

It appears to treat earlier versions of Lua as satisfying this
dependency, but not 5.3 and 5.4. Changing the dependency to "lua5.2 |
lua" makes the error go away, but I would prefer not to do this as 5.2
is missing a lot of nice-to-have features.

The repository https://salsa.debian.org/technomancy-guest/fennel branch 
"debian/131-prep" can be used to demonstrate this problem.

In addition, lintian should probably not be recommending lua40 (removed in
2011) or lua50 (removed in 2021).

thanks,
Phil

-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-10-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils2.40-2
ii  bzip2   1.0.8-5+b1
ii  diffstat1.65-1
ii  dpkg1.21.22
ii  dpkg-dev1.21.22
ii  file1:5.44-3
ii  gettext 0.21-12
ii  gpg 2.2.40-1.1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.15.0-1
ii  libapt-pkg-perl 0.1.40+b2
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b1
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b1
ii  libclone-perl   0.46-1
ii  libconfig-tiny-perl 2.28-2
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.35-1
ii  libdata-dpath-perl  0.58-2
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2+b1
pn  libdigest-sha-perl  
ii  libdpkg-perl1.21.22
ii  libemail-address-xs-perl1.05-1+b1
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.023-2
ii  libipc-run3-perl0.048-3
ii  libjson-maybexs-perl1.004004-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.59-1
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005005-1
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.144-1
ii  libperlio-gzip-perl 0.20-1+b1
ii  libperlio-utf8-strict-perl  0.010-1
ii  libproc-processtable-perl   0.634-1+b2
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.003+ds-1
ii  libsereal-encoder-perl  5.003+ds-1
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.28-1
ii  libterm-readkey-perl2.38-2+b1
ii  libtext-levenshteinxs-perl  0.03-5+b1
ii  libtext-markdown-discount-perl  0.16-1
ii  libtext-xslate-perl 3.5.9-1+b2
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2+b1
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2
ii  liburi-perl 5.17-1
ii  libwww-mechanize-perl   2.16-1
ii  libwww-perl 6.68-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b1
ii  libyaml-libyaml-perl0.86+ds-1
ii  lzop1.04-2
ii  man-db  2.11.2-2
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.36.0-7
ii  plzip [lzip-decompressor]   1.10-5
ii  t1utils 1.41-4
ii  unzip   6.0-28
ii  xz-utils5.4.1-0.2

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
pn  libtext-template-perl  

-- no debconf information



Bug#900299: leiningen-clojure: depends on openjdk-8

2019-01-22 Thread Phil Hagelberg
Elana Hashman  writes:

> So here's the issue with Leiningen and Java 11. We previously tracked 
> down some sort of bytecode incompatibilty problem. When Leiningen is 
> built with Java 11, it seems to recompile every time it's run, leading 
> to unacceptable performance, and it results in *different* help output, 
> which is baffling.
>
> Phil, have we attempted building Leiningen with Java 11 upstream?

I've tried it but Leiningen won't build on Java 11 because of this bug in 
Clojure:

  
https://dev.clojure.org/jira/browse/CLJ-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

It looks like it's been fixed in newer versions of Clojure, but we
haven't bumped that in Leiningen yet.

-Phil


signature.asc
Description: PGP signature


Bug#869539: can be closed

2017-11-24 Thread Phil Hagelberg
Talking with the devs further, this is an intentional change in
libsdl2. It notices that caps lock has been mapped to ctrl, so when you
ask it whether ctrl is being pressed, it only checks caps lock and
ignores the physical ctrl even though they are both mapped to ctrl.

This can be closed as it is not relevant to the love package.

-Phil



Bug#877418: dh-strip-nondeterminism: kills clojure performance

2017-10-04 Thread Phil Hagelberg
Hi; I'm the upstream maintainer of Leiningen, a Clojure application
being packaged for Debian.

I would strongly vote for adjusting the timestamps of .clj files to be
older than the corresponding .class files.

I don't know enough about filesystem timestamp granularity to comment on
the wisdom of >= vs >, but I do know that patches to Clojure from
outsiders (myself included) often take years to get applied (if ever)
and the value of maintaining compatibility with older versions of
Clojure shouldn't be underestimated.

Users of Leiningen will pull in whatever version of Clojure is specified
by their application (usually not the same one as is packaged by
Debian), and if jars from the Debian repository end are packaged with
the assumption that they are consumed with a >=-patched Clojure, this
will cause a lot of subtle confusion.

-Phil


signature.asc
Description: PGP signature


Bug#869539: Acknowledgement (love.keyboard.isDown("lctrl") always returns false)

2017-07-25 Thread Phil Hagelberg
After talking with the developers of the package, they suspect that the
problem lies with the version of libsdl2 which is shipped by
Debian. This would be consistent with the fact that all versions of LÖVE
seem affected by the problem on Stretch but none do on Jessie.



Bug#869539: love.keyboard.isDown("lctrl") always returns false

2017-07-23 Thread Phil Hagelberg
Package: love
Version: 0.9.1-4
Severity: important

After upgrading to Debian Stretch, I have observed that no matter
whether I press the left ctrl key, the function love.keyboard.isDown("lctrl")
always returns false. Right ctrl is unaffected. Note that this is
likely a problem with one of love's dependencies, since it affects
every version I have tried, including 0.10.2 and current trunk, and
these versions worked fine on jessie.

To reproduce, run this:

cd /tmp
mkdir ctrltest
cd ctrltest
echo 'love.keypressed = function(k) print(k, love.keyboard.isDown("lctrl", 
"rctrl") and "control") end' > main.lua
love .

-- System Information:
Debian Release: 9.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores)
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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages love depends on:
ii  libc6 2.24-11+deb9u1
ii  libdevil1c2   1.7.8-10+b2
ii  libfreetype6  2.6.3-3.2
ii  libgcc1   1:6.3.0-18
ii  libgl1-mesa-glx [libgl1]  13.0.6-1+b2
ii  libluajit-5.1-2   2.0.4+dfsg-1+b1
ii  libmodplug1   1:0.8.8.5-3
ii  libmpg123-0   1.23.8-1+b1
ii  libopenal11:1.17.2-4+b2
ii  libphysfs12.0.3-5
ii  libsdl2-2.0-0 2.0.5+dfsg1-2
ii  libstdc++66.3.0-18
ii  libvorbisfile31.3.5-4

Versions of packages love recommends:
pn  binfmt-support  

love suggests no packages.

-- no debconf information



Bug#754504: Recommend closing this bug

2017-05-26 Thread Phil Hagelberg
This bug should probably be closed; libpedantic is no longer its own
independent library but has been merged into Leiningen itself:

https://github.com/technomancy/leiningen/commit/c968fa5068fafada

Thanks,
Phil


signature.asc
Description: PGP signature


Bug#819811: ITP: leiningen -- simple build system for Clojure

2017-01-17 Thread Phil Hagelberg
> I understand this probably goes against some policies, but I would urge
> you to consider removing the search task if including it would add a
> significant burden to the job of packaging. If it would help, I will
> include a deprecation notice in version 2.7.2 of Leiningen recommending
> against the use of the search task.

Upon further reflection, I think it should probably be removed from
upstream as well. Sorry for the confusion.

Further discussion on the upstream issue tracker:

  https://github.com/technomancy/leiningen/pull/2234

Hope this makes the packaging job easier.


signature.asc
Description: PGP signature


Bug#819811: ITP: leiningen -- simple build system for Clojure

2017-01-17 Thread Phil Hagelberg
Elana Hashman  writes:

> Finally following up with some conversations I had at Clojure/conj, I'd 
> like to help get the ball rolling on this again. Based on leiningen 
> 2.7.1's dependencies, here's what we'll need to package/upgrade to make 
> this happen.

Very exciting; thanks!

> Packages that have a higher version in Debian unstable than in leiningen 
> 2.7.1:
>
> libdynapath-clojure aka org.tcrawley/dynapath (2.5.1 > 2.4.1)
> libmaven-indexer-java aka org.apache.maven.indexer/indexer-core (5.1.1 > 
> 4.1.3)
> libcommons-io-java aka commons-io (2.5 > 2.4)

For the record, the versions of both dynapath and commons-io in the
current git version of Leiningen (2.7.2-SNAPSHOT) match those in Debian
unstable.

The indexer is another story. It is use to support the `search' task,
but I really regret leaving that in Leiningen 2.x and am strongly
considering adding a warning not to use it. Since it was originally
introduced the indices it has to download have gotten so large as to be
quite impractical, and users are nearly always better off performing a
search in a web browser against an online index vs downloading their own
copy of the indices.

I understand this probably goes against some policies, but I would urge
you to consider removing the search task if including it would add a
significant burden to the job of packaging. If it would help, I will
include a deprecation notice in version 2.7.2 of Leiningen recommending
against the use of the search task.

Though obviously in most cases diverging from upstream in a situation
like this is a bad idea, the search task is *never* used in an automated
context; if it breaks it will not affect the builds of other projects
which use Leiningen. In addition, in the past three years the only time
anyone has mentioned the search task to me on IRC or elsewhere has been
to ask why it isn't working well and whether it's really going to take
as many hours as it claims to download the rest of the indices. My
suspicion is that the number of users who have the patience to wait for
the indices to actually download (vs switching to a browser and having
the search results displayed immediately) is in the low double digits.

If this is not acceptable then I will bump the version of Maven Indexer
used in Leiningen 2.7.2 to match the version in Debian.

-Phil


signature.asc
Description: PGP signature


Bug#761305: RM: leiningen -- obsolete

2014-09-12 Thread Phil Hagelberg
Subject: RM: leiningen -- obsolete
Package: leiningen
Severity: important

Dear Maintainer,

As the author of Leiningen, I would like to see the current package in
Debian removed. I field support questions on IRC on a regular basis
from users who install the 1.x version in Debian, but it is too old to
be used on most modern codebases.

I know there is an effort to get Leiningen 2.x packaged, but it's
doubtful whether this will happen in time for Jessie; in either case the
existing package is not helping. There are no reverse dependencies on
Leiningen as far as I can tell.

I have tried to contact the debian-java-maintainers on IRC but haven't
gotten a response on this subject.

-- System Information:
Debian Release: 7.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


pgpF6_FDDqwor.pgp
Description: PGP signature


Bug#647632: leiningen: Could not locate clojure/contrib/java_utils__init.class or clojure/contrib/java_utils.clj on classpath:

2011-11-05 Thread Phil Hagelberg
On Fri, Nov 4, 2011 at 10:22 AM, Mathieu Malaterre
mathieu.malate...@gmail.com wrote:

 pom         Write a pom.xml file to disk for Maven interop.
 leiningen.push  Problem loading: java.io.FileNotFoundException: Could not 
 locate clojure/contrib/java_utils__init.class or 
 clojure/contrib/java_utils.clj on classpath:  (push.clj:1)

While Leiningen itself does not use Clojure Contrib, many plugins do,
and the upstream includes it. Perhaps it should be listed as a regular
dependency rather than a Recommended?

A workaround is to manually install clojure-contrib for now.

-Phil



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#632365: libxbean-java recommends groovy

2011-07-01 Thread Phil Hagelberg
Package: libxbean-java
Version: 3.5-4
Severity: minor


I'm working on packaging an application that needs libmaven2-core-java
and noticed that installing my package would end up installing groovy,
which is unrelated and unnecessary. I traced it to libxbean-java,
which recommends groovy even though it seems unrelated.

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

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

libxbean-java depends on no packages.

Versions of packages libxbean-java recommends:
pn  groovynone (no description available)
pn  libasm2-java  none (no description available)
ii  libasm3-java  3.2-3  Java bytecode manipulation framewo
ii  libcommons-logging-java   1.1.1-8commmon wrapper interface for seve
pn  liblog4j1.2-java  none (no description available)

libxbean-java suggests no packages.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#632372: javahelper doesn't depend on a package that provides /usr/bin/jar

2011-07-01 Thread Phil Hagelberg
Package: javahelper
Version: 0.32
Severity: normal


I had to manually install fastjar before I could build debian packages
with javahelper; I believe this dependency should be declared.

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

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages javahelper depends on:
ii  bsdmainutils8.0.13   collection of more utilities from 
ii  dctrl-tools 2.14.5   Command-line tools to process Debi
ii  debhelper   8.0.0helper programs for debian/rules
ii  devscripts  2.10.69+squeeze1 scripts to make the life of a Debi
ii  dpkg-dev1.15.8.11Debian package development tools
ii  fastjar 2:0.98-3 Jar creation utility
ii  libarchive-zip-perl 1.30-3   Perl module for manipulation of ZI

javahelper recommends no packages.

Versions of packages javahelper suggests:
pn  cvs   none (no description available)
pn  gawk  none (no description available)
pn  tofrodos  none (no description available)

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#631991: libmaven-ant-tasks-java is missing all its dependencies.

2011-06-28 Thread Phil Hagelberg
Package: libmaven-ant-tasks-java
Version: 2.0.10-1
Severity: important


According to
http://search.maven.org/remotecontent?filepath=org/apache/maven/maven-ant-tasks/2.0.10/maven-ant-tasks-2.0.10.pom
the maven-ant-tasks library depends upon a number of libraries
including classworlds, ant, plexus, and an assortment of maven
libraries. However, the Debian package declares no dependencies
whatsoever.

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

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org