Bug#795423: marked as done (RFS: filezilla/3.12.0.2-1 -- Full-featured graphical FTP/FTPS/SFTP client)
Your message dated Thu, 13 Aug 2015 21:09:13 -0700 with message-id and subject line Re: Bug#795423: RFS: filezilla/3.12.0.2-1 -- Full-featured graphical FTP/FTPS/SFTP client has caused the Debian Bug report #795423, regarding RFS: filezilla/3.12.0.2-1 -- Full-featured graphical FTP/FTPS/SFTP client 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.) -- 795423: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795423 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for filezilla 3.12.0.2-1. The package is maintained in collab-main/git: http://anonscm.debian.org/gitweb/?p=collab-maint/filezilla.git Changes since the last upload: filezilla (3.12.0.2-1) unstable; urgency=medium * New upstream release (Closes: #789678) * Removed libidn build-dep as it's not necessary anymore * Updated Standards-Version to 3.9.6, no change needed -- Adrien Cunin Thu, 13 Aug 2015 16:00:10 +0200 Thanks, -- Adrien Cunin aka Adri2000 Ubuntu MOTU Developer Debian Contributor signature.asc Description: OpenPGP digital signature --- End Message --- --- Begin Message --- Hi Adrien, On Thu, Aug 13, 2015 at 1:44 PM, Adrien Cunin wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for filezilla 3.12.0.2-1. > > The package is maintained in collab-main/git: > http://anonscm.debian.org/gitweb/?p=collab-maint/filezilla.git > > Changes since the last upload: > > filezilla (3.12.0.2-1) unstable; urgency=medium > > * New upstream release (Closes: #789678) > * Removed libidn build-dep as it's not necessary anymore > * Updated Standards-Version to 3.9.6, no change needed > > -- Adrien Cunin Thu, 13 Aug 2015 16:00:10 +0200 Uploaded, thanks for your contribution to Debian! Regards, Vincent--- End Message ---
Bug#795423: RFS: filezilla/3.12.0.2-1 -- Full-featured graphical FTP/FTPS/SFTP client
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for filezilla 3.12.0.2-1. The package is maintained in collab-main/git: http://anonscm.debian.org/gitweb/?p=collab-maint/filezilla.git Changes since the last upload: filezilla (3.12.0.2-1) unstable; urgency=medium * New upstream release (Closes: #789678) * Removed libidn build-dep as it's not necessary anymore * Updated Standards-Version to 3.9.6, no change needed -- Adrien Cunin Thu, 13 Aug 2015 16:00:10 +0200 Thanks, -- Adrien Cunin aka Adri2000 Ubuntu MOTU Developer Debian Contributor signature.asc Description: OpenPGP digital signature
Bug#795224: RFS: sndio/0.0.10-1 [ITP] -- Small audio and MIDI framework from OpenBSD
A new package is now available on mentors at the same location.
Re: Bug#795344: libmems-1.6-1: not properly linked to its dependencies
On Thu, Aug 13, 2015 at 03:40:21PM +0100, Simon McVittie wrote: > On 13/08/15 15:06, Andreas Tille wrote: > > +libMems_la_LIBADD = $(DEPS_LIBS) @BOOST_FILESYSTEM_LIB@ > > @BOOST_IOSTREAMS_LIB@ @BOOST_SYSTEM_LIB@ > > + > > SUBDIRS = libMems > > Move this from /Makefile.am into /libMems/Makefile.am, where libMems.la > is built and the rest of the libMems_la_WHATEVER variables appear. I confirm that this at least has some effect - unfortunately not the wanted one sinde the @BOOST_FILESYSTEM_LIB@ @BOOST_IOSTREAMS_LIB@ @BOOST_SYSTEM_LIB@ placeholders remain unresolved and the $(DEPS_LIBS) variable remains empty. :_( Kind regards Andreas. -- http://fam-tille.de
Bug#795224: RFS: sndio/0.0.10-1 [ITP] -- Small audio and MIDI framework from OpenBSD
1) d/changelog:
sndio (0.0.10-1) UNRELEASED; urgency=low
(feel free to spot the error :) )
Interesting, I had thought that was supposed to be changed only right before the
"real" upload. Next will be for unstable, anyhow.
2) d/rules:
I would prefer to run dh_auto_configure -- instead of ./configure
but it should be the same...
(actually dh_auto_configure fails, because it adds something that is not
recognized by
the hand written configure script)
I think this should probably stay the same. dh_auto_configure(1) doesn't
seem to describe any mechanism to suppress the auto-added arguments, and
in fact encourages a direct call to ./configure if it doesn't work...
3) d/docs: empty?
Drat, thanks for catching. (All documentation for this package is in
manpage form, so d/docs will just go away entirely)
4) d/libsndio6.0.symbols
you seem to export something like:
strlcat@Base 0.0.10
strlcpy@Base 0.0.10
are you sure? you can just depend on libbsd-dev and link it
The next upload will have a patch for that, which has already been sent
upstream (and will probably be in the next upstream release). There is
unfortunately still one bsd-compat function (fortunately used only
inside libsndio, so it can reasonably be hidden upstream in the future)
that libbsd doesn't provide (issetugid - can only be implemented in a
crude and incorrect way outside of kernel space, which is probably why
libbsd doesn't bother)
5) d/libsndio-dev.install
usr/share/man/man3/*.3
this has to be handled by a libsndio-dev.manpages
man dh_installman helps :)
7) d/{sndiod.,sndio-tools,sndio-xtools}.install :
same contains manpages
Thanks for the hint.
6) d/sndiod.init:
this should be part of upstream, seems to be not Debian specific...
what about forwarding it there?
It is in fact based on upstream's example script with minor changes;
what I'll do for now is apply them the Right Way with a patch (again a
diff has been sent upstream).
let me know how you want to address the above, and I'll look again at
the package :)
I'll make another upload on mentors in a few hours, hopefully with all
of these issues corrected.
Re: Bug#795344: libmems-1.6-1: not properly linked to its dependencies
On 13/08/15 15:06, Andreas Tille wrote: > +libMems_la_LIBADD = $(DEPS_LIBS) @BOOST_FILESYSTEM_LIB@ > @BOOST_IOSTREAMS_LIB@ @BOOST_SYSTEM_LIB@ > + > SUBDIRS = libMems Move this from /Makefile.am into /libMems/Makefile.am, where libMems.la is built and the rest of the libMems_la_WHATEVER variables appear. S
Re: Bug#795344: libmems-1.6-1: not properly linked to its dependencies
Hi mentors, I have some problem with automake configuration to link library symbols properly. On Thu, Aug 13, 2015 at 11:31:02AM +0100, Simon McVittie wrote: > On 13/08/15 10:44, Andreas Tille wrote: > > However, from your mail it seems that there is some issue with libmuscle > > which I do not understand and where I have no idea how to fix. Could > > you be so kind to give some more detailed hint how this can be fixed and > > why the package is hidden from the transition tracker? > > The package is not in the transition trackers *because* of the linking > issue I reported: its dependencies are wrong. > > >> dpkg-shlibdeps: warning: symbol _ZN6muscle4QuitEPKcz used by > >> debian/libmems-1.6-1/usr/lib/i386-linux-gnu/libMems-1.6.so.1.0.0 found in > >> none of the libraries > >> dpkg-shlibdeps: warning: symbol _ZNK6genome10gnSequence6subseqEyy used by > >> debian/libmems-1.6-1/usr/lib/i386-linux-gnu/libMems-1.6.so.1.0.0 found in > >> none of the libraries > >> dpkg-shlibdeps: warning: symbol _ZN6muscle8DistFunc8SetCountEj used by > >> debian/libmems-1.6-1/usr/lib/i386-linux-gnu/libMems-1.6.so.1.0.0 found in > >> none of the libraries > >> dpkg-shlibdeps: warning: symbol > >> _ZN6muscle10RefineVertERNS_3MSAERKNS_4TreeEj used by > >> debian/libmems-1.6-1/usr/lib/i386-linux-gnu/libMems-1.6.so.1.0.0 found in > >> none of the libraries > >> dpkg-shlibdeps: warning: symbol > >> _ZNK5boost9iostreams18mapped_file_source4dataEv used by > >> debian/libmems-1.6-1/usr/lib/i386-linux-gnu/libMems-1.6.so.1.0.0 found in > >> none of the libraries > >> dpkg-shlibdeps: warning: symbol > >> _ZN5boost10filesystem4path27m_erase_redundant_separatorEj used by > >> debian/libmems-1.6-1/usr/lib/i386-linux-gnu/libMems-1.6.so.1.0.0 found in > >> none of the libraries > > libMems-1.6.so.1.0.0 should have been linked to the libraries it depends > on, something like > > gcc -o libMems-1.6.so.1.0.0 something.o someother.o \ > -lmuscle -lgenome -lboost-filesystem > > (those library names are just guesses and probably wrong, but hopefully > you get the general idea), I confirm that the idea is understood. > but in fact it was linked without specifying > the libraries it depends on, more like > > gcc -o libMems-1.6.so.1.0.0 something.o someother.o > > As a result, the .so does not have the correct DT_NEEDED headers > describing the libraries that it depends on (use "objdump -Tx" to see > those). As a result of that, dpkg-shlibdeps produces those warnings, and > does not generate the dependencies that it should. > > It does not appear in the transition trackers because each transition > tracker uses dependencies to find the packages that depend on the > transitioning library. At the moment, libmems-1.6-1 only depends on > libc, libgcc and libstdc++, and there is nothing in its metadata to > indicate that it should be involved in the boost or libgenome transitions. > > The solution is something like this in the Makefile.am: > > libMems_1_6_la_LIBADD = $(DEPS_LIBS) > > You might also need to append $(BOOST_LIBS) or -lboost-filesystem or > something, I don't know how Boost is meant to work. There might also be > additional libraries among the "more warnings" that dpkg-shlibdeps > suppressed. The general principle is to keep adding libraries until > dpkg-shlibdeps stops producing "found in none of the libraries" warnings :-) I have tried the following quilt patch --- a/Makefile.am +++ b/Makefile.am @@ -10,5 +10,7 @@ projects/libMems.vcproj pkgconfigdir = $(libdir)/pkgconfig pkgconfig_DATA = libMems-@GENERIC_API_VERSION@.pc +libMems_la_LIBADD = $(DEPS_LIBS) @BOOST_FILESYSTEM_LIB@ @BOOST_IOSTREAMS_LIB@ @BOOST_SYSTEM_LIB@ + SUBDIRS = libMems --- a/configure.ac +++ b/configure.ac @@ -97,6 +97,7 @@ BOOST_IOSTREAMS dnl Get location of libGenome Headers PKG_CHECK_MODULES(DEPS, libGenome-1.3 >= 1.3.1 libMUSCLE-3.7 >= 1.0.0) AC_SUBST(DEPS_CFLAGS) +AC_SUBST(DEPS_LIBS) dnl Check for OpenMP #AX_OPENMP() with no visible change in the build (I also tried the versioned libMems_1_6_la_LIBADD with the same zero effect). I suspect that also libMems-1.6.pc.in might need some love but I have no idea how. > If you add -no-undefined to the LDFLAGS, the linker will fail "hard" > (FTBFS) when it encounters missing dependencies, instead of continuing > to link a partially broken library. This flag is usually a good idea > where possible; it can be used for executables and most shared > libraries, but cannot be used for some loadable modules (e.g. Python > extensions) or for circularly dependent libraries. I'll add this but would like to fix this first that way. Kind regards Andreas. -- http://fam-tille.de
Bug#795347: RFS: pkwalify/1.22-1 (Closes: #792031)
> >For perl arch:all packages there are no relevant changes between >debhelper compat level 8 and 9. >But yes, it at least makes lintian (with its new pedantic warning) >happy. exactly :) >That's perfectly fine, is used all over the place in perl packages >and works. so my guess was true, wonderful >There have already been talks on IRC in #debian-perl which probably >will lead to moving the package to pkg-perl. Knowing that would have saved me some time, but who cares, it is nice to see some perl stuff :) cheers, Gianfranco
Bug#795347: RFS: pkwalify/1.22-1 (Closes: #792031)
On Thu, 13 Aug 2015 12:09:26 +, Gianfranco Costamagna wrote: > d/control: debhelper >=9 might be better For perl arch:all packages there are no relevant changes between debhelper compat level 8 and 9. But yes, it at least makes lintian (with its new pedantic warning) happy. > perl, perl (>= 5.13.11) | libtest-simple-perl (>= 0.98) > > seems hacky, but I understand simple-perl might be needed only for older perl > releases > (note: I'm not sure buildds understands such notation) That's perfectly fine, is used all over the place in perl packages and works. The idea is: - perl is needed in general, whatever version - for tests Test::More version 0.98 is required, which is in + either perl core since 5.13.11 + or the separate package libtest-simple-perl with the appropriate version > I'll leave this to other folks, and step in if *really* needed :) There have already been talks on IRC in #debian-perl which probably will lead to moving the package to pkg-perl. Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- signature.asc Description: Digital Signature
Bug#795347: RFS: pkwalify/1.22-1 (Closes: #792031)
Hi Victor, some spurious commenting (not a perl user, so I can't help in sponsoring) d/control: debhelper >=9 might be better perl, perl (>= 5.13.11) | libtest-simple-perl (>= 0.98) seems hacky, but I understand simple-perl might be needed only for older perl releases (note: I'm not sure buildds understands such notation) d/compat: 9 the other stuff looks good. I'll leave this to other folks, and step in if *really* needed :) (I would like to avoid learning perl ATM) cheers, Gianfranco
Re: Introduce wrapper package of linuxbrew into Debian
Hi Zhou, General Note: I don't think I'll sponsor this package without a discussion on debian-devel mail list, because I do not honestly think we need another package management, specially because mixing stuff might lead to libraries incompatibilities, and something more. Do you install something in non-standard directories so there is no need of looking at this? (note: I used too few times homebrew to know it) (I guess you install on HOMEBREW_PREFIX and ~/.linuxbrew if I read correctly the code) BTW, you should also try to patch cmake to look at the new directories, at least when it isn't run in a buildd system. anyway, let's review: 1) d/changelog: UNRELEASED is not an acceptable pocket distribution. it should just say "initial release closes: #blah) if you have something more to say, there is a README.Debian file for that purpose (or README.source) 2) d/control: supporting only amd64 seems well... bad :) 3) please add a manpage (help2man might help as a starting point) 4) add a real watch file or remove it completely 5) copyright: I do not like GPL-3.0+, maybe 2.0+ might be better, and usually it is considered a good copyright the one that is the same as upstream, because otherwise you might not be able to forward Debian patches upstream (like in this case, GPL-3+ means you can't redistribute as BSD-2-clause without an explicit written permission, even if I didn't check right now the above, and IANAL) TLTR: having the same license avoids many troubles :) 6) no patches? fine, then please remove d/patches directory. cheers, Gianfranco
Bug#795224: RFS: sndio/0.0.10-1 [ITP] -- Small audio and MIDI framework from OpenBSD
Control: owner -1 !
Hi Peter
some comments
1) d/changelog:
sndio (0.0.10-1) UNRELEASED; urgency=low
(feel free to spot the error :) )
2) d/rules:
I would prefer to run dh_auto_configure -- instead of ./configure
but it should be the same...
(actually dh_auto_configure fails, because it adds something that is not
recognized by
the hand written configure script)
3) d/docs: empty?
4) d/libsndio6.0.symbols
you seem to export something like:
strlcat@Base 0.0.10
strlcpy@Base 0.0.10
are you sure? you can just depend on libbsd-dev and link it
5) d/libsndio-dev.install
usr/share/man/man3/*.3
this has to be handled by a libsndio-dev.manpages
man dh_installman helps :)
6) d/sndiod.init:
this should be part of upstream, seems to be not Debian specific...
what about forwarding it there?
BONUS: write a systemd service file
7) d/{sndiod.,sndio-tools,sndio-xtools}.install :
same contains manpages
let me know how you want to address the above, and I'll look again at
the package :)
cheers,
(note: some of them are nitpicks, some others are really packaging errors
if in doubt please ask, and I'll tell you my opinion about them)
Gianfranco
Bug#795347: RFS: pkwalify/1.22-1 (Closes: #792031)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "pkwalify" * Package name: pkwalify Version : 1.22 Upstream Author : Slaven Rezic * URL : https://github.com/eserte/p5-Kwalify/ * License : Artistic-2.0 Programming Lang: Perl Description : perl kwalify schema validator Kwalify is a Perl implementation for validating data structures against the Kwalify schema. For a schema definition, see http://www.kuwata-lab.com/kwalify/ruby/users-guide.01.html . Note that there is no support for validator hooks (section 1-7 of the user guide document). There is already a kwalify package[0] but it's implemented in Ruby and this allows the user not to install another interpreter I'm planing to push this to pkg-perl team repo [0] https://packages.debian.org/wheezy/kwalify It builds those binary packages: pkwalify - perl kwalify validator To access further information about this package, please visit the following URL: http://mentors.debian.net/package/pkwalify Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/pkwalify/pkwalify_1.22-1.dsc More information about hello can be obtained from http://www.example.com. Changes since the last upload: pkwalify (1.22-1) unstable; urgency=low * Initial Release (closes: #792031). -- Victor Seva Fri, 10 Jul 2015 11:41:05 +0200 Regards, Victor Seva -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (650, 'testing'), (600, 'unstable'), (500, 'testing-updates') Architecture: amd64 (x86_64) Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#795298: #795298 RFS: roxterm/3.1.3-1
Hi Vincent, On Wed, Aug 12, 2015 at 1:00 PM, Vincent Bernat wrote: > ❦ 12 août 2015 20:16 +0100, Tony Houghton : > >>> Oops, please wait until I change it to 3.1.4-1. I overlooked the appdata >>> file in #795217. It contains some outdated content so I need to change >>> it upstream. >> >> OK, 3.1.4-1 is ready now. The dget command is now: >> >> dget -x >> http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_3.1.4-1.dsc > > Did you contact your regular sponsor? I see you put him in copy of your > message but it is unclear if you have previously tried to reach him and > he was unresponsive. For the record, I have no objections if other DDs sponsor packages that I've sponsored in the past; it just means less work for me, after all. That being said, I am indeed active and intend on sponsoring roxterm... Regards, Vincent
Bug#795298: #795298 RFS: roxterm/3.1.3-1
Control: owner -1 ! Control: tag -1 + moreinfo Hi Tony, On Wed, Aug 12, 2015 at 12:16 PM, Tony Houghton wrote: > On 12/08/15 19:39, Tony Houghton wrote: >> >> Oops, please wait until I change it to 3.1.4-1. I overlooked the appdata >> file in #795217. It contains some outdated content so I need to change >> it upstream. > > > OK, 3.1.4-1 is ready now. The dget command is now: > > dget -x > http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_3.1.4-1.dsc > > and the ChangeLog since the last release is: > > roxterm (3.1.4-1) unstable; urgency=medium > > * Make --fork wait until dbus service name has been acquired. > * Fixed child-exited signal handler for vte-2.91's new signature. > * Support named user sessions. > * Removed profile option for initial number of tabs. > * Updated roxterm.svg's and roxterm.appdata.xml.in's licence and > copyright (Closes: #795217). > * debian/control: Changed descriptions and dependencies of dummy > packages to prevent lintian warnings. > * Added lintian overrides for warnings about dummy dbg packages. > > -- Tony Houghton Wed, 12 Aug 2015 19:54:53 +0100 If d/copyright includes a license that's not shipped in /usr/share/common-licenses (i.e. in this case, CC-BY 4.0), you need to include its full text rather than just a link to a remote resource. While you're at it, s/updgrade/upgrade/ in your package descriptions in d/control. Regards, Vincent
