Bug#850587: ITP: cohomcalg -- sheaf cohomology of line bundles on toric varieties

[Doug Torrance]

Package: wnpp
Severity: wishlist
Owner: Doug Torrance 

* Package name: cohomcalg
  Version : 0.31b
  Upstream Author : Ralph Blumenhagen, Benjamin Jurke, Thorsten Rahn,
Helmut Roschy
* URL : http://wwwth.mpp.mpg.de/members/bjurke/cohomcalg/
* License : GPL-3+
  Programming Lang: C++
  Description : sheaf cohomology of line bundles on toric varieties

The algorithm for the computation of sheaf cohomologies for line bundles on
toric varieties presented in "Cohomology of Line Bundles: A Computational
Algorithm" by Ralph Blumenhagen, Benjamin Jurke, Thorsten Rahn, and Helmut
Roschy has been implemented in a convenient and high-performance C/C++
application called cohomCalg.

The optional cohomCalg Koszul extension serves as a Mathematica 7 frontend and
allows for the easy computation of hypersurface and complete intersection
cohomologies, following the material presented in "Cohomology of Line Bundles:
Applications" by the same authors.

I plan to maintain this package as a member of the Debian Science Team.

Re: Feedback on 3.0 source format problems

[Ritesh Raj Sarraf]

On Mon, 2017-01-02 at 12:36 +, Sean Whitton wrote:
> Dear Josh,
> 
> On Mon, Jan 02, 2017 at 03:25:29AM -0800, Josh Triplett wrote:
> > Currently working on some improvements in that direction, to separate
> > repository format from workflow.
> 
> I'd like to encourage you to read my dgit-maint-merge(7) workflow
> tutorial.  Perhaps the work to which you refer could result in some
> improvements to what I wrote there.  Thanks in advance.

Thank you very much for creating and mentioning about such tutorials. I wasn't
aware of them. I'm going to try some of the exampled workflows.


-- 
Given the large number of mailing lists I follow, I request you to CC
me in replies for quicker response

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

Bug#850590: ITP: openmeca -- a graphical application to model and simulate mechanical systems

[Damien Andre]

Package: wnpp
Severity: wishlist
Owner: Damien Andre 

* Package name: openmeca
  Version : 2.1.2
  Upstream Author : Damien Andre 
* URL : https://gitlab.com/damien.andre/openmeca
* License : GPL v3
  Programming Lang: C++
  Description : a graphical application to model and simulate mechanical 
systems

OpenMeca is based on the chronoengine library. The aim of openmeca is to 
provide a software for simulating mechanical systems easily. openmeca allow us 
to builds a 3D sketch, where the bonds are represented by symbols and gives a 
simple way to apply loading and boundary conditions. Thanks to numerical 
sensors, different kind of data (force, torque, displacement, velocity, etc.) 
could be extracted from the simulation.

Hello, I am developing the openmeca software. openmeca is a scientific software 
especially designed for teaching mechanical dynamics. I started this 
development a long time ago (8 years) and I think that the program is correct 
now.

I propose to work myself on the packaging. By following the FAQ instructions, I 
just made a first version of the source and binary package. However, I probably 
need help from debian mentors to improve the quality of the package.

Best regards, Damien.

Newcomer to Debian: Help wanted

[Vijeth T Aradhya]

Hi,

Hey guys I'd like to start contributing to Debian and be a part of the
community. I just need some help getting started!

When I looked at the bug tracker system, it was very difficult for a
*newcomer* to Debian like me, to get started to solve easy bugs.

I have already looked at many links for getting started. It'd be great if
you guys can lead me directly to fixing bugs in languages like C, Python or
Haskell. I'm really sorry, but I did not get enough information on where
and how to get started. Can you guys help me out? Thanks!

Thank you,
Vijeth Aradhya

Re: Newcomer to Debian: Help wanted

[Paul Wise]

On Sun, Jan 8, 2017 at 5:05 PM, Vijeth T Aradhya wrote:

> Hey guys I'd like to start contributing to Debian and be a part of the
> community. I just need some help getting started!

Great! Here are some ideas for things to work on:

https://www.debian.org/intro/help

> When I looked at the bug tracker system, it was very difficult for a
> newcomer to Debian like me, to get started to solve easy bugs.

Check out the list of bugs tagged newcomer:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=newcomer

> I have already looked at many links for getting started. It'd be great if
> you guys can lead me directly to fixing bugs in languages like C, Python or
> Haskell. I'm really sorry, but I did not get enough information on where and
> how to get started. Can you guys help me out? Thanks!

A great way to find packages to work on is the how-can-i-help tool:

https://wiki.debian.org/how-can-i-help

Also, you can use the debtags site to find packages tagged as being
implemented in C/Python/Haskell. Then click through to the bugs pages.

https://debtags.debian.org/search/?q=implemented-in%3A%3Ac+implemented-in%3A%3Apython+implemented-in%3A%3Ahaskell

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Newcomer to Debian: Help wanted

[Jonas Smedegaard]

Quoting Paul Wise (2017-01-08 10:19:06)
> On Sun, Jan 8, 2017 at 5:05 PM, Vijeth T Aradhya wrote:
> 
> > Hey guys I'd like to start contributing to Debian and be a part of the
> > community. I just need some help getting started!
> 
> Great! Here are some ideas for things to work on:
> 
> https://www.debian.org/intro/help
> 
> > When I looked at the bug tracker system, it was very difficult for a
> > newcomer to Debian like me, to get started to solve easy bugs.
> 
> Check out the list of bugs tagged newcomer:
> 
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=newcomer
> 
> > I have already looked at many links for getting started. It'd be great if
> > you guys can lead me directly to fixing bugs in languages like C, Python or
> > Haskell. I'm really sorry, but I did not get enough information on where and
> > how to get started. Can you guys help me out? Thanks!
> 
> A great way to find packages to work on is the how-can-i-help tool:
> 
> https://wiki.debian.org/how-can-i-help
> 
> Also, you can use the debtags site to find packages tagged as being
> implemented in C/Python/Haskell. Then click through to the bugs pages.
> 
> https://debtags.debian.org/search/?q=implemented-in%3A%3Ac+implemented-in%3A%3Apython+implemented-in%3A%3Ahaskell

