Package: sponsorship-requests
Followup-For: Bug #745126
PS:
The announcement about the move of the repositoriy to github is here:
https://sourceforge.net/p/passwordsafe/news/2015/08/passwordsafes-git-repository-moved-to-github/?limit=25
-- System Information:
Debian Release: stretch/sid
APT pre
Package: sponsorship-requests
Followup-For: Bug #745126
Control: owner -1 !
Hi Bill,
I'll take a look tonight.
Tobi
-- System Information:
Debian Release: stretch/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_6
Hi Gianfranco,
Thanks for the review!
> 1) please bump debhelper and compat level to 9
> (bonus points for converting the package to multiarch)
>
I've bumped those to 9.
For multiarch, I will address that in the next upstream version since there
are quite some changes needed.
> 2) please drop
Package: sponsorship-requests
Severity: wishlist
Hey dear mentors,
Looking for a sponsor for this package:
* Package name : snes9x
Version : 1.53+git20150819
Upstream Author : Gary Henderson
and others
* URL : http://www.snes9x.com/
* Lic
Your message dated Tue, 22 Sep 2015 21:48:35 +0200
with message-id <5601b093.7090...@debian.org>
and subject line Re: Bug#799093: RFS: chrony/1.31.1-2
has caused the Debian Bug report #799093,
regarding RFS: chrony/1.31.1-2
to be marked as done.
This means that you claim that the problem has been
Hi,
I took a peek and didn't find get-orig-source in d/rules. d/watch has link to
github, while pwsafe.org links to sourceforge.
I can sponsor the package with that lintian warning.
as said before the package should be lintian clean as long as lintian is
correct.
But overriding lintian is wrong, because it is still an issue.
If it is ok for you I would prefer a package with a lintian warning.
cheers,
Gianfranco
Sen
nope, but maybe autogenerating one starting from help2man and pushing upstream
might be worth the effort
about fortify you need to be sure the code doesn't override CPPFLAGS CFLAGS and
LDFLAGS (or uses them indeed)
IIRC that warning is about CPPFLAGS
cheers,
G.
Sent from Yahoo Mail on And
Hi Cesar and Gianfranco,
I have fixed 2 lintian warnings about `debian/copyright', it is in the
attachment. They are `dep5-copyright-license-name-not-unique' and
`old-fsf-address-in-copyright-file'. I think it would be great to
update the address of FSF in the source files as well.
I notice there
Dear mentors,
I am still looking for a sponsor for my package "passwordsafe"
* Package name: passwordsafe
Version : 0.95.1+dfsg-1
Upstream Author : Rony Shapiro
* URL : http://www.pwsafe.org/
* License : Artistic 2.0
Section : utils
It bui
Hi Jeffrey,
RFS actually stands for Request for Sponsorship. So these endless bug
reports are opened by (mostly) non-Debian-developers who want to get
their packages in Debian, or to upload a new version of existing
packages. Perhaps one day you will subscribe to this list again if you
want to upl
On 22/09/15 17:32, Gianfranco Costamagna wrote:
I would appreciate a lintian warning instead of a broken documentation
e.g. look at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736360
G.
Should the warning be overridden for the purpose or the review? Apart
from that, I am ready to p
On Tue, Sep 22, 2015 at 1:10 PM, Alex Vong wrote:
> Hi Jeffrey,
>
> What sort of bug reports are you receiving? If their titles are in the
> form "Bug#: foolishbar (RFS: blablabla)", then they should
> belong to the debian-mentors mailing list. I guess the type of bug
> reports you are receiving s
Hi Jeffrey,
What sort of bug reports are you receiving? If their titles are in the
form "Bug#: foolishbar (RFS: blablabla)", then they should
belong to the debian-mentors mailing list. I guess the type of bug
reports you are receiving should show what mailing list they are
belonging to.
Cheers,
A
Your message dated Tue, 22 Sep 2015 16:30:57 +
with message-id
and subject line closing RFS: mtpolicyd/1.18 [ITP] -- modular policy daemon for
postfix
has caused the Debian Bug report #783158,
regarding RFS: mtpolicyd/1.18 [ITP] -- modular policy daemon for postfix
to be marked as done.
This
>
>I still don't get what the recommended solution is. So far, I have been
>(wrongly?) following what Lintian suggested to do with embedded jquery.
I would appreciate a lintian warning instead of a broken documentation
e.g. look at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736360
Your message dated Tue, 22 Sep 2015 16:30:57 +
with message-id
and subject line closing RFS: gnss-sdr/0.0.6-1 [ITP]
has caused the Debian Bug report #797794,
regarding RFS: gnss-sdr/0.0.6-1 [ITP]
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is
Your message dated Tue, 22 Sep 2015 16:30:57 +
with message-id
and subject line closing RFS: libcdio-paranoia/10.2+0.93+1-1 [ITP] -- upstream
split of libcdio-paranoia
has caused the Debian Bug report #784056,
regarding RFS: libcdio-paranoia/10.2+0.93+1-1 [ITP] -- upstream split of
libcdio-p
Your message dated Tue, 22 Sep 2015 16:30:57 +
with message-id
and subject line closing RFS: haxe/1:3.2.0+dfsg-1
has caused the Debian Bug report #799092,
regarding RFS: haxe/1:3.2.0+dfsg-1
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not th
Your message dated Tue, 22 Sep 2015 16:30:53 +
with message-id
and subject line closing RFS: libphpcpp/1.3.2-1 [ITP] -- C++ library for
developing PHP extensions
has caused the Debian Bug report #783935,
regarding RFS: libphpcpp/1.3.2-1 [ITP] -- C++ library for developing PHP
extensions
to b
For some reason, I seem to receive a copy of everyone's bug reports.
I tried to unsubscribe by sending an unsubscribe email to
submit-requ...@bugs.debian.org, but nothing happened. (-REQUEST@
is supposed to be the address to use).
Why am I receiving everyone's bugs, and how do I stop it?
(There'
Your message dated Tue, 22 Sep 2015 16:30:57 +
with message-id
and subject line closing RFS: passwordsafe/0.95.1+dfsg-1 [ITP] -- Simple &
Secure Password Management
has caused the Debian Bug report #745126,
regarding RFS: passwordsafe/0.95.1+dfsg-1 [ITP] -- Simple & Secure Password
Managemen
On 22/09/15 14:57, Gianfranco Costamagna wrote:
Control: merge -1 799767
Control: owner -1 !
Hi Ghislain,
the packaging looks good, however I have some nitpicks/issues:
rules file:
"-DCMAKE_INSTALL_PREFIX=/usr"
is this really needed? AFAIK it should be the default inside a dh build.
(ple
Control: owner -1 !
Hi, quick review:
1) please bump debhelper and compat level to 9
(bonus points for converting the package to multiarch)
2) please drop useless build-dependencies (such as quilt and maybe some others,
e.g. pkg-config?)
3) rules file, can you please convert in plain dh_ ca
Your message dated Tue, 22 Sep 2015 15:33:31 + (UTC)
with message-id <1066647587.2337726.1442936011846.javamail.ya...@mail.yahoo.com>
and subject line Re: Bug#799094: RFS: node-kerberos/0.0.14-1 [ITP]
has caused the Debian Bug report #799094,
regarding RFS: node-kerberos/0.0.14-1 [ITP]
to be ma
Your message dated Tue, 22 Sep 2015 14:45:01 + (UTC)
with message-id <2025357966.2264338.1442933101920.javamail.ya...@mail.yahoo.com>
and subject line Re: Bug#799770: RFS: pyfftw/0.9.2+dfsg-3
has caused the Debian Bug report #799770,
regarding RFS: pyfftw/0.9.2+dfsg-3
to be marked as done.
Thi
On 22/09/15 14:42, Gianfranco Costamagna wrote:
Control: owner -1 !
Hi Ghislain,
the packaging looks good, however:
1) watch file: what about using this one?
http://pypi.debian.net/pyFFTW/watch
2)+ * d/control: bump standards version, no changes required.
I would also mention "3.9.6" somewh
Hi again,
some lintian stuff
http://debomatic-amd64.debian.net/distribution#unstable/eviacam/2.0.1-5/lintian
cheers,
G.
Control: merge -1 799767
Control: owner -1 !
Hi Ghislain,
the packaging looks good, however I have some nitpicks/issues:
rules file:
"-DCMAKE_INSTALL_PREFIX=/usr"
is this really needed? AFAIK it should be the default inside a dh build.
(please check)
"--builddirectory=$(BUILDDIR)"
same her
Control: owner -1 !
Hi Ghislain,
the packaging looks good, however:
1) watch file: what about using this one?
http://pypi.debian.net/pyFFTW/watch
2)+ * d/control: bump standards version, no changes required.
I would also mention "3.9.6" somewhere
they are nitpicks, the packaging looks really
Hi Cesar,
>> maybe run "debconf-updatepo" in the clean target, to avoid forgetting of
>> updating translations.
>
>Done
nack :) you did it correctly, but that way dh_clean is never called :)
override_dh_clean:
debconf-updatepo
dh_clean
this is what I meant.
"#634840 (wishlist):
Your message dated Tue, 22 Sep 2015 13:46:06 +0100
with message-id <56014d8e.1010...@gmail.com>
and subject line uploaded to unstable
has caused the Debian Bug report #799655,
regarding RFS: arrayfire/3.1.1+dfsg1-1
to be marked as done.
This means that you claim that the problem has been dealt wit
Hi Gianfranco,
the other stuff might be food
maybe run "debconf-updatepo" in the clean target, to avoid forgetting of
updating translations.
Done
I've uploaded an updated version to mentors. I've also fixed some issues
(missing .mo files in .deb, remove unneeded files and dependencies).
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for my package "pyfftw"
* Package name: pyfftw
Version : 0.9.2+dfsg-3
Upstream Author : Henry Gomersall
* URL : http://hgomersall.github.io/pyFFTW/
* License : BSD-3-clau
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for my package "ismrmrd"
* Package name: ismrmrd
Version : 1.3.1-1
Upstream Author : The ISMRMRD developers
* URL : http://ismrmrd.github.io/
* License : Expat
Section
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for my package "ismrmrd"
* Package name: ismrmrd
Version : 1.3.1-1
Upstream Author : The ISMRMRD developers
* URL : http://ismrmrd.github.io/
* License : Expat
Section
Hi,
libfann 2.1.0~beta+dfsg-1 in Debian currently builds a library as
binary package libfann2, and Python bindings for it as binary package
python-pyfann.
The new upstream version 2.2.0 of libfann no longer provides the Python
bindings; they are now provided by an external contributor instead.
(A
It is in the pipe :)
Cheers
On Tue, Sep 22, 2015 at 05:59:48AM +, PICCA Frederic-Emmanuel wrote:
> I will take care of this.
Ahh, I missed this. Frederic, if you could upload this would be great
since I'm behind a slow connection.
Kind regards
Andreas.
--
http://fam-tille.de
Hi,
>So it is explainable that symbol loading works between
>fewly different package versions.
>I would still like to know how i managed to break it.
>Just to be able to avoid this in future.
as said before, the debug package should depend on binary:Version binary
package.
e.g.
Package: fo
Hi,
Gianfranco Costamagna wrote:
> So how did it work for Thomas with the previous version installed?
The /usr/bin/cdrskin files of 1.4.0-2 and 1.4.0-3 are identical
(at least their MD5s are).
Curse or blessing of reproducible building.
Niels Thykier wrote:
> * The path where the binaries were
Hi Niels,
>If the old and the new binary have the same build-id, they can reuse the
>same debug symbols - regardless of the debug symbols are installed by
>name or by build id. :)
>
so the __TIME__ __DATE__ macros are not used, but *might* be used
and not during the build-id computation, but d
42 matches
Mail list logo
