Re: [Pkg-citadel-devel] Bug#851086: Bug#859789: RFH: citadel/webcit
> 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) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#884832: ITP: node-gulp-header -- Gulp extension for adding headers to files
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 : Expat Programming Lang: JavaScript Description : Gulp extension for adding headers to files This package is needed for building a new version of GRR.
Bug#884833: ITP: node-gulp-footer -- Gulp extension for adding footers to files
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 Programming Lang: JavaScript Description : Gulp extension for adding footers to files This package is needed for building a new version of GRR.
Bug#884834: ITP: node-gulp-if -- Gulp extension for using the LESS CSS compiler
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: JavaScript Description : Gulp extension Gulp extension for using the LESS CSS compiler This package is needed for building a new version of GRR.
Re: Why do we list individual copyright holders?
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 to hold _copyright_) you document in debian/copyright that a) you assume copyright holder to be the stated author, and b) that the copyright holder is anonymous. ...and see where that leads... - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#884839: ITP: node-gulp-angular-templatecache -- Gulp extension for dealing with AngularJS templates
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 : Expat Programming Lang: JavaScript Description : Gulp extension for dealing with AngularJS templates This package is needed for building a new version of GRR.
Bug#884841: ITP: node-gulp-closure-deps -- Gulp extension for generating Closure deps.js files
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 : Expat Programming Lang: JavaScript Description : Gulp extension for generating Closure deps.js files This package is needed for building a new version of GRR.
Bug#884840: ITP: node-gulp-closure-compiler -- Gulp extension for the Google Closure Compiler
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 * License : Expat Programming Lang: JavaScript Description : Gulp extension for the Google Closure Compiler This package is needed for building a new version of GRR.
Bug#884842: ITP: node-gulp-if -- Gulp extension for controlling the flow of vinyl objects.
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: JavaScript Description : Gulp extension for controlling the flow of vinyl objects. This package is needed for building a new version of GRR.
Bug#884844: ITP: node-gulp-sass -- Gulp extension for using the SASS CSS compiler
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: JavaScript Description : Gulp extension for using the SASS CSS compiler This package is needed for building a new version of GRR.
Bug#884843: ITP: node-gulp-insert -- String manipulation library for Gulp
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 Programming Lang: JavaScript Description : String manipulation library for Gulp This package is needed for building a new version of GRR.
Re: Why do we list individual copyright holders?
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 >>> file. In the rest, there is no need to list them. Only the license >>> matters. >>> >>> .oO( should the copyright file be renamed to license to avoid this >>> eternal discussion? ) >> >> Tracking copyright holders is an essential prerequisite for tracking >> licensing, because only a license granted by the copyright holder(s) >> of a work is of any use to us (and our users). > > I suspect you are setting an impossibly high bar for determining the > license of a work. We can (and do) rely on upstream telling us the > truth when they say the work is of a certain license, and that > contributions from third parties have been accepted under that > license. I suspect you read more into my words than I (intended to) put there. I did not imply that we need to hunt down and get physical documentation attesting copyright. By "tracking" I merely meant that we should keep track of which parts of the source code correlates with which (upstream claims of) copyright and (only their) licensing grants. Or that in case of relaxing (e.g. assuming a copyright holder from metadata like commit messages) then we should document in what way we are arguably "inventing facts". > If what you say were true, no non-trivial piece of software would be > distributable. I disagree - but maybe because I don't understand your logic. Care to elaborate (sorry, I didn't get your meaning from below questions)? > Is your copyright credited on all the packages where you have > submitted patches? Not explicitly in the header of all (substantial) patches that I have authored, no. I am not perfect, but I try. I do believe that others examining my packaging work can sensibly assume from my copyright claims of packaging files in general, that (substantial) patches authored by me is copyright me with same license as the packaging in general. If they cannot safely assume that, then they will need to get in touch with me to verify - just as I will have to do with our upstreams. Was your point in asking that question something else? > There's plenty of software in the archive where there is uncredited > copyright, and that is not a problem because the contribution was made > under a given license. Care to provide some examples? I strongly believe you mistaken: Code licensed but without a copyright holder is not really licensed. [ I am not a lawyer, yada yada... ] - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Why do we list individual copyright holders?
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 more important, in general terms, than problems that are > strictly theoretical. > > 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 accepted are a bit confusing and only partly documented, and > the people who set those requirements basically don't participate in these > discussions. As long as the decision-makers aren't participating and we > don't have clear documentation of the rules, even talking about it is > pointless. > > I feel like what we really need is a working group that contains members > with the authority to speak for ftpmaster, along with a good cross-section > of interested parties, to get together on a public but separate mailing > list and hash out a concrete proposal for how we think copyright and > license notices should work in the project. Then bring that back to the > project. Otherwise, we're just going to keep having this discussion every > three months or so, and nothing is going to really change. YES. -- cheers, Holger signature.asc Description: PGP signature
Exclicitly or "implicitly" mark architectures a packages does not build
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[1] the severity of this issue for packages that were never built on a certain architecture are not serious. So the severity of all these bugs was decreased to wishlist. Since we also intend to care for wishlist bugs I'm now wondering the following: 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 bad idea since once the Build-Depends might become available the package could easily build. In some cases we even added a Build-Depends which actually is not really a Build-Depends but just a Depends of the package but there is no point to build the package if it can not be installed afterwards (see for instance gasic[2]). So as far as I see #860655 there is no sensible means to fix it properly and I'm tempted to close it (since I also do not see any sense in tagging it wontfix). May be it needs to be said that we do not have the manpower to fix each and every piece of code to make sure all Build-Depends build on every architecture neither does it make sense technically to for instance have gene sequencing software on outdated hardware available. Some code just needs 64 bit and upstream will not support other hardware. Am I missing something? Kind regards Andreas. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860652#15 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873859#15 -- http://fam-tille.de
Re: Exclicitly or "implicitly" mark architectures a packages does not build
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 bad idea since once the > Build-Depends might become available the package could easily 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) - mozjs/gjs and Cinnamon's cjs fork (ostree) - valgrind (dbus) smcv
Re: Exclicitly or "implicitly" mark architectures a packages does not build
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)
> - mozjs/gjs and Cinnamon's cjs fork (ostree)
> - valgrind (dbus)
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 WTF. Is this trying to do Build-Recommends ? :-)
Is this something to do with a test-suite ? Maybe those tests should
be autopkgtests instead.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Exclicitly or "implicitly" mark architectures a packages does not build
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 WTF. Is this trying to do Build-Recommends ? :-)
>
> Is this something to do with a test-suite ? Maybe those tests should
> be autopkgtests instead.
Someone on #chiark pointed me to #728371. Good grief.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#884851: ITP: r-cran-crosstalk -- GNU R inter-widget interactivity for HTML widgets
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-widget interactivity for HTML widgets Provides building blocks for allowing HTML widgets to communicate with each other, with Shiny or without (i.e. static .html files). Currently supports linked brushing and filtering. Remark: This package will be maintained by the Debian Science team at https://anonscm.debian.org/git/debian-science/packages/r-cran-crosstalk.git
Re: Has Copyright summarizing outlived its usefulness?
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 with copyright files that were touched only by two persons: Once by me when writing it and once by ftpmaster when reading it. This seems like spending time of two people who might do something more fruitful things for our users caused by an interpretation of our policy which is obviously not shared by every contributor to this thread. I admit I became used to simply follow ftpmaster requests blindly since this was the less time consuming way to deal with the problem. Discussions here on debian-devel list leaded close to never to a response by ftpmaster and thus were no efficient means to let a package passing new. In general I'm very happy with ftpmaster work since frequently there were real issues. I'm not happy with e-mail communication with ftpmaster but I learned that IRC can fix this in most cases. I'm happy that our ftpmasters take over some work I would not like to do myself and thus a repeated thank you guys Andreas. -- http://fam-tille.de
Re: Exclicitly or "implicitly" mark architectures a packages does not build
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 these > architectures from the list of architectures in d/control. However, as > far as I understood that's rather a bad idea since once the > Build-Depends might become available the package could easily build. Correct. > So as far as I see #860655 there is no sensible means to fix it properly > and I'm tempted to close it (since I also do not see any sense in > tagging it wontfix). 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 archived. > May be it needs to be said that we do not have the > manpower to fix each and every piece of code to make sure all > Build-Depends build on every architecture neither does it make sense > technically to for instance have gene sequencing software on outdated > hardware available. Some code just needs 64 bit and upstream will not > support other hardware. If code will not actually build or run on 32-bit systems then it's reasonable to mark it as not for those arches, but if it could, or might (we don't know yet), even if you think it would be uselessly slow, I'd leave the option open (i.e. allow the package to build if all the build-deps are available). > Am I missing something? Not that I can see. You understand the situation. One of the good things about debian is the availablity of software for many architectures. We shouldn't restrict that any more than we have to. 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', so making such a list was unhelpful. Often they really wanted to make a 'doesn't build on arch foo' list but we didn't have a mechanism for that (that's still not fixed SFAIK). So not giving a list at all is good if it can be avoided. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Exclicitly or "implicitly" mark architectures a packages does not build
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', so making such a list was > unhelpful. Often they really wanted to make a 'doesn't build on arch > foo' list but we didn't have a mechanism for that (that's still not > fixed SFAIK). So not giving a list at all is good if it can be > avoided. It would be really good to have such a list, this would ease QA work on "uncommon" archs. Background: for reproducible builds we're rebuilding all sid/main packages on amd64, i386, arm64 and armel. And thankfully people actually look at all these results, both for plain old ftbfs bugs as well as for reproducible builds issues. 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 maintainers do not want such bugs to clutter their views of the BTS. Hmm. Something certainly *is* buggy, if "only" debian/control for not having a better way to express this. :-) -- cheers, Holger signature.asc Description: PGP signature
Re: Exclicitly or "implicitly" mark architectures a packages does not build
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 there yet, or arch >> is new since I made the list', so making such a list was >> unhelpful. Often they really wanted to make a 'doesn't build on arch >> foo' list but we didn't have a mechanism for that (that's still not >> fixed SFAIK). So not giving a list at all is good if it can be >> avoided. > > It would be really good to have such a list, this would ease QA work on > "uncommon" archs. Background: for reproducible builds we're rebuilding > all sid/main packages on amd64, i386, arm64 and armel. And thankfully > people actually look at all these results, both for plain old ftbfs bugs > as well as for reproducible builds issues. > > Thus it would be great to mark such packages as "currently ftbfs on > $arch, we know that, it's not great, but expected". > 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. gfaksdr IOhannes
Re: Exclicitly or "implicitly" mark architectures a packages does not 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 yet be available there…) this also and mostly affects arch:all binary packages. -- cheers, Holger signature.asc Description: PGP signature
wontfix close vs open (was Re: Exclicitly or "implicitly" mark architectures a packages does not build)
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 archived. speaking of wontfix bugs: is there a way to hide wontfix bugs from the list of bugs on "my"¹ qa page? this might already be the case (afair i currently don't have any open "wontfix" bugs), but it is something that keeps bothering me, so i'm raising it now that i got the cue :-) the BTS is both for users (those who report a bug) and developers (those that fix a bug). i understand that the first group should be made aware that there are issues that aren't going to be fixed. otoh i think that the second group shouldn't be bothered with bugs that they have already discarded (unless they are in a mood of "let's revise former decisions"). aiui to cater for the first group, bugs are tagged "wontfix" and left open. for the 2nd group, it strikes me more logical to tag the bug "wontfix" and close it. to cater for the needs of both groups, i think it would be nice to have two different views on all bugs (of a package, of a DM/team, of ...): - all open bugs including those "wontfix" - all closed bugs including those "wontfix" is this something that's already there and i just missed it? fgamsdr IOhannes ¹ https://qa.debian.org/developer.php?login=someuser
Re: Exclicitly or "implicitly" mark architectures a packages does not build
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 would be Build-Depends: valgrind-dev if that package
existed. (Arguably it should: it would be a tiny binary package containing
only a few headers, but it could be Architecture: all, and then packages
like dbus could Build-Depend on it unconditionally.)
> 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 WTF. Is this trying to do Build-Recommends ?
Sort of. It's enabling a non-essential feature on (hopefully) exactly
those architectures where it can work, to make programs that use libdbus
slightly more debuggable on those architectures.
Users of other architectures would be upset if dbus and all its
reverse-dependencies weren't buildable on that architecture (there are a
lot of rdeps), but at the same time it seems foolish to reject a helpful
debuggability feature available on most architectures just because there
exist architectures that can't do it.
libdbus contains a memory-pool allocator to recycle small,
repeatedly-allocated structs (quite possibly premature optimization, it
was added long before my involvement), which makes valgrind think memory
is still reachable even when, conceptually, it has been freed. To help
developers debug programs that are linked to libdbus, there's a debug
build that can be pulled in via LD_LIBRARY_PATH or LD_PRELOAD, which
among other things includes special instrumentation (using )
to tell valgrind to treat memory that is returned to the pool as though
it had been freed.
smcv
Re: Exclicitly or "implicitly" mark architectures a packages does not build
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 maintainers do not want such bugs to clutter their views of the BTS. Besides cluttering the view of BTS I think that's not the best approach since it requires manual interaction that somebody really files a bug which is not granted. Even if somebody like Lukas took over the task of filing bugs manually that's IMHO wasted time since you can finally "calculate" the packages in question with a sensibly crafted UDD query. So why on one hand spending developer time to file a bug and why cluttering BTS view on the other hand if things could be automatically calculated and you can get an up to date list easily? > Hmm. Something certainly *is* buggy, if "only" debian/control for not > having a better way to express this. :-) At least Wookey and I have the opinion that nothing (also not debian/contol) is buggy - that's why I was asking whether closing the bug is a sensible course of action. I also do not like to set > 20 bugs wontfix. Kind regards Andreas. -- http://fam-tille.de
Re: Exclicitly or "implicitly" mark architectures a packages does not build
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 the rebuilds. > > besides that it's not that easy (eg a package might not yet be available > there…) this also and mostly affects arch:all binary packages. 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? Kind regards Andreas. -- http://fam-tille.de
Bug#884861: ITP: node-temp-write -- Write string/buffer/stream to a temporary file
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 Programming Lang: JavaScript Description : Write string/buffer/stream to a temporary file This package is needed for gulp-closure-compiler which is needed building a new version of GRR.
Bug#884866: ITP: libspreadsheet-readsxc-perl -- Extract OpenOffice 1.x spreadsheet data
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 Description : Extract OpenOffice 1.x spreadsheet data The module parses OpenOffice 1.x spreadsheet files (.sxc) and returns Perl data structure to access its values. The package is a dependency of libspreadsheet-read-perl, but is silently ignored if not used. I plan to team-maintain the package in Debian Perl Group. I will need a sponsor to upload the package once it is ready.
Re: Exclicitly or "implicitly" mark architectures a packages does not build
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 know whether it's a known missing feature that the package doesnt build on $arch (or a new problem) or you would need to introduce state tracking and then you still wouldn't know whether a build failure on $arch is a new problem or an old problem, because maybe it's a temporary problem... -- cheers, Holger signature.asc Description: PGP signature
Re: Why do we list individual copyright holders?
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 accepted are a bit confusing and only partly documented, and >the people who set those requirements basically don't participate in these >discussions. As long as the decision-makers aren't participating and we >don't have clear documentation of the rules, even talking about it is >pointless. I must mention that this is most often the case with one quite powerful group in Debian, and it has been that way for more than a decade. And I get beaten up for mentioning this every time I do. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Exclicitly or "implicitly" mark architectures a packages does not build
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 any architecture will make the arch:all package > appear and then you cannot know whether it's a known missing feature > that the package doesnt build on $arch Sure you can know. You can calculate from UDD on what architecture you can create the arch:all package and on what you can't. > (or a new problem) or you would > need to introduce state tracking and then you still wouldn't know > whether a build failure on $arch is a new problem or an old problem, > because maybe it's a temporary problem... Since you can also query UDD whether a missing package has was there (at least on a previous release) you can know this as well. May be I should write an according query and than close all those bugs ... Kind regards Andreas. -- http://fam-tille.de
Re: Exclicitly or "implicitly" mark architectures a packages does not build
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
Bug#884872: ITP: iem-plugin-suite -- IEM's spatialization suite
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 suite The IEM Plug-in Suite is an audio plugin suite created at the Institute of Electronic Music and Acoustics (Graz, Austria). It features Higher-Order Ambisonic plug-ins (up to 7th order), among them a number of state of the art encoders, directional compressors, directivity shapers, delay and reverb effects and analysis tools. The binary packages will include the plugins as Linux VST plugins and as standalone applications. I intend to maintain this under the pkg-multimedia-maintainers umbrella.