Mentioned briefly in first URL above, but I'd like to emphasize one 
suggestion: Cosnider join (or at list get in touch with) the teams 
relevant for your particular interests.  Here's an incomplete list: 
https://wiki.debian.org/Teams


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Bug#850597: ITP: python-month-delta

[Nupur Malpani]

Package: wnpp
Owner: Nupur Malpani 
Severity: wishlist
X-Debbugs-Cc: debian-devel@lists.debian.org,debian-pyt...@lists.debian.org

* Package name: python-month-delta
  Version : 1.0b
  Upstream Author : Jess Austin
* URL : https://pypi.python.org/pypi/MonthDelta
* License : MIT
  Programming Lang: Python
  Description : enables easy month-related calculations with the
standard Python date
 and
datetime

classes from the *datetime*
 module.

Re: Accepted ncc 2.8-2.1 (source amd64) into unstable

[Simon McVittie]

On Sat, 07 Jan 2017 at 22:18:45 +, Holger Levsen wrote:
> On Sat, Jan 07, 2017 at 11:11:02PM +0100, Mattia Rizzolo wrote:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677673
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755420

See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542747 which
has a lintian patch to add these tags:

# sbuild -d unstable, debian/changelog says experimental
# (the case you typically have to fix with epochs)
E: mypackage changes: distribution-and-experimental-mismatch unstable

# sbuild -d unstable, debian/changelog says UNRELEASED
E: mypackage changes: unreleased-changes

# sbuild -d stable, debian/changelog says unstable
# (or other distributions known to Lintian)
W: mypackage changes: distribution-and-changes-mismatch stable unstable

Regards,
S

Re: Feedback on 3.0 source format problems

[James Clarke]

On Sun, Jan 08, 2017 at 01:53:51AM +0100, Johannes Schauer wrote:
> Quoting Thibaut Paumard (2017-01-07 07:12:59)
> > I manage my patches using quilt. I would really prefer if sbuild et al.
> > would revert the patches after building by default, but that's life. I
> > respect that other people have other views.
>
> you could always file a wishlist bug against sbuild with your feature request.
> ;)
>
> I guess you are using sbuild from within an unpacked source package?
>
> The input for sbuild is always a source package. If all you give to sbuild is 
> a
> directory, then it first needs to create that source package. It uses
> "dpkg-source -b ." for this purpose. It is dpkg-source which applies the
> patches.
>
> What you could already do today with sbuild is to say:
>
> sbuild --pre-build-commands="dpkg-source --after-build $(pwd)" ...
>
> You can also put this into your ~/.sbuildrc but that would then prevent you
> from using sbuild outside of unpacked source package directories.
>
> Sbuild could do this cleanup itself if there was a way to automatically
> determine whether the user would like their tree to be patches applied or
> unapplied. I do not even know of a way to determine upfront whether a source
> tree is patches applied or unapplied (that check has to be independent of the
> source format). Heck, with quilt, the source tree could even have patches half
> applied. I'm not so sure how fragile it will be to let sbuild try to put your
> source directory back into the state that it found it.

dpkg-source can almost do this for you; see later :)

> This also brings me to a question about the --unapply-patches option. The man
> page says:
>
>--no-unapply-patches, --unapply-patches
>   By  default,  dpkg-source will automatically unapply the patches
>   in  the  --after-build  hook  if  it  did  apply   them   during
>   --before-build(--unapply-patchessincedpkg1.15.8,
>   --no-unapply-patches since dpkg 1.16.5).   Those  options  allow
>   you  to  forcefully  disable  or  enable the patch unapplication
>   process.Thoseoptions are only allowed in
>   debian/source/local-options   so   that   all  generated  source
>   packages have the same behavior by default.
>
> Is --before-build not also run when using --build? That patches are applied
> when using --build indicates to me that it is.

No, it's not, but per dpkg-source(1) you can see that for 3.0 (quilt),
both --before-build and --build apply patches.

> But the --unapply-patches option
> seems to have no effect when used with --build. So is there a way to apply and
> unapply patches with a single dpkg-source call?

No, there isn't. The standard invocation by dpkg-buildpackage -S is:

dpkg-source --before-build .
fakeroot debian/rules clean
dpkg-source -b .
dpkg-source --after-build .
(also dpkg-gencontrol and dpkg-genbuildinfo)

> And if --unapply-patches does
> not have any effect together with --build, why do I not get a warning on the
> command line about this?

Wishlist bug against dpkg? :)

> And then there is the mysterious hint about
> debian/source/local-options which doesn't increase my understanding of the
> matter

Indeed, but they seem to work when given on the command-line for
--after-build.

Now, if you look at the --(no-)unapply-patches description, you will see

> By default, dpkg-source will automatically unapply the patches in the
> --after-build hook if it did apply them during --before-build

This turns out to be true. Working in a patches-applied tree:

$ dpkg-source --before-build .
$ dpkg-source -b .
$ dpkg-source --after-build .

leaves the patches applied. Working in a patches-unapplied tree, the
patches are unapplied during the --after-build. This seems to do exactly
what you want, with the caveat that, if patches are only *part*-applied,
they will be completely unapplied by the --after-build, but this seems
like a very strange edge-case.

This behaviour is exactly what pdebuild has been doing forever (and
therefore git-buildpackage --git-pbuilder and others).

Regards,
James

Re: Feedback on 3.0 source format problems

[Johannes Schauer]

Hi all,

Mattia, please see below for a pbuilder-specific question.

Quoting James Clarke (2017-01-08 12:14:07)
> This turns out to be true. Working in a patches-applied tree:
> 
> $ dpkg-source --before-build .
> $ dpkg-source -b .
> $ dpkg-source --after-build .
> 
> leaves the patches applied. Working in a patches-unapplied tree, the
> patches are unapplied during the --after-build. This seems to do exactly
> what you want, with the caveat that, if patches are only *part*-applied,
> they will be completely unapplied by the --after-build, but this seems
> like a very strange edge-case.
> 
> This behaviour is exactly what pdebuild has been doing forever (and
> therefore git-buildpackage --git-pbuilder and others).

I'm not very familiar with pbuilder. Looking at the man page it seems that
pbuilder itself exclusively accepts a source package .dsc and for building a
source directory one needs the pdebuild wrapper?

