Bug#799205: RFS: eviacam/2.0.1-1 [ITP] -- webcam based mouse emulator

[Cesar Mauri]

Hi Alex (and all),


About the `hardening-no-fortify-functions' lintian warning, I use the
`debian/rule' template generated by dh_make and merges it with the
original `debian/rule' file. Now the warning goes away with the new
`debian/rule' file, which is in the attachment. Please try to see if
it works!


I merged your changes. I builds fine and it seems that the lintian warning
is gone.

Thank you!

Regards, Cesar

Bug#800403: RFS: node-util-deprecate/1.0.1-1 [ITP]

[Ross Gammon]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "node-util-deprecate"

* Package name: node-util-deprecate
  Version : 1.0.1-1
  Upstream Author : Nathan Rajlich 
* URL : https://github.com/TooTallNate/util-deprecate
* License : Expat
  Section : web

It builds this binary package:

node-util-deprecate - Node.js's `util.deprecate()` function with browser
support

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

http://mentors.debian.net/package/node-util-deprecate


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

dget -x http://mentors.debian.net/debian/pool/main/n/node-util-deprecate/node-
util-deprecate_1.0.1-1.dsc

Packaging can be found in the Javascript Team repository at:
http://anonscm.debian.org/cgit/pkg-javascript/node-util-deprecate.git/

Changes since the last upload:

  * Initial release (Closes: #796365)


Regards,
Ross Gammon




-- System Information:
Debian Release: jessie/sid
  APT prefers vivid-updates
  APT policy: (500, 'vivid-updates'), (500, 'vivid-security'), (500, 'vivid'), 
(100, 'vivid-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.19.0-28-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

python-fabio circular dependency

[PICCA Frederic-Emmanuel]

Hello, I would like to solve a circular dependency with the python-fabio package

before (N) binaries

python-fabio

after (N+1) binaries

fabio_viewer
python-fabio
python-fabio-dbg
python3-fabio
python3-fabio-dbg


for this new version, I move the /usr/bin files from python-fabio (N) into 
fabio_viewer (N+1).
So I did a split (script + python-module) of python-fabio (N) in two separate 
binary packages (fabio_viewer + python-fabio N+1)

Here is my problem

I want during the upgrade (python-fabio N)  -> python-fabio N+1 to install also 
the fabio_viewer.
this way the user has the same amount of services on it system.
(python-fabio n contains also the scripts) 

so I added a DEpends on fabio_viewer to pyton-fabio (n+1)

and now I have

fabio_viewer -> python-fabio -> fabio_viewer  and I got a bug report :)

So what is the best way to solve my problem.

upgrade  with same functionnality but without this circulardependency.
Indeed fabio_viewer MUST depends on python-fabio.


Thanks for your help

Frederic

Bug#799205: RFS: eviacam/2.0.1-5 [ITP] -- webcam based mouse emulator

[Cesar Mauri]

Hi,


this is a string I used recently for another package help2man -N -n
"enhanced HTTPS support for httplib and urllib2 using PyOpenSSL"
/usr/bin/ndg_httpclient --version-string=v0.4.0 > ndg_httpclient.1


done. thanks for the hint.



I see

#CPPFLAGS="$CPPFLAGS $COMPFLAGS" CPPFLAGS="$COMPFLAGS"
#CXXFLAGS="$CXXFLAGS $COMPFLAGS" CXXFLAGS="$COMPFLAGS"

commit fc42432855a02c6881199ff09eef95e84db43345 Author: Cesar Mauri
 Date:   Tue Mar 8 20:29:04 2011 +0100

Fixed compilation flags to produce a debuggable in debug mode


well, I guess maybe you didn't apply correctly the patch?


Those lines are probably the result of some trials
that I forgot to cleanup :)

I tidied up a bit the configuration.ac and Makefile.am files



I would like to understand the rationale for that commit!


The point of that commit was to add the debugging flags to the
compiler command line.

 if ! "$debug"; then
-   COMPFLAGS="$COMPFLAGS -DNDEBUG"
+   COMPFLAGS="$COMPFLAGS -DNDEBUG -O2"
+else
+   COMPFLAGS="$COMPFLAGS -DDEBUG -g -O0"
 fi



