Bug#798057: ITP RFS: node-sprintf-js/1.0.3-1

[Stephen Kitt]

Control: owner -1 !
Control: tag -1 + moreinfo

Salut Bastien,

On Sat, 5 Sep 2015 00:17:01 +0200, Bastien ROUCARIES
 wrote:
>   I am looking for a sponsor for my package "node-sprintf-js"
> 
>  * Package name: node-sprintf-js
>Version : 1.0.3-1
>Upstream Author :Alexandru Marasteanu
>  * URL : https://github.com/alexei/sprintf.js/issues
>  * License : BSD-3-Clause
>Section : web
> 
>   It builds those binary packages:
> 
> node-sprintf-js - JavaScript sprintf implementation
> 
>   To access further information about this package, please visit the
> following URL:
> 
>   http://mentors.debian.net/package/node-sprintf-js

Thanks for packaging this!

Just a few comments:
* debian/README.Source should be README.source (policy 4.14)
* debian/changelog still has UNRELEASED
* I'd rather have "Priority: optional" but I didn't check the other
  dependencies
* is there any point in symlinking the source code contained in the upstream
  package in missing-sources (other than fixing a Lintian warning)?
* debian/copyright should reproduce the license grant given by upstream
  verbatim (OK, this is really "couper les cheveux en quatre")

Regards,

Stephen


pgpoHD2DIm_uU.pgp
Description: OpenPGP digital signature

Bug#797888: RFS: panda3d/1.9.0-1 [ITP]

[Jörn Schönyan]

Hi everyone,

I think everything is now ready for further work on the package. Thank you 
very much for your help!


Regards

Re: Bug#797888: RFS: panda3d/1.9.0-1 [ITP]

[Alex Vong]

Package: wnpp
retitle 597172 ITP: panda3d -- Panda3D is a game engine, a framework for 3D 
rendering and game development for Python and C++ programs.
thanks

Hi Jörn,

It seems your email client does line wrapping, so I am re-sending the retitle 
command.
Usually line wrapping is good for readability (at least for my 
79-coloumn-compatible eyes).
However, if you try to send long command to control server, or sending inline 
patch to mailing list, line wrapping will cause problem.
I personally use Claws Mail which supports disabling line wrapping.

Cheers,
Alex

2015-09-05 16:52 GMT+08:00, Jörn Schönyan :
> Hi everyone,
> 
> I think everything is now ready for further work on the package.
> Thank you very much for your help!
> 
> Regards
> 
>

Bug#798057: marked as done (ITP RFS: node-sprintf-js/1.0.3-1)

[Debian Bug Tracking System]

Your message dated Sat, 5 Sep 2015 19:29:04 +0200
with message-id <20150905192904.2128a...@heffalump.lan>
and subject line Re: Bug#798057: ITP RFS: node-sprintf-js/1.0.3-1
has caused the Debian Bug report #798057,
regarding ITP RFS: node-sprintf-js/1.0.3-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.)


-- 
798057: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798057
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 "node-sprintf-js"

 * Package name: node-sprintf-js
   Version : 1.0.3-1
   Upstream Author :Alexandru Marasteanu
 * URL : https://github.com/alexei/sprintf.js/issues
 * License : BSD-3-Clause
   Section : web

  It builds those binary packages:

node-sprintf-js - JavaScript sprintf implementation

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

  http://mentors.debian.net/package/node-sprintf-js


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

dget -x 
http://mentors.debian.net/debian/pool/main/n/node-sprintf-js/node-sprintf-js_1.0.3-1.dsc

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

  About linitan warning I have fixed it directly on lintian (as a DM
of lintian).

This package is a direct depend of grunt

  Regards,
   bastien roucaries
--- End Message ---
--- Begin Message ---
On Sat, 5 Sep 2015 15:49:50 +0200, Bastien ROUCARIES
 wrote:
> On Sat, Sep 5, 2015 at 1:41 PM, Stephen Kitt  wrote:
> > Just a few comments:
> > * debian/README.Source should be README.source (policy 4.14)
> 
> DOne. Will add a lintian tag.
> > * debian/changelog still has UNRELEASED
> Done. Will also add a lintian tag

I like that approach, adding lintian tags for these kinds of things!