If that is the case, then it seems sensible for sbuild to do the same as
pdebuild if given a source directory only. Both tools should behave the same
way when executed in the same context, I think.

Are there any reasons against this plan? (targeting Buster)

Thanks!

cheers, josch


signature.asc
Description: signature

Re: Newcomer to Debian: Help wanted

[Vijeth T Aradhya]

Hi,

Firstly, thank you so much for such a quick response! It's really nice when
the community responds to you so quickly, hopefully I can be a part of it
in the coming near future :)

Mentioned briefly in first URL above, but I'd like to emphasize one
> suggestion: Cosnider join (or at list get in touch with) the teams
> relevant for your particular interests.  Here's an incomplete list:
> https://wiki.debian.org/Teams
>
>
I looked at the teams, and I have sent a mail to pkg-GPG about joining and
development there. This was mainly because I became interested in PGP/PKI
Clean Room Project proposed by Daniel Pocock on his blog. (
https://danielpocock.com/outreachy-gsoc-2017-pki-clean-room). Hopefully,
they will get back to me!

I'll look at other teams as well! Any other path you suggest which will
help me get acquainted with the org so that it will help with Gsoc?

Thank you,
*Vijeth Tumkur Aradhya*
Undergraduate Sophomore,
International Institute of Information Technology, Hyderabad


Thank you,
*Vijeth Tumkur Aradhya*
Undergraduate Sophomore,
International Institute of Information Technology, Hyderabad

On Sun, Jan 8, 2017 at 4:31 PM, Jonas Smedegaard  wrote:

> Quoting Paul Wise (2017-01-08 10:19:06)
> > On Sun, Jan 8, 2017 at 5:05 PM, Vijeth T Aradhya wrote:
> >
> > > Hey guys I'd like to start contributing to Debian and be a part of the
> > > community. I just need some help getting started!
> >
> > Great! Here are some ideas for things to work on:
> >
> > https://www.debian.org/intro/help
> >
> > > When I looked at the bug tracker system, it was very difficult for a
> > > newcomer to Debian like me, to get started to solve easy bugs.
> >
> > Check out the list of bugs tagged newcomer:
> >
> > http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=newcomer
> >
> > > I have already looked at many links for getting started. It'd be great
> if
> > > you guys can lead me directly to fixing bugs in languages like C,
> Python or
> > > Haskell. I'm really sorry, but I did not get enough information on
> where and
> > > how to get started. Can you guys help me out? Thanks!
> >
> > A great way to find packages to work on is the how-can-i-help tool:
> >
> > https://wiki.debian.org/how-can-i-help
> >
> > Also, you can use the debtags site to find packages tagged as being
> > implemented in C/Python/Haskell. Then click through to the bugs pages.
> >
> > https://debtags.debian.org/search/?q=implemented-in%3A%
> 3Ac+implemented-in%3A%3Apython+implemented-in%3A%3Ahaskell
>
> Mentioned briefly in first URL above, but I'd like to emphasize one
> suggestion: Cosnider join (or at list get in touch with) the teams
> relevant for your particular interests.  Here's an incomplete list:
> https://wiki.debian.org/Teams
>
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
>
>

Bug#850605: ITP: node-home-path -- Cross-platform home directory retriever

[Roshan]

Package: wnpp
Severity: wishlist
Owner: Roshan Nalawade 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-home-path
  Version : 1.0.3
  Upstream Author : Lloyd Brookes <75po...@gmail.com>
* URL : https://github.com/75lb/home-path#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Cross-platform home directory retriever

Re: Newcomer to Debian: Help wanted

[Jonas Smedegaard]

Quoting Vijeth T Aradhya (2017-01-08 13:23:41)
> Firstly, thank you so much for such a quick response! It's really nice 
> when the community responds to you so quickly, hopefully I can be a 
> part of it in the coming near future :)
> 
>> Mentioned briefly in first URL above, but I'd like to emphasize one 
>> suggestion: Cosnider join (or at list get in touch with) the teams 
>> relevant for your particular interests.  Here's an incomplete list: 
>> https://wiki.debian.org/Teams
>>
>>
> I looked at the teams, and I have sent a mail to pkg-GPG about joining 
> and development there. This was mainly because I became interested in 
> PGP/PKI Clean Room Project proposed by Daniel Pocock on his blog. ( 
> https://danielpocock.com/outreachy-gsoc-2017-pki-clean-room). 
> Hopefully, they will get back to me!
> 
> I'll look at other teams as well!

Great.

You mentioned Haskell specifically, and I know that team will appreciate 
more participants.  Probably same for most if not all teams - just 
wanted to encourage your exploring more options, now that you asked.


> Any other path you suggest which will help me get acquainted with the 
> org so that it will help with Gsoc?

There are so many suggestions, but also so much already documented at 
many places.  I think pabs referenced plenty of god starting points.

Seem you might also appreciate reading how we prefer to use 
mailinglists: https://www.debian.org/MailingLists/#codeofconduct

Welcome to the World of Debian :-)


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Re: Newcomer to Debian: Help wanted

[Samuel Henrique]