maybe by providing an eviacam-doc package, because I bet the 6MB are
because of the documentation.


right



But well, it isn't too much, you can also just don't care

(just think about small systems, where space matters, but I'm not
sure they will run a webcam)


OK. Then, let's leave it as is.



P: eviacam source: debian-watch-may-check-gpg-signature

this is about gpg signing the releases, but I'm not sure sf supports
that


Not sure about how much important is this issue (says pedantic).

Perhaps I should consider another way to publish the tarball...

 

Perhaps I could fix the remaining issues, bump the upstream version
number and then upload the (right) tarball.


yes, but I hope you will considering having the Debian packaging in
a different branch that way you are not forced to do a new upstream
release at each Debian upload. (that might be just because of a
packaging issue)


also other linux distros might not like the Debian directory :)


Agreed. It will be better to keep the packaging files in a different branch.

Moreover, I'm also considering building the tarball directly from the
repository (i.e. using git-archive) instead of building it from sources.
The latter approach (the one I'm currently using) produces (slightly) different
tarballs for each run (due to changes in the atime of some files, I guess),
and so are the digital signatures

I tried with git-archive and it seems that it generate the very same
tarball given a specific commit (even tried cloning the repo).

However, I'm not sure if the git-archive approach has any downsides.
What do you think?



I guess override_dh_auto_build: dh_auto_build and here generate them
# for i in `ls po`; do \ #msgfmt -o "po/$$i.mo" \
# "po/$$i.po"; \

#   fi; \ # done; \


or just generate them in your Makefile.am or whatever

you can also use pocompile if needed, just add the required
build-dependency.


Thanks. Finally, I solved like this:

override_dh_auto_build:
cd po; make update-po; cd ..



last two issues: "Recommends: wx3.0-i18n"

can you please clarify? is that required or not?


Is not strictly required for running eviacam.



does the build work with or without?


The build works fine in both cases.



does it increase the user experience?


I think so. It provides localization for common strings
(e.g. 'Yes', 'No', 'Cancel', etc.)



and... what about having a dbg package too?


I understand that a dbg package is "...useful if program crashes and you
want to generate stack trace..." [1]. But not sure who might take advantage
if this kind of package. I think that I need more information about this.

[1] https://wiki.debian.org/DebugPackage


Regards, Cesar

Bug#799268: RFS: ck/1.6.2 [ITP]

[Grigori Fursin]

Dear colleagues,

I fixed all the issues with my package, added the latest
upstream release, and uploaded the new version to Debian mentors:

http://mentors.debian.net/package/python-ck

The only problem is that I have an error message there
"Bug #799268 does not belong to this package"

Can it be because I originally submitted a request
for package 'ck' and not 'python-ck'?

Is there a way to change it?

Thanks a lot and have a good week,
Grigori


-Original Message- 
From: Grigori Fursin

Sent: Saturday, September 19, 2015 11:18 AM
To: Gianfranco Costamagna ; Lucas Nussbaum ; 799...@bugs.debian.org
Subject: Bug#799268: RFS: ck/1.6.2 [ITP]

Actually, it's done more or less like that.
ck is a batch script that sets environment and calls python module.

So, it should be easy to change the name if will be required.

However, I made some search and didn't not find obvious conflicts so far ;)
...

Thanks,
Grigori

-Original Message- 
From: Gianfranco Costamagna

Sent: Friday, September 18, 2015 4:02 PM
To: Lucas Nussbaum ; Grigori Fursin ; 799...@bugs.debian.org
Subject: Bug#799268: RFS: ck/1.6.2 [ITP]






Oh, I didn't know that :( . Will it really be a problem (I didn't see any
tool called ck yet)? The problem is that our users now share some 
artifacts

in this format and they use this name (in scripts or internal calls),
so changing this name now will be a nightmare :( ...


I'm not sure if there's an official policy about that. It's probably
worth trying to upload with a ck binary, and see if someone complains :)




I guess you can always install a longer name and create a symlink to ck.
(and bother upstream about it)


