Bug#860804: RFS: highwayhash/0~20170419-g1f4a24f-1 [ITP] -- tensorflow dependency library

2017-04-20 Thread Lumin 
Hi Adam,

Thank you for reviewing this package!

Updated package was uploaded to mentors:
https://mentors.debian.net/debian/pool/main/h/highwayhash/highwayhash_0~20170419-g1f4a24f-1.dsc

and debomatic:
http://debomatic-amd64.debian.net/distribution#experimental/highwayhash/0~20170419-g1f4a24f-1/buildlog

Changes:
* fixed the mistaken /lib//libxxx.a install path.
The static library didn't drop
  sip_tree_hash.o object.
* patched upstream makefile to produce a shared object file
(sip_tree_hash.o is dropped from so file)
* added symbols control file
* override dh_auto_test to run upstream test binaries (except for the
"benchmark").

Is it acceptable now?
:-)

On 20 April 2017 at 16:08, Adam Borowski  wrote:
> On Thu, Apr 20, 2017 at 10:35:41AM +, Lumin wrote:
>>   I am looking for a sponsor for my package "highwayhash"
>>
>>  * Package name: highwayhash
>>Upstream Author : google
>>  * URL : https://github.com/google/highwayhash
>
>>   It builds those binary packages:
>>
>> libhighwayhash-dev - Fast strong hash functions: SipHash/HighwayHash
>
> You install the .a file into /lib, that's a place for important boot-time
> shared libraries, not for stuff that's used only during compilation.
>
> I see no shared library at all -- why do you provide only a static version?
> That's useful only for limited special uses, unfit for a general purpose
> library.  Static libs might sort-of work for Google's internal projects, as
> they have a centralized tightly managed infrastructure so "recompile world"
> for every single bug fix is doable, but in a loose ecosystem such as a
> distribution it's unfeasible.  You might get away with static libs if you
> closely cooperate with all of your reverse dependencies, but that's
> pointless for a library meant for wide use, such as hashes.
>
> Also, the SipTreeHash runs only a small set of CPUs and thus is useless for
> an universal distibution.  The other two hashes provide portable versions
> that work on every CPU of every arch, but as SipTreeHash gives a different
> output, its inclusion is kind of pointless.
>
>
> Your choices may differ, but I'd make the following changes:
> * provide a shared library
> * drop the static one -- or at least move it into the proper place
> * disable SipTreeHash, as failing at compile time rather than runtime is
>   nicer to users
>
> --
> ⢀⣴⠾⠻⢶⣦⠀ Meow!
> ⣾⠁⢠⠒⠀⣿⡁
> ⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
> ⠈⠳⣄ preimage for double rot13!



-- 
Best,
Lumin

Bug#859988: closed by Adam Borowski <kilob...@angband.pl> (Re: Bug#859988: RFS: gcc-6-doc/6.3.0-1)

2017-04-20 Thread Guo Yixuan 
Hi Adam and Mattias,

Thank you! I'll try to upload gcc-doc-default soon.

Cheers,
Yixuan