One of the best ways to start IMHO, is to get one of these packages[1]
(don't get the old ones, as they're probably harder to work on) and prepare
a QA upload fixing easy things, like:
DH bump
Standards Version bump
Fix/bump d/watch
Convert d/copyright to DEP-5
Change maintainer to QA Group
Fix typos
wrap-and-sort a
Package new release
ACK bugs with patch attached (eg.: the reproducible-builds team is always
opening bugs with patch attached, and BTW they're awesome)

The QA upload can be sponsored by any DD, and you can ask sponsorhip ont
mentors.

[1]https://www.debian.org/devel/wnpp/orphaned_byage

Samuel Henrique 

2017-01-08 10:54 GMT-02:00 Jonas Smedegaard :

> Quoting Vijeth T Aradhya (2017-01-08 13:23:41)
> > Firstly, thank you so much for such a quick response! It's really nice
> > when the community responds to you so quickly, hopefully I can be a
> > part of it in the coming near future :)
> >
> >> Mentioned briefly in first URL above, but I'd like to emphasize one
> >> suggestion: Cosnider join (or at list get in touch with) the teams
> >> relevant for your particular interests.  Here's an incomplete list:
> >> https://wiki.debian.org/Teams
> >>
> >>
> > I looked at the teams, and I have sent a mail to pkg-GPG about joining
> > and development there. This was mainly because I became interested in
> > PGP/PKI Clean Room Project proposed by Daniel Pocock on his blog. (
> > https://danielpocock.com/outreachy-gsoc-2017-pki-clean-room).
> > Hopefully, they will get back to me!
> >
> > I'll look at other teams as well!
>
> Great.
>
> You mentioned Haskell specifically, and I know that team will appreciate
> more participants.  Probably same for most if not all teams - just
> wanted to encourage your exploring more options, now that you asked.
>
>
> > Any other path you suggest which will help me get acquainted with the
> > org so that it will help with Gsoc?
>
> There are so many suggestions, but also so much already documented at
> many places.  I think pabs referenced plenty of god starting points.
>
> Seem you might also appreciate reading how we prefer to use
> mailinglists: https://www.debian.org/MailingLists/#codeofconduct
>
> Welcome to the World of Debian :-)
>
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
>
>

Re: Accepted ncc 2.8-2.1 (source amd64) into unstable

[Bastien ROUCARIES]

On Sun, Jan 8, 2017 at 12:28 PM, Simon McVittie  wrote:
> On Sat, 07 Jan 2017 at 22:18:45 +, Holger Levsen wrote:
>> On Sat, Jan 07, 2017 at 11:11:02PM +0100, Mattia Rizzolo wrote:
>> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677673
>> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755420
>
> See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542747 which
> has a lintian patch to add these tags:
>
> # sbuild -d unstable, debian/changelog says experimental
> # (the case you typically have to fix with epochs)
> E: mypackage changes: distribution-and-experimental-mismatch unstable
>
> # sbuild -d unstable, debian/changelog says UNRELEASED
> E: mypackage changes: unreleased-changes
>
> # sbuild -d stable, debian/changelog says unstable
> # (or other distributions known to Lintian)
> W: mypackage changes: distribution-and-changes-mismatch stable unstable

Will get a glimpse at this patch (lintian hat on)

Bastien

> Regards,
> S
>

Re: Can we kill net-tools, please?

[Tom H]

On Fri, Jan 6, 2017 at 7:58 PM, Toni Mueller  wrote:
> On Thu, Dec 29, 2016 at 09:01:51PM +0500, Andrey Rahmatullin wrote:
>> On Thu, Dec 29, 2016 at 10:30:26AM -0500, Theodore Ts'o wrote:


>>> Ifconfig has been deprecated; you should probably use "ip a show
>>> dev lo" instad of the shorter and more convenient "ifconfig lo"
>>
>> ... and often wrong
>
> The BSD ifconfig can do this with ease, and since ages, too. Why is
> the Linux ifconfig _so_ different? Forking for the sake of it?

Is there any relationship between current ifconfig on Linux and the
BSDs, other than the name? I don't think so. The BSDs have continued
to develop ifconfig, adding many features and options.


> Eg adding an IPv6 address:
> # ifconfig em0 inet6 address alias
>
> and removing it:
> # ifconfig em0 inet6 address -alias

On Linux, you can do the same with ipv6

ifconfig eth0 inet6 add ipv6_address

but for ipv4 you have to label the NIC as an alias

ifconfig eth0:0 ipv4_address

You can use

ip a sh lo (if you have bash-completion installed, "a" will
complete to "addr" and "sh" will complete to "show")

instead of "ip a show dev lo" above (still longer than "ifc though).

Re: Can we kill net-tools, please?

[Andrey Rahmatullin]

On Sun, Jan 08, 2017 at 10:49:23AM -0500, Tom H wrote:
> You can use
> 
> ip a sh lo (if you have bash-completion installed, "a" will
> complete to "addr" and "sh" will complete to "show")
> 
> instead of "ip a show dev lo" above (still longer than "ifc though).
OTOH "ip a" is not longer than that.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#850622: ITP: r-cran-survey -- GNU R analysis of complex survey samples

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-survey
  Version : 3.31-5
  Upstream Author : Thomas Lumley 
* URL : https://cran.r-project.org/package=survey
* License : GPL
  Programming Lang: GNU R
  Description : GNU R analysis of complex survey samples
 Summary statistics, two-sample tests, rank tests, generalised linear
 models, cumulative link models, Cox models, loglinear models, and
 general maximum pseudolikelihood estimation for multistage stratified,
 cluster-sampled, unequally weighted survey samples. Variances by Taylor
 series linearisation or replicate weights. Post-stratification,
 calibration, and raking. Two-phase subsampling designs. Graphics. PPS
 sampling without replacement. Principal components, factor analysis.


Remark: This package is needed to upgrade r-cran-zelig to the latest
upstream version.  It will be maintained by the Debian Science team
at
   https://anonscm.debian.org/git/debian-science/packages/r-cran-survey.git

Python 3.6 in stretch

[Galbo Branbert]

I couldn't find any official statement if Python 3.6 will be the default
interpreter in stretch (as it was the current stable when the soft freeze
happened it should be, right?)

Some reasons for it: (https://docs.python.org/3/whatsnew/3.6.html)
-)SHA-3, formatted string literals, file system path protocol
-)secrets module has been added to simplify the generation of
cryptographically strong pseudo-random number
-)Dicts need 20-25% less memory (kinda a huge deal)

Re: Can we kill net-tools, please?

[Alexey Salmin]

On Sun, Jan 8, 2017 at 10:49 PM, Tom H  wrote:
> On Fri, Jan 6, 2017 at 7:58 PM, Toni Mueller  wrote:
>> On Thu, Dec 29, 2016 at 09:01:51PM +0500, Andrey Rahmatullin wrote:
>>> On Thu, Dec 29, 2016 at 10:30:26AM -0500, Theodore Ts'o wrote:
>
>
 Ifconfig has been deprecated; you should probably use "ip a show
 dev lo" instad of the shorter and more convenient "ifconfig lo"
>>>
>>> ... and often wrong
>>
>> The BSD ifconfig can do this with ease, and since ages, too. Why is
>> the Linux ifconfig _so_ different? Forking for the sake of it?
>
> Is there any relationship between current ifconfig on Linux and the
> BSDs, other than the name? I don't think so. The BSDs have continued
> to develop ifconfig, adding many features and options.