this way people can move to the new binary, and if somebody complain you can
"safely" drop the symlink.

(or use some "update-alternative" tools I don't remember how)


Just my .02$

G. 

Bug#799268: RFS: ck/1.6.2 [ITP]

[Grigori Fursin]

Hi Gianfranco,

But I already retitled it some time ago as you
suggested (including the latest upstream version)
and it's now: RFS: python-ck/1.6.11-1 [ITP]

My submitted package name is also python-ck.

However, it still says that
"Bug #799268 does not belong to this package"

That's why I am not sure what's wrong :( ...

Maybe the package name is taken from the body
of the original message, i.e. "ck" instead of "python-ck"?

Sorry for bothering with that and thanks for your help,
Grigori






-Original Message- 
From: Gianfranco Costamagna

Sent: Monday, September 28, 2015 10:21 AM
To: Grigori Fursin ; 799...@bugs.debian.org
Subject: Bug#799268: RFS: ck/1.6.2 [ITP]

Hi,

https://www.debian.org/Bugs/server-control


retitle is the keyword :)

cheers,

G.


Il Lunedì 28 Settembre 2015 10:15, Grigori Fursin 
 ha scritto:

Dear colleagues,

I fixed all the issues with my package, added the latest
upstream release, and uploaded the new version to Debian mentors:

http://mentors.debian.net/package/python-ck

The only problem is that I have an error message there
"Bug #799268 does not belong to this package"

Can it be because I originally submitted a request
for package 'ck' and not 'python-ck'?

Is there a way to change it?

Thanks a lot and have a good week,
Grigori



-Original Message- 
From: Grigori Fursin

Sent: Saturday, September 19, 2015 11:18 AM
To: Gianfranco Costamagna ; Lucas Nussbaum ; 799...@bugs.debian.org
Subject: Bug#799268: RFS: ck/1.6.2 [ITP]

Actually, it's done more or less like that.
ck is a batch script that sets environment and calls python module.

So, it should be easy to change the name if will be required.

However, I made some search and didn't not find obvious conflicts so far ;)
...

Thanks,
Grigori

-Original Message- 
From: Gianfranco Costamagna

Sent: Friday, September 18, 2015 4:02 PM
To: Lucas Nussbaum ; Grigori Fursin ; 799...@bugs.debian.org
Subject: Bug#799268: RFS: ck/1.6.2 [ITP]






Oh, I didn't know that :( . Will it really be a problem (I didn't see any
tool called ck yet)? The problem is that our users now share some
artifacts
in this format and they use this name (in scripts or internal calls),
so changing this name now will be a nightmare :( ...


I'm not sure if there's an official policy about that. It's probably
worth trying to upload with a ck binary, and see if someone complains :)




I guess you can always install a longer name and create a symlink to ck.
(and bother upstream about it)


this way people can move to the new binary, and if somebody complain you can
"safely" drop the symlink.

(or use some "update-alternative" tools I don't remember how)


Just my .02$

G. 

Bug#799268: RFS: ck/1.6.2 [ITP]

[Gianfranco Costamagna]

Hi,

https://www.debian.org/Bugs/server-control


retitle is the keyword :)

cheers,

G.


Il Lunedì 28 Settembre 2015 10:15, Grigori Fursin  
ha scritto:
Dear colleagues,

I fixed all the issues with my package, added the latest
upstream release, and uploaded the new version to Debian mentors:

http://mentors.debian.net/package/python-ck

The only problem is that I have an error message there
"Bug #799268 does not belong to this package"

Can it be because I originally submitted a request
for package 'ck' and not 'python-ck'?

Is there a way to change it?

Thanks a lot and have a good week,
Grigori



-Original Message- 
From: Grigori Fursin
Sent: Saturday, September 19, 2015 11:18 AM
To: Gianfranco Costamagna ; Lucas Nussbaum ; 799...@bugs.debian.org
Subject: Bug#799268: RFS: ck/1.6.2 [ITP]

Actually, it's done more or less like that.
ck is a batch script that sets environment and calls python module.

So, it should be easy to change the name if will be required.

However, I made some search and didn't not find obvious conflicts so far ;)
...