> > * I'd rather have "Priority: optional" but I didn't check the other
> >   dependencies
> Done.
> > * is there any point in symlinking the source code contained in the
> > upstream package in missing-sources (other than fixing a Lintian warning)?
> Removed. Fixed upstream on debian.
> 
> > * debian/copyright should reproduce the license grant given by upstream
> >   verbatim (OK, this is really "couper les cheveux en quatre")
> 
> Done

I meant that the "License" stanza in debian/copyright should really be copied
exactly from the LICENSE file (in this particular package), so

diff -u <(cut -c2- debian/copyright) LICENSE

doesn't show any difference in the license content. But it's not that
important since the meaning is the same, so I'll upload the package as-is.
(Strictly speaking "All rights reserved." is a bit contradictory here, and it
may be considered part of the copyright statement rather than the license
grant... But upstream put it there, so let's keep it.)

Thanks for your work,

Stephen


pgpteZDKabVXU.pgp
Description: OpenPGP digital signature
--- End Message ---

What to do with a kernel bug which lets my package work result look bad ?

[Thomas Schmitt]

Hi,

maybe somewhat off topic, but i don't know where else
to ask for advise:

While doing regression tests with my readily prepared
packages (*), i stumbled over a bug in fs/isofs/rock.c which
truncates filenames of length 254 or 255 to quite random
lengths and thus can let readdir(3) emit multiple identical
names in the same directory.

I can reproduce. I see the buggy constant "254" in line 270
of https://github.com/torvalds/linux/blob/master/fs/isofs/rock.c
as well as in my Sid's /usr/src/linux-source-4.1/fs/isofs/rock.c.
I see a coarse reaction which leads to the really bad behavior
in userland.

What to do now with this knowledge ?

Does Debian have a kernel department ? With round tuits ?

(On LKML they will at best urge me to fix it myself.
 But i have my own alternative ready in userland. And my
 kernel skills stem from a short adventure in NetBSD's
 ISO 9660 driver. This constant "254" might have a good
 reason. Who can tell ?)

(*) I found two sponsor candidates. Now i am waiting
whether the packages will get de-orphaned or
re-parented. Thanks again for this list's support.


Have a nice day :)

Thomas

Re: What to do with a kernel bug which lets my package work result look bad ?

[Rebecca N. Palmer]

Report a bug (or if someone has already reported this against your 
package, reassign it) with


Package: src:linux
Control: affects -1 

'affects' means it will appear in your package's bug list but be marked 
as linux's bug.  (Example, now fixed: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767148 )

Bug#798044: RFS: php-mf2/0.2.12-1 [ITP] -- Microformats2 is the simplest way to markup structured information in HTML.

[Gianfranco Costamagna]

Hi Bhuvan

the packaging looks good to me, however I have some issues that you might want 
to address:

1) 
override_dh_install:
dh_install


well, this is funny and useless :)

2) no watch file is usually bad...
please add one if possible

3) DH_VERBOSE in the rules file might be disabled, not an issue, just be sure 
that you want verbose
log by default.

4) debian/install.

well, upstream might want to have a custom Makefile for installing stuff

5) copyright: 

License: AGPL-3+
Released under the GNU Affero General Public License, version 3 or later.
See https://www.gnu.org/licenses/agpl.html for terms.


I usually prefer the same license as upstream, this way you avoid license 
incompatibilities
in patch forwarding upstream and you make easier to keep the copyright updated.

moreover the license text should be extended
http://sources.debian.net/src/ghostscript/9.16%7Edfsg-2/debian/copyright/?hl=59#L387

6) lintian complains from mentors

I composer-package-without-pkg-php-tools-builddep 
I description-synopsis-might-not-be-phrased-properly 


7) (something strictly personal)
usr/share/php/Mf2

I personally do not like Upper Case in Linux, but this is just me, and you 
shouldn't diverge
on path from upstream.

However please consider making it lower case.


(note: I have little php knowledge, so I'm not sure I'll be able to sponsor the 
package, sorry)

cheers,

G.




Il Venerdì 4 Settembre 2015 21:03, Bhuvan Krishna  ha 
scritto:
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

  I am looking for a sponsor for my package "php-mf2":

* Package name: php-mf2
   Version : 0.2.12
Upstream Author : Barnaby Walters 
* URL : http://microformats.org/wiki/microformats-2
* License : MIT
  Programming Lang: PHP


  It installs files to /usr/share/php/Mf2

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

  http://mentors.debian.net/package/php-mf2


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

  dget -x