Right, but this raises all kinds of questions like "Is it possible to
improve the ifconfig on Linux to catch up with the BSD version? And
even with ip?". Networking standards and protocols are
platform-independent, maintaining a Unix-wide interface to do the
basic networking stuff sounds like a reasonable thing to do. At this
time ifconfig seems to be the answer, no ip is visible on the BSDs
horizon.

I realize that net-tools version is long gone, but what about the GNU
inetutils one? It's supported and is not Linux-specific. Maybe a new
default implementation of ifconfig should be provided rather than
simply discarding one from a basic install. Another question is
whether you absolutely have to switch to netlink to have a reasonable
ifconfig implementation or ioctl is still acceptable (I don't know).

Alexey

Re: Python 3.6 in stretch

[Andrey Rahmatullin]

On Sun, Jan 08, 2017 at 04:58:01PM +0100, Galbo Branbert wrote:
> I couldn't find any official statement if Python 3.6 will be the default
> interpreter in stretch (as it was the current stable when the soft freeze
> happened it should be, right?)
python3.6 is not even in sid so no.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Can we kill net-tools, please?

[Tom H]

On Sun, Jan 8, 2017 at 10:55 AM, Andrey Rahmatullin  wrote:
> On Sun, Jan 08, 2017 at 10:49:23AM -0500, Tom H wrote:
>>
>> You can use
>>
>> ip a sh lo (if you have bash-completion installed, "a" will
>> complete to "addr" and "sh" will complete to "show")
>>
>> instead of "ip a show dev lo" above (still longer than "ifc
>> though).
>
> OTOH "ip a" is not longer than that.

Sure. But I was replying to displaying "ip a" for a specific NIC.

Re: Accepted ncc 2.8-2.1 (source amd64) into unstable

[Bastien ROUCARIES]

On Sun, Jan 8, 2017 at 4:03 PM, Bastien ROUCARIES
 wrote:
> On Sun, Jan 8, 2017 at 12:28 PM, Simon McVittie  wrote:
>> On Sat, 07 Jan 2017 at 22:18:45 +, Holger Levsen wrote:
>>> On Sat, Jan 07, 2017 at 11:11:02PM +0100, Mattia Rizzolo wrote:
>>> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677673
>>> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755420
>>
>> See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542747 which
>> has a lintian patch to add these tags:
>>
>> # sbuild -d unstable, debian/changelog says experimental
>> # (the case you typically have to fix with epochs)
>> E: mypackage changes: distribution-and-experimental-mismatch unstable
>>
>> # sbuild -d unstable, debian/changelog says UNRELEASED
>> E: mypackage changes: unreleased-changes
>>
>> # sbuild -d stable, debian/changelog says unstable
>> # (or other distributions known to Lintian)
>> W: mypackage changes: distribution-and-changes-mismatch stable unstable
>
> Will get a glimpse at this patch (lintian hat on)

Applied patch for #542747

Bastien
>
> Bastien
>
>> Regards,
>> S
>>

Re: Python 3.6 in stretch

[Lars Wirzenius]

On Sun, Jan 08, 2017 at 04:58:01PM +0100, Galbo Branbert wrote:
> I couldn't find any official statement if Python 3.6 will be the default
> interpreter in stretch (as it was the current stable when the soft freeze
> happened it should be, right?)

Python 3.6 was released 23 December. The stretch transition freeze was
on 5 November, a month and a half earlier. Upgrading the default
Python 3 from 3.5 to 3.6 is a transition, and given the number of
Python packges, it's likely to be a large on. What's more, Python 3.6
isn't even in experimental yet, so it seems to me that it's way past
the time when switching to it would be appropriate. After all, the
point is not to sneak in a new version at the latest possible moment,
but instead make sure whatever version of Python is in stretch, and
all the packages that use it, work very well

It'd be nice to have the newest of the newest of everything in a
Debian stable release. That seems to be incompatible with actually
making a stable release.

This time, us Python users need to compromise and make do with a
slighly older version of Python. It's not too bad.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Can we kill net-tools, please?

[Adam Borowski]

On Sun, Jan 08, 2017 at 11:14:52PM +0700, Alexey Salmin wrote:
> At this time ifconfig seems to be the answer, no ip is visible on the BSDs
> horizon.

There's a patch set to add netlink to FreeBSD (I don't know how complete or
likely to be merged it is).

It even has  in the public headers :)


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Re: Python 3.6 in stretch

[Lars Wirzenius]

On Sun, Jan 08, 2017 at 06:27:57PM +0200, Lars Wirzenius wrote:
> Python 3.6 isn't even in experimental yet

This bit was wrong. 3.6 is in experimental. That doesn't change my
point about a transition being too late now, however.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Can we kill net-tools, please?

[Vincent Bernat]

 ❦  8 janvier 2017 23:14 +0700, Alexey Salmin  :

