Bug#737602: ITP: rpmlint -- RPM package checker
Package: wnpp Severity: wishlist Owner: Arturo Borrero Gonzalez * Package name: rpmlint Version : 1.5 Upstream Author : Ville Skyttä * URL : http://sourceforge.net/p/rpmlint/ * License : GPL-2 Programming Lang: Python Description : RPM package checker rpmlint is a tool for checking common errors in rpm packages. rpmlint can be used to test individual packages before uploading or to check an entire distribution. By default all applicable checks are performed but specific checks can be performed by using command line parameters. rpmlint can check binary rpms (files and installed ones), source rpms, and plain specfiles, but all checks do not apply to all argument types. For best check coverage, run rpmlint on source rpms instead of plain specfiles, and installed binary rpms instead of uninstalled binary rpm files. The idea for rpmlint is from the lintian tool of the Debian project. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140204082722.4209.17045.report...@r2d2.cica.es
Re: Bug#737563: ITP: telegram-cli -- Command-line interface for Telegram
On Mon, Feb 03, 2014 at 08:52:41PM +, Cleto Martín wrote: > * URL : https://github.com/vysheng/tg > * License : GPL As the binary is linked with -lssl, it cannot be distributed. -- WBR, wRAR -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140204093514.ga3...@belkar.wrar.name
Bug#489173: marked as done (Support for mips/mipsel)
Your message dated Fri, 13 Dec 2013 10:49:54 +
with message-id
and subject line Accepted openmpi 1.6.5-6 (source amd64 all)
has caused the Debian Bug report #489173,
regarding Support for mips/mipsel
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
489173: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489173
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: openmpi
Version: 1.2.7~rc2-1
Tags: patch
Severity: wishlist
I believe the appended patch is sufficient to add Linux/MIPS support
to openmpi (for both the mips and mipsel variants). That said, I wasn't
able to build and test it, due to some libtool-induced trouble:
- With just this patch, ./libtool gets triggered and falls over an
undefined CDPATH variable:
[...]
Making all in asm
make[3]: Entering directory `/srv/ths/debian/openmpi/openmpi-1.2.7~rc2/opal/asm'
depbase=`echo asm.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-I../../opal/include -I../../orte/include -I../../ompi/include -I../..
-DNDEBUG -Wall -g -O2 -finline-functions -fno-strict-aliasing -pthread -MT
asm.lo -MD -MP -MF $depbase.Tpo -c -o asm.lo asm.c &&\
mv -f $depbase.Tpo $depbase.Plo
../../libtool: line 463: CDPATH: command not found
../../libtool: line 1266: func_opt_split: command not found
libtool: Version mismatch error. This is libtool 2.1a, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.1a
libtool: and run autoconf again.
make[3]: *** [asm.lo] Error 63
make[3]: Leaving directory `/srv/ths/debian/openmpi/openmpi-1.2.7~rc2/opal/asm'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/srv/ths/debian/openmpi/openmpi-1.2.7~rc2/opal'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/srv/ths/debian/openmpi/openmpi-1.2.7~rc2'
make: *** [build] Error 2
dpkg-buildpackage: failure: debian/rules build gave error exit status 2
- The native approach of re-libtoolizing broke down in opal/libltdl,
which does some special libtool handling I couldn't figure out.
Thiemo
Index: openmpi-1.2.7~rc2/config/ompi_config_asm.m4
===
--- openmpi-1.2.7~rc2.orig/config/ompi_config_asm.m42007-12-06
20:20:58.0 +
+++ openmpi-1.2.7~rc2/config/ompi_config_asm.m4 2008-07-03 18:21:34.0
+0100
@@ -873,6 +873,18 @@
OMPI_GCC_INLINE_ASSIGN='"bis [$]31,[$]31,%0" : "=&r"(ret)'
;;
+mips64*-linux-*)
+ompi_cv_asm_arch="MIPS"
+OMPI_ASM_SUPPORT_64BIT=1
+OMPI_GCC_INLINE_ASSIGN='"or %0,[$]0,[$]0" : "=&r"(ret)'
+;;
+
+mips*-linux-*)
+ompi_cv_asm_arch="MIPS"
+OMPI_ASM_SUPPORT_64BIT=0
+OMPI_GCC_INLINE_ASSIGN='"or %0,[$]0,[$]0" : "=&r"(ret)'
+;;
+
mips-*|mips64-*)
# Should really find some way to make sure that we are on
# a MIPS III machine (r4000 and later)
Index: openmpi-1.2.7~rc2/debian/control
===
--- openmpi-1.2.7~rc2.orig/debian/control 2008-07-03 18:21:22.0
+0100
+++ openmpi-1.2.7~rc2/debian/control2008-07-03 18:21:34.0 +0100
@@ -12,7 +12,7 @@
XS-Dm-Upload-Allowed: yes
Package: openmpi-bin
-Architecture: alpha amd64 i386 ia64 powerpc ppc64 sparc kfreebsd-i386
kfreebsd-amd64 hurd-i386
+Architecture: alpha amd64 i386 ia64 powerpc ppc64 sparc kfreebsd-i386
kfreebsd-amd64 hurd-i386 mips mipsel
Depends: ${shlibs:Depends}, ${misc:Depends}, openmpi-common (=
${source:Version})
Suggests: gfortran
Description: high performance message passing library -- binaries
@@ -40,7 +40,7 @@
Package: libopenmpi-dev
Section: libdevel
-Architecture: alpha amd64 i386 ia64 powerpc ppc64 sparc kfreebsd-i386
kfreebsd-amd64 hurd-i386
+Architecture: alpha amd64 i386 ia64 powerpc ppc64 sparc kfreebsd-i386
kfreebsd-amd64 hurd-i386 mips mipsel
Depends: ${shlibs:Depends}, libopenmpi1 (= ${binary:Version}), openmpi-common
(= ${source:Version})
Conflicts: libopal-dev, pgapack (<= 1.0.0.1-4.2), openmpi-dev
Replaces: openmpi-dev, openmpi-bin (<= 1.2.4-0)
@@ -57,7 +57,7 @@
Package: libopenmpi1
Section: libs
-Architecture: alpha amd64 i386 ia64 powerpc ppc64 sparc kfreebsd-i386
kfreebsd-amd64 hurd-i386
+Architecture: alpha amd64 i386 ia64 powerpc ppc64 sparc kfreebsd-i386
kfreebsd-amd64 hurd-i386 mips mipsel
Depends: ${shlibs:Depen
RE: dpkg-dev: please reject native/non-native version when building native/non-native source packages
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700177 How to override this new behaviour that breaks backwards compatibility of existing packages that (abuse) these bad version numbers? It appears to be enforcing a "Debian Project Policy" onto packages which are not in Debian. Can this be reverted, or dpkg-source option provided to override this new behaviour that is rejecting to build these? For defaults metapackages it is often useful to have source version match binary version which matches the version of non-native packages that it points to. It appears that e.g. "3.0 (quilt)" + --create-empty-orig is the migration path for those that (abuse) bad version numbers, but that also appears to be broken at the moment. In my opinion, this is a serious RC bug in debian, since source package out in the wild that one can create with dpkg-source -b . in stable, are not recreatable with dpkg-source -b . in testing. Enforcing Debian Policy at dpkg-source -b . level, is not a good idea, especially when it breaks backwards compat for 3rd parties. We have lintian, and ftp-master lintian auto-rejects to clense the archive if so is desired. If this change is desired, the source package version should be bumped from 3.0 -> 3.1 and keep 3.0 as it was behaving before (and allow building with missmatched version numbers). -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlujhoq1nmtdjofq0nrm-mtp_7muxlhddmpae9moo8up...@mail.gmail.com
Re: dpkg-dev: please reject native/non-native version when building native/non-native source packages
* Dimitri John Ledkov , 2014-02-04, 13:30: Enforcing Debian Policy at dpkg-source -b . level, is not a good idea, especially when it breaks backwards compat for 3rd parties. We have lintian, and ftp-master lintian auto-rejects to clense the archive if so is desired. Hear, hear. And I even doubt there's consensus it is desired. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140204133857.ga30...@jwilk.net
Re: Wanted: perl package home for condorcet computation script
Paul Wise writes ("Re: Wanted: perl package home for condorcet computation
script"):
> On Mon, Feb 3, 2014 at 11:46 PM, Ian Jackson wrote:
> > It would like to live in some Debian package.
>
> devscripts seems like the ideal package. I guess some folks would want
> to use it for meeting times and team decisions.
CCing the devscripts list. Hi, devscripts maintainers. What do you
think ?
Ian.
(trying again with the right list address)
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/21232.63567.534334.543...@chiark.greenend.org.uk
Re: dpkg-dev: please reject native/non-native version when building native/non-native source packages
On 4 February 2014 13:38, Jakub Wilk wrote: > * Dimitri John Ledkov , 2014-02-04, 13:30: > >> Enforcing Debian Policy at dpkg-source -b . level, is not a good idea, >> especially when it breaks backwards compat for 3rd parties. We have lintian, >> and ftp-master lintian auto-rejects to clense the archive if so is desired. > > > Hear, hear. And I even doubt there's consensus it is desired. > Patch is attached to the new bug filed about this issue http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737634 Proposed patch adds "--force-native" dpkg-source option for the "3.0 (Native)" format, which ignores enforcing native version number check. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUjd_pvmn_Rp-S+k=rett_atuoczvtesdpuzcex2xv-...@mail.gmail.com
Re: Wanted: perl package home for condorcet computation script
Paul Wise writes ("Re: Wanted: perl package home for condorcet computation
script"):
> On Mon, Feb 3, 2014 at 11:46 PM, Ian Jackson wrote:
> > It would like to live in some Debian package.
>
> devscripts seems like the ideal package. I guess some folks would want
> to use it for meeting times and team decisions.
CCing the devscripts list. Hi, devscripts maintainers. What do you
think ?
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/21232.63296.818806.960...@chiark.greenend.org.uk
Re: dpkg-dev: please reject native/non-native version when building native/non-native source packages
Dimitri John Ledkov writes ("Re: dpkg-dev: please reject native/non-native
version when building native/non-native source packages"):
> Patch is attached to the new bug filed about this issue
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737634
> Proposed patch adds "--force-native" dpkg-source option for the "3.0
> (Native)" format, which ignores enforcing native version number check.
Thanks for that. (Sorry, please ignore my previous mail.)
I think that this behaviour needs to be the default. Otherwise there
are packages in the archive that cannot be processed with the new
tool using the default options, which I think is a
non-backwards-compatible change.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/21232.63894.530607.304...@chiark.greenend.org.uk
RE: dpkg-dev: please reject native/non-native version when building native/non-native source packages
Dimitri John Ledkov writes ("RE: dpkg-dev: please reject native/non-native
version when building native/non-native source packages"):
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700177
...
> Can this be reverted, or dpkg-source option provided to override this
> new behaviour that is rejecting to build these?
I agree that this change should be reverted. But the way to request
that would surely be to file a bug against dpkg-dev.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/21232.63829.846809.660...@chiark.greenend.org.uk
Re: dpkg-dev: please reject native/non-native version when building native/non-native source packages
+++ Dimitri John Ledkov [2014-02-04 13:30 +]: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700177 Do I understand this correctly - that it prevents a package cross-binutils-0.1 to generate binaries called binutils-arm-linux-gnueabi-2.24-3 binutils-arm-linux-gnueabihf-2.24-3 unless cross-binutils-0.1 is package format 1.0 rather than 3.0? Doing the above is the right way to build packages which are Built-Using: binutils (=2.24-3) Making the binutils- binary packages have 0.1 version numbers would be unhelpful and cause issues with 3rd party installs (newer packages with smaller version numbers). I guess requiring this to be done as a 1.0 format package is OK within debian, but derivatives or anyone who needs to hack around a bit would be better off if it was a 3.0 package, and that's the format I prefer to use, as general good practice. So unless I'm confused the above seems like a reasonable use-case where this new restriction is problematic. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140204162027.gu26...@stoneboat.aleph1.co.uk
Bug#737654: ITP: python-intef-exe -- eLearning XHTML editor
Package: wnpp Severity: wishlist Owner: Mercedes Cotelo Lois * Package name: python-intef-exe Version : 2.0-beta2 Upstream Author : eXeLearning.net * URL : http://exelearning.net/ * License : GPL Programming Lang: Python Description : eLearning XHTML editor The eXe project is an authoring environment to enable teachers to publish web content without the need to become proficient in HTML or XML markup. Content generated using eXe can be used by any Learning Management System. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140204193719.3493.99862.reportbug@mclois
cjs build error
Hello, When I try to port Cjs to debian testing I ran into this problem https://github.com/linuxmint/cjs/issues/5 Any debian developer which wants to help me to figure out what is wrong here ? Roelof -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/dub121-w21062e29816322351972a3ae...@phx.gbl
Bug#737674: ITP: libhtml-dashboard-perl -- module that tries to achieve spreadsheet-like formatting for HTML tables
Package: wnpp Owner: Radu-Bogdan Croitoru Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libhtml-dashboard-perl Version : 0.03 Upstream Author : Philipp Janert * URL : https://metacpan.org/release/HTML-Dashboard * License : Artistic or GPL-1+ Programming Lang: Perl Description : module that tries to achieve spreadsheet-like formatting for HTML tables Rather than having to build up an HTML table from data, row by row and cell by cell, applying formatting rules at every step, this module allows the user to specify a set of simple rules with the desired formatting options. The module will evaluate the rules and apply the formatting options as necessary. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1391550162.998367.20533.nullmailer@dotix
Re: dpkg-dev: please reject native/non-native version when building native/non-native source packages
On Tue, 4 Feb 2014 16:20:28 +, Wookey wrote: > +++ Dimitri John Ledkov [2014-02-04 13:30 +]: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700177 > > Do I understand this correctly - that it prevents a package > cross-binutils-0.1 to generate binaries called > binutils-arm-linux-gnueabi-2.24-3 > binutils-arm-linux-gnueabihf-2.24-3 > > unless cross-binutils-0.1 is package format 1.0 rather than 3.0? No, the check only involves the source version. My toolchain packages still build fine, e.g. the binutils-mingw-w64 3 source package builds the binutils-mingw-w64 2.24-3+3 binary package without complaint from dpkg-dev. But if I change the source version to 3-1: dpkg-source: error: can't build with source format '3.0 (native)': native package version may not have a revision Regards, Stephen signature.asc Description: PGP signature
Re: dpkg-dev: please reject native/non-native version when building native/non-native source packages
On 4 February 2014 16:20, Wookey wrote: > +++ Dimitri John Ledkov [2014-02-04 13:30 +]: >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700177 > > Do I understand this correctly - that it prevents a package > cross-binutils-0.1 to generate binaries called No, you can still generate any binaries with any version numbers. This is specifically about dpkg-source failing to build .dsc of 3.0 (quilt / native) formats if version number in the top debian/changelog is ( native / foreign ), respectively. The combination of "3.0 (native)" + "foreign version number" is what my patch resolves. An equivalent patch for "3.0 (quilt)" + "native version number" has not been done yet, but i haven't checked if this latter case was actually possible before or ever used. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluhy2xx0ubndfgscvrzj2vy1sgc5_ywyvzqvdjhmart...@mail.gmail.com
Re: dpkg-dev: please reject native/non-native version when building native/non-native source packages
Le Tue, Feb 04, 2014 at 02:05:45PM +, Dimitri John Ledkov a écrit : > On 4 February 2014 13:38, Jakub Wilk wrote: > > * Dimitri John Ledkov , 2014-02-04, 13:30: > > > >> Enforcing Debian Policy at dpkg-source -b . level, is not a good idea, > >> especially when it breaks backwards compat for 3rd parties. We have > >> lintian, > >> and ftp-master lintian auto-rejects to clense the archive if so is desired. > > > > Hear, hear. And I even doubt there's consensus it is desired. > > Patch is attached to the new bug filed about this issue > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737634 > Proposed patch adds "--force-native" dpkg-source option for the "3.0 > (Native)" format, which ignores enforcing native version number check. Hi Dimitri, and everybody, I fully agree that the behaviour should not be changed without reaching consensus, and I am very disapointed that the bug that you opened on dpkg was tagged "wontfix". The current practice is that there is no strict correspondance between using a "native" dpkg source format and being "native" to Debian. In that sense, I do not see the point for forbidding to use non-"native" version numbers with "non-native" dpkg formats. The 3.0 (native) format is useful when packaging a work that is developped and distributed in a Git repository. Please leave us this possibility. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140204230829.gb21...@falafel.plessy.net
Re: Bug#737563: ITP: telegram-cli -- Command-line interface for Telegram
Hi, On Montag, 3. Februar 2014, Cleto Martín wrote: > * URL : https://github.com/vysheng/tg > Telegram messenger is a cloud-based instant messaging platform > designed for smart phones and similar to Whatsapp but more flexible, > and powerful. You can send messages, photos, videos and documents to > people who are in your phone contacts (and have Telegram). Telegram > also supports secret chats whose provide a private (encrypted) way of > communication. according to http://blog.tincho.org/posts/Telegram/ the privacy of this tool/plattform is non existing, it rather collects the users private data and sends it to a server. I believe such software should not be packaged for+in Debian as it seems to be today...: literally, a money-quote from this blog post (from a fellow DD): "The first thing the application did was to check my address book for contacts, without my permission or knowledge. I got greeted by being told that some of my contacts already have Telegram installed, and since then I keep getting notification that some more of my geek friends are installing it. So it is obvious that this company got all my records, breaking my privacy and security." cheers, Holger, who hasn't tried telegram himself... signature.asc Description: This is a digitally signed message part.
Re: File naming of scripts in /etc/init.d
I noticed someone was wrong on the Internet, and decided to follow up on this old thread. [Steve R. Petruzzello] > I noticed that some scripts in /etc/init.d/ are suffixed by .sh and > some are not. [...] All except console-screen.sh, hwclock.sh and > keymap.sh are from the initscripts package. > > So 1) nowhere is .sh suffixing mentioned and 2) some scripts are not > named by their package's name (hwclock.sh is part of the util-linux > package). Is there a reason for this? Before concurrent running of init.d scripts were implemented in sysv-rc, the .sh scripts would be sourced by /etc/init.d/rc and /etc/init.d/rcS while the non-.sh scripts would be executed. This distinciton were removed when sysv-rc started to run scripts in parallell, as it no longer made sense. > So my question was not too stupid :) Not at all. :) -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2fl61oua1na@diskless.uio.no
Bug#737696: ITP: mpria -- multi-precision rational interval arithmetic library
Package: wnpp Severity: wishlist Owner: Jerome Benoit * Package name: mpria Upstream Author : Jerome Benoit * URL : http://www.gnu.org/software/mpria/ * License : GPL Programming Lang: C Description : multi-precision rational interval arithmetic library GNU MPRIA is a mathematical C library for rational interval arithmetic computations with arbitrary precision. The basic principle of rational interval arithmetic consists in enclosing every number by a rational interval containing it: each number is stored as its lower and upper endpoints and these bounds are rational numbers; their absolute difference measures the precision. The purpose is on the right hand to obtain guaranteed results, thanks to interval computation, and on the left hand to compute accurate results, thanks to arbitrary precision arithmetic. The arithmetic operations are extended for interval operands in such a way that the exact result of the operation belongs to the computed rational interval. The GNU MPRIA library is built upon the GNU MP library for operating on rational numbers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140205025943.998.77108.report...@nen.dnsalias.org