http://mentors.debian.net/debian/pool/main/p/php-mf2/php-mf2_0.2.12-1.dsc

  More information about hello can be obtained from
http://microformats.org/wiki/microformats-2#PHP.

  Regards,
Bhuvan Krishna

Re: error adding symbols: DSO missing from command line

[J.S.Júnior]

> Em 04/09/2015, à(s) 19:17, Craig Small  escreveu:
> 
> On Fri, Sep 04, 2015 at 08:33:52PM +0200, Jakub Wilk wrote:
>> "help" is not a helpful subject. I updated it, so that is provides some
>> context.
> :)
> 

Thanks. :)

>> If you want people to help you, you need to make it easy for them to
>> understand and reproduce the problem. In case of compiler errors, including
>> the compiler command that failed is absolute minimum.
> Especially for this one, the common problem here is that the order of
> options is wrong.
> 

I’m compiler for debianaze .

> e.g. ld thing.o -lqdb -lthingqbneeds
> So if libqdb needs symbols from libthingqdbneeds it will error like
> this.
> 
> Sometimes the dpkg-buildflags (correctly) trips these things up. I've
> found them a useful check for getting upstream in order.
> 
> But yes, as Jakub said, bit hard to debug this further without the
> actual command line.
> 

I don’t find "ld thing.o -lqdb -lthingqbneeds" in upstream code

> - Craig
> 
> --
> Craig Small (@smallsees)   http://enc.com.au/   csmall at : enc.com.au
> Debian GNU/Linux   http://www.debian.org/   csmall at : debian.org
> GPG fingerprint:5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5
> 

Thanks Crag and Thanks Jakub



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#798057: ITP RFS: node-sprintf-js/1.0.3-1

[Bastien ROUCARIES]

On Sat, Sep 5, 2015 at 1:41 PM, Stephen Kitt  wrote:
> Control: owner -1 !
> Control: tag -1 + moreinfo
>
> Salut Bastien,
>
> On Sat, 5 Sep 2015 00:17:01 +0200, Bastien ROUCARIES
>  wrote:
>>   I am looking for a sponsor for my package "node-sprintf-js"
>>
>>  * Package name: node-sprintf-js
>>Version : 1.0.3-1
>>Upstream Author :Alexandru Marasteanu
>>  * URL : https://github.com/alexei/sprintf.js/issues
>>  * License : BSD-3-Clause
>>Section : web
>>
>>   It builds those binary packages:
>>
>> node-sprintf-js - JavaScript sprintf implementation
>>
>>   To access further information about this package, please visit the
>> following URL:
>>
>>   http://mentors.debian.net/package/node-sprintf-js
>
> Thanks for packaging this!
>
> Just a few comments:
> * debian/README.Source should be README.source (policy 4.14)

DOne. Will add a lintian tag.
> * debian/changelog still has UNRELEASED
Done. Will also add a lintian tag
> * I'd rather have "Priority: optional" but I didn't check the other
>   dependencies
Done.
> * is there any point in symlinking the source code contained in the upstream
>   package in missing-sources (other than fixing a Lintian warning)?
Removed. Fixed upstream on debian.

> * debian/copyright should reproduce the license grant given by upstream
>   verbatim (OK, this is really "couper les cheveux en quatre")

Done

Reuploaded
> Regards,
>
> Stephen

Bug#797898: RFS: caffe/0.9999~rc2+git20150902+e8e660d3-1 [ITP]

[lumin]

On Fri, 2015-09-04 at 17:14 +, Gianfranco Costamagna wrote:
> Hi again,
> 
> The package doesn't build in a clean environment.
> 
> http://debomatic-amd64.debian.net/distribution#experimental/caffe/0.~rc2+git20150902+e8e660d3-1/buildlog

Well, I am surprised source Caffe suffers FTBFS on x86 and x86_64.
While the source never fails to build on my machines...

  Debomatic build result

amd64   [FTBFS] caffe-cuda: ld error: undefined reference to xxx [1]
arm64   [ - ]
armel   [ - ]
armhf   [ debomatic issue ? ] nearly success but failed several tests, then: 
qemu: uncaught target signal 6 (Aborted) - core dumped [3]
i386[FTBFS] dh_auto_configure: cmake error: variables NOTFOUND [2]
mipsel  [ debomatic issue ] apt-get update failed
mips[ - ]
powerpc [ debomatic issue ] E: Failed to execute “/usr/bin/aptitude”: Exec 
format error [4]
ppc64el [ - ]
s390x   [ debomatic issue ] E: Failed to execute “/usr/bin/aptitude”: Exec 
format error [5]