Thanks,
Grigori

-Original Message- 
From: Gianfranco Costamagna
Sent: Friday, September 18, 2015 4:02 PM
To: Lucas Nussbaum ; Grigori Fursin ; 799...@bugs.debian.org
Subject: Bug#799268: RFS: ck/1.6.2 [ITP]

>

>> Oh, I didn't know that :( . Will it really be a problem (I didn't see any
>> tool called ck yet)? The problem is that our users now share some 
>> artifacts
>> in this format and they use this name (in scripts or internal calls),
>> so changing this name now will be a nightmare :( ...
>
>I'm not sure if there's an official policy about that. It's probably
>worth trying to upload with a ck binary, and see if someone complains :)



I guess you can always install a longer name and create a symlink to ck.
(and bother upstream about it)


this way people can move to the new binary, and if somebody complain you can
"safely" drop the symlink.

(or use some "update-alternative" tools I don't remember how)


Just my .02$

G.

Bug#799268: RFS: ck/1.6.2 [ITP]

[Gianfranco Costamagna]

You need to open an ITP bug
https://www.debian.org/devel/wnpp/
and close *that* bug.

the RFS bug is closed by your sponsor when the upload is performed.

cheers,

G.





Il Lunedì 28 Settembre 2015 10:34, Grigori Fursin  
ha scritto:
Hi Gianfranco,

But I already retitled it some time ago as you
suggested (including the latest upstream version)
and it's now: RFS: python-ck/1.6.11-1 [ITP]

My submitted package name is also python-ck.

However, it still says that
"Bug #799268 does not belong to this package"

That's why I am not sure what's wrong :( ...

Maybe the package name is taken from the body
of the original message, i.e. "ck" instead of "python-ck"?

Sorry for bothering with that and thanks for your help,
Grigori







-Original Message- 
From: Gianfranco Costamagna
Sent: Monday, September 28, 2015 10:21 AM
To: Grigori Fursin ; 799...@bugs.debian.org
Subject: Bug#799268: RFS: ck/1.6.2 [ITP]

Hi,

https://www.debian.org/Bugs/server-control


retitle is the keyword :)

cheers,

G.


Il Lunedì 28 Settembre 2015 10:15, Grigori Fursin 
 ha scritto:
Dear colleagues,

I fixed all the issues with my package, added the latest
upstream release, and uploaded the new version to Debian mentors:

http://mentors.debian.net/package/python-ck

The only problem is that I have an error message there
"Bug #799268 does not belong to this package"

Can it be because I originally submitted a request
for package 'ck' and not 'python-ck'?

Is there a way to change it?

Thanks a lot and have a good week,
Grigori



-Original Message- 
From: Grigori Fursin
Sent: Saturday, September 19, 2015 11:18 AM
To: Gianfranco Costamagna ; Lucas Nussbaum ; 799...@bugs.debian.org
Subject: Bug#799268: RFS: ck/1.6.2 [ITP]

Actually, it's done more or less like that.
ck is a batch script that sets environment and calls python module.

So, it should be easy to change the name if will be required.

However, I made some search and didn't not find obvious conflicts so far ;)
...

Thanks,
Grigori

-Original Message- 
From: Gianfranco Costamagna
Sent: Friday, September 18, 2015 4:02 PM
To: Lucas Nussbaum ; Grigori Fursin ; 799...@bugs.debian.org
Subject: Bug#799268: RFS: ck/1.6.2 [ITP]

>

>> Oh, I didn't know that :( . Will it really be a problem (I didn't see any
>> tool called ck yet)? The problem is that our users now share some
>> artifacts
>> in this format and they use this name (in scripts or internal calls),
>> so changing this name now will be a nightmare :( ...
>
>I'm not sure if there's an official policy about that. It's probably
>worth trying to upload with a ck binary, and see if someone complains :)



I guess you can always install a longer name and create a symlink to ck.
(and bother upstream about it)


this way people can move to the new binary, and if somebody complain you can
"safely" drop the symlink.

