hi,
after the (not so) recent discussion on the use of 'debian/upstream/',
i'd like to question one of my own packaging practices:
whenever i feel the need to use small scripts in my packaging (scripts
that are called during the build phase, e.g. in order to work around
upstream weirdnesses), i te
Sébastien Villemot wrote:
> Le samedi 08 mars 2014 à 12:18 +, Ghislain Vaillant a écrit :
>> I am currently working on packaging a scientific project for which
>> MATLAB wrappers are available. I was wondering where these should be
>> installed in the file system tree and whether there were par
Paul Wise writes ("Re: Bits from the Security Team"):
> Debian doesn't support skipping releases right now and I expect if we
> support releases for a longer amount of time that won't change.
But, in practice, skip upgrades often work anyway. I'd encourage
maintainers not to gratuitously break th
Package: wnpp
Owner: Marius Gavrilescu
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org
* Package name: libplack-middleware-header-perl
Version : 0.04
Upstream Author : Masahiro Chiba
* URL : https://metacpan.org/release/Plac
Christoph Biedl schrieb:
> Matthias Urlichs wrote...
>
>> IMHO the decision to designate release N to be a LTS release has too be
>> made at release time of N+1 _at_the_latest_, so maintainers know that they
>> may not remove their "old" upgrade script snippets.
>
> Agreed, but given the long inte
On Thu, Mar 06, 2014 at 09:00:13AM +0800, Paul Wise wrote:
> > * There are quite some vulnerabilities which are addressed in Debian,
> > but for which no CVE identifier has been assigned.
>
> Perhaps we could encourage those submitting security bugs to
> X-Debbugs-CC the oss-sec list?
That woul
Hi,
> Skipping releases will not be possible/supported
Oh, it's certainly *possible*.
The question is, how painful an experience fixing the resulting problems
will be …
However, "LTS" releases should support upgrades from one LTS to the next.
That's kindof what I'd expect, and Ubuntu certainly
Le lundi, 10 mars 2014, 13.52:59 Ian Jackson a écrit :
> Paul Wise writes ("Re: Bits from the Security Team"):
> > Debian doesn't support skipping releases right now and I expect if
> > we
> > support releases for a longer amount of time that won't change.
>
> But, in practice, skip upgrades often
On 10/03/14 15:44, Matthias Urlichs wrote:
> However, "LTS" releases should support upgrades from one LTS to the
> next. That's kindof what I'd expect, and Ubuntu certainly shows
> that it's possible.
I think LTS is being used to mean two different things here. Debian
releases are already more lik
Hi,
Simon McVittie:
> Does Ubuntu support upgrading directly from old-old-LTS to
> current-LTS, e.g. from hardy to precise or from lucid to trusty?
Not that I know of, no.
> Ubuntu's Wikipedia page doesn't seem to think so. A direct upgrade
> from squeeze to jessie would be of a similar magnitud
Hi,
I keep discussing the same issues caused by minified JS files (mostly
JQuery) in their source tarballs over and over. Could maybe those who
care deeply about this write a concise wiki page with all that upstream
needs to know about our expectations, so that I can point them to it?
That page sh
On March 10, 2014 06:27:01 PM Joachim Breitner wrote:
> Also, am I too pragmatic in suggesting that we should accept non-source
> files in tarballs if they are legally distributed and not used during
> the build (especially not included in the binary packages)?
I generally take that approach.
On 2014-03-10 13:05:30, Steve M. Robbins wrote:
> On March 10, 2014 06:27:01 PM Joachim Breitner wrote:
>
> > Also, am I too pragmatic in suggesting that we should accept non-source
> > files in tarballs if they are legally distributed and not used during
> > the build (especially not included in
Xavier Roche dijo [Wed, Mar 05, 2014 at 06:47:13PM +0100]:
> > I would tend to side more with Odyx here in that the keys are still
> > considered trustworthy enough to be in the keyring but we're encouraging
> > moving to stronger keys and no longer accepting these keys to be
> > included.
>
> Yes
Hi,
On 2014-03-10 18:27, Joachim Breitner wrote:
I keep discussing the same issues caused by minified JS files (mostly
JQuery) in their source tarballs over and over. Could maybe those who
care deeply about this write a concise wiki page with all that upstream
needs to know about our expectation
On 2014-03-10 17:32, Matthias Urlichs wrote:
Simon McVittie:
Ubuntu's Wikipedia page doesn't seem to think so. A direct upgrade
from squeeze to jessie would be of a similar magnitude.
Well, yes, except that I continue to hope that with a LTS release in
our
archive the non-LTS releases would ap
Didier 'OdyX' Raboud wrote...
> I, for one, have been routinely dropping transitional binary packages
> that were in the latest stable; they were needed to migrate from (the
> releases which are now) oldstable to stable but are only archive noise
> now. Delaying that cleanup for an additional s
Hi,
On Sat, Mar 08, 2014 at 07:36:23PM +0100, Christoph Biedl wrote:
> Moritz Muehlenhoff wrote...
>
> > Security archive
> > -
> >
> > * In order to avoid bottlenecks and to open up the security process
> > further we're planning to allow maintainers which are not part of
> >
Hi,
Am Montag, den 10.03.2014, 20:29 +0100 schrieb Philipp Kern:
> as long as the code in question is not under a license that requires the
> full, non-minified source to be reproduced and if the copyright notices
> and license terms as potentially required by the license are present, I
> don't
Joachim Breitner writes:
> So you’d say it is acceptable to leave jquery-1.11.0.min.js in a tarball
> if it is unused (e.g. if it is removed in the clean target, and possibly
> documented in README.Source)? Can maybe someone from the ftp-team
> confirm this?
My understanding (as someone who is n
On Tue, Mar 11, 2014 at 3:29 AM, Philipp Kern wrote:
> Hi,
>
>
> On 2014-03-10 18:27, Joachim Breitner wrote:
>>
>> I keep discussing the same issues caused by minified JS files (mostly
>> JQuery) in their source tarballs over and over. Could maybe those who
>> care deeply about this write a conci
On Tue, Mar 11, 2014 at 3:29 AM, Philipp Kern wrote:
> as long as the code in question is not under a license that requires the
> full, non-minified source to be reproduced and if the copyright notices and
> license terms as potentially required by the license are present, I don't
> see why not. B
Paul Wise writes:
> I'd suggest an acceptable workaround is to include the source in the
> debian.tar.gz/diff.gz or to repack the upstream tarball, probably the
> latter since jQuery is usually an embedded code copy.
> https://wiki.debian.org/EmbeddedCodeCopies
Note that we do not (and should n
On Tue, Mar 11, 2014 at 1:27 AM, Joachim Breitner wrote:
> nor mess with tarball repackaging (which I consider ugly, a cludge, and
> to be avoided if possible)
Recent versions of uscan can automatically repack upstream tarballs to
remove files, just include a Files-Excluded line in debian/copyrig
On Tue, Mar 11, 2014 at 7:43 AM, Ben Finney wrote:
> I'd love to see clarification of the ftp-team's position on obfuscated
> files in source packages, preferably in an official location for future
> reference.
I quote from [1]:
Source missing
Your package contains files that need source but do
Very goood, the great names.
2014-03-10 14:35 GMT-03:00 Kurt Roeckx - Debian Project Secretary <
secret...@debian.org>:
>
> We're now into the campaigning period. The candidates this year
> are:
> - Lucas Nussbaum
> - Gergely Nagy
> - Neil McGovern
>
> More details about the vote can be found a
Paul Wise writes:
> I think that DFSG item 2 means we have promised not to do this.
>
> Also this particular issue is in the reject FAQ.
>
> https://ftp-master.debian.org/REJECT-FAQ.html
It would be very helpful if Paul could at this point give a URL to
exactly which item he's referring to. But
On March 11, 2014 10:50:10 AM Paul Wise wrote:
> On Tue, Mar 11, 2014 at 7:43 AM, Ben Finney wrote:
> > I'd love to see clarification of the ftp-team's position on obfuscated
> > files in source packages, preferably in an official location for future
> > reference.
Recalling that the context of th
28 matches
Mail list logo
