Re: FTBFS: how to test fixes
hi, On 09/05/2016 09:11 PM, Christian Seiler wrote: > On 09/05/2016 08:59 PM, Muri Nicanor wrote: >> On 09/05/2016 08:33 PM, Christian Seiler wrote: >>>Since you depend on systemd.pc, which is part of the >>>systemd package, just Build-Depend on systemd to make >>>systemd.pc available. You won't need porterbox access >>>to fix that issue. (Btw. libsystemd.pc != systemd.pc) >> >> ah, that comment in paranthesis helped me to understand the problem ;) i >> was looking at the wrong package and was wondering what to do, because >> there is no official libsystemd-dev package for hppa. thanks for >> pointing that out! ;) > > Huh? There is libsystemd-dev on hppa, it's just out of date > at the moment: ah, yeah- in addition, i looked in the wrong place: https://packages.debian.org/search?searchon=contents&keywords=systemd.pc&mode=path&suite=stable&arch=any ;) cheers and thanks for all the help! -- muri signature.asc Description: OpenPGP digital signature
Bug#836316: marked as done (RFS: glbinding/2.1.1-1 [ITP])
Your message dated Tue, 06 Sep 2016 04:33:29 + with message-id and subject line closing RFS: glbinding/2.1.1-1 [ITP] has caused the Debian Bug report #836316, regarding RFS: glbinding/2.1.1-1 [ITP] 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.) -- 836316: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836316 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "glbinding" * Package name: glbinding Version : 2.1.1-1 Upstream Author : CG Internals * URL : https://github.com/cginternals/glbinding * License : Expat Section : libs It builds those binary packages: glbinding-doc - documentation for glbinding glbinding-tools - command-line tools for glbinding libglbinding-dev - development files for glbinding libglbinding2 - cross-platform C++ binding for OpenGL To access further information about this package, please visit the following URL: https://mentors.debian.net/package/glbinding Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/glbinding/glbinding_2.1.1-1.dsc Successful build on debomatic: http://debomatic-amd64.debian.net/distribution#unstable/glbinding/2.1.1-1/buildlog Changes since the last upload: * Initial release. (Closes: #834825) Regards, Ghislain Vaillant --- End Message --- --- Begin Message --- Package glbinding version 2.1.1-1 is in unstable now. https://packages.qa.debian.org/glbinding--- End Message ---
Bug#777651: RFS: syncterm/1.0+dfsg-1 [ITP]
El 16/08/16 a las 09:15, Gianfranco Costamagna escribió:
> control: tags -1 moreinf
>
> Hi,
>
>>* Initial release (Closes: #739035)
> lets try a review:
Hi gianfranco! lets go:
>
> 1) std-version is 3.9.8 now
fixed.
>
> 2) debhelper (>= 9), libncurses5-dev (>= 5.9),
> unzip (>= 6.0), libsdl2-dev (>= 2.0.2), libsdl1.2-dev (>= 1.2.15),
> gcc (>= 4:4.9)
>
>
> do you really need both sdl1.2 and sdl2?
> do you really need the version constraints for each dependency?
> why gcc is listed here?
> please drop versions when already satisfied in jessie, or wheezy in case you
> want to try
> a backport-sloppy (I would really avoid that)
remove gcc,
let sdl 1.2 (remove unused sdl2)
update versions from unstable
fixed.
>
> 3)
> Architecture: i386 amd64
> Depends: ${shlibs:Depends}, ${misc:Depends}, libncurses5 (>= 5.9),
> libsdl2-2.0-0 (>= 2.0.2), libsdl1.2debian (>= 1.2.15)
>why only two architectures? why aren't the runtime dependencies picked up with
>shlibs:Depends?
> ldd debian/syncterm/usr/bin/syncterm
> linux-vdso.so.1 => (0x7ffeca745000)
> libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7efc98d79000)
> libncurses.so.5 => /lib/x86_64-linux-gnu/libncurses.so.5
> (0x7efc98b57000)
> libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5
> (0x7efc9892d000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7efc98729000)
> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7efc9842)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x7efc98202000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7efc97e39000)
> /lib64/ld-linux-x86-64.so.2 (0x560b91261000)
>
>
> at least they seems to be mostly not linked at runtime.
fixed.
i only can test in these archs, but i changed it to => any
>
> 4) rules: to understand the platform you are building, I suggest to use
> dpkg-architecture
> dpkg-architecture -qDEB_TARGET_*
>
im cleanup the code and use dpkg-architecture now. Great!
fixed
> 5) override_dh_strip:
> dh_strip --dbg-package=syncterm-dbg
>
>
> please avoid dbg packages, they are auto generated now
true! i remove it. fixed
>
>
> 6) ls src/
> build comio conio sbbs3 smblib syncterm uifc xpdev
>
> some (most) of them looks like embedded libraries
it's part of uptream source. can i do something to make it better?
>
> 7) disabled_cryptlib needs to end in .patch (also in series file you should
> change it)
fixed.
> ---
> The information above should follow the Patch Tagging Guidelines, please
> checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
> are templates for supplementary fields that you might want to add:
>
> this seems useless
fixed too
>
> 8) the license is non dfsg
>
> The files sbbs3/zmodem.h and sbbs3/zmodem.c are derived from the
> zmtx/zmrx package available at
> ftp://ftp.netsw.org/net/modem/protocols/zmodem/zmtx-zmrx/
> .
> The licence contained in the archive is:
> .
> MCS allows you to use and copy/modify this source under the following
> conditions:
> .
> - MCS or Jacques Mattheij shall not be liable for any damages arising
> from the use of this code
> - the archive must be distributed as a whole leaving version numbers intact.
> please do not distribute modifications; mail them back to us for inclusion
> in the next release which should follow each other fairly quickly in
> the beginning
> - you will not use this software for commercial purposes.
> (commercial licenses are available contact us for info)
> .
> As such, this program may not be redistributable. YOU HAVE BEEN WARNED!
> .
> If anyone can put me (sh...@sasktel.net) in contact with the authours,
> that would be greatly appreciated.
>
this was fixed.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777651#57
You can check the zmodem.* header file on cvs
http://cvs.synchro.net/cgi-bin/viewcvs.cgi/src/sbbs3/zmodem.h?revision=1.54&view=markup
Unfortunately, this was after 1.0 release date, and it was made through
my work to contact everyone involved and good response from them.
>
> 9) LGPL with no versioning is wrong.
fixed
>
> 10) many missing licenses: e.g. BSD-4-clause
> 11) many missing copyrights, e.g.
> grep copyright . -Ri
>
> stopping here the review, because of 8, that needs to be fixed upstream I
> think
>
I think that can parse file by file to fine copyright settings.
i update it, please check,
I want to the package fit the debian legal requeriments, the code is
gpl, lgpl and some files bsd. i think that all are dfsg
The non-dfsg part was cryplib and was removed via patch (the app can be
used without that lib)
> automatic checks from check-all-the-things:
>
> $ env PERL5OPT=-m-lib=. cme check dpkg
> [lots]
> $ codespell --quiet-level=3
> [lots]
> $ cppcheck -j1 --quiet -f .
> [lots]
> $ find -type f -iname '*.desktop' -exec desktop-file-validate {} \;
> [some]
> $ fdupes -q -r . | gre
Re: Advices for packaging a daemon of galileo
Dylan writes: > Some users request the possibility to install galileo as a daemon. I > do not want to run galileo as a daemon for my own use. So, I created a > new binary package "galileo-daemon" which configure galileo as a > daemon. Thank you for working to improve the package. Could you instead have the existing ‘galileo’ package install the SystemD service, but not activate it? That way, anyone who installs ‘galileo’ can choose whether to enable the service. You could describe how to do that in the ‘README.Debian’ document. -- \ “As scarce as truth is, the supply has always been in excess of | `\ the demand.” —Josh Billings | _o__) | Ben Finney
Advices for packaging a daemon of galileo
Hi, Galileo [1] is a python utility to securely synchronize a Fitbit device with the Fitbit web service. Some users request the possibility to install galileo as a daemon. I do not want to run galileo as a daemon for my own use. So, I created a new binary package "galileo-daemon" which configure galileo as a daemon. This new package installs a systemd service file and a new udev rule to run galileo as a daemon. This new rule overrides the previous one (with a higher priority). And finally, it creates a new specific user to run the daemon. Since I do not have previous experience with daemon, I would like to have some comments/advices on my package [2]. Thank you. Best regards, Dylan [1] https://tracker.debian.org/pkg/galileo [2] https://anonscm.debian.org/git/debian-med/galileo.git/commit/?id=919e32cc9
Re: FTBFS: how to test fixes
On 09/05/2016 08:59 PM, Muri Nicanor wrote: > On 09/05/2016 08:33 PM, Christian Seiler wrote: >>Since you depend on systemd.pc, which is part of the >>systemd package, just Build-Depend on systemd to make >>systemd.pc available. You won't need porterbox access >>to fix that issue. (Btw. libsystemd.pc != systemd.pc) > > ah, that comment in paranthesis helped me to understand the problem ;) i > was looking at the wrong package and was wondering what to do, because > there is no official libsystemd-dev package for hppa. thanks for > pointing that out! ;) Huh? There is libsystemd-dev on hppa, it's just out of date at the moment: https://packages.debian.org/unstable/libsystemd-dev (231-3 instead of 231-5) Note that hppa is a non-official port, so e.g. rmadison won't show it. See: https://www.ports.debian.org/ + the systemd directory in the hppa ports pool: http://ftp.ports.debian.org/debian-ports/pool-hppa/main/s/systemd/ Regards, Christian
Re: FTBFS: how to test fixes
Hi, On 09/05/2016 08:33 PM, Christian Seiler wrote: > On 09/05/2016 07:20 PM, Andrey Rahmatullin wrote: >> On Mon, Sep 05, 2016 at 07:07:51PM +0200, Muri Nicanor wrote: >>> so, i've got my first two FTBFS bugs (on mips and hppa)- what the >>> recommended way of testing fixes for architectures i don't have >>> testmachines of? >> Porterboxes. See https://dsa.debian.org/doc/guest-account/ about getting >> access for non-DDs. > > Note that there are no official hppa porterboxes. You can ask on > the debian-hppa mailing list for access to an unofficial one > though. > > But speaking of the bugs, they don't actually require porterbox > access. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836713 > >The hppa build chroots don't have systemd installed (for >whatever reasaon), in contrast to chroots on most other >architectures. > >Since you depend on systemd.pc, which is part of the >systemd package, just Build-Depend on systemd to make >systemd.pc available. You won't need porterbox access >to fix that issue. (Btw. libsystemd.pc != systemd.pc) ah, that comment in paranthesis helped me to understand the problem ;) i was looking at the wrong package and was wondering what to do, because there is no official libsystemd-dev package for hppa. thanks for pointing that out! ;) >Also note that there are plans to make init non-Essential >in the future, so more build chroots will not have >systemd preinstalled in them, so the problem you're seeing >on hppa now is going to be a problem on all archs sooner >or later. ok, thanks for the hint! > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836712 > >MIPS (at least 32bit) doesn't support 64bit atomic >operations intrinsically (_8 == 8 bytes) - and your software >uses std::atomic (found that by grepping). > >However, gcc provides an emulation library called libatomic. >You should link against that emulation library if present >in order to use those intrinsics. aha, thanks for the explanation! that makes the situation a lot clearer. >I've attached a patch against your package (add it as a quilt >patch) that checks for the availability of libatomic and adds >it to the linker flags. This might result in a spurious >dependency on libatomic on other platforms, but unfortunately >I don't know of any way to properly pass --as-needed for just >this library without libtool reordering the entire list of >linker flags. :-( thanks a lot! i'll integrate that asap and relay it to upstream. cheers, -- muri signature.asc Description: OpenPGP digital signature
Re: FTBFS: how to test fixes
On 09/05/2016 07:20 PM, Andrey Rahmatullin wrote: > On Mon, Sep 05, 2016 at 07:07:51PM +0200, Muri Nicanor wrote: >> so, i've got my first two FTBFS bugs (on mips and hppa)- what the >> recommended way of testing fixes for architectures i don't have >> testmachines of? > Porterboxes. See https://dsa.debian.org/doc/guest-account/ about getting > access for non-DDs. Note that there are no official hppa porterboxes. You can ask on the debian-hppa mailing list for access to an unofficial one though. But speaking of the bugs, they don't actually require porterbox access. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836713 The hppa build chroots don't have systemd installed (for whatever reasaon), in contrast to chroots on most other architectures. Since you depend on systemd.pc, which is part of the systemd package, just Build-Depend on systemd to make systemd.pc available. You won't need porterbox access to fix that issue. (Btw. libsystemd.pc != systemd.pc) Also note that there are plans to make init non-Essential in the future, so more build chroots will not have systemd preinstalled in them, so the problem you're seeing on hppa now is going to be a problem on all archs sooner or later. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836712 MIPS (at least 32bit) doesn't support 64bit atomic operations intrinsically (_8 == 8 bytes) - and your software uses std::atomic (found that by grepping). However, gcc provides an emulation library called libatomic. You should link against that emulation library if present in order to use those intrinsics. I've attached a patch against your package (add it as a quilt patch) that checks for the availability of libatomic and adds it to the linker flags. This might result in a spurious dependency on libatomic on other platforms, but unfortunately I don't know of any way to properly pass --as-needed for just this library without libtool reordering the entire list of linker flags. :-( I've build-tested (including test suite) on amd64 and mipsel (qemu-user though) and the patch fixes the error. Regards, Christian --- a/Makefile.am +++ b/Makefile.am @@ -134,7 +134,8 @@ libusbguard_la_LIBADD=\ @json_LIBS@ \ @udev_LIBS@ \ @crypto_LIBS@ \ - @pegtl_LIBS@ + @pegtl_LIBS@ \ + @atomic_LIBS@ libusbguard_la_SOURCES=\ src/Common/Thread.hpp \ --- a/configure.ac +++ b/configure.ac @@ -71,6 +71,13 @@ AM_PROG_LIBTOOL AC_PROG_LIBTOOL # +# Check if libatomic is available, might be required for emulating +# atomic intrinsics on some platforms. +# +AC_CHECK_LIB([atomic], [__atomic_add_fetch_8], [atomic_LIBS="-latomic"], [atomic_LIBS=""]) +AC_SUBST([atomic_LIBS]) + +# # Checks for required libraries. # PKG_CHECK_MODULES([udev], [libudev >= 200],
Re: FTBFS: how to test fixes
On Mon, Sep 05, 2016 at 05:39:16PM +, Gianfranco Costamagna wrote: > (I don't think every architecture has a porterbox machine, so some of them > might be out of possibility I think all release one have. > e.g. mips good, hppa not. I'm not sure it's worth one's time to test packages on non-release arches, especially when one cannot easily find out which of them are almost release ones and which don't even have a buildd. -- WBR, wRAR signature.asc Description: PGP signature
Re: FTBFS: how to test fixes
* Muri Nicanor , 2016-09-05, 19:07: so, i've got my first two FTBFS bugs (on mips and hppa)- what the recommended way of testing fixes for architectures i don't have testmachines of? Ask on porters' mailing lists (debian-hppa@, debian-mips@) for someone to test it for you. If that doesn't work, ask your sponsor to test it for you. If that doesn't work, ask here for someone to test it for you. -- Jakub Wilk
Re: FTBFS: how to test fixes
Hi, >Porterboxes. See https://dsa.debian.org/doc/guest-account/ about getting >access for non-DDs. or if you aren't a DM, and have some patches to test, send them to me and I'll try to do test builds. (note: my time is limited, so try to avoid ~100 patches to test, unless I can script them and launch in a screen environment) (I don't think every architecture has a porterbox machine, so some of them might be out of possibility also to DD). e.g. mips good, hppa not. https://db.debian.org/machines.cgi thanks, G.
Bug#836381: RFS: couchapp/1.0.2+dfsg1-1
Hi Gustavo
>> INSTALL_REQUIRES = ['restkit==4.2.2', 'watchdog==0.6.0']
>> why is restkit manually listed in runtime dependencies?
>
>that's for setuptools, I could patch it out, but why?
please read what I wrote :)
python-restkit is a build-dependency, and listed in install_requires keyword.
dh_python2 should pick it up automagically and translate it into
a runtime-dependency in ${python:Depends}
please remove it, and check if the dependency is correctly added in the binary
file (debian/control)
>no, is not wrong
>$ git clone
>https://anonscm.debian.org/cgit/collab-maint/couchapp.git
>Cloning into 'couchapp'...
yes, I know it works, but probably because of some rewrite rule in collab-maint
git
apache configuration.
I still prefer to have them separate, because it won't work on other non alioth
git repo.
(and some bad copy-paste might introduce such issues)
(this *isn't* a blocker for this upload, feel free to keep it that way)
>restkit doest not have a python3 package, nose-testconfig does not work on
>python3 AFAIK, and it is necesary for tests
>
>the mention in README.md about python3 is to host the coverage
>reports
ack thanks
>thanks, how did you find it? licensecheck didn't!
some grep copyright . -Ri ; grep license . -Ri
and debdiff between the two versions did spot it
(did you remove such file in debian/repack script?)
>PS: I've added autopkgtest support to the package :)
nice!
this is always appreciated.
Ready for a next ping on the above points :)
G.
Re: FTBFS: how to test fixes
On 05/09/16 18:20, Andrey Rahmatullin wrote: On Mon, Sep 05, 2016 at 07:07:51PM +0200, Muri Nicanor wrote: so, i've got my first two FTBFS bugs (on mips and hppa)- what the recommended way of testing fixes for architectures i don't have testmachines of? Porterboxes. See https://dsa.debian.org/doc/guest-account/ about getting access for non-DDs. Or debomatic? http://debomatic-mips.debian.net/ Ghis
Re: FTBFS: how to test fixes
On Mon, Sep 05, 2016 at 07:07:51PM +0200, Muri Nicanor wrote: > so, i've got my first two FTBFS bugs (on mips and hppa)- what the > recommended way of testing fixes for architectures i don't have > testmachines of? Porterboxes. See https://dsa.debian.org/doc/guest-account/ about getting access for non-DDs. -- WBR, wRAR signature.asc Description: PGP signature
FTBFS: how to test fixes
hi, so, i've got my first two FTBFS bugs (on mips and hppa)- what the recommended way of testing fixes for architectures i don't have testmachines of? cheers, -- muri signature.asc Description: OpenPGP digital signature
Re: d/control: Depends on same version
hi,
On 09/04/2016 11:03 PM, Christian Seiler wrote:
> On 09/04/2016 09:40 PM, Muri Nicanor wrote:
>> if i have source package foo-x.y that builds binary packages foo_x.y and
>> libfoo_x.y, how can i declare a dependency from foo on libfoo where
>> libfoo has to be the same version of foo?
>
> If both are Arch: any (or linux-any or something similar):
>
> Depends: libfoo (= ${binary:Version})
thanks a lot, thats exactly what i was looking for!
cheers,
--
muri
signature.asc
Description: OpenPGP digital signature
Bug#836350: marked as done (RFS: flycheck/29-1 -- modern on-the-fly syntax checking for Emacs)
Your message dated Mon, 5 Sep 2016 08:03:16 -0700
with message-id <20160905150316.xijha3bqm2xcl...@shortgeese.silentflame.com>
and subject line Accepted
has caused the Debian Bug report #836350,
regarding RFS: flycheck/29-1 -- modern on-the-fly syntax checking for Emacs
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.)
--
836350: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836350
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 new release of flycheck.
I have DM upload rights for this package but this revision introduced a
new binary package, flycheck-doc.
* Package name: flycheck
Version : 29-1
Upstream Author : Sebastian Wiesner and Flycheck contributors
* URL : http://flycheck.org/
* License : GPL-3+
Section : lisp
Changes since the last upload:
* New upstream release.
- New build-dep on elpa-f
* Build new offline docs in new flycheck-doc binary package.
- flycheck suggests flycheck-doc
- Build-depend on python3-{sphinx,requests,docutils}
- Declare build conflict with python-sphinx
- Call dh --with sphinxdoc
- Add d/clean, d/flycheck-doc.doc-base, d/flycheck-doc.docs
* Add elpa-geiser dependency to d/tests/control.
Enable some more tests.
* Test for ADT_TMP as well as AUTOPKGTEST_TMP.
For compatibility with ci.debian.net
* Drop obsolete paragraph from d/copyright.
Upstream deleted test/specs/test-code-style.el
* Update d/copyright information for doc/ dir.
* Remove references to legacy manual that we don't install:
- Extend patch-README-for-Debian.patch
- Add remove-references-to-legacy-manual.patch
* Add remove-todolist.patch
* Drop patches merged upstream:
- Update-expected-values-for-cppcheck-1.74.patch
- pass-epg-gpg-home-directory-to-gpg-invocation.patch
- set-C-locale-and-patch-C-and-fortran-tests.patch
- update-expected-values-for-gcc-6.patch
- update-expected-values-for-rustc-version-1.9.0.patch
- update-expected-values-for-rustc-1.10.patch
- update-perl-expected-values.patch
* Drop obsolete patch disable-code-style-spec-test.patch.
* Refresh patches.
Download with dget:
dget -x
http://mentors.debian.net/debian/pool/main/f/flycheck/flycheck_29-1.dsc
Or build it with gbp:
gbp clone --pristine-tar
https://anonscm.debian.org/git/pkg-emacsen/pkg/flycheck.git
git checkout debian/29-1
git verify-tag debian/29-1 # if you have my key
gbp buildpackage
Thanks.
--
Sean Whitton
signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Thanks for uploading this one, Fred.
--
Sean Whitton--- End Message ---
Bug#836381: RFS: couchapp/1.0.2+dfsg1-1
On Fri, Sep 02, 2016 at 03:23:58 +, Gianfranco Costamagna wrote: > control: owner -1 ! > control: tags -1 moreinfo > > Hi, > > >I'm looking for an sponsor for my updated package couchapp > > > some questions before sponsoring or giving you DM > > 1) > > INSTALL_REQUIRES = ['restkit==4.2.2', 'watchdog==0.6.0'] > > > why is restkit manually listed in runtime dependencies? that's for setuptools, I could patch it out, but why? > > 2) > Vcs-Git: https://anonscm.debian.org/cgit/collab-maint/couchapp.git > > > cgit is wrong for Vcs-Git :) no, is not wrong $ git clone https://anonscm.debian.org/cgit/collab-maint/couchapp.git Cloning into 'couchapp'... remote: Counting objects: 7239, done. remote: Compressing objects: 100% (2726/2726), done. remote: Total 7239 (delta 4007), reused 7169 (delta 3955) Receiving objects: 100% (7239/7239), 5.61 MiB | 942.00 KiB/s, done. Resolving deltas: 100% (4007/4007), done. Checking connectivity... done. > > 3) this release seems to be Python3 ready, did you consider checking > if all the dependencies are Python3 ready and switching to it? > (note: I didn't check) restkit doest not have a python3 package, nose-testconfig does not work on python3 AFAIK, and it is necesary for tests the mention in README.md about python3 is to host the coverage reports > > 4) > +# Sample script to install Python and pip under Windows > +# Authors: Olivier Grisel, Jonathan Helmus and Kyle Kastner > +# License: CC0 1.0 Universal: > http://creativecommons.org/publicdomain/zero/1.0/ > > +:: > +:: Author: Olivier Grisel > +:: License: CC0 1.0 Universal: > http://creativecommons.org/publicdomain/zero/1.0/ > > > showstopper! thanks, how did you find it? licensecheck didn't! PS: I've added autopkgtest support to the package :) -- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 keybase: https://keybase.io/gfa signature.asc Description: PGP signature
Bug#836763: marked as done (hdparm/9.48+ds-2)
Your message dated Mon, 5 Sep 2016 14:09:29 + (UTC) with message-id <1317895224.1352100.1473084569...@mail.yahoo.com> and subject line Re: Bug#836763: hdparm/9.48+ds-2 has caused the Debian Bug report #836763, regarding hdparm/9.48+ds-2 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.) -- 836763: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836763 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: wishlist X-Debbugs-Cc: mailatgo...@gmail.com Dear mentors, I am looking for a sponsor for my package "hdparm": * Package name: hdparm Version : 9.48 Upstream Author : Mark Lord * URL : http://sourceforge.net/projects/hdparm/files/hdparm/ * License : hdparm Section : Admin It builds following binary packages: - hdparm To access further information about this package, please visit the following URL: https://mentors.debian.net/package/hdparm Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/h/hdparm/hdparm_9.48+ds-2.dsc More information about hdparm can be obtained from https://anonscm.debian.org/cgit/collab-maint/hdparm.git Changes since last upload: * Fix typo in the long description, Closes: #818612 thanks to Laura Arjona Reina for the patch. * Apply cme fix dpkg, update license name to match license short name * Apply patch from Helmut Grohne, Closes: #836504 - Pass triplet-prefixed CC to make - Do not strip during build * Update d/control, fix typo in Vcs-Browser field Best regards, Alex --- End Message --- --- Begin Message --- Hi, > I am looking for a sponsor for my package "hdparm": ok done. G.--- End Message ---
Bug#836763: hdparm/9.48+ds-2
Package: sponsorship-requests Severity: wishlist X-Debbugs-Cc: mailatgo...@gmail.com Dear mentors, I am looking for a sponsor for my package "hdparm": * Package name: hdparm Version : 9.48 Upstream Author : Mark Lord * URL : http://sourceforge.net/projects/hdparm/files/hdparm/ * License : hdparm Section : Admin It builds following binary packages: - hdparm To access further information about this package, please visit the following URL: https://mentors.debian.net/package/hdparm Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/h/hdparm/hdparm_9.48+ds-2.dsc More information about hdparm can be obtained from https://anonscm.debian.org/cgit/collab-maint/hdparm.git Changes since last upload: * Fix typo in the long description, Closes: #818612 thanks to Laura Arjona Reina for the patch. * Apply cme fix dpkg, update license name to match license short name * Apply patch from Helmut Grohne, Closes: #836504 - Pass triplet-prefixed CC to make - Do not strip during build * Update d/control, fix typo in Vcs-Browser field Best regards, Alex
Bug#836749: marked as done (RFS: autoconf-archive/20160320-1)
Your message dated Mon, 5 Sep 2016 13:24:54 + (UTC) with message-id <145823428.1256271.1473081894...@mail.yahoo.com> and subject line Re: Bug#836749: RFS: autoconf-archive/20160320-1 has caused the Debian Bug report #836749, regarding RFS: autoconf-archive/20160320-1 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.) -- 836749: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836749 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 my package "autoconf-archive" * Package name: autoconf-archive Version : 20160320-1 Section : devel It builds those binary packages: autoconf-archive - Autoconf Macro Archive autoconf-gl-macros - Autoconf OpenGL Macro Archive -- transitional dummy package To access further information about this package, please visit the following URL: https://mentors.debian.net/package/autoconf-archive Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/a/autoconf-archive/autoconf-archive_20160320-1.dsc More information about hello can be obtained from https://www.example.com. Changes since the last upload: * New upstream release (Closes: #829292). * Bug fix: "AX_CODE_COVERAGE: does not support lcov-1.12", thanks to Roman Lebedev (Closes: #834645). * Put my name is lower case. * Bump Standards-Version in debian/control (no changes required). * Fix lintian warnings. Regards, bastien roucaries --- End Message --- --- Begin Message --- Hi, > I am looking for a sponsor for my package "autoconf-archive" already in and you uploaded it? G.--- End Message ---
Bug#836749: RFS: autoconf-archive/20160320-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "autoconf-archive" * Package name: autoconf-archive Version : 20160320-1 Section : devel It builds those binary packages: autoconf-archive - Autoconf Macro Archive autoconf-gl-macros - Autoconf OpenGL Macro Archive -- transitional dummy package To access further information about this package, please visit the following URL: https://mentors.debian.net/package/autoconf-archive Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/a/autoconf-archive/autoconf-archive_20160320-1.dsc More information about hello can be obtained from https://www.example.com. Changes since the last upload: * New upstream release (Closes: #829292). * Bug fix: "AX_CODE_COVERAGE: does not support lcov-1.12", thanks to Roman Lebedev (Closes: #834645). * Put my name is lower case. * Bump Standards-Version in debian/control (no changes required). * Fix lintian warnings. Regards, bastien roucaries
Bug#836709: marked as done (RFS: 9wm/1.3.9-1)
Your message dated Mon, 5 Sep 2016 08:44:50 -0400 with message-id <1dba55d7-3e3d-43b9-81f3-c78306161...@gmail.com> and subject line has caused the Debian Bug report #836709, regarding RFS: 9wm/1.3.9-1 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.) -- 836709: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836709 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 my package "9wm" * Package name: 9wm Version : 1.3.9-1 Upstream Author : Jacob Adams * URL : https://github.com/9wm/9wm/ * License : Expat Section : x11 It builds those binary packages: 9wm - X11 window manager inspired by Plan 9's rio To access further information about this package, please visit the following URL: https://mentors.debian.net/package/9wm Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/9/9wm/9wm_1.3.9-1.dsc Changes since the last upload: 9wm (1.3.9-1) unstable; urgency=medium * New upstream release * Fix manpage typo (Closes: #836314) -- Jacob Adams Sun, 04 Sep 2016 21:48:37 -0400 Regards, Jacob Adams --- End Message --- --- Begin Message --- I made an incorrect release upstream so closing this Jacob --- End Message ---