On Mon, Apr 10, 2017 at 1:27 AM, Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:
>
> This is an automatic notification regarding your Bug report
> which was filed against the sponsorship-requests package:
>
> #859988: RFS: gcc-6-doc/6.3.0-1
>
> It has been closed by Adam Borowski .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Adam Borowski <
kilob...@angband.pl> by
> replying to this email.
>
>
> --
> 859988: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859988
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
> -- Forwarded message --
> From: Adam Borowski 
> To: 859988-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Mon, 10 Apr 2017 07:23:45 +0200
> Subject: Re: Bug#859988: RFS: gcc-6-doc/6.3.0-1
> On Sun, Apr 09, 2017 at 11:44:03PM -0400, Guo Yixuan wrote:
> > I'm looking for a sponsor for my package gcc-6-doc.
> >
> > Changes for this upload:
> >  gcc-6-doc (6.3.0-1) unstable; urgency=medium
> >  .
> >* New upstream release.
> >* Synced patches with gcc-6, 6.3.0-12.
> >* Build manpages for gcov-tool/gcov-dump. (Closes: #859974)
>
> As you coordinate with Matthias Klose, I assume uploading this large blob
of
> changes to unstable is ok.
>
> Looks good to me.
>
> --
> ⢀⣴⠾⠻⢶⣦⠀ Meow!
> ⣾⠁⢠⠒⠀⣿⡁
> ⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
> ⠈⠳⣄ preimage for double rot13!
>
> -- Forwarded message --
> From: "Guo Yixuan (郭溢譞)" 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Sun, 09 Apr 2017 23:44:03 -0400
> Subject: RFS: gcc-6-doc/6.3.0-1
> Package: sponsorship-requests
> Severity: normal
> Control: block 859974 by -1
>
> Dear mentors,
>
> I'm looking for a sponsor for my package gcc-6-doc.
>
> Changes for this upload:
>  gcc-6-doc (6.3.0-1) unstable; urgency=medium
>  .
>* New upstream release.
>* Synced patches with gcc-6, 6.3.0-12.
>* Build manpages for gcov-tool/gcov-dump. (Closes: #859974)
>
> Package description:
>
> * Package name: gcc-6-doc
>   Version : 6.3.0-1
>   Upstream Author : FSF
> * URL : http://gcc.gnu.org/
> * License : GFDL-1.3+, with invariant sections
>   Programming Lang: Texinfo
>   Description : documentation for the GNU compilers (gcc, gobjc, g++)
>
> This package contains manual pages and documentation in info, html,
> and pdf format, for the GNU compilers.
>
> This documentation is licensed under the terms of the GNU Free
> Documentation License, and contains invariant sections, so it can't be
> part of Debian main.
>
> (See gcc-5-doc as an example.)
>
>   It builds those binary packages:
>
>  cpp-6-doc  - documentation for the GNU C preprocessor (cpp)
>  gcc-6-doc  - documentation for the GNU compilers (gcc, gobjc, g++)
>  gccgo-6-doc - documentation for the GNU Go compiler (gccgo)
>  gcj-6-doc  - documentation for the GNU Java tools (gcj, gij)
>  gfortran-6-doc - documentation for the GNU Fortran Compiler (gfortran)
>  gnat-6-doc - documentation for the GNU Ada Compiler (gnat)
>
>   To access further information about this package, please visit the
following URL:
>
>   https://mentors.debian.net/package/gcc-6-doc
>
>
>   Alternatively, one can download the package with dget using this
command:
>
> dget -x
https://mentors.debian.net/debian/pool/non-free/g/gcc-6-doc/gcc-6-doc_6.3.0-1.dsc
>
> Thanks,
> Yixuan
>



--
GUO Yixuan

Bug#859778: RFS: xtrs/4.9d-2

2017-04-20 Thread Sean Whitton 
Hello Branden,

On Thu, Apr 20, 2017 at 04:58:03PM -0400, G. Branden Robinson wrote:
> Sure am.  In fact I have xtrs 4.9d-3 pretty much ready to go except for
> the official versioning and tagging.  I've also been in touch with
> upstream; he's been working on an xtrs 5.0 for quite some time.  :)
> 
> See attachments.  I've also pushed my work to alioth.

Please remove the moreinfo tag from the bug when it's ready to be
uploaded.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#859778: RFS: xtrs/4.9d-2

2017-04-20 Thread G. Branden Robinson 
At 2017-04-20T15:58:04-0700, Sean Whitton wrote:
> Please remove the moreinfo tag from the bug when it's ready to be
> uploaded.

Will do!

Regards,
Branden


signature.asc
Description: PGP signature

Bug#859778: RFS: xtrs/4.9d-2

2017-04-20 Thread G. Branden Robinson 
At 2017-04-20T09:45:13-0700, Sean Whitton wrote:
> Hello Branden,

Hi Sean!

> On Wed, Apr 12, 2017 at 11:09:45PM -0400, G. Branden Robinson wrote:
> > Yeah, I didn't understand that at the time.  Subsequently I changed all
> > the 4.9d changelog entries to target experimental.
> > 
> > > Thus, it'd be better to target the new version at experimental instead
> > > (or refrain from updates for now -- but that goes against "release
> > > early, release often" and makes debdiffs far harder to read).
> > 
> > It sounds like I should maybe just forget about -2 and upload -3.  I had
> > one more thing I wanted to do for it but it's a big task, rather
> > involved, and not required.
> 
> What is the status of this RFS?  Are you still working on the upload to
> experimental?

Sure am.  In fact I have xtrs 4.9d-3 pretty much ready to go except for
the official versioning and tagging.  I've also been in touch with
upstream; he's been working on an xtrs 5.0 for quite some time.  :)

See attachments.  I've also pushed my work to alioth.

-- 
Regards,
Branden
Format: 3.0 (quilt)
Source: xtrs
Binary: xtrs
Architecture: any
Version: 4.9d-3~~unreleased
Maintainer: G. Branden Robinson 
Homepage: http://www.tim-mann.org/xtrs.html
Standards-Version: 3.9.8
Build-Depends: bsdmainutils, debhelper (>= 9), groff-base, html2text, 
libreadline-dev, libx11-dev, po-debconf
Package-List:
 xtrs deb contrib/otherosfs extra arch=any
Checksums-Sha1:
 42b1fc90246901456d29071421e838b545f39f0f 99 xtrs_4.9d.orig.tar.gz
 a346107dc33d28e66e440590edeb63c1e35fe679 100156 
xtrs_4.9d-3~~unreleased.debian.tar.xz
Checksums-Sha256:
 3985f2331e76198dfc027bc2afcd09a158d2bcad0348aeb4a4958a8fb99cf5c4 99 
xtrs_4.9d.orig.tar.gz
 702129c437c486a6b98d75b54ff1561aff16b1e59b96189e44c6c9a31a873163 100156 
xtrs_4.9d-3~~unreleased.debian.tar.xz
Files:
 93868bed769c038bfae907375316bb2d 99 xtrs_4.9d.orig.tar.gz
 f89963f7dc0155dd23eeb65f9d4d3f23 100156 xtrs_4.9d-3~~unreleased.debian.tar.xz
 dpkg-buildpackage -rfakeroot -us -uc
dpkg-buildpackage: info: source package xtrs
dpkg-buildpackage: info: source version 4.9d-3~~unreleased
dpkg-buildpackage: info: source distribution experimental
dpkg-buildpackage: info: source changed by G. Branden Robinson 

 dpkg-source --before-build xtrs
dpkg-buildpackage: info: host architecture amd64
dpkg-source: info: applying prep-makefiles-for-debian.patch
dpkg-source: info: applying fix-compiler-warnings.patch
dpkg-source: info: applying ignore-alt-key-events.patch
dpkg-source: info: applying add-ifdef-guards-around-setuid.patch
dpkg-source: info: applying stop-ignoring-result-from-fread.patch
dpkg-source: info: applying make-plain-text-docs-from-html.patch
dpkg-source: info: applying debian-stop-clobbering-cflags-and-ldflags.patch
dpkg-source: info: applying mkdisk-document-d-option-in-usage-message.patch
dpkg-source: info: applying stop-mkdisk-from-overflowing-buffers.patch
dpkg-source: info: applying mkdisk-check-fopen-return-with-dmk-images.patch
dpkg-source: info: applying mkdisk-protect-against-overwrites.patch
dpkg-source: info: applying this-one-goes-to-c11.patch
dpkg-source: info: applying hex2cmd-idiomatize-manpage.patch
dpkg-source: info: applying cmddump-idiomatize-manpage.patch
dpkg-source: info: applying cassette-idiomatize-manpage.patch
dpkg-source: info: applying debian-cassette-manpage-del-paragraph.patch
dpkg-source: info: applying mkdisk-idiomatize-manpage.patch
dpkg-source: info: applying xtrs-idiomatize-manpage.patch
dpkg-source: info: applying makefile-generate-pdf-manpages.patch
dpkg-source: info: applying emtsafe-flag-on-by-default.patch
dpkg-source: info: applying write-online-help-to-stderr-if-small-window.patch
dpkg-source: info: applying kill-last-fprintf-stderr-stragglers.patch
 fakeroot debian/rules clean
dh clean
   dh_testdir
   dh_auto_clean
make -j1 clean
make[1]: Entering directory '/home/branden/git/debian/xtrs'
rm -f z80.o main.o load_cmd.o load_hex.o trs_memory.o trs_keyboard.o error.o 
debug.o dis.o trs_io.o trs_cassette.o trs_xinterface.o trs_chars.o 
trs_printer.o trs_rom1.o trs_rom3.o trs_rom4p.o trs_disk.o trs_interrupt.o 
trs_imp_exp.o trs_hard.o trs_uart.o mkdisk.o compile_rom.o error.o load_cmd.o 
load_hex.o cmd.o error.o load_hex.o hex2cmd.o \
cmddump.o load_cmd.o trs_rom*.c *~ \
xtrs mkdisk hex2cmd cmddump compile_rom \
cpmutil.txt dskspec.txt
make[1]: Leaving directory '/home/branden/git/debian/xtrs'
   dh_clean
rm -f debian/debhelper-build-stamp
rm -f debian/xtrs.substvars
rm -f debian/xtrs.*.debhelper
rm -rf debian/xtrs/
rm -rf debian/.debhelper/
rm -f debian/*.debhelper.log
rm -f debian/files
rm -f -- debian/copyright-info.actual debian/no-copyright-info.actual
find .  \( \( \
\( -path .\*/.git -o -path .\*/.svn -o -path .\*/.bzr -o -path 
.\*/.hg -o -path .\*/CVS \)

Bug#860496: RFS: drgeo/1.1.0-10.3 [NMU, RC]

2017-04-20 Thread Adrian Bunk 
On Tue, Apr 18, 2017 at 08:19:35PM -0400, Patrick Hetu wrote:
> > > On Mon, Apr 17, 2017 at 05:59:11PM -0400, Patrick Hetu wrote:
> > > >   * Fixed compatibility with Guile 2.0. (Closes: #707903)
> > 
> > Thank you for your work to fix this bug.
> > 
> > What is the source of the patch you have added?
> 
> I did the patch myself.
>...

drgeo is not in jessie and won't be in stretch, so there is no need to 
hurry with patching this upstream version from 2005.

https://git.gnome.org/browse/archive/drgeo/log/
This looks very dead.

#736535 mentions an active fork (that seems to be quite different).

What drgeo needs is an active maintainer who packages code that is 
also maintained upstream.

Trying to revive 2005 code after it has already missed two Debian
releases doesn't make much sense.

> thanks,
> 
> Patrick

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: C++ help needed for psortb

2017-04-20 Thread Bastien ROUCARIES 
On Wed, Apr 19, 2017 at 4:20 PM, Andreas Tille  wrote:
> Hi Bastien,
>
> On Wed, Apr 19, 2017 at 01:32:43PM +, Bastien Roucaries wrote:
>>
>> Le 19 avril 2017 08:09:11 GMT+02:00, Andreas Tille  a 
>> écrit :
>> >
>> >Psortb[1] was using header files from biosquid[2] and hmmer2[3] but did
>> >not shipped the according library code.  No idea how this might have
>> >worked - I assume most users just took the compiled binaries and did
>> >not
>> >noticed.  Biosquid and hmmer2 development is discontinued.  There is
>> >hmmer 3.x but several users rely on hmmer2.  The latter contained
>> >another copy of biosquid which I removed inside the package in
>> >experimental by dynamically linking against biosquid.  The biosquid
>> >package in experimental was also overhauled with newly written automake
>> >stuff to enable dynamic libraries which were not available before.
>> >
>> >In other words: The biosquid library is used by two packages (hmmer2
>> >and
>> >psortb - possibly more code copies around which will be removed later)
>> >but as far as I know hmmer2 was creating the library only to link its
>> >own executables.  While I'd prefer a dynamic library for the same
>> >reasons as you specified above the effort to realise this is higher and
>> >the use less than for biosquid (but I would not stop anybody to invest
>> >some time into low popcon orphaned code which is not bad in principle)
>>
>> Could you please give some string ti identify both library ?
>
> I'm sorry, I can't parse this.  Current status is:  With Build-Depends
>
>libsquid-dev (>= 1.9g+cvs20050121-9~),
>libhmmer2-dev (>= 2.3.2+dfsg-2~),
>
> the build target of psortb succeeds but package build fails in
> build time test due to missing symbol:
>
> # Error:  Can't load 
> '/build/psortb-3.0.4+dfsg/bio-tools-psort-svmloc/../blib/arch/auto/Bio/Tools/PSort/SVMLoc/SVMLoc.so'
>  for module Bio::Tools::PSort::SVMLoc: 
> /build/psortb-3.0.4+dfsg/bio-tools-psort-svmloc/../blib/arch/auto/Bio/Tools/PSort/SVMLoc/SVMLoc.so:
>  undefined symbol: _ZN7DataSet12getAttributeEi at 
> /usr/lib/x86_64-linux-gnu/perl/5.24/DynaLoader.pm line 187.

I means lintian can detect embeded code. I only need some strings that
reprensent the lib. String is the name of the unix tools.

Bastien
>
>
> So what "string to identify both libraries" do you want me to give to
> approach what?
>
> Kind regards
>
>   Andreas.
>
>> >[1] https://anonscm.debian.org/git/debian-med/psortb.git
>> >[2] https://anonscm.debian.org/git/debian-med/biosquid.git
>> >[3] https://anonscm.debian.org/git/debian-med/hmmer2.git
>
> --
> http://fam-tille.de

Bug#859778: RFS: xtrs/4.9d-2

2017-04-20 Thread Sean Whitton 
Hello Branden,

On Wed, Apr 12, 2017 at 11:09:45PM -0400, G. Branden Robinson wrote:
> Yeah, I didn't understand that at the time.  Subsequently I changed all
> the 4.9d changelog entries to target experimental.
> 
> > Thus, it'd be better to target the new version at experimental instead
> > (or refrain from updates for now -- but that goes against "release
> > early, release often" and makes debdiffs far harder to read).
> 
> It sounds like I should maybe just forget about -2 and upload -3.  I had
> one more thing I wanted to do for it but it's a big task, rather
> involved, and not required.

What is the status of this RFS?  Are you still working on the upload to
experimental?

Thanks!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#860466: RFS: equivs/2.0.10 [QA] -- Circumvent Debian package dependencies

2017-04-20 Thread Sean Whitton 
control: tag -1 +moreinfo

Dear Roger,

On Wed, Apr 19, 2017 at 09:10:52AM +0900, Roger Shimizu wrote:
> And I pushed my fixes to branch qa_upload2.
> (I removed the final releasing commit of branch qa_upload, and added update 
> commit)

I'd like to note that I'm planning to upload with dgit, so you shouldn't
rebase after the upload.  It's okay to rebase before the upload.

> Indeed.
> The new d/copyright was generated by decopy.
> I think it's just have issue to support native package, or 1.0 source format,
> when I invoked decopy command. (I changed to 3.0 native afterwards)
> 
> Now I merged two parts.
> New entries are catched by decopy, which find it in d/changelog, I think.

Good, thanks.

> > d/changelog:
> > 
> > - You should include in the changelog that you updated the Maintainer:
> >   field (not every QA upload does this).  It's also good to write
> >   something like (see #xx) where that's the number of the orphaning
> >   bug.
> 
> Fixed.

The changelog still doesn't say that the Maintainer: field has been updated.

If you're able to address the issues I've raised in this message, please
remove the moreinfo tag in this bug, and don't forget to re-run `dch -r`
to refresh the changelog timestamp.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#860804: RFS: highwayhash/0~20170419-g1f4a24f-1 [ITP] -- tensorflow dependency library

2017-04-20 Thread Adam Borowski 
On Thu, Apr 20, 2017 at 10:35:41AM +, Lumin wrote:
>   I am looking for a sponsor for my package "highwayhash"
> 
>  * Package name: highwayhash
>Upstream Author : google
>  * URL : https://github.com/google/highwayhash

>   It builds those binary packages:
> 
> libhighwayhash-dev - Fast strong hash functions: SipHash/HighwayHash

You install the .a file into /lib, that's a place for important boot-time
shared libraries, not for stuff that's used only during compilation.

I see no shared library at all -- why do you provide only a static version? 
That's useful only for limited special uses, unfit for a general purpose
library.  Static libs might sort-of work for Google's internal projects, as
they have a centralized tightly managed infrastructure so "recompile world"
for every single bug fix is doable, but in a loose ecosystem such as a
distribution it's unfeasible.  You might get away with static libs if you
closely cooperate with all of your reverse dependencies, but that's
pointless for a library meant for wide use, such as hashes.

Also, the SipTreeHash runs only a small set of CPUs and thus is useless for
an universal distibution.  The other two hashes provide portable versions
that work on every CPU of every arch, but as SipTreeHash gives a different
output, its inclusion is kind of pointless.


Your choices may differ, but I'd make the following changes:
* provide a shared library
* drop the static one -- or at least move it into the proper place
* disable SipTreeHash, as failing at compile time rather than runtime is
  nicer to users

-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄ preimage for double rot13!

Bug#860804: RFS: highwayhash/0~20170419-g1f4a24f-1 [ITP] -- tensorflow dependency library

2017-04-20 Thread Lumin 
Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

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

 * Package name: highwayhash
   Version : 0~20170419-g1f4a24f-1
   Upstream Author : google
 * URL : https://github.com/google/highwayhash
 * License : Apache-2.0
   Section : science

  It builds those binary packages:

libhighwayhash-dev - Fast strong hash functions: SipHash/HighwayHash

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/h/highwayhash/highwayhash_0~20170419-g1f4a24f-1.dsc

  More information about hello can be obtained from

http://debomatic-amd64.debian.net/distribution#experimental/highwayhash/0~20170419-g1f4a24f-1/buildlog

  Changes since the last upload:

highwayhash (0~20170419-g1f4a24f-1) experimental; urgency=medium

  * Initial release. (Closes: #848885)