> I realize that net-tools version is long gone, but what about the GNU
> inetutils one? It's supported and is not Linux-specific. Maybe a new
> default implementation of ifconfig should be provided rather than
> simply discarding one from a basic install. Another question is
> whether you absolutely have to switch to netlink to have a reasonable
> ifconfig implementation or ioctl is still acceptable (I don't know).

The information you can gather from ioctl and files are incomplete. You
need to use netlink. Moreover, netlink is far more efficient (compare
"netstat -an" and "ss -an").
-- 
You tread upon my patience.
-- William Shakespeare, "Henry IV"


signature.asc
Description: PGP signature

Re: Can we kill net-tools, please?

[Vincent Bernat]

 ❦  8 janvier 2017 10:49 -0500, Tom H  :

>> The BSD ifconfig can do this with ease, and since ages, too. Why is
>> the Linux ifconfig _so_ different? Forking for the sake of it?
>
> Is there any relationship between current ifconfig on Linux and the
> BSDs, other than the name? I don't think so. The BSDs have continued
> to develop ifconfig, adding many features and options.

The BSDs maintain ifconfig (and route, netstat, arp) in parity with the
kernel. That's something that didn't happen with Linux for various
reasons (different teams, output compatibility to be maintained, dead
upstream, portability requirement).
-- 
Use uniform input formats.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Python 3.6 in stretch

[Galbo Branbert]

Thanks for the info, didn't know that the transition freeze was actually
the version freeze for minor versions of Python. (and that 3.6 is not in
Stretch, oops)
For the next version of Debian it would be nice to know the version that
will be included in the 'Bits from the Stable Release Managers' message
(that one got quite many views around where I work)

Re: Python 3.6 in stretch

[Andrey Rahmatullin]

On Sun, Jan 08, 2017 at 06:55:45PM +0100, Galbo Branbert wrote:
> Thanks for the info, didn't know that the transition freeze was actually
> the version freeze for minor versions of Python. 
A minor version upgrade would be 3.5.3 -> 3.5.4. 3.5 -> 3.6 is a lot of
changes.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Python 3.6 in stretch

[Matthias Klose]

On 08.01.2017 17:27, Lars Wirzenius wrote:
> On Sun, Jan 08, 2017 at 04:58:01PM +0100, Galbo Branbert wrote:
>> I couldn't find any official statement if Python 3.6 will be the default
>> interpreter in stretch (as it was the current stable when the soft freeze
>> happened it should be, right?)
> 
> Python 3.6 was released 23 December. The stretch transition freeze was
> on 5 November, a month and a half earlier. Upgrading the default
> Python 3 from 3.5 to 3.6 is a transition, and given the number of
> Python packges, it's likely to be a large on. What's more, Python 3.6
> isn't even in experimental yet, so it seems to me that it's way past
> the time when switching to it would be appropriate. After all, the
> point is not to sneak in a new version at the latest possible moment,
> but instead make sure whatever version of Python is in stretch, and
> all the packages that use it, work very well
> 
> It'd be nice to have the newest of the newest of everything in a
> Debian stable release. That seems to be incompatible with actually
> making a stable release.
> 
> This time, us Python users need to compromise and make do with a
> slighly older version of Python. It's not too bad.

It would be easy to include python3.6 itself, however the real issues are
getting all third party python packages working with 3.6.  So no, this is not
going to happen.  Instead I hope we'll see the soon to be released 3.5.3 in 
stretch.

Matthias

Bash different behaviour in jessie versus stretch (maybe a regression?)

[foo fighter]

Hi,

I could see different bash behaviour and do not know if these are regressions 
in jessie or fixes for jessie. I searched for bugrepots (bash jessie) but did 
not find something I could connect to it
itemcoumt in "version 2" differs and especially "version 3" bothers me: error 
exit in jessie and NO error exit when running in stretch).

Yours lopiuh
===
CODE:
===

#!/usr/bin/env bash
set -o errexit  # (set -e)
set -o nounset  # (set -u)
set -o pipefail
shopt -s nullglob # enable
#shopt -s failglob
#set -o noglob

clear
echo "===Version 1==="
echo "Bash Version: $BASH_VERSION"
echo -n "IFS:"; echo "$IFS" | cat -vte
echo

unset _array; declare -a _array

_inputstring="$(echo -e "item01\nitem02\nitem03")"
echo "inputstring:"
echo -n "$_inputstring" | xxd; echo

read -ra _array <<<$(echo $_inputstring) # <<< NO -"- around string

echo "itemcount of array: ${#_array[@]}"
for i in "${_array[@]}"; do
echo -n "element: "; echo -n "$i" | xxd; echo
done
#
echo "===Version 2==="
echo "Bash Version: $BASH_VERSION"
echo -n "IFS:"; echo "$IFS" | cat -vte
echo

unset _array; declare -a _array

_inputstring="$(echo -e "item01\nitem02\nitem03")"
echo "inputstring:"
echo -n "$_inputstring" | xxd; echo

read -ra _array <<<$(echo "$_inputstring") # <<< WITH -"- around string

echo "itemcount of array: ${#_array[@]}"
for i in "${_array[@]}"; do
echo -n "element: "; echo -n "$i" | xxd; echo
done

echo "===Version 3==="
echo "Bash Version: $BASH_VERSION"
echo -n "IFS:"; echo "$IFS" | cat -vte
echo

unset _array; declare -a _array

_inputstring="telnet*"
echo "inputstring:"
echo -n "$_inputstring" | xxd; echo

read -ra _array <<<$(echo $_inputstring) # <<< NO -"- around string, 0 item due 
to globbing. errexit in jessie, no exit in stretch

echo "itemcount of array: ${#_array[@]}"
for i in "${_array[@]}"; do
echo -n "element: "; echo -n "$i" | xxd; echo
done
echo "Ende"
exit



OUTPUT in jessie:
===Version 1===
Bash Version: 4.3.30(1)-release
IFS: ^I$
$

inputstring:
000: 6974 656d 3031 0a69 7465 6d30 320a 6974  item01.item02.it
010: 656d 3033em03

itemcount of array: 3
element: 000: 6974 656d 3031   item01

element: 000: 6974 656d 3032   item02

element: 000: 6974 656d 3033   item03

===Version 2===
Bash Version: 4.3.30(1)-release
IFS: ^I$
$

inputstring:
000: 6974 656d 3031 0a69 7465 6d30 320a 6974  item01.item02.it
010: 656d 3033em03

itemcount of array: 3
element: 000: 6974 656d 3031   item01

element: 000: 6974 656d 3032   item02

element: 000: 6974 656d 3033   item03

===Version 3===
Bash Version: 4.3.30(1)-release
IFS: ^I$
$

inputstring:
000: 7465 6c6e 6574 2atelnet*

itemcount of array: 0
/mnt/data/sh/finalize_installation.sh: Zeile 91: _array[@] ist nicht gesetzt.

===
OUTPUT in stretch:
===

===Version 1===
Bash Version: 4.4.5(1)-release
IFS: ^I$
$

inputstring:
: 6974 656d 3031 0a69 7465 6d30 320a 6974  item01.item02.it
0010: 656d 3033em03

itemcount of array: 3
element: : 6974 656d 3031   item01

element: : 6974 656d 3032   item02

element: : 6974 656d 3033   item03

===Version 2===
Bash Version: 4.4.5(1)-release
IFS: ^I$
$