(or use some "update-alternative" tools I don't remember how)


Just my .02$

G.

Bug#800319: marked as done (RFS: arrayfire/3.1.2+dfsg1-1)

[Debian Bug Tracking System]

Your message dated Mon, 28 Sep 2015 11:07:04 + (UTC)
with message-id <1165771024.2670139.1443438424974.javamail.ya...@mail.yahoo.com>
and subject line Re: Bug#800319: RFS: arrayfire/3.1.2+dfsg1-1
has caused the Debian Bug report #800319,
regarding RFS: arrayfire/3.1.2+dfsg1-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.)


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

* Package name: arrayfire
  Version : 3.1.2+dfsg1-1
  Upstream Author : ArrayFire Development Group
* URL : http://arrayfire.com/
* License : BSD
  Section : science

It builds those binary packages:

  libarrayfire-cpu-dev - Development files for ArrayFire (CPU backend)
  libarrayfire-cpu3 - High performance library for parallel computing 
(CPU backend)

  libarrayfire-cpu3-dbg - Debugging symbols for ArrayFire (CPU backend)
  libarrayfire-doc - Common documentation for ArrayFire

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


  http://mentors.debian.net/package/arrayfire

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

  dget -x 
http://mentors.debian.net/debian/pool/main/a/arrayfire/arrayfire_3.1.2+dfsg1-1.dsc


Changes since the last upload:

  * New upstream release.
  * d/patches:
- refresh patch bugfix-in-assign.patch,
- drop patch bugfix-cpuid-usage.patch, applied upstream.
  * d/rules: drop restriction of test suite to 64-bit architectures only.

Best regards,
Ghislain Vaillant
--- End Message ---
--- Begin Message ---
Hi Ghislain,

I sponsored the package, however :



1) ./src/backend/cpu/platform.cpp:mVendorId = "Unkown, probably ARM";


(typo)


2) I was also a little bit worried about the rules file, but your indep/arch
targets seems to work, for this reason I did a source-only upload, lets see
it buildd works too :)

3) I couldn't test arm64, please consider checking if the arch builds fine next 
time

4) please run again wrap-and-sort, because the control file looks ugly in this 
upload
(at least to me, but you are free to put this nitpick in dev/null :D )

5) please try to be more verbose in changelog
"- refactor  rules file by splitting targets" or whatever might be worth a 
mention.

But the package was fine, so Built, thanks for your 
contribution to Debian!

cheers,

G.--- End Message ---

Bug#799615: RFS: netmask/2.4.0-1 [ITA] - helps determine network masks

[Paul Wise]

On Mon, 2015-09-28 at 13:13 +0200, Guilhem Moulin wrote:

> That's also what I understand since you wrote that upfront.  Sorry if I
> sounded rude :-/  I was merely arguing in case a potential sponsor would
> wait for me to fix these before stepping forward ;-)

I see, thanks for the clarification. I agree these are minor issues.

> Yeah, many thanks for the review anyway.  And as far as I'm concerned
> the advertisement is a success and I'll make sure to watch your talk from
> Debconf ;-)

This year was only a check-all-the-things BoF and it wasn't recorded
but I presented the tool at DebConf14 in the live demos session:

http://meetings-archive.debian.net/pub/debian-meetings/2014/debconf14/webm/Live_Demos.webm
https://gobby.debian.org/export/debconf15/bof/check-all-things

> Yes indeed, I also found this tarball, but it's much older than github's
> 2.4.0.  In particular IPv6 addresses are not supported.

Interesting, so I guess the version numbers are a bit murky :(

> Yeah the way #718434 is a pity IMHO :-/  Anyway that's why I intend to
> to switch to Let's Encrypt in two months.

LE can't come soon enough :)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#799615: RFS: netmask/2.4.0-1 [ITA] - helps determine network masks

[Guilhem Moulin]

On Mon, 28 Sep 2015 at 11:37:39 +0200, Paul Wise wrote:
> On Fri, Sep 25, 2015 at 9:26 PM, Guilhem Moulin wrote:
>> not a reason for rejection
> 
> Not being willing to sponsor the package isn't a rejection, just an
> indicator that I don't have time for a proper initial review and
> ongoing sponsorship.

That's also what I understand since you wrote that upfront.  Sorry if I
sounded rude :-/  I was merely arguing in case a potential sponsor would
wait for me to fix these before stepping forward ;-)

