Bug#849170: RFS: gdbm/1.12-4

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "gdbm"

* Package name: gdbm
  Version : 1.12-4
  Upstream Author : bug-g...@gnu.org
* Url : https://gnu.org/software/gdbm
* Licenses: GFDL-1.3+,GPL-3+
  Section : libs

It builds those binary packages:

  * libgdbm4
  * gdbm-l10n
  * libgdbm-dev
  * gdbmtool
  * libgdbm-compat4
  * libgdbm-compat-dev

To access further information about this package, visit the following URL:

https://mentors.debian.net/package/gdbm

Alternatively, one can download the package with dget using this command:
dget -x https://mentors.debian.net/debian/pool/main/g/gdbm/gdbm_1.12-4.dsc

Alternatively, you can access package debian/ directory via git from URL:
https://anonscm.debian.org/cgit/users/kaction-guest/gdbm.git

More information about gdbm can be obtained from
https://gnu.org/software/gdbm

Changes since last upload:

  * Compile and install version of library, compiled with diet libc
in addition to GNU libc.
  * Use debhelper compat 10, which provides --with autoreconf implicitly.

Regards,
  Dmitry Bogatov

Bug#848993: RFS: llmnrd/0.2-1 [ITP]

[Christian Seiler]

Hi,

as announced on IRC, I'm just doing a review, since I'm not a DD
and can't sponsor:

 - packaging in a VCS would be nice to have (plus the appropriate
   Vcs-Browser / Vcs-... headers in d/control)

 - debian/copyright:

 * Tobias Klauser wasn't just active in 2016, the earliest
   copyright notice of his I could find in the package is
   from 2014; so s/2016/2014-2016/ there

 * missing mention of Copyright (C) 2012 Christoph Jaeger
   for pkt.h

 * missing mention of Copyright (C) 2009-2012 Daniel
   Borkmann for util.[ch]

 - debian/compat: why only 9? compat 10 is considered stable now
   and unless you have a good reason I would recommend that any new
   package should use compat 10. (please read the debhelper manual
   though for information on what changed between 9 and 10)

 - init.d: this file name works with dh_installinit, but is not
   documented, so I'd recommend using llmnrd.init as the file name

 - init.d: any particular reason you don't use init-d-script? (See
   current /etc/init.d/skeleton for how this works; it will
   automatically source /etc/default/$scriptname and interpret the
   DAEMON_ARGS variable, so your init script could probably be just
   a couple of lines that set the name of the executable)

 - any reason you don't install the systemd service provided by
   upstream in addition to the init script?

 - debian/rules: nice and clean, I like it

 - upstream's build system does git id to get the git revision of
   the current source - but that will clash if you have the packaging
   in git (which can happen implicitly when someone checks out the
   package source via e.g. dgit)

   Minor cosmetic thing, but makes the package non-reproducible
   depending on whether you build from unpacked .dsc or from a git
   environment

 - lintian warnings:
   W: llmnrd: binary-without-manpage usr/bin/llmnr-query
   W: llmnrd: binary-without-manpage usr/sbin/llmnrd


 - you should probably add a line "export Q =" to debian/rules to
   disable silent builds. While these look nicer, automated build
   log scanners such as blhc aren't able to catch problems.

 - Building in sbuild appears to work fine.

 - Package appears to work fine (though I don't have any llmnr
   device running at the moment, so I could only test name
   resolution of my own system)

Regards,
Christian

Bug#848993: RFS: llmnrd/0.2-1 [ITP]

[Pali Rohár]

Updated to version 0.2.1-1

https://mentors.debian.net/debian/pool/main/l/llmnrd/llmnrd_0.2.1-1.dsc

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Bug#846306: RFS: ondir/0.2.3+git0.55279f03-1 [ITP]

[Gianfranco Costamagna]

Hello



>I completely missed that part of the sentence, sorry. Any
>particular reason why you prefer it that way? (To me it seems
>logical the other way around, since the preprocessor is run
>before the compiler. But OTOH I don't really care, so had I
>not missed the sentence, I would have changed the order.)


not sure, I usually see
$(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) foo $(LIBS)


but I really don't care, and you are probably right :)
>Well, I'll probably send a github pull request that updates the
>Makefile to allow external flags to be passed in via environment
>variables. If that gets merged upstream in time for another
>upload before the deep freeze on Feb. 5th I'll prepare a new
>upload with this fixed, otherwise this will have to wait until
>the Buster release cycle.
>
>I'd like to wait until the current version migrates to stretch
>in 10-11 days before preparing any new upload though, otherwise
>the package won't be part of Stretch at all.


sure! fingers crossed!

G.

Bug#846306: RFS: ondir/0.2.3+git0.55279f03-1 [ITP]

[Christian Seiler]

Hi Gianfranco,

thank you very, very much for sponsoring and your proactiveness
w.r.t. the public copyright statement issue!

On 12/22/2016 03:10 PM, Gianfranco Costamagna wrote:
>>> CFLAGS_FOR_MAKEFILE=$(shell dpkg-buildflags --get CPPFLAGS) $(shell 
>>> dpkg-buildflags --get CFLAGS) -DVERSION=\"$(VERSION)\" 
>>> -DGLOBAL_CONF=\"/etc/onddirrc\"
>>>
>>> I prefer CFLAGS and then CPPFLAGS
> 
> you didn't change the order, but nevermind :)

I completely missed that part of the sentence, sorry. Any
particular reason why you prefer it that way? (To me it seems
logical the other way around, since the preprocessor is run
before the compiler. But OTOH I don't really care, so had I
not missed the sentence, I would have changed the order.)

> peter said *exactly* my opinion. Overriding flags in Makefile should be done
> only when necessary and "cum grano salis"

Well, I'll probably send a github pull request that updates the
Makefile to allow external flags to be passed in via environment
variables. If that gets merged upstream in time for another
upload before the deep freeze on Feb. 5th I'll prepare a new
upload with this fixed, otherwise this will have to wait until
the Buster release cycle.

I'd like to wait until the current version migrates to stretch
in 10-11 days before preparing any new upload though, otherwise
the package won't be part of Stretch at all.

Anyway, thanks again!

Regards,
Christian

Bug#837167: RFS: aiscm/0.6.2-2

[Jan Wedekind]

On Thu, 22 Dec 2016, Andrey Rahmatullin wrote:


On Thu, Dec 22, 2016 at 12:32:20PM +, Jan Wedekind wrote:

There is one final unresolved issue: "hardening-no-fortify-functions"
(certainty: wild-guess) even though GCC is now run with hardening options.
Can I leave it as it is, do I need to override the lintian warning, or do I
need to file a bug report for the lintian warning?

You should use blhc to check if the flags are passed correctly for all
cases. This tag is sometimes a false positive.


Ok,

blhc aiscm*.build

does not output anything. I verified that blhc works by running it on an 
edited build file, too.

Bug#849131: RFS: photocollage/1.4.3-2

[Adrien Vergé]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "photocollage"

 Package name: photocollage
 Version : 1.4.3-2
 Upstream Author : Adrien Vergé 
 URL : https://github.com/adrienverge/PhotoCollage
 License : GPL-2+
 Section : graphics

It builds this binary package:

  photocollage - Graphical tool to make photo collage posters

To access further information about this package, please visit the
following URL:

https://mentors.debian.net/package/photocollage


Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/p/photocollage/photocollage_1.4.3-2.dsc

More information about hello can be obtained from https://www.example.com.

Changes since the last upload:

  * Add missing 'python3-six' to dependencies

Regards,
 Adrien Vergé

Bug#846364: RFS: discover/2.1.2-7.1 [NMU]

[Gianfranco Costamagna]

Hello Petter,
> Debian is upstream.
> 

oops, I read this email after sponsoring it in deferred/3.
I discovered that -O1 made the program stop crashing, so I sponsored the 
debdiff with that change
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=533688#45

the freeze is approaching, and a package that on binNMU starts crashing seems 
an obvious RC bug.

this is why I sponsored it.