inputstring:
: 6974 656d 3031 0a69 7465 6d30 320a 6974  item01.item02.it
0010: 656d 3033em03

itemcount of array: 1
element: : 6974 656d 3031   item01

===Version 3===
Bash Version: 4.4.5(1)-release
IFS: ^I$
$

inputstring:
: 7465 6c6e 6574 2atelnet*

itemcount of array: 0
Ende

Re: Feedback on 3.0 source format problems

[Paul Wise]

On Sun, Jan 8, 2017 at 8:05 PM, Johannes Schauer wrote:

> I'm not very familiar with pbuilder. Looking at the man page it seems that
> pbuilder itself exclusively accepts a source package .dsc and for building a
> source directory one needs the pdebuild wrapper?

Right.

> If that is the case, then it seems sensible for sbuild to do the same as
> pdebuild if given a source directory only. Both tools should behave the same
> way when executed in the same context, I think.

An sdebuild script sounds good to me.

> Are there any reasons against this plan? (targeting Buster)

Longer-term, I think we want debuild and possibly pdebuild to become
just `exec dpkg-buildpackage` so we should probably think about where
the code for this should live.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Feedback on 3.0 source format problems

[Sean Whitton]

Hello Ian,

On Fri, Jan 06, 2017 at 03:29:38PM +, Ian Jackson wrote:
> Sean Whitton writes ("Re: Feedback on 3.0 source format problems"):
> > Could you explain in general terms the difference between the
> > interchange and packaging-only branches
> 
> See modified diagram below.  Are the annotations I have added (and the
> name change) any help ?

Yes, thanks, I think I see most of what's going on now.  Thank you for
taking the time to draw the diagrams.  It's certainly an ingenious use
of git.

I take it that only the maintainer is meant to look at the
merging-baseline, and everyone else looks at the interchange view.  My
first worry is that pseudomerges are weird.  In fact, I've never seen
them outside of weird Debian git workflows :)  Someone might look at the
interchange view, see all these pseudomerges, and have no idea how to
interpret what the Debian maintainer is doing.  Do you have any thoughts
on mitigating the potential confusion?

The advantage of thinking of the Debian packaging as just another branch
of development is that the branching structure itself is easy to
interpret for anyone who uses git.  "Ah, I see they merged my release
tag into their branch, they must have been bringing Debian up-to-date
with the latest release" -- this is very natural for git users.  We call
it "packaging a new upstream release" but it's easier for an outsider to
think of it as bringing a feature branch up-to-date with the latest
mainline developments.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Fwd: Report: Debian Packaging Workshop at COEP

[Pirate Praveen]

 Forwarded Message 
Subject:Report: Debian Packaging Workshop at COEP
Resent-Date:Sun, 8 Jan 2017 13:59:19 + (UTC)
Resent-From:debian-dug...@lists.debian.org
Date:   Sun, 8 Jan 2017 19:32:47 +0530
From:   Abhijit A. M. 
To: debian-dug...@lists.debian.org



Dear Debianers,

A Debian Packaging workshop was organized by Dept. of Computer Engg. and
I.T. at College of Engineering Pune (COEP)[0]  and COEP's Free Software
Users Group (COFSUG)[5] on 2-8 Jan 2016.

Praveen A, Debian Developer and Sruthi Chandran,  Debian Maintainer were
the main instructors for the workshop. Abhijit A. M., faculty at COEP,
was the coordinator.

A total of 32 students from the department of Computer Engineering and
I.T. participated in the workshop. We had total 2*7 total sessions on 7
continuous days. This was perhaps for the first time that a Debian
Packaging workshop was conducted for this long interval in India.

The workshop was also addressed voluntarily by Raju Vindane, an intern
with Hamara Linux, Krishnakant Mane and Abhijith Balan from the GNUkhata
team.

The students were introduced with basics of packaging like lxc
container, npm2deb, build system, dpkg-buildpackage, lintian,  changing
the files in debian/ folder (copyright, rules, changelog, copyright,
etc.), sbuild, Debian processes, debian mailing lists,  in the first
three days.  As a learning exercise the students did packaging of Nodejs
packages  deep-eql, pretty-hrline and prase-glob which were
already packaged.

After that the students voluntarily took up the packaging of different
nodejs related packages. A total of 32 packages were packaged by
students.  As on Sunday, 8th Jan 2017, 12 packages were actually
uploaded to the NEW queue of Debian system.

Some of the students have expressed their interests in packaging key and
important  software like gitlab, diaspora and GNUkhata in future. Some
have expressed their desire to continue packaging the nodejs packages.

The list of packages done during the workshop:

*Package*



*Packager Name*

Is-generator-fn



Aarti Kashyap

node-uglifycss



Abhijit A.M.

md5-o-matic



Abhishek Kuvalekar

node-plur



Abhishek Lolage

asynckit



Aditya Neralkar

node-console-control-strings



Ajinkya Chavan

node-hoek



Akash Sarda

Node-pkgconf



Akshay Kemekar

node-json-schema



Amarpreet Arora

common-path-prefix



Ameya Apte

node-is-ob



Gaurav Juvekar

node-buf-compare



Nikhil Gawande

node-single-line-log-1.1.2



Nupur Malpani

node-cli-boxes



Pradnya Hulle

clean-yaml-object



Prathamesh Mane

node-arrify



Ravi Purne

imurmurhash



Roshan

stringstream



Rushikesh Bhadane

node-assert-plus



Saurabh Agrawal

is-retry-allowed



Saurabh Agrawal

node-fn-name



Shirish Togarla

node-ci-info



Siddhesh Rane

node-call-signature



Sudhanshu Allurwar

node-binary-extensions



Sumedh Pendurkar

node-aproba-1.0.4



Tushar Agey

node-xdg-basedir



Vinay Desai

Ansi-align



Yashashree Kolhe

tweetnacl



Yashashree Kolhe

has-unicode



Yogiraj Kulkarni

node-caller



Yogiraj Kulkarni

node-require-inject



Yogiraj Kulkarni


The workshop is documented on the Loomio (www.loomio.org) page at [1]
and [2] and also on COEP Moodle [3], and being updated on COEP wiki also
[4]. Photos are available on Loomio page [2].

Regards,
Abhijit A M
abhiji...@disroot.org