> My mail was part quick review for things you might want to look at and
> part advertisment for the check-all-the-things tool :)

Yeah, many thanks for the review anyway.  And as far as I'm concerned
the advertisement is a success and I'll make sure to watch your talk from
Debconf ;-)

>> Done for the homepage and upstream/metadata.  Thanks for the tips.
>> (Unfortunately upstream currently doesn't tag their release nor provide
>> tarballs, so the watchfile is useless right now since I don't know how
>> to mangle the versions, right?)
> 
> There is a versioned upstream tarball available on the author's
> website, I assumed that was where you got your tarball from but I
> guess you generated it from github somehow?
> 
> http://trap.mtview.ca.us/~talby/
> http://trap.mtview.ca.us/~talby/netmask_2.4.tar.gz

Yes indeed, I also found this tarball, but it's much older than github's
2.4.0.  In particular IPv6 addresses are not supported.

>> I serve git over (smart) HTTP.  And well, the CA is valid, it just
>> happen not to be in your CA store :-P
> 
> Nor in any other default CA store ;-P

Yeah the way #718434 is a pity IMHO :-/  Anyway that's why I intend to
to switch to Let's Encrypt in two months.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Re: Suggestion of new program: execute mathematical set operations on lists

[Rick Thomas]

On Sep 25, 2015, at 9:11 AM, Frank Stähr  wrote:

> I am ,,,  going to program a tiny tool:
> 
> “setup" takes as inputs several lists/sets, calculates desired (mathematical) 
> set operations on them and outputs the final set (or depending on operation 
> resulting number of elements, answer yes/no, …).
> …
> So my questions is: Is there a need for such a program or is there already 
> something very similar?
> 
> I would be very grateful for your feedback,
> Frank

If it were a Debian package, I’d use it.
Rick

Bug#800140: marked as done (RFS: traitlets/4.0.0-1 [ITP] -- Lightweight Traits-like package)

[Debian Bug Tracking System]

Your message dated Mon, 28 Sep 2015 09:36:56 + (UTC)
with message-id <1925922752.2558020.1443433016076.javamail.ya...@mail.yahoo.com>
and subject line Re: Bug#800140: RFS: traitlets -- Lightweight Traits-like 
package
has caused the Debian Bug report #800140,
regarding RFS: traitlets/4.0.0-1 [ITP] -- Lightweight Traits-like package
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.)


-- 
800140: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800140
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: sponsorship-requests
Severity: wishlist

Hi,

I'm looking for a sponsor for the package:

* Package name: traitlets
  Version : 4.0.0
  Upstream Author : IPython Development Team
* URL : https://github.com/ipython/traitlets
* License : BSD-3-clause
  Programming Lang: Python
  Description : Lightweight Traits-like package
 A lightweight pure-Python derivative of Enthought Traits, used
 for configuring Python objects.
 .
 It powers the config system of IPython and Jupyter.

It is one of the last depends before the newer IPython can be packaged .

It is packaged within the Debian Python Module Team repository here:

Vcs-Git: git://anonscm.debian.org/python-modules/packages/traitlets.git
Vcs-Browser: 
http://anonscm.debian.org/cgit/python-modules/packages/traitlets.git


It builds those binary packages:

python-traitlets - Lightweight Traits-like package for Python 2
 python-traitlets-doc - Lightweight Traits-like package for Python
 python3-traitlets - Lightweight Traits-like package for Python 3

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


  http://mentors.debian.net/package/traitlets

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

dget -x 
http://mentors.debian.net/debian/pool/main/t/traitlets/traitlets_4.0.0-1.dsc



Thanks,

Snark on #debian-python
--- End Message ---
--- Begin Message ---
Built, thanks for your contribution to Debian!


(the fixes were mentioned on irc, sorry for people reading only half the 
discussion :) )



cheers,

Gianfranco--- End Message ---

Bug#799615: RFS: netmask/2.4.0 - helps determine network masks

[Paul Wise]

On Fri, Sep 25, 2015 at 9:26 PM, Guilhem Moulin wrote:

> not a reason for rejection

Not being willing to sponsor the package isn't a rejection, just an
indicator that I don't have time for a proper initial review and
ongoing sponsorship. My mail was part quick review for things you
might want to look at and part advertisment for the
check-all-the-things tool :)

> Done for the homepage and upstream/metadata.  Thanks for the tips.
> (Unfortunately upstream currently doesn't tag their release nor provide
> tarballs, so the watchfile is useless right now since I don't know how
> to mangle the versions, right?)

There is a versioned upstream tarball available on the author's
website, I assumed that was where you got your tarball from but I
guess you generated it from github somehow?

http://trap.mtview.ca.us/~talby/
http://trap.mtview.ca.us/~talby/netmask_2.4.tar.gz

> I serve git over (smart) HTTP.  And well, the CA is valid, it just
> happen not to be in your CA store :-P

Nor in any other default CA store ;-P

> Again I intend to be the maintainer, not upstream :-P  (And the package
> has been around in its current state for 16 years.)  I'll forward your
> remarks upstream though.

Part of the package maintainer's job is to forward patches, bug
reports and feedback upstream, so thanks for doing that :)

https://www.debian.org/doc/manuals/developers-reference/ch03.en.html#upstream-coordination

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Suggestion of new program: execute mathematical set operations on lists

[Alex Vong]

Hi Frank,

I think I know a language that will do what you want, it is called
LISP! Lisp stands for `list processing language' or `lots of
irritating superfluous parentheses' when it doesn't. Lisp allows you
to program as if you were writing mathematics, aka functional
programming.

I learned Lisp from the 1986 6.001 lectures
.
The dialect of Lisp I am using is called Scheme and the implementation
I am using is called Guile
.