let me know if I can speed it up, of course a sane fix would be preferrable, 
but I don't have the knowledge
to properly add it :)

G.



signature.asc
Description: OpenPGP digital signature

Bug#846364: marked as done (RFS: discover/2.1.2-7.1 [NMU])

[Debian Bug Tracking System]

Your message dated Thu, 22 Dec 2016 14:35:16 -0200
with message-id 
and subject line Re: Bug#846364: RFS: discover/2.1.2-7.1 [NMU]
has caused the Debian Bug report #846364,
regarding RFS: discover/2.1.2-7.1 [NMU]
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.)


-- 
846364: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846364
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 the package "discover".

It is an NMU and would fix #812667 and #533688.

It builds those binary packages:

discover   - hardware identification system
libdiscover-dev - hardware identification library development files
libdiscover2 - hardware identification library

To access further information about this package, please visit the following 
URL:

https://mentors.debian.net/package/discover

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/d/discover/discover_2.1.2-7.1.dsc

Changes since the last upload:

  * Non-maintainer upload.

  [ Helmut Grohne ]
  * Fix FTCBFS: Pass --host to configure (Closes: #812667).

  [ Logan Rosen ]
  * Fix FTBFS on various archs: Use autotools-dev to update
config.guess and config.sub. (Closes: #533688)

Regards,

-- 

Fernando Seiti Furusato
IBM Linux Technology Center




signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
I am closing this one, since the general recommendation is to use other
packages instead of discover.
I would actually try to fix this, but this is not a critical package and
do not I have the skills to resolve this quickly.

Regards.

Fernando



signature.asc
Description: OpenPGP digital signature
--- End Message ---

Bug#846306: marked as done (RFS: ondir/0.2.3+git0.55279f03-1 [ITP])

[Debian Bug Tracking System]

Your message dated Thu, 22 Dec 2016 14:10:21 + (UTC)
with message-id <1970194290.612459.1482415821...@mail.yahoo.com>
and subject line Re: Bug#846306: RFS: ondir/0.2.3+git0.55279f03-1 [ITP]
has caused the Debian Bug report #846306,
regarding RFS: ondir/0.2.3+git0.55279f03-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.)


-- 
846306: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846306
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: wishlist
Control: block 846237 by -1

Dear mentors,

I am looking for a sponsor for my package "ondir"

 * Package name: ondir
   Version : 0.2.3+git0.55279f03-1
   Upstream Author : Alec Thomas 
 * URL : http://swapoff.org/ondir.html
 * License : GPL-2
   Section : utils

It builds those binary packages:

  ondir - Automate tasks specific to certain directories in the shell

To access further information about this package, please visit the following 
URL:

https://mentors.debian.net/package/ondir


Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/o/ondir/ondir_0.2.3+git0.55279f03-1.dsc

The package is also available via git in the debian/master branch of:

https://anonscm.debian.org/git/collab-maint/ondir.git

Regards,
Christian
--- End Message ---
--- Begin Message ---
Hi Christian, Alec


>

>Done.

>> CFLAGS_FOR_MAKEFILE=$(shell dpkg-buildflags --get CPPFLAGS) $(shell 
>> dpkg-buildflags --get CFLAGS) -DVERSION=\"$(VERSION)\" 
>> -DGLOBAL_CONF=\"/etc/onddirrc\"
>>
>> I prefer CFLAGS and then CPPFLAGS


you didn't change the order, but nevermind :)
>after thinking about what Peter said in this thread, I removed


peter said *exactly* my opinion. Overriding flags in Makefile should be done
only when necessary and "cum grano salis"


(I probably never found an Use case for overriding the default flags)

but you agreeded this is a bug, and hacky rules vs patch is an equivalent 
approach,
so lets sponsor and open a bug

>I've done so, received a quick response that v2 or later is ok,

>and added a comment to d/copyright.

nice, maybe try to get it on github, because I don't think ftpmasters will 
accept
a "private corrispondence" email with no public record.
Alec, would you please answer here too?

thanks

G.--- End Message ---

Bug#846306: RFS: ondir/0.2.3+git0.55279f03-1 [ITP]

[Christian Seiler]

Control: tags -1 - moreinfo

Hi Gianfranco,

I've uploaded an updated version of the package to mentors (and
also to git on alioth) that fixes these issues.

On 12/22/2016 12:29 PM, Christian Seiler wrote:
> On 12/22/2016 12:05 PM, Gianfranco Costamagna wrote:
>> 1) chmod a-x debian/ondir/usr/share/ondir/integration/*
>>
>> why no dh_fixperms override?
> 
> I forgot about dh_fixperms, will change that in the next iteration.

Done.

>> 2) 
>> CFLAGS_FOR_MAKEFILE=$(shell dpkg-buildflags --get CPPFLAGS) $(shell 
>> dpkg-buildflags --get CFLAGS) -DVERSION=\"$(VERSION)\" 
>> -DGLOBAL_CONF=\"/etc/onddirrc\"
>>
>> I prefer CFLAGS and then CPPFLAGS
>> LDFLAGS_FOR_MAKEFILE=$(shell dpkg-buildflags --get CFLAGS) $(shell 
>> dpkg-buildflags --get LDFLAGS)
>>
>> why CFLAGS in LDFLAGS?

That wasn't actually required, so I dropped it. Additionally,
after thinking about what Peter said in this thread, I removed
the -DVERSION=... from this line and rather added it to a
DEB_CPPFLAGS_MAINT_APPEND, which seems cleaner to me.

>> 3) please ask upstream about the "+" in license
> 
> I've sent upstream an email about this.

I've done so, received a quick response that v2 or later is ok,
and added a comment to d/copyright.

Updated package available under:

https://mentors.debian.net/package/ondir
https://mentors.debian.net/debian/pool/main/o/ondir/ondir_0.2.3+git0.55279f03-1.dsc
gbp clone https://anonscm.debian.org/git/collab-maint/ondir.git

Regards,
Christian

Bug#837167: RFS: aiscm/0.6.2-2

[Andrey Rahmatullin]

On Thu, Dec 22, 2016 at 12:32:20PM +, Jan Wedekind wrote:
> There is one final unresolved issue: "hardening-no-fortify-functions"
> (certainty: wild-guess) even though GCC is now run with hardening options.
> Can I leave it as it is, do I need to override the lintian warning, or do I
> need to file a bug report for the lintian warning?
You should use blhc to check if the flags are passed correctly for all
cases. This tag is sometimes a false positive.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#837167: RFS: aiscm/0.6.2-2

[Jan Wedekind]

On Sat, 17 Dec 2016, Andrey Rahmatullin wrote:


You shouldn't put upstream changes into d/changelog.

I have removed those by the way.


Your package has quite a lot of lintian problems, some of them are even
listed on the mentors, page.


There is one final unresolved issue: "hardening-no-fortify-functions" 
(certainty: wild-guess) even though GCC is now run with hardening options. 
Can I leave it as it is, do I need to override the lintian warning, or do 
I need to file a bug report for the lintian warning?


Regards
Jan

Bug#846306: RFS: ondir/0.2.3+git0.55279f03-1 [ITP]

[Christian Seiler]

On 12/22/2016 01:18 PM, Peter Pentchev wrote:
> On Thu, Dec 22, 2016 at 12:29:23PM +0100, Christian Seiler wrote:
>> Hi Gianfranco,
>>
>> Thanks for taking care of this.
>>
>> On 12/22/2016 12:05 PM, Gianfranco Costamagna wrote:
> [snip]
>>> why override dh_auto_build and dh_auto_install?
>>> probably exporting LDFLAGS and CFLAGS should work
>>
>> No, it won't, because I have to override the variables in the
>> Makefile.
>>
>> For a simple example, take the following Makefile:
> [snip]
>>
>> If one uses cmake or autoconf or similar, then environment variables
>> are sufficient. If the Makefile uses ?= to set the environment variables,
>> then as well. But since upstream's Makefile uses a plain and = for the
>> assignment of the environment variable, we need to override that
>> explicitly via an argument to make.
> 
> That's why I always add a patch to the Makefile that changes the "=" to
> "?=" and then send it upstream; so far the upstream authors have always
> accepted such trivial yet quite useful patches :)

I'd like to get this into Stretch, and while I do believe that
upstream is likely to accept such a patch, the additional round
trip time for that (the package is slow-moving) doesn't seem
worth the tiny amount of higher elegance in d/rules right now.

But thanks for this suggestion, I'll definitely do so at the
beginning of the Buster release cycle, so once the package has
been accepted, I'll open a bug with severity wishlist for this,
so I don't forget it.

But thinking about this, I do think I can make d/rules more
readable regardless, by using DEB_CPPFLAGS_MAINT_APPEND instead
of hard-coding them into the line. Thanks for letting me think
of that. :)

Regards,
Christian

Bug#846306: RFS: ondir/0.2.3+git0.55279f03-1 [ITP]

[Peter Pentchev]

On Thu, Dec 22, 2016 at 12:29:23PM +0100, Christian Seiler wrote:
> Hi Gianfranco,
> 
> Thanks for taking care of this.
> 
> On 12/22/2016 12:05 PM, Gianfranco Costamagna wrote:
[snip]
> > why override dh_auto_build and dh_auto_install?
> > probably exporting LDFLAGS and CFLAGS should work
> 
> No, it won't, because I have to override the variables in the
> Makefile.
> 
> For a simple example, take the following Makefile:
[snip]
> 
> If one uses cmake or autoconf or similar, then environment variables
> are sufficient. If the Makefile uses ?= to set the environment variables,
> then as well. But since upstream's Makefile uses a plain and = for the
> assignment of the environment variable, we need to override that
> explicitly via an argument to make.

That's why I always add a patch to the Makefile that changes the "=" to
"?=" and then send it upstream; so far the upstream authors have always
accepted such trivial yet quite useful patches :)

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#846306: RFS: ondir/0.2.3+git0.55279f03-1 [ITP]

[Christian Seiler]

Hi Gianfranco,

Thanks for taking care of this.

On 12/22/2016 12:05 PM, Gianfranco Costamagna wrote:
> 1) chmod a-x debian/ondir/usr/share/ondir/integration/*
> 
> why no dh_fixperms override?

I forgot about dh_fixperms, will change that in the next iteration.

> 2) 
> CFLAGS_FOR_MAKEFILE=$(shell dpkg-buildflags --get CPPFLAGS) $(shell 
> dpkg-buildflags --get CFLAGS) -DVERSION=\"$(VERSION)\" 
> -DGLOBAL_CONF=\"/etc/onddirrc\"
> 
> I prefer CFLAGS and then CPPFLAGS
> LDFLAGS_FOR_MAKEFILE=$(shell dpkg-buildflags --get CFLAGS) $(shell 
> dpkg-buildflags --get LDFLAGS)
> 
> why CFLAGS in LDFLAGS?

Good question. I'll get back to you on that. I think I had a
reason for it, but I don't remember it. If there is a good
reason, I'll add a comment to d/rules, if there isn't, I'll
drop CFLAGS from there.

> why override dh_auto_build and dh_auto_install?
> probably exporting LDFLAGS and CFLAGS should work

No, it won't, because I have to override the variables in the
Makefile.

For a simple example, take the following Makefile:

CFLAGS = -O2
all:
@echo $(CFLAGS)

Then you get:

env var:
$ CFLAGS=-O0 make
-O2

argument:
$ make CFLAGS=-O0
-O0

If one uses cmake or autoconf or similar, then environment variables
are sufficient. If the Makefile uses ?= to set the environment variables,
then as well. But since upstream's Makefile uses a plain and = for the
assignment of the environment variable, we need to override that
explicitly via an argument to make.

> 3) please ask upstream about the "+" in license

I've sent upstream an email about this.

> 4) missing hardening flags
> http://debomatic-amd64.debian.net/distribution#unstable/ondir/0.2.3+git0.55279f03-1/blhc

That's a false positive: since gcc now sets PIE by default on various
architectures (amd64 included), dpkg-buildflags doesn't pass it any
more.

The binary itself is PIE:

readelf -d /usr/bin/ondir | grep PIE
 0x6ffb (FLAGS_1)Flags: NOW PIE

Compare the output of:

DEB_BUILD_MAINT_OPTIONS=hardening=+pie dpkg-buildflags --get CFLAGS

and

DEB_BUILD_MAINT_OPTIONS=hardening=-pie dpkg-buildflags --get CFLAGS

on both Jessie and Stretch/sid.



Once I hear back from upstream about GPL-2/2+, I'll get back to
you again. (With an updated package that also cleans up the other
issues.)

Regards,
Christian

Bug#846306: RFS: ondir/0.2.3+git0.55279f03-1 [ITP]

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

>I'd appreciate it if a friendly DD could have a look at this
>package and sponsor it. Thanks. :)

1) chmod a-x debian/ondir/usr/share/ondir/integration/*

why no dh_fixperms override?


2) 
CFLAGS_FOR_MAKEFILE=$(shell dpkg-buildflags --get CPPFLAGS) $(shell 
dpkg-buildflags --get CFLAGS) -DVERSION=\"$(VERSION)\" 
-DGLOBAL_CONF=\"/etc/onddirrc\"

I prefer CFLAGS and then CPPFLAGS
LDFLAGS_FOR_MAKEFILE=$(shell dpkg-buildflags --get CFLAGS) $(shell 
dpkg-buildflags --get LDFLAGS)

why CFLAGS in LDFLAGS?
why override dh_auto_build and dh_auto_install?
probably exporting LDFLAGS and CFLAGS should work

3) please ask upstream about the "+" in license

4) missing hardening flags
http://debomatic-amd64.debian.net/distribution#unstable/ondir/0.2.3+git0.55279f03-1/blhc

G.

Bug#848698: marked as done (RFS: imagemagick/8:6.9.7.0+dfsg-1 [RC,Security][experimental])

[Debian Bug Tracking System]

Your message dated Thu, 22 Dec 2016 10:45:52 + (UTC)
with message-id <888483557.343231.1482403552...@mail.yahoo.com>
and subject line Re: Bug#848698: [RC] imagemagick
has caused the Debian Bug report #848698,
regarding RFS: imagemagick/8:6.9.7.0+dfsg-1 [RC,Security][experimental]
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.)


-- 
848698: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848698
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: important
control: block  846385- by -1

  Dear mentors,

  I am looking for a sponsor for my package "imagemagick"

 * Package name: imagemagick
   Version : 8:6.9.7.0+dfsg-1
   Section : graphics

  It builds those binary packages:

imagemagick - image manipulation programs -- binaries
 imagemagick-6-common - image manipulation programs -- infrastructure
 imagemagick-6-doc - document files of ImageMagick
 imagemagick-6.q16 - image manipulation programs -- quantum depth Q16
 imagemagick-6.q16hdri - image manipulation programs -- quantum depth Q16HDRI
 imagemagick-common - image manipulation programs -- infrastructure
dummy package
 imagemagick-doc - document files of ImageMagick -- dummy package
 libimage-magick-perl - Perl interface to the ImageMagick graphics routines
 libimage-magick-q16-perl - Perl interface to the ImageMagick graphics
routines -- Q16 versio
 libimage-magick-q16hdri-perl - Perl interface to the ImageMagick
graphics routines -- Q16HDRI ve
 libmagick++-6-headers - object-oriented C++ interface to ImageMagick
- header files
 libmagick++-6.q16-7 - C++ interface to ImageMagick -- quantum depth Q16
 libmagick++-6.q16-dev - C++ interface to ImageMagick - development files (Q16)
 libmagick++-6.q16hdri-7 - C++ interface to ImageMagick -- quantum depth Q16HDRI
 libmagick++-6.q16hdri-dev - C++ interface to ImageMagick -
development files (Q16HDRI)
 libmagick++-dev - object-oriented C++ interface to ImageMagick -- dummy package
 libmagickcore-6-arch-config - low-level image manipulation library -
architecture header files
 libmagickcore-6-headers - low-level image manipulation library - header files
 libmagickcore-6.q16-3 - low-level image manipulation library --
quantum depth Q16
 libmagickcore-6.q16-3-extra - low-level image manipulation library -
extra codecs (Q16)
 libmagickcore-6.q16-dev - low-level image manipulation library -
development files (Q16)
 libmagickcore-6.q16hdri-3 - low-level image manipulation library --
quantum depth Q16HDRI
 libmagickcore-6.q16hdri-3-extra - low-level image manipulation
library - extra codecs (Q16HDRI)
 libmagickcore-6.q16hdri-dev - low-level image manipulation library -
development files (Q16HDRI
 libmagickcore-dev - low-level image manipulation library -- dummy package
 libmagickwand-6-headers - image manipulation library - headers files
 libmagickwand-6.q16-3 - image manipulation library -- quantum depth Q16
 libmagickwand-6.q16-dev - image manipulation library - development files (Q16)
 libmagickwand-6.q16hdri-3 - image manipulation library -- quantum depth Q16HDRI
 libmagickwand-6.q16hdri-dev - image manipulation library -
development files (Q16HDRI)
 libmagickwand-dev - image manipulation library -- dummy package
 perlmagick - Perl interface to ImageMagick -- dummy package

  To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/imagemagick


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/i/imagemagick/imagemagick_6.9.7.0+dfsg-1.dsc

 imagemagick (8:6.9.7.0+dfsg-1) experimental; urgency=high
 .
   * Bump so version due to structure change
 thanks to Nishanth Aravamudan (Closes: #846385).
   * Fix CVE-2016-8707  ImageMagick Convert Tiff Adobe Deflate
 Code Execution Vulnerability (Closes: #848139)
   * Bug fix: "fails to upgrade wheezy -> jessie -> stretch", thanks
 to Andreas Beckmann (Closes: #847282).


  Changes since the last upload:
--- End Message ---
--- Begin Message ---
Hi Bastien,

you are mostly a DD, so I just did a superficial review (even because
I can't understand all the huge changes you did)

some nitpicks:
1)

-%  Copyright 1999-2016 ImageMagick Studio LLC, a non-profit organization  %
+%  Copyright 1999-2017 ImageMagick Studio LLC, a non-profit organization  %


do upstream have some sort of time-machine?
last time I checked we still were in 2016
(FWIW you also need to document that change in copyright file, sigh)


2)

symbols bumped (all, 

Bug#849014: marked as done (RFS: forge/0.9.2-1)

[Debian Bug Tracking System]

Your message dated Thu, 22 Dec 2016 10:04:56 + (UTC)
with message-id <1369093177.294681.1482401096...@mail.yahoo.com>
and subject line Re: Bug#849014: RFS: forge/0.9.2-1
has caused the Debian Bug report #849014,
regarding RFS: forge/0.9.2-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.)


-- 
849014: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849014
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 "forge"

* Package name: forge
  Version : 0.9.2-1
  Upstream Author : ArrayFire
* URL : https://github.com/arrayfire/forge
* License : BSD
  Section : libs

It builds those binary packages:

 forge-doc  - documentation for forge
 libforge-dev - development files for forge
 libforge0  - high-performance OpenGL visualization

To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/forge

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/f/forge/forge_0.9.2-1.dsc


Successful build on debomatic:


http://debomatic-amd64.debian.net/distribution#unstable/forge/0.9.2-1/buildlog

Changes since the last upload:

  * Switch to git-dpm.
  * New upstream release.
  * Drop patch Fix-build-of-examples-with-the-system-cl2hpp.patch, 
applied upstream.

  * New patch No-version-queries-with-Git.patch, avoid spurious "git not
found" entries in the build log when the documentation is generated.
  * Drop gbp configuration in favor of git-dpm
  * Upgrade packaging to debhelper 10
  * Use architecture.mk to query DEB_HOST_MULTIARCH
  * Cosmetic fixup of rules file

Regards,
Ghislain Vaillant
--- End Message ---
--- Begin Message ---


>I am looking for a sponsor for my package "forge"

seems already done

G.--- End Message ---