I have been looking into this issue for a while.

[1] 
http://debomatic-amd64.debian.net/distribution#experimental/caffe/0.~rc2+git20150902+e8e660d3-1/buildlog
[2] 
http://debomatic-i386.debian.net/distribution#experimental/caffe/0.~rc2+git20150902+e8e660d3-1/buildlog
[3] 
http://debomatic-armhf.debian.net/distribution#experimental/caffe/0.~rc2+git20150902+e8e660d3-1/buildlog
[4] 
http://debomatic-powerpc.debian.net/distribution#experimental/caffe/0.~rc2+git20150902+e8e660d3-1/buildlog
[5] 
http://debomatic-s390x.debian.net/distribution#experimental/caffe/0.~rc2+git20150902+e8e660d3-1/buildlog



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

Re: What to do with a kernel bug which lets my package work result look bad ?

[Henrique de Moraes Holschuh]

On Sat, 05 Sep 2015, Thomas Schmitt wrote:
> packages (*), i stumbled over a bug in fs/isofs/rock.c which
> truncates filenames of length 254 or 255 to quite random
> lengths and thus can let readdir(3) emit multiple identical
> names in the same directory.

Ugh.  Yeah, that code looks broken at first glance.  Looks like it doesn't
try to return as much as possible of a file name when it hits the character
limit: it seems to just end the filename at the previous chunk.

Maybe it should instead drop the long name, and return the ISOFS name,
instead.  Nasty crap will, of course, happen if there is a
colision between the two namespaces.  I don't know enough about Rock Ridge
to know whether it mandates something specific in this regard.

Whatever is done to fix this, it needs to properly handle 255-byte file
names, anyway.  A simple fix at first glance would be to append enough of
the current chunk to hit exactly the 255-byte boundary, and truncate at that
point.  This would fix the issue for all valid ISOFS+RRIP filename sizes.

However, one has to check the code throughoutly to ensure it can deal with
the 255-bytes size.  If it doesn't, that's a separate bug that needs fixing.

> What to do now with this knowledge ?

Opening a bug report on bugzilla.kernel.org for 'isofs' would be the typical
way to go about it, I guess.  You could just report in LKML as well, but
then you must ask again should nobody reply after two weeks, etc.

> Does Debian have a kernel department ? With round tuits ?

We do, but they're often overworked.  You can file a bug in the Debian BTS
against the "linux" source package, which is the kernel.

> (On LKML they will at best urge me to fix it myself.

They'd like you to do that, I suppose, since nobody is really working on
ISOFS.  But this is a clear bug that hits legal filesystems, so it is not a
"fix it yourself" deal.  It MIGHT be a "fix it yourself if you want it done
anytime soon", though :-(

OTOH, it is a >10-year old bug, so there are some kudos and credit to be
proud of for anyone that fixes it :-)

>  ISO 9660 driver. This constant "254" might have a good
>  reason. Who can tell ?)

Most of the RRIP support in Linux ISOFS predates git (2.6.11/2.6.12), which
kinda means in practice that you are better off analysing the code in depth
to find out its limitations (and fix them).

The code in fs/isofs/rock.c looks like it has lots of cowebs and some
bitrot, though.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Bug#798044: RFS: php-mf2/0.2.12-1 [ITP] -- Microformats2 is the simplest way to markup structured information in HTML.

[Bhuvan Krishna]

Hi Gianfranco,

Thanks a lot for reviewing the package I will do the necessary changes
as suggested. I will make the upper case to lower too as suggested ;)

Regards,
Bhuvan