For examples on doing sets operations on list, see
,
but you would need to know basic Scheme first. (Just watch the 6.001
lectures, they should blow your mind if you haven't seen Lisp before!)

Examples:
(lset-union eq? '(a b c d e) '(a e i o u))
=> (u o i a b c d e)
(lset<= eq? '(a) '(a b a) '(a b c c))
=> #t

Explanations:
Q: What is the union of (a b c d e) and (a e i o u)
A: (u o i a b c d e)
Q: Is (a) a subset of (a b a) and (a b a) a subset of (a b c c)?
A: True

Cheers,
Alex

2015-09-26 0:11 GMT+08:00, Frank Stähr :
> Hello everybody,
>
> I am not yet looking for a sponsor, but going to program a tiny tool:
>
> "setop" takes as inputs several lists/sets, calculates desired
> (mathematical) set operations on them and outputs the final set (or
> depending on operation resulting number of elements, answer yes/no, …).
>
> For example: File A contains 3 3 2 5 1 (each number an extra line). Then
> setop A
> would result in 1 2 3 5. This is equivalent to
> sort | uniq
>
> With a file B containing 5 90 2 7 the command
> setop -i A B
> would yield 2 5.
>
> Here, -i stands for intersection. Of course, there is no limitation to
> numbers, elements can be any non-empty strings. Other operations are
> union, symmetric difference, difference, contains element, is subset,
> cardinality and so on.
> Is this tool senseful, is there a certain need for it?
>
> As you can see on
> 
> nearly all these operations can already be done with other tools, but
> the according command lines are mostly very tortuous. There doesn’t seem
> to be a tool that directly works with sets.
>
> So my questions is: Is there a need for such a program or is there
> already something very similar? (Is this the right place for asking?)
> I even exactly know what options setop should have and what it can do
> (how it is used), but am waiting for some responses from you before
> programming.
>
> Note: I already asked two years ago but didn’t get satisfactory
> responses. Only now I remembered my idea.
>
> I would be very grateful for your feedback,
> Frank
>
>

Bug#799268: RFS: ck/1.6.2 [ITP]

[Grigori Fursin]

Oh, I see - I was jumping too far ;) !

I actually still don't have an official sponsor,
so I removed "closing bug" from the changelog,
uploaded a new package (it doesn't have
errors anymore), and will now be patiently
waiting for a sponsor ...

By the way, I also uploaded python3-ck:
https://mentors.debian.net/package/python3-ck

Thanks a lot for your help,
Grigori

-Original Message- 
From: Gianfranco Costamagna

Sent: Monday, September 28, 2015 10:38 AM
To: Grigori Fursin ; 799...@bugs.debian.org
Subject: Re: Bug#799268: RFS: ck/1.6.2 [ITP]

You need to open an ITP bug
https://www.debian.org/devel/wnpp/
and close *that* bug.

the RFS bug is closed by your sponsor when the upload is performed.

cheers,

G.





Il Lunedì 28 Settembre 2015 10:34, Grigori Fursin 
 ha scritto:

Hi Gianfranco,

But I already retitled it some time ago as you
suggested (including the latest upstream version)
and it's now: RFS: python-ck/1.6.11-1 [ITP]

My submitted package name is also python-ck.

However, it still says that
"Bug #799268 does not belong to this package"

That's why I am not sure what's wrong :( ...

Maybe the package name is taken from the body
of the original message, i.e. "ck" instead of "python-ck"?

Sorry for bothering with that and thanks for your help,
Grigori







-Original Message- 
From: Gianfranco Costamagna

Sent: Monday, September 28, 2015 10:21 AM
To: Grigori Fursin ; 799...@bugs.debian.org
Subject: Bug#799268: RFS: ck/1.6.2 [ITP]

Hi,

https://www.debian.org/Bugs/server-control


retitle is the keyword :)

cheers,

G.


Il Lunedì 28 Settembre 2015 10:15, Grigori Fursin
 ha scritto:
Dear colleagues,

I fixed all the issues with my package, added the latest
upstream release, and uploaded the new version to Debian mentors:

http://mentors.debian.net/package/python-ck

The only problem is that I have an error message there
"Bug #799268 does not belong to this package"

Can it be because I originally submitted a request
for package 'ck' and not 'python-ck'?

Is there a way to change it?

Thanks a lot and have a good week,
Grigori



-Original Message- 
From: Grigori Fursin

Sent: Saturday, September 19, 2015 11:18 AM
To: Gianfranco Costamagna ; Lucas Nussbaum ; 799...@bugs.debian.org
Subject: Bug#799268: RFS: ck/1.6.2 [ITP]

Actually, it's done more or less like that.
ck is a batch script that sets environment and calls python module.

So, it should be easy to change the name if will be required.

However, I made some search and didn't not find obvious conflicts so far ;)
...

Thanks,
Grigori

-Original Message- 
From: Gianfranco Costamagna

Sent: Friday, September 18, 2015 4:02 PM
To: Lucas Nussbaum ; Grigori Fursin ; 799...@bugs.debian.org
Subject: Bug#799268: RFS: ck/1.6.2 [ITP]






Oh, I didn't know that :( . Will it really be a problem (I didn't see any
tool called ck yet)? The problem is that our users now share some
artifacts
in this format and they use this name (in scripts or internal calls),
so changing this name now will be a nightmare :( ...


I'm not sure if there's an official policy about that. It's probably
worth trying to upload with a ck binary, and see if someone complains :)




I guess you can always install a longer name and create a symlink to ck.
(and bother upstream about it)


this way people can move to the new binary, and if somebody complain you can
"safely" drop the symlink.

(or use some "update-alternative" tools I don't remember how)


Just my .02$

G. 

Bug#799615: RFS: netmask/2.4.2-1 [ITA] - helps determine network masks

[Guilhem Moulin]

Control: retitle -1 RFS: netmask/2.4.2-1 [ITA] - helps determine network masks

On Mon, 28 Sep 2015 at 11:37:39 +0200, Paul Wise wrote:
> Part of the package maintainer's job is to forward patches, bug
> reports and feedback upstream, so thanks for doing that :)

Moreover upstream has been super reactive on this one and has already
released a new version with some of the fixes you suggested, which also
allowed me to further simplify debian/rules.  I just finished the
packaging and uploaded it to d.m.n:

  dget -x 
http://mentors.debian.net/debian/pool/main/n/netmask/netmask_2.4.2-1.dsc

Thanks!
Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature