> We are one bugfix away from that release. Hoping to get it out over
> the
> next week or so.
>
> It will have a new version number :)
Great! Thanks Art! I'll do an upload when it's available.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Me
Package: wnpp
Owner: Hilko Bengen
Severity: wishlist
Control: block 884830 by -1
* Package name: node-gulp-header
Version : 1.8.9
Upstream Author : Michael J. Ryan
(http://github.com/tracker1)
* URL : https://github.com/tracker1/gulp-header#readme
* License :
Package: wnpp
Owner: Hilko Bengen
Severity: wishlist
Control: block 884830 by -1
* Package name: node-gulp-footers
Version : 1.0.5
Upstream Author : Michael J. Ryan
(http://github.com/tracker1)
* URL : https://github.com/tracker1/gulp-footer
* License : Expat
Package: wnpp
Owner: Hilko Bengen
Severity: wishlist
Control: block 884830 by -1
* Package name: node-gulp-footers
Version : 3.3.2
Upstream Author : Chris Cowan
* URL : https://github.com/plus3network/gulp-less#readme
* License : Expat
Programming Lang: JavaS
Quoting Holger Levsen (2017-12-19 22:01:52)
> On Tue, Dec 19, 2017 at 06:44:54PM +0100, Jonas Smedegaard wrote:
>>> What if the author is anonymous then?
>> Then who granted the license?
>
> the anonymous author.
Ok. Then (assuming the source mentions only that anonymous _author_ not
who claims t
Package: wnpp
Owner: Hilko Bengen
Severity: wishlist
Control: block 884830 by -1
* Package name: node-gulp-angular-templatecache
Version : 2.0.0
Upstream Author : Mickel (http://mickel.me)
* URL : https://github.com/miickel/gulp-angular-templatecache#readme
* License
Package: wnpp
Owner: Hilko Bengen
Severity: wishlist
Control: block 884830 by -1
* Package name: node-gulp-closure-deps
Version : 0.4.0
Upstream Author : Daniel Steigerwald (https://github.com/steida)
* URL : https://github.com/steida/gulp-closure-deps
* License
Package: wnpp
Owner: Hilko Bengen
Severity: wishlist
Control: block 884830 by -1
* Package name: node-gulp-closure-compiler
Version : 0.4.0
Upstream Author : Daniel Steigerwald (https://github.com/steida)
* URL : https://github.com/steida/gulp-closure-compiler#readme
*
Package: wnpp
Owner: Hilko Bengen
Severity: wishlist
Control: block 884830 by -1
* Package name: node-gulp-if
Version : 2.0.2
Upstream Author : Rob Richardson (http://robrich.org/)
* URL : https://github.com/robrich/gulp-if
* License : Expat
Programming Lang:
Package: wnpp
Owner: Hilko Bengen
Severity: wishlist
Control: block 884830 by -1
* Package name: node-gulp-sass
Version : 3.1.0
Upstream Author : David Manning
* URL : https://github.com/dlmanning/gulp-sass#readme
* License : Expat
Programming Lang: JavaScrip
Package: wnpp
Owner: Hilko Bengen
Severity: wishlist
Control: block 884830 by -1
* Package name: node-gulp-insert
Version : 0.5.0
Upstream Author : Ryan Schmukler
(http://slingingcode.com/)
* URL : https://github.com/rschmukler/gulp-insert/
* License : Expat
Quoting Felipe Sateler (2017-12-19 23:52:55)
> On Tue, 19 Dec 2017 15:41:00 +0100, Jonas Smedegaard wrote:
>> Quoting Felipe Sateler (2017-12-19 14:20:42)
>>> Sometimes the license requires listing the copyright holders. In
>>> those cases, the list of holders must be present in the copyright
>>>
On Tue, Dec 19, 2017 at 03:46:58PM -0800, Russ Allbery wrote:
> This is all kind of a mess, and I think Debian would be well-served by
> looking for opportunities to minimize the very real and significant cost
> to Debian contributors for doing boring and demotivating paperwork.
> That's probably m
Hi,
in spring several packages from Debian Med team received "FTBFS on i386:
unsatisfiable build-dependencies" bug reports (sorry for not caring
earlier). An "example bug" #860655 is in CC. Originally these bugs
were filed with severity serious but at it was pointed out by Gianfranco
Costamagna[
On Wed, 20 Dec 2017 at 12:05:19 +0100, Andreas Tille wrote:
> Yes, there are packages that do not build on a certain
> architecture due to missing Build-Depends. I could exclude these
> architectures from the list of architectures in d/control. However, as
> far as I understood that's rather a ba
Simon McVittie writes ("Re: Exclicitly or "implicitly" mark architectures a
packages does not build"):
> Some dependencies outside Debian-Med that often cause this issue, due
> to needing specific porting to each new architecture:
>
> - libseccomp (example dependent packages: systemd, flatpak)
>
Ian Jackson writes ("Re: Exclicitly or "implicitly" mark architectures a
packages does not build"):
> I see in dbus_1.12.2-1.dsc
>
> Build-Depends: ...
> valgrind [amd64 arm64 armhf i386 mips64 mips64el mips mipsel powerpc
> ppc64 ppc64el s390x]
> , ...
>
> which is rather
Package: wnpp
Severity: wishlist
Owner: Andreas Tille
* Package name: r-cran-crosstalk
Version : 1.0.0
Upstream Author : Joe Cheng
* URL : https://cran.r-project.org/package=crosstalk
* License : MIT
Programming Lang: GNU R
Description : GNU R inter-wi
Hi,
On Sun, Dec 17, 2017 at 12:34:24PM +0100, Gert Wollny wrote:
> ...
> Unless there is a legally binding reason to add individual copyrights
> to d/copyright, I'd vote for only a summary statement that lists all
> contributors for a package.
I agree to the point that in *some* cases I dealt wi
On 2017-12-20 12:05 +0100, Andreas Tille wrote:
> Hi,
>
> in spring several packages from Debian Med team received "FTBFS on i386:
> unsatisfiable build-dependencies" bug reports
> Yes, there are packages that do not build on a certain
> architecture due to missing Build-Depends. I could exclude
On Wed, Dec 20, 2017 at 02:31:42PM +, Wookey wrote:
> As a porter I notice quite a few packages where the maintainer has
> made things 'tidy' by giving an explicit architecture list when really
> the unlisted ones were really just 'doesn't build there yet, or arch
> is new since I made the list
On 2017-12-20 15:51, Holger Levsen wrote:
> On Wed, Dec 20, 2017 at 02:31:42PM +, Wookey wrote:
>> As a porter I notice quite a few packages where the maintainer has
>> made things 'tidy' by giving an explicit architecture list when really
>> the unlisted ones were really just 'doesn't build
On Wed, Dec 20, 2017 at 04:10:09PM +0100, IOhannes m zmölnig (Debian/GNU) wrote:
> but isn't this something that can be detected automatically?
> e.g. if <> on <> is not available in unstable and/or
> testing, exclude it from the rebuilds.
besides that it's not that easy (eg a package might not y
On 2017-12-20 15:31, Wookey wrote:
> Leaving it open wontfix makes it easy for someone to find the issue in
> the future and see what decision was made and why, and that the
> current situation is as correct as we can currently make it. But
> closing is also OK IMHO. The reasoning will still get ar
On Wed, 20 Dec 2017 at 12:51:36 +, Ian Jackson wrote:
> Simon McVittie writes ("Re: Exclicitly or "implicitly" mark architectures a
> packages does not build"):
> > - valgrind (dbus)
> Is this something to do with a test-suite ? Maybe those tests should
> be autopkgtests instead.
No, it woul
Hi Holger,
On Wed, Dec 20, 2017 at 02:51:55PM +, Holger Levsen wrote:
>
> Thus it would be great to mark such packages as "currently ftbfs on
> $arch, we know that, it's not great, but expected".
>
> One of way of marking this is certainly to have a bug open, though I can
> see how maintaine
On Wed, Dec 20, 2017 at 03:31:33PM +, Holger Levsen wrote:
> On Wed, Dec 20, 2017 at 04:10:09PM +0100, IOhannes m zmölnig (Debian/GNU)
> wrote:
> > but isn't this something that can be detected automatically?
> > e.g. if <> on <> is not available in unstable and/or
> > testing, exclude it from
Package: wnpp
Owner: Hilko Bengen
Severity: wishlist
Control: block 884840 by -1
* Package name: node-temp-write
Version : 3.3.0
Upstream Author : Sindre Sorhus (sindresorhus.com)
* URL : https://github.com/sindresorhus/temp-write#readme
* License : Expat
Pr
Package: wnpp
Severity: wishlist
Owner: Andrius Merkys
* Package name: libspreadsheet-readsxc-perl
Version : 0.20
Upstream Author : Christoph Terhechte
* URL : https://metacpan.org/release/Spreadsheet-ReadSXC
* License : Perl
Programming Lang: Perl
Descrip
On Wed, Dec 20, 2017 at 05:13:26PM +0100, Andreas Tille wrote:
> I can confirm that it also affects arch:all packages. But why shouldn't
> it be possible to detect this automatically also in this case?
because a build on any architecture will make the arch:all package
appear and then you cannot
On Tue, 19 Dec 2017 15:46:58 -0800, Russ Allbery
wrote:
>The problem with all of these discussions, however, and the reason why I
>largely stopped participating in them (particularly with my Policy Editor
>hat on), is that the rules for what one actually has to do in Debian to
>get a package accep
On Wed, Dec 20, 2017 at 05:44:31PM +, Holger Levsen wrote:
> On Wed, Dec 20, 2017 at 05:13:26PM +0100, Andreas Tille wrote:
> > I can confirm that it also affects arch:all packages. But why shouldn't
> > it be possible to detect this automatically also in this case?
>
> because a build on an
On Wed, Dec 20, 2017 at 08:10:19PM +0100, Andreas Tille wrote:
> May be I should write an according query and than close all those
> bugs ...
please do ;)
--
cheers,
Holger
signature.asc
Description: PGP signature
Package: wnpp
Severity: wishlist
Owner: IOhannes m zmoelnig
* Package name: iem-plugin-suite
Version : 1.0.0
Upstream Author : Daniel Rudrich
* URL : https://plugins.iem.at
* License : GPL-3+
Programming Lang: C++
Description : IEM's spatialization sui
34 matches
Mail list logo
