Bug#827887: marked as done (RFS: burp/1.4.40-2 [QA] -- Simple cross-platform network BackUp and Restore Program)
Your message dated Wed, 22 Jun 2016 07:06:52 + (UTC) with message-id <306714397.12316497.1466579212677.javamail.ya...@mail.yahoo.com> and subject line Re: Bug#827887: RFS: burp/1.4.40-2 [QA] -- Simple cross-platform network BackUp and Restore Program has caused the Debian Bug report #827887, regarding RFS: burp/1.4.40-2 [QA] -- Simple cross-platform network BackUp and Restore Program 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.) -- 827887: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827887 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 a QA upload of burp. * Package name: burp Version : 1.4.40-2 Upstream Author : Graham Keeling * URL : http://burp.grke.net/ * License : AGPL-3 Section : utils Changes since the last upload: * QA upload. * Remove lock.patch from d/patches/series. The burp 2.0.x series test suite fails when this patch is applied. Please see commentary in #747672, which has been re-opened. * Watch file now tracks 1.4.x series instead of old 1.3.x series. Download with dget: dget -x http://mentors.debian.net/debian/pool/main/b/burp/burp_1.4.40-2.dsc Or build it with gbp: gbp clone --pristine-tar --debian-branch=debian https://anonscm.debian.org/git/collab-maint/burp.git cd burp git checkout debian/1.4.40-2 git verify-tag debian/1.4.40-2 # if you have my key gbp buildpackage Successful sbuild: http://debomatic-i386.debian.net/distribution#unstable/burp/1.4.40-2/buildlog Thanks. -- Sean Whitton signature.asc Description: PGP signature --- End Message --- --- Begin Message --- Hi, burp is now on its way for unstable! thanks, G.--- End Message ---
Re: Bug#827700: RFS: cplay/1.50-1 [NMU]
On Wed, Jun 22, 2016 at 06:54:38AM +, Gianfranco Costamagna wrote: > >The changes I have quoted above are not usually appropriate for NMUs. > > > >In this case, it looks like those package maintainers are inactive (no > >uploads since 2005). You should contact the MIA team to have the > >package orphaned. > > well, the package hasn't been touched in over a decade, so I presume > it might be fine to upload the fixes in deferred/15, even as NMU. > I guess they had *all* the time to refactor the package, and update it. > > I'm ccing them both, and a member of MIA team, even if I'm unsure about the > MIA process for non DD people, The MIA database does contain information about everyone, any DD can query it: ssh qa.debian.org /srv/qa.debian.org/mia/mia-query jesus.clim...@hispalinux.es ssh qa.debian.org /srv/qa.debian.org/mia/mia-query pe...@p12n.org As activity-pgp is Dec 2006 and Apr 2013 respectively, both of them are pretty thoroughly inactive. I've thus pushed the big "O" button and filed #827890. > So, I think the particular bug can be fixed only with a package refactor, and > I don't want to throw away half of your work just because of policy, in case > of a package *clearly* unmaintained since 11 years. With the package freshly orphaned, it's a matter of a QA upload or adoption. We're in salvage not hijack land... Meow! -- An imaginary friend squared is a real enemy.
Bug#827700: RFS: cplay/1.50-1 [NMU]
Hi Gianfranco, On Wed, Jun 22, 2016 at 06:54:38AM +, Gianfranco Costamagna wrote: > well, the package hasn't been touched in over a decade, so I presume > it might be fine to upload the fixes in deferred/15, even as NMU. > I guess they had *all* the time to refactor the package, and update it. > > I'm ccing them both, and a member of MIA team, even if I'm unsure about the > MIA process for non DD people, > MIA Team is also handling non-DD, so I'm on it already. -- tobi (for the MIA Team)
Bug#827895: RFS: lua-torch-nn/0~20160604-gd23a8f5+dfsg-1 [ITP]
Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Dear mentors, I am looking for a sponsor for my package "lua-torch-nn" * Package name: lua-torch-nn Version : 0~20160604-gd23a8f5+dfsg-1 Upstream Author : Torch devs * URL : github.com/torch/nn * License : BSD-3-Clause Section : interpreters It builds those binary packages: libtorch-thnn - libTHNN.so of Neural Network Package for Torch Framework libtorch-thnn-dev - libTHNN.so of Neural Network Package for Torch Framework (dev) lua-torch-nn - Neural Network Package for Torch Framework To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lua-torch-nn Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lua-torch-nn/lua-torch-nn_0~20160604-gd23a8f5+dfsg-1.dsc More information about hello can be obtained from https://www.example.com. Changes since the last upload: lua-torch-nn (0~20160604-gd23a8f5+dfsg-1) unstable; urgency=low * Initial release. Closes: #826794 -- Best, Lumin
Bug#827037: RFS: xpad/4.8.0-1 [ITA]
> imagemagick and libmagickcore-extra, can you please provide a > rationale for their removal? these were only there because of 'convert' in d/rules, used for creating an xpm (in turn needed for menu support) out of the upstream svg icon. With all that gone, the build-deps had become useless, guess I could have spelled that out in the changelog though. > btw removing that will probably allow me to do a sync --force in > Ubuntu, because you seem to have incorporated all the Ubuntu delta Feel free to sync this. The entire ubuntu diff was a side effect of their version bump ahead of debian, hence the similarities with the work done here for 4.8.0. I use xubuntu as my primary os, making sure things just work on *buntu is but self interest. Regards ps: please do cc me on replies, as the bts doesn't keep bug submitters in the loop automagically. pgpdlDT7WOTJL.pgp Description: OpenPGP digital signature
Bug#827037: RFS: xpad/4.8.0-1 [ITA]
On Wed, Jun 22, 2016 at 10:30:23AM +0200, JCF Ploemen wrote: > ps: please do cc me on replies, as the bts doesn't keep bug submitters > in the loop automagically. If you subscribe to debian-mentors@lists.debian.org you'll get all the messages. -- Sean Whitton signature.asc Description: PGP signature
Bug#827037: marked as done (RFS: xpad/4.8.0-1 [ITA])
Your message dated Wed, 22 Jun 2016 09:59:22 + (UTC) with message-id <1133882683.12649633.1466589562925.javamail.ya...@mail.yahoo.com> and subject line Re: Bug#827037: RFS: xpad/4.8.0-1 [ITA] has caused the Debian Bug report #827037, regarding RFS: xpad/4.8.0-1 [ITA] 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.) -- 827037: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827037 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 "xpad": Package name: xpad Version : 4.8.0-1 Upstream Author : Michael Terry, Arthur Borsboom URL : https://launchpad.net/xpad License : GPL-3+ Section : x11 It builds a single binary package: xpad - sticky note application for X Mentors URL: https://mentors.debian.net/package/xpad Download with dget: dget -x https://mentors.debian.net/debian/pool/main/x/xpad/xpad_4.8.0-1.dsc Changes since last upload: * New upstream release: (Closes: #805723) (LP: #1525656) + fixes markup issue in russian translation. (Closes: #797630) + fixes moving xpad window rendering the application unresponsive. (Closes: #614337) + includes a configurable wait for the systray. (Closes: #555934) * New maintainer. (Closes: #826924) * Patches: + remove missing.diff, no longer needed. + add 01_fix_typos, 02_add_keywords_to_desktop_file, and 03_preserve_po-Makefile-in-in.diff. * Remove Debian menu support as per #741573. * Control: + add build-depends on libgtk-3-dev, libgtksourceview-3.0-dev, dh-autoreconf. + remove build-depends on libgtk2.0-dev, libmagickcore-extra, autotools-dev, imagemagick. + add VCS links. + change upstream homepage to their launchpad site. * Bump compat and debhelper version to 9. * Docs: don't install AUTHORS, THANKS, TODO (not relevant for end users) or NEWS (superseded by ChangeLog). * Rules: + simplify to just dh sequencer with autoreconf. + enable all hardening. * Copyright: + convert to machine-readable format. + update all upstream info. + add myself as a copyright holder for the packaging. * Bump Standards-Version to 3.9.8 (from 3.9.3; no further changes). Regards. pgpLVwtj7T4hX.pgp Description: OpenPGP digital signature --- End Message --- --- Begin Message --- Hi, >these were only there because of 'convert' in d/rules, used for >creating an xpm (in turn needed for menu support) out of the upstream >svg icon. With all that gone, the build-deps had become useless, guess I >could have spelled that out in the changelog though. wonderful! thanks >Feel free to sync this. The entire ubuntu diff was a side effect of >their version bump ahead of debian, hence the similarities with the >work done here for 4.8.0. I use xubuntu as my primary os, making sure >things just work on *buntu is but self interest. I uploaded on unstable some seconds ago, and uploaded on Ubuntu versioned 4.8.0-1~build1, so it will be syncd automatically tonight! thanks for the hard work you did! Gianfranco--- End Message ---
Bug#827907: RFS: evil/1.2.12-1 ITP
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "evil" * Package name: evil Version : 1.2.12-1 Upstream Author : Vegard Ãye * Url : https://bitbucket.org/lyro/evil/wiki/Home * Licenses: GFDL-1.3+, GPL-3+ Section : lisp It builds those binary packages: elpa-evil -- extensible vi layer for Emacs To access futher information about this package, visit the following URL: http://mentors.debian.net/package/evil Alternatively, one can download the package with dget using this command: http://mentors.debian.net/debian/pool/main/e/evil/evil_1.2.12-1.dsc Alternatively, you can access package debian/ directory via git from URL: https://anonscm.debian.org/git/pkg-emacsen/pkg/evil.git More information about evil can be obtained from https://bitbucket.org/lyro/evil/wiki/Home Changes since last upload: * Initial release. (Closes: #827897) Regards, Dmitry Bogatov
C++ help needed for libsmithwaterman
Hi, I need to package libsmithwaterman[1] as a pre-pre-dependency for some Debian Med package. The code comes with a manually crafted Makefile that simply creates an executable while the pre-depencency of my package[2] needs a devel package (tries to include one of the contained headers SmithWatermanGotoh.h). I considered it the easiest way to build the lib by adding configure.ac and Makefile.am as quilt patch and use autoconf which does at least to the point where some C++ error stops the build (due to stricter compile options). Any hint how to fix: ... libtool: compile: g++ -DHAVE_CONFIG_H -I. -I. -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -c SWMain.cpp -fPIC -DPIC -o .libs/libsmithwaterman_la-SWMain.o SWMain.cpp: In function ‘int main(int, char**)’: SWMain.cpp:92:77: error: no matching function for call to ‘CSmithWatermanGotoh::Align(unsigned int&, std::__cxx11::string&, const char*&, const unsigned int&, const char*&, const unsigned int&)’ sw.Align(referenceSW, cigarSW, pReference, referenceLen, pQuery, queryLen); ^ In file included from SWMain.cpp:6:0: SmithWatermanGotoh.h:28:10: note: candidate: void CSmithWatermanGotoh::Align(unsigned int&, std::__cxx11::string&, const string&, const string&) void Align(unsigned int& referenceAl, string& cigarAl, const string& s1, const string& s2); ^ SmithWatermanGotoh.h:28:10: note: candidate expects 4 arguments, 6 provided SWMain.cpp:93:84: error: no matching function for call to ‘CBandedSmithWaterman::Align(unsigned int&, std::__cxx11::string&, const char*&, const unsigned int&, const char*&, const unsigned int&, std::pair, std::pair >&)’ bsw.Align(referenceBSW, cigarBSW, pReference, referenceLen, pQuery, queryLen, hr); ^ In file included from SWMain.cpp:7:0: BandedSmithWaterman.h:35:7: note: candidate: void CBandedSmithWaterman::Align(unsigned int&, std::__cxx11::string&, const string&, const string&, std::pair, std::pair >&) void Align(unsigned int& referenceAl, string& stringAl, const string& s1, const string& s2, pair< pair, pair >& hr); ^ BandedSmithWaterman.h:35:7: note: candidate expects 5 arguments, 7 provided Makefile:604: recipe for target 'libsmithwaterman_la-SWMain.lo' failed would be welcome. Bonus points for verifying my probably weak autoconf stuff. :-) Thanks for your time Andreas. [1] https://anonscm.debian.org/git/debian-med/libsmithwaterman.git [2] https://anonscm.debian.org/git/debian-med/libvcflib.git -- http://fam-tille.de
Re: C++ help needed for libsmithwaterman
Hi, On Wed, Jun 22, 2016 at 7:22 PM, Andreas Tille wrote: [snip] > [1] https://anonscm.debian.org/git/debian-med/libsmithwaterman.git It's broken, did you forget to push this repository ? Best regards, Neutron Soutmun
Re: C++ help needed for libsmithwaterman
On Wed, Jun 22, 2016 at 7:37 PM, Neutron Soutmun wrote: > Hi, > > On Wed, Jun 22, 2016 at 7:22 PM, Andreas Tille wrote: > [snip] >> [1] https://anonscm.debian.org/git/debian-med/libsmithwaterman.git > > It's broken, did you forget to push this repository ? A few minutes later, it's valid. Sorry for the noise.
Re: [Debian-med-packaging] C++ help needed for libsmithwaterman
Hello Andreas, Am Mittwoch, den 22.06.2016, 14:22 +0200 schrieb Andreas Tille: > Hi, > > I need to package libsmithwaterman[1] as a pre-pre-dependency for > some Debian Med package. The code comes with a manually crafted > Makefile that simply creates an executable while the pre-depencency > of my package[2] needs a devel package (tries to include one of the > contained headers SmithWatermanGotoh.h). For this one should probably add installation of the header files :) Since the header file in question includes other headers of the project it might be best to put the header files into a sub-directory and also create a pkg-config file. I'll see what I can do to add these things, I expect to push this later today or tomorrow. > I considered it the easiest way to build the lib by adding > configure.ac and Makefile.am as quilt patch and use autoconf which > does at least to the point where some C++ error stops the build (due > to stricter compile options). Any hint how to fix: Actually, the original Makefile doesn't touch the offending file SWMain.cpp, which means you just shouldn't compile it at all. It also doesn't make much sense to add into the library since it defines a main function. best, Gert
Bug#827082: RFS: libredjackipset/1.1.1+20150311-1 [ITP] -- C library to store sets/maps of IP address
Dear G,
Thanks for your review!
I updated the package.
On Wed, Jun 22, 2016 at 1:28 AM, Gianfranco Costamagna
wrote:
>>So I used the same way in libcork to generate docs.
>>Actually the upstream was during the transition from sphinx to pandoc.
>>They removed sphinx setting, added pandoc setting, but didn't remove
>>sphinx docs.
>>So I patched back sphinx setting, just works.
>>
>>(docs from upstream just poor, even I wrote a patch to add index page)
>
>
> I was already ok with the patch, just adding some Description makes the
> review easier ;)
Thanks!
My additional description already added since previous update.
>>After reading your comment for three time, now I understand it.
>>I put it under dh_install as you recommend.
>>Now it's rebuildable.
>
> :)
>
>>Without "--builddirectory=build", the docs will be built under
>>/docs/
>>This make install file hard to write.
>>So here I keep as it was.
>
> mmm strange...
> this is what I have in the docs file
> cat debian/libcorkipset-doc.docs
> build-*/docs/html
Debian builds obj- by default.
So it seems to specify "--builddirectory=build" safe for both debian and ubuntu.
>>Since the most authors quit redjack, and they're almost not active,
>
>>I consider it should be called libcorkipset.
>
> I see activity upstream, lets wait for the rename to be effective then!
Yes, upstream just don't like calling it libredjackipset.
They seems fine with libcorkipset, but proposed another option: libipaddrset
I don't like the latter one because the header will be installed to
/usr/include/libipaddrset/ipset.h
and user need to "#include "
I think "#include " makes more sense.
>>> "set(CMAKE_INSTALL_LIBDIR lib${LIB_SUFFIX} CACHE STRING"
>>> note the LIB_SUFFIX
>>>
>>> and then the install files can change from
>>> usr/lib/lib*.so usr/lib/${DEB_HOST_MULTIARCH}
>>> to
>>> usr/lib/*/*.so
>>> and similar for others
>>
>>Yes, moving "include(GNUInstallDirs)" makes dh-exec useless.
>>My mistake forced me to introduced this complex. Sorry about that.
>
>
> the missing LIB_SUFFIX makes it FTBFS on Ubuntu, where cmake has a little
> different implementation.
>
> (and a non-defined variable is just a no-op in Debian)
"LIB_SUFFIX" is added to patch.
Takes you time and thanks again!
Cheers,
--
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: [Debian-med-packaging] C++ help needed for libsmithwaterman
Am Mittwoch, den 22.06.2016, 14:54 +0200 schrieb Gert Wollny: > I'll see what I can do to add these things, I expect to push this > later today or tomorrow. Later as in: "I just did it" :)
Re: [Debian-med-packaging] C++ help needed for libsmithwaterman
On Wed, Jun 22, 2016 at 03:04:06PM +0200, Gert Wollny wrote: > > I'll see what I can do to add these things, I expect to push this > > later today or tomorrow. > > Later as in: "I just did it" :) Muchas gracias. Thanks for the very quick help Andreas. -- http://fam-tille.de
Bug#827913: RFS: goto-chg/1.6-1 ITP
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "goto-chg" * Package name: goto-chg Version : 1.6-1 Upstream Author : David Andersson * Url : https://www.emacswiki.org/emacs/goto-chg.el * Licenses: GPL-2+ Section : lisp It builds those binary packages: elpa-goto-chg -- navigate the point of the most recent edit in the buffer To access futher information about this package, visit the following URL: http://mentors.debian.net/package/goto-chg Alternatively, one can download the package with dget using this command: http://mentors.debian.net/debian/pool/main/g/goto-chg/goto-chg_1.6-1.dsc Alternatively, you can access package debian/ directory via git from URL: https://anonscm.debian.org/git/pkg-emacsen/pkg/goto-chg.git More information about goto-chg can be obtained from https://www.emacswiki.org/emacs/goto-chg.el Changes since last upload: * Initial release. (Closes: #827910) Regards, Dmitry Bogatov
Bug#827082: RFS: libredjackipset/1.1.1+20150311-1 [ITP] -- C library to store sets/maps of IP address
Hi Roger
>> cat debian/libcorkipset-doc.docs
>> build-*/docs/html
>
>Debian builds obj- by default.
>So it seems to specify "--builddirectory=build" safe for both debian and
>ubuntu.
yes, but useless...
maybe you didn't get completely the hint, but my guess was:
remove the --builddirectory stuff
and change
build/docs/html
to
build-*/docs/html
probably this sounds stupid/nitpick to you, but allows
people to easily cross-compile stuff, or to compile the library for
both amd64 and i386 without having to choose one or the other.
that triplet is trivial, and makes less confusion to porters
or even developer, who might want to build it on their own laptop
and use on different architectures.
(note: this isn't a blocker)
>Yes, upstream just don't like calling it libredjackipset.
>They seems fine with libcorkipset, but proposed another option: libipaddrset
I'll wait for them make a decision then
>I don't like the latter one because the header will be installed to
>/usr/include/libipaddrset/ipset.h
>and user need to "#include "
>
>I think "#include " makes more sense.
just explain that upstream :)
I honestly don't care too much, but I want to use the name that upstream choose
to avoid overcomplicate things in the long run
>"LIB_SUFFIX" is added to patch.
bad me, it didn't work :(
the patch wasn't correct, because the variable gets overridden anyway on the
following line.
I tweaked the patch, to do something like
+if(NOT CMAKE_INSTALL_LIBDIR)
+set(CMAKE_INSTALL_LIBDIR lib CACHE STRING
+ "The base name of the installation directory for libraries")
+endif(NOT CMAKE_INSTALL_LIBDIR)
otherwise no matter who sets it, it gets defaulted to what upstream thinks it
is better for everybody.
BTW I can't run dpkg-buildpackage twice, because a "RELEASE-VERSION" file is
added to the source
tree
echo RELEASE-VERSION > debian/clean might just fix that
so, please consider applying my above fixes, and ask me to sponsor&upload&review
when upstream releases a new fixed renamed tarball
(this should even avoid your dh_install override if I'm correctly understanding
it)
GianfrancoFrom: Roger Shimizu
Date: Sat, 11 Jun 2016 23:37:44 +0900
Subject: add library multi-arch support
Followed the instruction:
https://wiki.debian.org/Multiarch/Implementation#CMake
---
CMakeLists.txt | 4 +++-
include/CMakeLists.txt | 2 +-
src/ipset.pc.in| 4 ++--
3 files changed, 6 insertions(+), 4 deletions(-)
--- libcorkipset-1.1.1+20150311.orig/CMakeLists.txt
+++ libcorkipset-1.1.1+20150311/CMakeLists.txt
@@ -78,8 +78,12 @@ if(NOT CMAKE_BUILD_TYPE)
FORCE)
endif(NOT CMAKE_BUILD_TYPE)
-set(CMAKE_INSTALL_LIBDIR lib CACHE STRING
-"The base name of the installation directory for libraries")
+include(GNUInstallDirs)
+
+if(NOT CMAKE_INSTALL_LIBDIR)
+set(CMAKE_INSTALL_LIBDIR lib CACHE STRING
+ "The base name of the installation directory for libraries")
+endif(NOT CMAKE_INSTALL_LIBDIR)
if(CMAKE_C_COMPILER_ID STREQUAL "GNU")
add_definitions(-Wall -Werror)
diff --git a/include/CMakeLists.txt b/include/CMakeLists.txt
index d1e4a7d..097b775 100644
--- a/include/CMakeLists.txt
+++ b/include/CMakeLists.txt
@@ -8,5 +8,5 @@
# --
install(DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/
-DESTINATION include
+DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}"
FILES_MATCHING PATTERN "*.h")
diff --git a/src/ipset.pc.in b/src/ipset.pc.in
index 47a6637..0f8fd84 100644
--- a/src/ipset.pc.in
+++ b/src/ipset.pc.in
@@ -1,7 +1,7 @@
prefix=@prefix@
exec_prefix=${prefix}
-libdir=${exec_prefix}/lib
-includedir=${prefix}/include
+libdir=${exec_prefix}/@CMAKE_INSTALL_LIBDIR@
+includedir=${prefix}/@CMAKE_INSTALL_INCLUDEDIR@
sharedir=${prefix}/share
sphinxdir=${sharedir}/doc/libcorkipset-doc/html
Bug#827700: RFS: cplay/1.50-1 [NMU]
On Wed, Jun 22, 2016 at 10:10:37AM +0200, Tobias Frost wrote: > > I'm ccing them both, and a member of MIA team, even if I'm unsure about the > > MIA process for non DD people, > > MIA Team is also handling non-DD, so I'm on it already. BTW, the maintianer *is* a DD (the comaintainer is not). And the MIA process is not "just" about orphaning packages, but also making sure whether the involved person is still interested in being part of the project. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#827924: RFS: cplay/1.50-1 [QA] [RC]
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "cplay" * Package name: cplay Version : 1.50-1 Upstream Author : Tomi Pieviläinen * URL : https://github.com/hukka/cplay * License : GPL-2 Section : sound It builds those binary packages: cplay - A front-end for various audio players To access further information about this package, please visit the following URL: https://mentors.debian.net/package/cplay Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/cplay/cplay_1.50-1.dsc More information about cplay can be obtained from https://github.com/hukka/cplay. Changes since the last upload: * QA upload. * New upstream release (Closes: #279000, #375060, #413738) * Converted to quilt (3.0) (Closes: #664311) * Updated debhelper level to 9 (Closes: #817410, #808639) * Updated standards version to 3.9.8 * Updated menu file * Updated watch file (Closes: #449776, #691239) * Refreshed patches and removed if included upstream * Converted copyright to DEP-5 Regards, David William Richmond Jones
Becoming a Debian Maintainer - and behavior of DDs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, About 1.5-2 years ago I started working on Debian-HA. The project had been abandoned by Martin (as he works on other packages, and mainly Ubuntu last I recall), and I pursued getting involved and getting things started. I quickly got admitted to Alioth as an admin, and began getting things in order. I reached out to old devs, joined upstream, got IRC going, built us a wiki, and updated alioth (lists, etc). There was another contributor looking to get involved, Ferenc Wagner, though he only got involved after I started emailing, fixing up alioth, working on the software stack the team maintains, and found a sponsor for the team (prior to Christoph Berg joining us). After a week or so, Christoph Berg and 4 others joined the fray under the premise that his company was sponsoring them to work with the team on the software stack. Fast Forward a couple weeks - Ferenc suddenly disappears for 3 months after Christoph originally shut down a seemingly endless restructuring of Git repositories, claiming that he did not care for bike-shedding. In that time I not only finished the package I was working on, but I prepared LibQB, Pacemaker, Corosync, crmsh, pcs, the ruby packages, and more - asked for review and for other members to help contribute and potentially sponsor the uploads. I contribute upstream, am active in clusterlabs, and I even have a private ppa for hosting the stack unofficially, and I've been hounded by countless end-users to put it back up when it goes down. My mother even gets phone calls from Germany in that regard. During that time I worked with Christoph Berg, he advised not to play with repository structure too much - and asked that I didn't do more than I had to to get the stack working again. Next Ferenc comes into the fray again, upset that I had backed up the old corosync repository (thus removing the glorious contributions of previous contributors according to Ferenc - though I did reuse their changelog so only git history resided elsewhere, not that it was deleted) and created a new one (seeing as how upstream uses git now instead of mercurial, beyond other factors such as that we were standardizing our team). Ferenc disregards all my work and makes his own repository on github (instead of contributing to the team repository) so that he can structure branches how he wants and move to DEP-14 (I was never opposed to that, but its exactly what Christoph asked me not to do when I suggested it based off of conversations I had with Ferenc) - and after Christoph states that he doesn't care for bike-shedding and had been working with me already on some of the packages along with Adrian; he reneged with regard to Ferenc's new repository (which was now missing all of my changelog entries which cataloged my contributions to the package, the very thing I didn't do - but which Ferenc complained about himself). I spoke with Christoph about it, asking why he disregarded my work, why he allowed Ferenc to remove my changelog entries - he apologized and stated that he'd pay better attention next time. He had a sudden changing of mind though after Debconf. Yes, after Debconf Christoph's whole demeanor towards me changed; He blatantly started uploading each and every one of Ferenc's packages, 'mindfully' attempting to accept the ruby packages I worked on - I'm guessing to try to make me feel better and shut me up. And all he had to offer was a 'Sorry if your changelog entries got removed'. Sure I was still in the uploaders field or whatever, but the changes I made to code were no longer noted. I had also asked Christoph to advocate me as a maintainer 6-8 months prior to now, which was already almost a year after I had started working with the Debian-HA packages. He told me he'd consider it after the stack was done. He advocated for Ferenc very shortly after Debconf, far before the stack is complete (it still isnt complete even) - only a month or two later. Now, months after that, Christoph is advocating Ferenc as a DD. All the packages I've helped with, get uploaded almost as soon as Ferenc does a 'final' check-in. My work non-existent and/or removed, or left there but it is obvious that Ferenc is the final factor in Christoph's mind. If you cannot tell, this is a play of favoritism, and isn't right. Christoph was setting him up with history (by only uploading his work and ignoring mine and others) so he could exaggerate his contributions and quickly help him to promote to DD. In his advocacy for Ferenc, Christoph makes it appear as if Ferenc did all that work himself - though he most certainly did not. Countless months did Adrian and I work on those softwares in the stack, and I feel that I at least am being slapped in the face. Adrian - however - was advocated by Christoph very near the same time as Ferenc. Christoph is now lying to me, trying to say that I misread what he told me and that he
Bug#827933: RFS: yabar/0.4.0-1 [ITP]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "yabar" * Package name: yabar Version : 0.4.0-1 Upstream Author : George Badawi * URL : https://github.com/geommer/yabar * License : Expat Section : misc It builds those binary packages: yabar - Modern and lightweight status bar for X window managers To access further information about this package, please visit the following URL: https://mentors.debian.net/package/yabar Alternatively, one may download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/y/yabar/yabar_0.4.0-1.dsc For more information about yabar, please visit the project homepage: https://github.com/geommer/yabar Best Regards, Jack Henschel -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJXav2cAAoJEFeR0PrOCvA84WIP/jRAckqAcaY/Xh2c3vup7Zyv hnL/PIpGDWVRbaD3mOWwct9f0dBI3Mx/3YtiKHUjjGfo/0ib9OxRTjJ8HPVsSLg9 tqdGC0LoAULiAv1j9/+plx0wOpBhAvOk/xpj2ZVQLbhrSrTZmvgXcUUpVUO1SFwn BsjcnK+o++5weEh+WH0CtUnBgjlPo4CVENmP6pEzzoJK7bL4OyqyRheG+WOYuwjO 1swYwRhtPloSYlv0s/SJ/ja1SEeHwW1SMNYXRacmqz9l4xWaUEEflfzq2jAHewd0 xcU0iPzfDMm1jJYKp48kQwKVA+iQNrPFV2XPNbtJJzC5uXN8Tk64nWCYpjka87cO QObF7eDgEBmkYVSp04wBznZPfl2OgQrwdLXfIJoZiiMQjMu95WgLyVcOV+mGcE1d CpwU87V92C0N4jPB+BXzpERfzzrMchq/Q8X/lupydLbSi54caKrYMQrZfit/6fnm y1dKjqBov0aNTkWuy5FEuYdatMCQ4ntBecIm565CUwXVotAj0C4DvQWUpQQ2SB8l NKH5DAYAbLa7pa3DnoojdAvDmyQ7viZ2+BauZtGsPeSwS9Vjchfpja2RJ8SOvgAk cRHvAYI4ndfvGn0k/qpxT1/DVhWBBWi7ginvzY/jMhlsl2zhjbHVmKa7GzSX7sMa IVeWwZtCqjaBHxeoe4j2 =505N -END PGP SIGNATURE-
Re: Becoming a Debian Maintainer - and behavior of DDs
[tl;dr: Richard is disappointed that I didn't advocate him for DM, while I did advocate other team members shortly after.] Hi Richard, Re: Richard B Winters 2016-06-22 <204e2c0e01254a766699d615036d2...@mail.mmogp.com> > During that time I worked with Christoph Berg, he advised not to play with > repository structure too > much - and asked that I didn't do more than I had to to get the stack working > again. I didn't recommend any particular repository structure. What I did recommend was not to bikeshed about that, stop discussing the layout, and start the real work. > Ferenc disregards all my work and makes his own repository on github (instead > of contributing to > the team repository) so that he can structure branches how he wants and move > to DEP-14 (I was never > opposed to that, but its exactly what Christoph asked me not to do when I > suggested it based off of > conversations I had with Ferenc) - and after Christoph states that he doesn't > care for > bike-shedding and had been working with me already on some of the packages > along with Adrian; he > reneged with regard to Ferenc's new repository (which was now missing all of > my changelog entries > which cataloged my contributions to the package, the very thing I didn't do - > but which Ferenc > complained about himself). It was suboptimal that Feri's changes were often staged elsewhere, but this was communicated, and I think now everything relevant is on git.debian.org. > Yes, after Debconf Christoph's whole demeanor towards me changed; He > blatantly started uploading > each and every one of Ferenc's packages, 'mindfully' attempting to accept the > ruby packages I > worked on - I'm guessing to try to make me feel better and shut me up. And > all he had to offer was Sorry if uploading your packages was wrong. Would it have been better to not do anything? At that point, corosync and pacemaker were the next packages in the stack that needed to be done. "Your" pcs and crmsh packages were due after that. That was the reason for the ordering. > a 'Sorry if your changelog entries got removed'. Sure I was still in the > uploaders field or > whatever, but the changes I made to code were no longer noted. I don't fancy changelog bikeshedding. All your changes made it into the next package, though possibly after re-re-rebasing them through whatnot git operations, the changelogs were a mess. I'd care more about getting the problems fixed. > I had also asked Christoph to advocate me as a maintainer 6-8 months prior to > now, which was > already almost a year after I had started working with the Debian-HA > packages. He told me he'd > consider it after the stack was done. He advocated for Ferenc very shortly > after Debconf, far > before the stack is complete (it still isnt complete even) - only a month or > two later. Now, months > after that, Christoph is advocating Ferenc as a DD. Richard I'm sorry to have to say that: You were not ready to be advocated for DM, while Ferenc was. I like mumbled something like "later" when you asked me about it. I should have been more explicit about this. > If you cannot tell, this is a play of favoritism, and isn't right. Christoph > was setting him up > with history (by only uploading his work and ignoring mine and others) so he > could exaggerate his > contributions and quickly help him to promote to DD. In his advocacy for > Ferenc, Christoph makes it > appear as if Ferenc did all that work himself - though he most certainly did > not. Countless months > did Adrian and I work on those softwares in the stack, and I feel that I at > least am being slapped > in the face. Adrian - however - was advocated by Christoph very near the same > time as Ferenc. I've never said anywhere that Ferenc did all work there. I did say though that he did excellent work. That's a fine difference. > I continued to discuss this with Myon and he goes as far as to type 'stop > yelling', 'I'm more than > happy to have you on the team but...' Almost as if he's threatening to remove > me from Alioth and > kick me off the team if I pursue this. Meanwhile, the only all-caps words in > IRC were from > Christoph (Myon). I'll post our conversation from today [1], but please note > that I do get he doesnt > _have_ to advocate me - not as a DM or DD. But playing favorites and lying is > not really - in my > mind - the thing a DD (or any Debian Contributor) should be doing. The all caps part was when you insisted that you were removed from the Uploaders fields and wouldn't listen to me trying to tell you that this was just wrong. You have been in the Uploaders fields of all relevant packages all the time. Christoph signature.asc Description: PGP signature
Bug#827037: RFS: xpad/4.8.0-1 [ITA]
Hi, I didn't have time to thank you for your work on this :-) I done just a little maintenance on xpad, so I'm very happy to see a new maintainer for it :-) Regards, Julien Lavergne 2016-06-22 8:30 GMT+02:00 Gianfranco Costamagna : > control: tags -1 pending > >> control: tag -1 +confirmed > > Hi Sean, thanks for the really nice review! > > I did sponsor on deferred/5, because I would like to have a feedback about > the following > >>+ remove build-depends on libgtk2.0-dev, libmagickcore-extra, >> autotools-dev, imagemagick. > > > mmm why? I mean imagemagick and libmagickcore-extra, can you please provide a > rationale for > their removal? > I don't see a bug or a removal request, so I would like to be sure about that > > btw removing that will probably allow me to do a sync --force in Ubuntu, > because you seem to have > incorporated all the Ubuntu delta here > https://bugs.launchpad.net/ubuntu/+source/xpad/+bug/635871 > > Did you check the delta too? > https://patches.ubuntu.com/x/xpad/xpad_4.5.0-0ubuntu1.patch > > it might be nice to see if they have other fixes... > > thanks for your hard work! > > BTW I also think somebody will thanks you for the work you did :) > https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2016-June/016626.html > > I didn't update it just because I didn't find the orphan bug > (ccing gilir, he might want to give an additional review here, even if the > package is already on its > way for unstable) > > Gianfranco >
Bug#814859: RFS: runescape/0.1-1 [ITP] -- Set in a fantasy world of war, landscapes and sinister powers
Hi, Added the "metadata" in d/upstream Made to create a makefile. :/ but why? Sorry, I do not have programming skills in C and makefile. The source code is on github for those who want to improve it in the future. Thanks! Em 20-06-2016 10:34, Gianfranco Costamagna escreveu: Hi, Corrected the dependencies in d/control ack Made to create a makefile. :/ but why? [Sergio Durigan Junion] metadata stuff Sergio is correct, thanks! anyway, it seems working, so please answer the above and I'll do the final checks and hopefully upload. G. -- Carlos Donizete Froes [a.k.a coringao] - https://wiki.debian.org/coringao GPG: 4096R/B638B780 2157 630B D441 A775 BEFF D35F FA63 ADA6 B638 B780
