Bug#893919: [Pkg-emacsen-addons] Bug#893919: RFS: yasnippet-snippets/0~git20180307.2b4c4d7e-3 [RC]

2018-03-23 Thread Nicholas D Steeves 
Hi!

On Fri, Mar 23, 2018 at 02:27:15PM -0700, Sean Whitton wrote:
> Hello,
> 
> On Fri, Mar 23 2018, Nicholas D Steeves wrote:
> 
> > After many hours trying to work around bug #893598 while attempting to
> > transition yasnippet-snippets to a dummy package I have had to
> > conclude that yasnippet-snippets must remain the package that contains
> > the snippets until buster+1.
> 
> Please justify this conclusion.  Someone on debian-mentors might see a
> way out.
> 
> -- 
> Sean Whitton

I believe that it is preferable to have two packages with files that
upgrade without warnings than the alternative of a dummy package that
causes dpkg to emit warnings on upgrade.

I tried every combination of maintscript,
yasnippet-snippet.maintscript, and elpa-yasnippet.maintscript that I
could think of, a variety of postrm experiments, and a variety of ways
to treat the two packages in d/control.  With yasnippet-snippets as an
empty dummy package the following always occurred:

Unpacking yasnippet-snippets (0~git20180307.2b4c4d7e-3) over (0~git20161123-1) 
...
dpkg: warning: unable to delete old directory 
'/usr/share/yasnippet-snippets/tuareg-mode': Directory not empty
dpkg: warning: unable to delete old directory 
'/usr/share/yasnippet-snippets/scala-mode': Directory not empty
dpkg: warning: unable to delete old directory 
'/usr/share/yasnippet-snippets/ruby-mode': Directory not empty
dpkg: warning: unable to delete old directory 
'/usr/share/yasnippet-snippets/js-mode': Directory not empty
dpkg: warning: unable to delete old directory 
'/usr/share/yasnippet-snippets/clojure-mode': Directory not empty
dpkg: warning: unable to delete old directory
'/usr/share/yasnippet-snippets': Directory not empty

The one exception was when I even tried a yasnippet-snippet.postrm
which removed files from elpa-yasnippet-snippet...but that's an
unacceptable approach because a dummy package should be safe to remove
and shouldn't remove files from another package.

Given that these warnings go away when yasnippet-snippets contains the
snippets I have concluded that the snippets must remain as part of
this package for one release.  Given buster will have both an
elpa-yasnippet-snippets and a yasnippet-snippets package the most
significant reason against seems to be that users lose the ability to
remove a dummy package...

If someone sees a way around this, please ask if I've tried it :-)

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#893919: [Pkg-emacsen-addons] Bug#893919: RFS: yasnippet-snippets/0~git20180307.2b4c4d7e-3 [RC]

2018-03-23 Thread Sean Whitton 
Hello,

On Fri, Mar 23 2018, Nicholas D Steeves wrote:

> After many hours trying to work around bug #893598 while attempting to
> transition yasnippet-snippets to a dummy package I have had to
> conclude that yasnippet-snippets must remain the package that contains
> the snippets until buster+1.

Please justify this conclusion.  Someone on debian-mentors might see a
way out.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#893919: RFS: yasnippet-snippets/0~git20180307.2b4c4d7e-3 [RC]

2018-03-23 Thread Nicholas D Steeves 
Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "yasnippet-snippets".  While
I have DM permissions for the package, it is necessary to seek
sponsorship because this upload introduces a new bin:package
(elpa-yasnippet-snippets).  I've spoken with Sean Whitton on IRC and
he advocates that the elpa-package is a must.

After many hours trying to work around bug #893598 while attempting to
transition yasnippet-snippets to a dummy package I have had to
conclude that yasnippet-snippets must remain the package that contains
the snippets until buster+1.

Package name: yasnippet-snippets
Version : 0~git20180307.2b4c4d7e-3
Upstream Author : Andrea Crotti 
URL : https://github.com/AndreaCrotti/yasnippet-snippets
License : GPL-3+
Section : lisp

It builds these binary packages:

elpa-yasnippet-snippets - Andrea Crotti's official YASnippet snippets 
[configuration]
yasnippet-snippets - Andrea Crotti's official YASnippet snippets

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

https://mentors.debian.net/package/yasnippet-snippets

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

dget -x 
https://mentors.debian.net/debian/pool/main/y/yasnippet-snippets/yasnippet-snippets_0~git20180307.2b4c4d7e-3.dsc

More information about yasnippet-snippets can be obtained from 
https://github.com/AndreaCrotti/yasnippet-snippets

Alternatively, one can clone the git repo of the package using this command:

git clone https://salsa.debian.org/emacsen-team/yasnippet-snippets.git
# I am requestion sponsorship @commit: b4fbc92

Changes since the last upload:

yasnippet-snippets (0~git20180307.2b4c4d7e-3) unstable; urgency=medium

  * Add elpa-yasnippet-snippets package:
- Add 0003-Synchronise-declared-version-with-MELPA.patch.
- d/control: Change section to lisp.
- d/control: Add elpa-yasnippet-snippets section.
- d/control: Rely on ${elpa:Depends} for dependency resolution.
- d/control: yasnippet-snippets now depends on elpa-yasnippet-snippets.
  * Update yasnippet-snippets.maintscript to run for this version.

 -- Nicholas D Steeves   Fri, 23 Mar 2018 14:38:33 -0400

yasnippet-snippets (0~git20180307.2b4c4d7e-2) unstable; urgency=medium


Regards,
Nicholas D Steeves

Bug#861649: Newer version uploaded

2018-03-23 Thread Gard Spreemann 
On Tuesday 13 March 2018 13:58:07 CET Tobias Frost wrote:
> On Sun, Mar 11, 2018 at 06:48:10PM +0100, Gard Spreemann wrote:
> > On Sunday 11 March 2018 00:18:32 CET Gard Spreemann wrote:
> > > On Wednesday 7 March 2018 19:32:48 CET Tobias Frost wrote:
> > > > Please review d/copyright. I found at least one undocumented file which
> > > > is licensed Apache 2.0 and another one under LGPL3+. Neither are in 
> > > > d/copyright.
> > > 
> > > I'm looking into this, and will get back to you.
> > > 
> > 
> > I've updated the copyright information for the Apache 2.0-licensed
> > file, as well as another MIT-licensed file with missing coverage.
> 
> Thanks!.
> 
> Note that some files are claimed copyright just by "20xx INRIA" and
> "20xx INRIA (France)"
> As copyright must be verbatim, you need to addtionalyl write this in 
> d/copyright.
> Not sure about all those other variants of INRIA: Are they different
> organisattions (like a subsidiary) of just different writing of the same
> one? In the first case, you need to have one stanca for every different
> organisations,
> (hint: license-reconcile might help here)

I got in touch with upstream, who says:

[Begin quote]
This is a problem we have seen, but it was "too late", everybody
copy/paste the colleague copyright and just changed the Inria center's
name...  I have started to change it every where, every time I fix a
bug, but from what you say, I shall change it once for every files ;-)

The correct Copyright is "Inria".

If you want, I can change it everywhere and make a new version if it
can accelerate the submission.
[End quote]

It certainly sounds great if they can fix this upstream, but would a
statement like this suffice for now?
 
> Speaking about external sources... I see that there is also cpython in
> the source. As cpython is packaged, can it be also removed via
> Files-Exluded (as you said, you're repacking already, so we can reduce
> the size of the source package even more)

Maybe I misunderstood, but I can't see a bundled cpython. Did you mean
the cython subdirectory? It just contains .pyx sources to be compiled
with cython.

> Older stuff already mentioned, but still not fixed:
>   - many versioned build dependencies are already satisfied since
>   oldstable. As thus those old version constraint can be removed,
>   especially as this is a new package.

I've fixed this now (but haven't made a new upload).


Thanks a lot for your help. I'll upload a new version (also having a
new dependency that has become necessary after a change to sid's
Python package) when I hear back from you about the copyright question
above.


 Best,
 Gard

Bug#893904: RFS: dh-sysuser/1.3.2

2018-03-23 Thread Dmitry Bogatov 

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "dh-sysuser"

* Package name : dh-sysuser
  Version  : 1.3.2
  Upstream Author  : Dmitry Bogatov 
* Url  : https://salsa.debian.org/runit-team/dh-sysuser
* Licenses : GPL-3+
  Programming Lang : Perl
  Section  : admin

 dh-sysuser provides a debhelper sequence addon named 'sysuser'
 and command 'dh_sysuser', which provide declarating way to
 ensure, that required users are present after package installation
 and correctly handled after package removal.

It builds those binary packages:

  * dh-sysuser
  * sysuser-helper

This package succesfully builds on debomatic machine:

  http://debomatic-i386.debian.net/distribution#unstable/dh-sysuser/1.3.2

Alternatively, you can access package debian/ directory via git from URL:
https://salsa.debian.org/runit-team/dh-sysuser.git

More information about dh-sysuser can be obtained from
https://salsa.debian.org/runit-team/dh-sysuser

Changes since last upload:

  * Remove user on purge, not remove (Closes: #848239)
+ Thanks: Antoine Beaupré 

Regards,
  Dmitry Bogatov