Re: I'm not MIA
Hi Miriam, > I explained a few weeks ago in debian-private the reasons of my low > activity, but I'm certainly not MIA. Thanks for your answer, as I am not reading debian-private I just followed the MIA procedure as laid out in the developers reference, section 7.4. I have contacted you 6 weeks ago without answer (I just sent you the email again in private communcation), and I documented the reasons why I believed that you are MIA. Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. +JAIST +TeX Live +Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: I'm not MIA
I never received any email from you, Gmail's powerful search engine doesn't find it. It seems that you used a really old email address instead of my Debian's one, out even the one listed in my blog. El 24 oct. 2017 8:33, "Norbert Preining" escribió: > Hi Miriam, > > > I explained a few weeks ago in debian-private the reasons of my low > > activity, but I'm certainly not MIA. > > Thanks for your answer, as I am not reading debian-private I just > followed the MIA procedure as laid out in the developers reference, > section 7.4. I have contacted you 6 weeks ago without answer (I just > sent you the email again in private communcation), and I documented > the reasons why I believed that you are MIA. > > Best > > Norbert > > -- > PREINING Norbert http://www.preining.info > Accelia Inc. +JAIST +TeX Live +Debian Developer > GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 >
I'm not MIA
Hi, > I am trying to contact Miriam Ruiz (uid=miriam) but I haven't seen any > sign of life/answer. All recent uploads of her packages are from other > people, her own uploads are from 2015. Her last blog entry is also from > 2015. I explained a few weeks ago in debian-private the reasons of my low activity, but I'm certainly not MIA. Greetings, Miry
Re: allowed uses of non-baseline CPU extensions
Quoting Josh Triplett (2017-10-24 04:29:32) > Philipp Kern wrote: > > I think that's a very important observation. I don't think you can > > necessarily conclude that the system where the package is initially > > installed is the system were the code is executed. > > > > In many kinds of image-based environments the machines the image is > > shipped to have very likely a different instruction capability than the > > machine where the image is built on. > > > > You argued in #873733[1] that you'd rather see the package installation > > fail. I see the appeal of that, especially to alert the admin. But there > > needs to be some kind of switch to flip to ignore these. Right now it > > seems that switch is IGNORE_ISA in the environment. But given the > > attempts to get a cleaner environment for dpkg, I'm not sure that's the > > best file. I.e. it'd be better to also have a flag file. > > As with others in this thread, I'd prefer to have apt understand the > concept of architecture variations and instruction set features, as a > variation on multiarch. (apt could potentially have a command-line > option to override that and install a package onto a system that didn't > understand the instruction set features, but that would potentially > require delaying the execution of any code from the package, which could > include maintainer scripts, until runtime, much like debootstrap's cross > mode.) I fail to see where else in this thread multiarch was mentioned but let me mention some multiarch related issues related to this topic. One way to handle packages requiring extensions that are not part of an architecture's baseline would be to introduce a partial architecture, for example armhf-neon which would be armhf but with NEON support. A partial architecture would not contain the Essential:yes packages or build-essential. It would be an architecture that one cannot build natively with but that one cross-builds to. Thus, the archive of this partial architecture would only contain the few packages that want to make use of certain CPU extensions. Of course right now we are lacking the infrastructure for packages to declare that they should be cross-compiled for such a partial architecture and due to missing or wrong multiarch annotations, cross compilation support in Debian is also still far from ideal. Also related is the topic "Partial archives for different ISAs" as talked about in the 2014 bootstrap sprint. Search for the heading here: https://lists.debian.org/20140829095214.gv19...@stoneboat.aleph1.co.uk An orthogonal problem is the issue of how dpkg and apt shall know which architectures are can be executed on the current system. This problem does not only affect this discussion about packages using instructions that are not part of the baseline but is also an undocumented issue with multiarch. Right now, the problem only doesn't surface much because apt by default prefers packages of the native architecture over packages from architectures declared as foreign. But for issues like this one as well as for cross compiling it would be useful if there was a way to declare or detect which architecture can be executed on a system. For example an amd64 system might be able to execute code for: - i386 - amd64 - x32 - armhf (through binfmt-support and qemu-user mode) Though nothing in the multiarch spec prevents a mipsel package marked as Multi-Arch:foreign to satisfy dependencies on that system even if mipsel code cannot be executed... cheers, josch signature.asc Description: signature
Bug#879660: ITP: rabbitmq-java-client -- RabbitMQ Java client
Package: wnpp Severity: wishlist Owner: Christopher Hoskin * Package name: rabbitmq-java-client Version : 5.0.0 Upstream Author : Pivotal Software, Inc. * URL : https://www.rabbitmq.com/java-client.html * License : MPL-1.1, GPL-2+, Apache-2 Programming Lang: Java Description : RabbitMQ Java client The RabbitMQ Java client library allows Java code to interface with RabbitMQ. The binary package will be named librabbitmq-client-java. I plan to maintain it within the pkg-java team. Christopher Hoskin
Re: MIA ? Miriam Ruiz
On 24.10.2017 05:02, Norbert Preining wrote: I am trying to contact Miriam Ruiz (uid=miriam) but I haven't seen any sign of life/answer. All recent uploads of her packages are from other people, her own uploads are from 2015. Her last blog entry is also from 2015. I'll try to talk to her. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
MIA ? Miriam Ruiz
Dear all (please Cc) I am trying to contact Miriam Ruiz (uid=miriam) but I haven't seen any sign of life/answer. All recent uploads of her packages are from other people, her own uploads are from 2015. Her last blog entry is also from 2015. The only activity I see is on her facebook page https://www.facebook.com/MiriamRuiz and her Twitter https://twitter.com/renacuaja But she seems to have lost any connection to Debian. I have contacted her already 6 weeks ago via email and now via Twitter. I nobody else has any contact or information about Debian activities, I propose to orphan all her packages. In particular I am planning to take over Calibre, where she is listed as maintainer but has *never*done*anything* (ask Martin Pitt who did the maintainance till recently when I took over). Thanks Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. +JAIST +TeX Live +Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: allowed uses of non-baseline CPU extensions
Philipp Kern wrote: > I think that's a very important observation. I don't think you can > necessarily conclude that the system where the package is initially > installed is the system were the code is executed. > > In many kinds of image-based environments the machines the image is > shipped to have very likely a different instruction capability than the > machine where the image is built on. > > You argued in #873733[1] that you'd rather see the package installation > fail. I see the appeal of that, especially to alert the admin. But there > needs to be some kind of switch to flip to ignore these. Right now it > seems that switch is IGNORE_ISA in the environment. But given the > attempts to get a cleaner environment for dpkg, I'm not sure that's the > best file. I.e. it'd be better to also have a flag file. As with others in this thread, I'd prefer to have apt understand the concept of architecture variations and instruction set features, as a variation on multiarch. (apt could potentially have a command-line option to override that and install a package onto a system that didn't understand the instruction set features, but that would potentially require delaying the execution of any code from the package, which could include maintainer scripts, until runtime, much like debootstrap's cross mode.) > As a side note I'm also amazed that there's literally a uuencoded blob > in the preinst that contains binary code that is unpacked and executed, > just like any malware would do. :) You can, in fact, simply ship a binary preinst. ~$ file /var/lib/dpkg/info/bash.preinst /var/lib/dpkg/info/bash.preinst: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=09642c1eb0869e8a9c075d0e8109f7ef1f62b320, with debug_info, not stripped - Josh Triplett
Re: allowed uses of non-baseline CPU extensions
Hi, I believe that we haven't talked about another problem is that what if one installing Debian in the portable drive and use it in another computer. I think we could use debconf to warn user that the CPU of the computer you are installing does not support instructions the package is requiring, which should be also volkswagenable on user's request. Yao Wei signature.asc Description: PGP signature
Re: allowed uses of non-baseline CPU extensions
On Tue, Oct 24, 2017 at 4:25 AM, Philipp Kern wrote: > I think that's a very important observation. I don't think you can > necessarily conclude that the system where the package is initially > installed is the system were the code is executed. Indeed. > You argued in #873733[1] that you'd rather see the package installation > fail. I see the appeal of that, especially to alert the admin. But there > needs to be some kind of switch to flip to ignore these. Right now it > seems that switch is IGNORE_ISA in the environment. But given the > attempts to get a cleaner environment for dpkg, I'm not sure that's the > best file. I.e. it'd be better to also have a flag file. The discussion on IRC between myself, apt folks and Adam was leaning towards an apt config & cmdline option. There was an interesting idea about pinning, but in the end it was concluded that this wouldn't be workable because the pinning would only be generated after apt had already started. >From there the discussion moved towards integrating this into apt, but... There is still the question of if we want to allow deviation from the baseline at all and if we don't, who is going to do the work to achieve the goal of falling back on baseline code at runtime for all upstreams. > As a side note I'm also amazed that there's literally a uuencoded blob > in the preinst that contains binary code that is unpacked and executed, > just like any malware would do. :) It cannot use files from the package, since those are not available in preinst: https://www.debian.org/doc/debian-policy/#maintainer-script-flowcharts -- bye, pabs https://wiki.debian.org/PaulWise
Bug#879650: ITP: arctica-greeter -- LightDM Arctica Greeter
Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: arctica-greeter Version : 0.99.0.1 Upstream Author : Mike Gabriel * URL : https://github.com/ArcticaProject/arctica-greeter * License : GPL-3 Programming Lang: Vala Description : LightDM Arctica Greeter A greeter shell for the LightDM login manager. Arctica Greeter can be used as local display manager as well as thin client login manager. . With the bin:package arctica-greeter-remote-logon installed, you can use the greeter as a remote logon manager (currently supported: RDP sessions, X2Go sessions). This requires an X2Go Session Broker on the other end. . The arctica-greeter-guest-session bin:package will add guest session support to the greeter. . A special theme for Debian will also be provided.
Re: New package, name recycling
On Fri, Oct 20, 2017 at 16:59:58 +0200, W. Martin Borgert wrote: > Hi, > > just to be sure, that this is not a problem: > > There used to be a package "dino" in Debian until jessie. Upstream > development dried up years ago and dino became extinct. > > Recently, a new "dino" appeared on the surface of earth, which is a > completely different program. Like git vs git or node vs node, but > with only one contender. > > I would package the new dino under this name, because I don't think > there is a conflict. > > Any objections? > I think reusing package names for a different purpose is very bad, in almost all cases. Pretty sure including this one. Cheers, Julien
Re: allowed uses of non-baseline CPU extensions
On 10/05/2017 05:01 AM, Paul Wise wrote: > A better place to put isa-support might be in an apt plugin that > detects packages being installed that declare for example CPU-Flags: > SSE4.1 and prevents installing them unless in a chroot (for d-i or > debootstraps) and has an option to disable that blockage. Zero idea if > apt has a hook that could be used for this. I think that's a very important observation. I don't think you can necessarily conclude that the system where the package is initially installed is the system were the code is executed. In many kinds of image-based environments the machines the image is shipped to have very likely a different instruction capability than the machine where the image is built on. You argued in #873733[1] that you'd rather see the package installation fail. I see the appeal of that, especially to alert the admin. But there needs to be some kind of switch to flip to ignore these. Right now it seems that switch is IGNORE_ISA in the environment. But given the attempts to get a cleaner environment for dpkg, I'm not sure that's the best file. I.e. it'd be better to also have a flag file. As a side note I'm also amazed that there's literally a uuencoded blob in the preinst that contains binary code that is unpacked and executed, just like any malware would do. :) Kind regards Philipp Kern [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873733 signature.asc Description: OpenPGP digital signature
Re: New: "cme run paste-license script"
On Monday, 23 October 2017 13:27:48 CEST Pirate Praveen wrote: > On ഞായര് 22 ഒക്ടോബര് 2017 11:09 വൈകു, Dominique Dumont wrote: > I tried this today and it worked mostly. Thanks for doing the major part > already (the actual formatting part). You're welcome :-) > I think cme should not require --force here as earlier License: MPL-2.0 > lines have empty license text and cme should not remove those lines in > the final output (I have to add back 'License: MPL-2.0' lines removed by > cme). Agreed -> https://github.com/dod38fr/config-model/issues/15 > Note: I know MPL 2.0 is now part of common licenses but I wanted to try > cme as npm2deb did not create the correct copyright file in this case. have you tried "cme update dpkg-copyright" ? All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: New: "cme run paste-license script" (was: Re: pasting license text into debian/copyright)
On Sunday, 22 October 2017 21:47:12 CEST Andreas Tille wrote: > Could you please explain what you mean by "main section"? For me > > Files: * > > would qualify as "main section" but you seem to have a different > understanding of this term. ok. Let's use the same terminology as debian/copyright. I meant the section made of one or more "Stand-alone License paragraph" [1] . This one was missing from the file, the CeCILL license was not defined, hence the file was considered as invalid by cme. > > May be I should just display a > > "changed" message when summarising the changes applied to a text > > parameter. > > I think that's a more helpful output. ok. Will do. > I don't say that the GUI is bad - I just prefer a command line tool for > this job. ok. fair enough. > > $ cme modify dpkg-copyright -force 'License:CeCILL text=.file(COPYING) ! > > Files:"*" License short_name=CeCILL ! Files:"debian/*" License > > short_name=CeCILL' > > Ahhh, this helps. :-) > I just would love a way shorter command line since I somehow will never > remember this one. :-P You should be able to use paste-license script in you add first the License text as a standalone paragraph (using paste-license), *then* add the Files:* paragraphs. > Just to let me understand better: I understood this thread that way > that creating the license text in a proper form is a goal of this > specific cme option. In how far is the problem above a corner case. It's a corner case because you started from an copyright file that is considred invalid by cme because it lacks the standalone license paragraph that defines CeCILL license text). This challenges the way error tolerance is done in cme, which is not much tested yet. All the best Dod [1] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#stand-alone-license-paragraph -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: allowed uses of non-baseline CPU extensions
On Mon, 2017-10-23 at 16:47 +0200, Adam Borowski wrote: > On Mon, Oct 23, 2017 at 04:36:11PM +0200, Julian Andres Klode wrote: > > sse2-support and other packages that fail to install can massively > > screw up systems, potentially leaving dpkg in a state that people > > cannot easily recover from - that is, apt-get install -f might not > > be working at that point. We should not have such packages. > > It cleanly aborts installation in preinst. > > If there are any problems with that, they'd also apply to every other > package with preinst that can possibly fail. Anything with failing maintainer scripts is very much not nice, especially for unexperienced users. (One the reasons I don't like packages trying to be smart and configure things, then break in the maintainer script. Dumb packages are more friendly.) Ansgar
Re: allowed uses of non-baseline CPU extensions
On Mon, Oct 23, 2017 at 04:47:52PM +0200, Adam Borowski wrote: > It cleanly aborts installation in preinst. that's a violation of the release teams requirement for a stable release, where all packages *must* install cleanly… -- cheers, Holger signature.asc Description: PGP signature
Re: allowed uses of non-baseline CPU extensions
On Mon, Oct 23, 2017 at 04:36:11PM +0200, Julian Andres Klode wrote: > sse2-support and other packages that fail to install can massively > screw up systems, potentially leaving dpkg in a state that people > cannot easily recover from - that is, apt-get install -f might not > be working at that point. We should not have such packages. that's exactly why I marked #873733 as wonfix. -- cheers, Holger signature.asc Description: PGP signature
Re: allowed uses of non-baseline CPU extensions
On Mon, Oct 23, 2017 at 04:36:11PM +0200, Julian Andres Klode wrote: > sse2-support and other packages that fail to install can massively > screw up systems, potentially leaving dpkg in a state that people > cannot easily recover from - that is, apt-get install -f might not > be working at that point. We should not have such packages. It cleanly aborts installation in preinst. If there are any problems with that, they'd also apply to every other package with preinst that can possibly fail. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U. ⣾⠁⢰⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift ⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters ⠈⠳⣄ relevant to duties], shall be punished by death by shooting.
Re: allowed uses of non-baseline CPU extensions
On Sun, Oct 22, 2017 at 12:33:02PM +0300, Adrian Bunk wrote:
> On Thu, Oct 05, 2017 at 03:52:56AM +0200, Adam Borowski wrote:
> >...
> > But, Adrian Bunk warned that this makes violating the baseline too easy.
> > And indeed, I just noticed an attempt to use an extension in a way I don't
> > consider to be valid: #864012. I understand the maintainer's reasoning,
> > and don't blame him for following recommendations of that package's
> > upstream, but it's not appropriate for what I assume our _unwritten_ rules
> > mean. And here's the problem: I can't seem to find an explicit requirement
> > that packages must follow the baseline! So let's discuss and make a policy.
> >...
>
> The policy so far has been "baseline violations are RC bugs".
>
> And while your intentions are laudable, you are solving a small problem
> but creating a huge problem.
>
> For pcsx2, an obscure emulator that only works on i386 and requires SSE2,
> I am saying meh and see how a dependency on sse2-support is actually an
> improvement.
>
> Note that the number of such packages is very low, usually there is
> portable code with the problematic code (build time or runtime) optional.
>
> The problem is that blessing baseline violations with a dependy on
> *-support is completely screwing the baseline.
>
> One interesting aspect of baseline violations are upgrades
> to a new stable.
>
> The documented way to upgrade jessie -> stretch is:
> apt-get upgrade
> apt-get dist-upgrade
>
> Think of at what point newly added *-support dependencies
> will become visible during stretch -> buster upgrades.
sse2-support and other packages that fail to install can massively
screw up systems, potentially leaving dpkg in a state that people
cannot easily recover from - that is, apt-get install -f might not
be working at that point. We should not have such packages.
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.
Bug#879604: ITP: r-cran-rcpproll -- GNU R efficient rolling / windowed operations
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-rcpproll Version : 0.2.2 Upstream Author : Kevin Ushey * URL : https://cran.r-project.org/package=RcppRoll * License : GPL Programming Lang: GNU R Description : GNU R efficient rolling / windowed operations Provides fast and efficient routines for common rolling / windowed operations. Routines for the efficient computation of windowed mean, median, sum, product, minimum, maximum, standard deviation and variance are provided. Remark: This package belongs to a pyramid of dependencies to upgrade r-cran-caret to its latest upstream version. It will be maintained by the Debian Science team at https://anonscm.debian.org/git/debian-science/packages/r-cran-rcpproll.git Any takers for other new dependencies of r-cran-caret would be really appreciated. Also other Uploaders who volunteer to keep on maintaining the packages are really welcome.
Bug#879601: ITP: r-cran-sfsmisc -- GNU R utilities from 'Seminar fuer Statistik' ETH Zurich
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-sfsmisc Version : 1.1-1 Upstream Author : Martin Maechler * URL : https://cran.r-project.org/package=sfsmisc * License : GPL Programming Lang: GNU R Description : GNU R utilities from 'Seminar fuer Statistik' ETH Zurich This packagr assembles a set of useful utilities ['goodies'] from Seminar fuer Statistik ETH Zurich, quite a few related to graphics; some were ported from S-plus. Remark: This package belongs to a pyramid of dependencies to upgrade r-cran-caret to its latest upstream version. It will be maintained by the Debian Science team at https://anonscm.debian.org/git/debian-science/packages/r-cran-cvst.git Any takers for other new dependencies of r-cran-caret would be really appreciated. Also other Uploaders who volunteer to keep on maintaining the packages are really welcome.
Bug#879598: ITP: r-cran-gower -- GNU R Gower's Distance
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-gower Version : 0.1.2 Upstream Author : Mark van der Loo * URL : https://cran.r-project.org/package=gower * License : GPL Programming Lang: GNU R Description : GNU R Gower's Distance Compute Gower's distance (or similarity) coefficient between records. Compute the top-n matches between records. Core algorithms are executed in parallel on systems supporting OpenMP. Remark: This package belongs to a pyramid of dependencies to upgrade r-cran-caret to its latest upstream version. It will be maintained by the Debian Science team at https://anonscm.debian.org/git/debian-science/packages/r-cran-cvst.git Any takers for other new dependencies of r-cran-caret would be really appreciated. Also other Uploaders who volunteer to keep on maintaining the packages are really welcome.
Re: allowed uses of non-baseline CPU extensions
On Sun, Oct 22, 2017 at 06:53:49PM +0800, Aron Xu wrote: >... > With packages like sse2-support maintainers have the option of > creating different flavors of their packages with modern instructions > enabled/disabled, The opposite is true. The result are not different flavors (which would be OK), the result is one package that does not support the baseline. If what you have in mind is a foo-avx package in addition to a foo package, then that's not the problematic case (the only technical question would be whether foo-avx should be in a separate package or in the foo package). > this gives great possibility to some very common use > cases, for instance "avx-support" on amd64, which is critical to most > scientific software to run at appropriate performance. In this case we > can avoid a painful tradeoff between keeping and raising the baseline > which has zero flexibility. There is no such tradeoff, the only thing we avoid is either upstream or the maintainer supporting both. The proper upstream solution are several versions of the performance critical part with runtime selection. If a maintainer wants to provide different flavors, I remember seeing some package (in Debian Med?) taking the approach of compiling the whole program twice with a tiny wrapper program that does runtime detection and then calls the actual program. And if things should *really* be optimimized for maximum performance, you'd end up with a -src package that compiles the software with no hardening and -march=native. > Users of really old or rare hardware should be able to handle their > own case - by recompiling critical packages themselves, Debian is a binary distribution, it is not for the individual maintainer to decide how many users to screw by not supporting their hardware. And if the package can just be recompiled to support the baseline, this is somehting the maintainer is supposed to be able to handle (see above). > by producing something like raspbian, The raspian baseline has never been supported by the Debian armhf port. non-AVX on amd64 and non-NEON on armhf are fully supported by Debian. > or at least by staying on an old release if > they need something can't be supported at all (i.e. upstream removed > compatibility in current release). How many packages can you name that do support non-SSE2 in a previous Debian stable but cannot be made to compile without SSE2-support now? > Regards, > Aron cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: New: "cme run paste-license script"
On ഞായര് 22 ഒക്ടോബര് 2017 11:09 വൈകു, Dominique Dumont wrote: > No problem. cme tries to address a very complicated problem and can be > confusing when dealing with corner cases. I tried this today and it worked mostly. Thanks for doing the major part already (the actual formatting part). Original copyright file, __ Files: * Copyright: 2017 Mozilla Developer Network License: MPL-2.0 Files: debian/* Copyright: 2017 Pirate Praveen License: MPL-2.0 __ cme run paste-license --arg license=MPL-2.0 --arg file=LICENSE --force I think cme should not require --force here as earlier License: MPL-2.0 lines have empty license text and cme should not remove those lines in the final output (I have to add back 'License: MPL-2.0' lines removed by cme). git diff after cme run, __ diff --git a/debian/copyright b/debian/copyright index 94e94df..b5f7980 100644 --- a/debian/copyright +++ b/debian/copyright @@ -5,10 +5,381 @@ Source: https://developer.mozilla.org Files: * Copyright: 2017 Mozilla Developer Network -License: MPL-2.0 Files: debian/* Copyright: 2017 Pirate Praveen -License: MPL-2.0 +License: MPL-2.0 + Mozilla Public License Version 2.0 + == [...] __ Note: I know MPL 2.0 is now part of common licenses but I wanted to try cme as npm2deb did not create the correct copyright file in this case. signature.asc Description: OpenPGP digital signature