On Sunday 06 September 2015 03:19 AM, Gianfranco Costamagna wrote:
> Hi Bhuvan
>
> the packaging looks good to me, however I have some issues that you might 
> want to address:
>
> 1) 
> override_dh_install:
> dh_install
>
>
> well, this is funny and useless :)
>
> 2) no watch file is usually bad...
> please add one if possible
>
> 3) DH_VERBOSE in the rules file might be disabled, not an issue, just be sure 
> that you want verbose
> log by default.
>
> 4) debian/install.
>
> well, upstream might want to have a custom Makefile for installing stuff
>
> 5) copyright: 
>
> License: AGPL-3+
> Released under the GNU Affero General Public License, version 3 or later.
> See https://www.gnu.org/licenses/agpl.html for terms.
>
>
> I usually prefer the same license as upstream, this way you avoid license 
> incompatibilities
> in patch forwarding upstream and you make easier to keep the copyright 
> updated.
>
> moreover the license text should be extended
> http://sources.debian.net/src/ghostscript/9.16%7Edfsg-2/debian/copyright/?hl=59#L387
>
> 6) lintian complains from mentors
>
> I composer-package-without-pkg-php-tools-builddep 
> I description-synopsis-might-not-be-phrased-properly 
>
>
> 7) (something strictly personal)
> usr/share/php/Mf2
>
> I personally do not like Upper Case in Linux, but this is just me, and you 
> shouldn't diverge
> on path from upstream.
>
> However please consider making it lower case.
>
>
> (note: I have little php knowledge, so I'm not sure I'll be able to sponsor 
> the package, sorry)
>
> cheers,
>
> G.
>
>
>
>
> Il Venerdì 4 Settembre 2015 21:03, Bhuvan Krishna  ha 
> scritto:
> Package: sponsorship-requests
> Severity: wishlist
>
> Dear mentors,
>
>   I am looking for a sponsor for my package "php-mf2":
>
> * Package name: php-mf2
>Version : 0.2.12
> Upstream Author : Barnaby Walters 
> * URL : http://microformats.org/wiki/microformats-2
> * License : MIT
>   Programming Lang: PHP
>
>
>   It installs files to /usr/share/php/Mf2
>
>   To access further information about this package, please visit the
> following URL:
>
>   http://mentors.debian.net/package/php-mf2
>
>
>   Alternatively, one can download the package with dget using this command:
>
>   dget -x
> http://mentors.debian.net/debian/pool/main/p/php-mf2/php-mf2_0.2.12-1.dsc
>
>   More information about hello can be obtained from
> http://microformats.org/wiki/microformats-2#PHP.
>
>   Regards,
> Bhuvan Krishna
>




signature.asc
Description: OpenPGP digital signature

Re: Bug#797898: RFS: caffe/0.9999~rc2+git20150902+e8e660d3-1 [ITP]

[lumin]

Hi Gianfranco Costamagna,

On Fri, 2015-09-04 at 17:04 +, Gianfranco Costamagna wrote:
> if they aren't called by standard dh calls it is fine to keep them there.
> 
> maybe just move to the bottom, (I think they are already there)

I will keep those custom target in the bottom of d/rules.
Yes, all of custom-target-related lines had been already 
clustered at the bottom of d/rules, and I have drew a big
split line at the beginning of them, in the updated version.

> well, they aren't called by buildd systems, so I don't care.
> 
> Users who apt-get source your package should also know how to build
> the custom stuff.

The custom stuff is explained in the README.Debian, and it
in fact includes a custom compile guide and some more other
things.

> I guess you already did it correctly.
> 
> I like this version more than the previous one (note, I didn't test a build)
> 
> anyway:
> please add gcc/g++ 4.9 or whatever to the b-d in control file. It is not 
> guarantee
> specially after the gcc-5 switch that they will be there.

I have added g{cc,++}-4.9 in the updated d/control, so this package
won't FTBFS due to dependency bump of build-essential to gcc5.

However if CUDA/experimental is an updated version (7.0), 
gcc5 should be able to work.
(I successfully built Caffe on ArchLinux + CUDA 7 + gcc 5)

> to see if nvidia is available (amd or i386 I would do something like:
> 
> In rules file, to see
> ifeq ($(shell dpkg-query --status nvidia-cuda-toolkit |grep -o Package), 
> Package)
> 
> flag_build_caffe_cuda := y
> 
> endif

I think this is better than above:

 19 ifeq (installed, $(shell dpkg -s nvidia-cuda-toolkit | grep -o installed))
 20 flag_build_caffe_cuda := y
 21 endif

then we can make sure nvidia-cuda-toolkit is "installed" on
system rather than "residual-config" or something else.

Thank you for this trick and it looks cool.
:-)

> this way you avoid a double "if" and if tomorrow cuda gets another arch 
> support, you just need
> to add it in the control file.

Thanks.



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