[0] http://www.coep.org.in
[1] https://www.loomio.org/d/LTpSdMuX/debian-packaging-pre-requisites
[2]
https://www.loomio.org/d/grVdcCx8/debian-packaging-workshop-at-coep-jan-2017

[3] http://moodle.coep.org.in/moodle/course/view.php?id=428#section-0
[4]
http://foss.coep.org.in/coepwiki/index.php/Debian_Packaging_workshop_2nd_Jan_to_8th_Jan_2017

[5] http://co.fsug.in



signature.asc
Description: OpenPGP digital signature

Re: Fwd: Report: Debian Packaging Workshop at COEP

[Geert Stappers]

On Mon, Jan 09, 2017 at 10:57:31AM +0530, Pirate Praveen wrote:
>  Forwarded Message 
> Subject:  Report: Debian Packaging Workshop at COEP
> Resent-Date:  Sun, 8 Jan 2017 13:59:19 + (UTC)
> Resent-From:  debian-dug...@lists.debian.org
> Date: Sun, 8 Jan 2017 19:32:47 +0530
> From: Abhijit A. M. 
> To:   debian-dug...@lists.debian.org
> 
> 
> 
> Dear Debianers,
> 
> A Debian Packaging workshop was organized by Dept. of Computer Engg. and
> I.T. at College of Engineering Pune (COEP)[0]  and COEP's Free Software
> Users Group (COFSUG)[5] on 2-8 Jan 2016.
> 
> Praveen A, Debian Developer and Sruthi Chandran,  Debian Maintainer were
> the main instructors for the workshop. Abhijit A. M., faculty at COEP,
> was the coordinator.
> 
> A total of 32 students from the department of Computer Engineering and
> I.T. participated in the workshop. We had total 2*7 total sessions on 7
> continuous days. This was perhaps for the first time that a Debian
> Packaging workshop was conducted for this long interval in India.
> 
> The workshop was also addressed voluntarily by Raju Vindane, an intern
> with Hamara Linux, Krishnakant Mane and Abhijith Balan from the GNUkhata
> team.
> 
> The students were introduced with basics of packaging like lxc
> container, npm2deb, build system, dpkg-buildpackage, lintian,  changing
> the files in debian/ folder (copyright, rules, changelog, copyright,
> etc.), sbuild, Debian processes, debian mailing lists,  in the first
> three days.

Nice to see that the introduction includes Debian mailing lists.
Communicating with others of the "tribe" is essential for the "tribe".

That we haven't yet seen the students on this ML, d-devel@l.d.o.
reminds me that I took me a long time before subscribing here.
(And it is unlikely that I will soon join the javascript packaging ML)

So it will be a surprise when I meet a member of the class of 2017.
I'm looking forward to it.


> As a learning exercise the students did packaging of Nodejs
> packages  deep-eql, pretty-hrline and prase-glob which were
> already packaged.
> 
> After that the students voluntarily took up the packaging of different
> nodejs related packages. A total of 32 packages were packaged by
> students.  As on Sunday, 8th Jan 2017, 12 packages were actually
> uploaded to the NEW queue of Debian system.
> 
> Some of the students have expressed their interests in packaging key and
> important  software like gitlab, diaspora and GNUkhata in future. Some
> have expressed their desire to continue packaging the nodejs packages.

Nice, very nice.


> The list of packages done during the workshop:
> *Package* : *Packager Name*
> Is-generator-fn : Aarti Kashyap
> node-uglifycss : Abhijit A.M.
> md5-o-matic : Abhishek Kuvalekar
> node-plur : Abhishek Lolage
> asynckit : Aditya Neralkar
> node-console-control-strings : Ajinkya Chavan
> node-hoek : Akash Sarda
> Node-pkgconf : Akshay Kemekar
> node-json-schema : Amarpreet Arora
> common-path-prefix : Ameya Apte
> node-is-ob : Gaurav Juvekar
> node-buf-compare : Nikhil Gawande
> node-single-line-log-1.1.2 : Nupur Malpani
> node-cli-boxes : Pradnya Hulle
> clean-yaml-object : Prathamesh Mane
> node-arrify : Ravi Purne
> imurmurhash : Roshan

I did see more then one ITP from Roshan


> stringstream : Rushikesh Bhadane
> node-assert-plus : Saurabh Agrawal
> is-retry-allowed : Saurabh Agrawal
> node-fn-name : Shirish Togarla
> node-ci-info : Siddhesh Rane
> node-call-signature : Sudhanshu Allurwar
> node-binary-extensions : Sumedh Pendurkar
> node-aproba-1.0.4 : Tushar Agey
> node-xdg-basedir : Vinay Desai
> Ansi-align : Yashashree Kolhe
> tweetnacl : Yashashree Kolhe
> has-unicode : Yogiraj Kulkarni
> node-caller : Yogiraj Kulkarni
> node-require-inject : Yogiraj Kulkarni
> 
> The workshop is documented on the Loomio (www.loomio.org) page at [1]
> and [2] and also on COEP Moodle [3], and being updated on COEP wiki also
> [4]. Photos are available on Loomio page [2].
> 
> Regards,
> Abhijit A M
> abhiji...@disroot.org
> 
> [0] http://www.coep.org.in
> [1] https://www.loomio.org/d/LTpSdMuX/debian-packaging-pre-requisites

Which starts with
  On previous packaging workshops, we had to spent a lot of time
  troubleshooting issues when people used older versions of Ubuntu which
  had older version of dh-make, gem2deb, npm2deb etc. So we thought of
  clearly mentioning the pre requisites so we can use the available time
  more efficiently.
That is soo familiar,
thanks for the text after
  You MUST have a debian unstable system (physical, virtual machine or a 
container)

> [2] 
> https://www.loomio.org/d/grVdcCx8/debian-packaging-workshop-at-coep-jan-2017
> [3] http://moodle.coep.org.in/moodle/course/view.php?id=428#section-0
> [4] 
> http://foss.coep.org.in/coepwiki/index.php/Debian_Packaging_workshop_2nd_Jan_to_8th_Jan_2017
> [5] http://co.fsug.in



Nice achievement.
Respect.


It is up to us, the Debian community, to accept new members, to blend them in.


Groeten
G