use of debian/scripts/ folder

[forum : : für : : umläute]

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 tend to collect them in a folder debian/scripts/
i like this approach as it doesn't pollute the debian/ namespace too
much, and clearly distinguishes between build-scripts and e.g.
"maintainer-scripts".

now i wonder: is this good practice? is debian/scripts/ a good place to
put things into? is there a DEP-x on the way that reserves a file
"debian/scripts" for other purposes?

fgamsdr
IOhannes


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/531da7bc.4050...@umlaeute.mur.at

Re: packaging of MATLAB files

[Stuart Prescott]

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 particular
>> things to be careful with. I am talking about pure MATLAB files for
>> now, i.e. only files with .m extension, no mex files.
> 
> The first thing to figure out is whether your .m files run under GNU
> Octave (which is likely, but needs to be verified). If not, the .m files
> cannot be put in the main section of Debian since they depend on nonfree
> software, and should rather go in the contrib section.

I would disagree with this interpretation. We have lots of things in the 
archive that are designed to interoperate with non-free software. 

- packages provide files in /usr/share/doc/$package/examples that require 
things not in Debian
- packages provide interfaces to read files that might not be able to be 
generated by anything in Debian
- we include software that interfaces with non-free services

Now if matlab were required for operation of this package, then it's heading 
towards contrib rather than main. But just because the .m files are not 
useful to people without matlab, they are useful as examples to people who 
do have matlab and there's no reason to deprive those users of useful files. 
We shouldn't pretend that the examples are universally useful though and a 
README to that effect would be appropriate.

Of course if they just worked with octave, then that would be even better.

cheers
Stuart

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lfkbvc$41v$1...@ger.gmane.org

Re: Bits from the Security Team

[Ian Jackson]

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 them.  For example, aggressively
removing compatibility code is a bad idea.  (It's bad for our
downstreams too).

> We don't yet do any testing for upgrades from oldstable2testing etc so
> there will probably be some broken things, perhaps we should?

That would be nice but I don't have any effort to do it personally...

Thanks,
Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21277.50107.155216.490...@chiark.greenend.org.uk

Bug#741260: ITP: libplack-middleware-header-perl -- middleware for modifying HTTP response headers

[Marius Gavrilescu]

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/Plack-Middleware-Header
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : middleware for modifying HTTP response headers

Plack::Middleware::Header is a Plack middleware for modifying HTTP response
headers.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1wn0zt-00038w...@ieval.ro

Re: Bits from the Security Team

[Moritz Mühlenhoff]

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 intervals between releases: Waiting until
> wheezy enters that state means at least two years, and I'd expect the
> enthusiasm I've seen for LTS to cool down a lot in that time.

(In case sufficient momentum is reached for squeeze-lts, which *hint* *hint*
needs actual commitment:)
Skipping releases will not be possible/supported, if anyone wants to
upgrade from squeeze-lts to jessie both updates can to be done subsequently
in one maintenance windows.

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/slrnlhrmkc.4jj@inutil.org

Re: Bits from the Security Team

[Moritz Mühlenhoff]

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 would generate to much noise.

> Reading LWN I sometimes note the same issue happens for other
> distributions. Does the security team monitor the advisory
> announcements of upstreams and other distributions and auto-correlate
> those with CVEs?

Yes, from time to time we pick up issues from distros which don't 
request CVE IDs for their advisories. 
 
> > * We're currently using Subversion. We discussed changing to git, but
> >   git doesn't offer significant benefit for our purpose so we decided
> >   to stick with it.
> 
> >From when alioth was having repository issues, it appears having the
> full history locally is useful so git would still be a net win. Also
> is the SHA-1 hash chain not useful?

It doesn't really outweigh the additional work needed for the move.
 
> > * In order to avoid bottlenecks and to open up the security process
> >   further we're planning to allow maintainers which are not part of
> >   the security team to release security updates on their own
> 
> The backports archive has a whitelist mechanism, would that be useful?

Probably, we'll have a look when we get into the actual implementation.
 
> The information at www.d.o/security could use some updates.

Please file bugs against the www.debian.org pseudo bug with specific
changes.
 
> Will security team members be at DebConf14?

Most likely not.
 
> Is the team filtering debian-devel-changes and looking for words like
> security, overflow, attack etc? This might turn up some things that
> don't have CVEs but should.

Yes, at least two people are reading d-d-changes on a daily basis.

Cheers,
Moritz




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140310153043.GA4777@pisco.westfalen.local

Re: Bits from the Security Team

[Matthias Urlichs]

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 shows that it's
possible.

Downloading a GByte of packages just to immediately drop them again does
not strike me like a good solution, even in these days of mostly-high
bandwidth 'net access; don't forget that a couple of our users don't have
that luxury.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: Bits from the Security Team

[Didier 'OdyX' Raboud]

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 work anyway.  I'd encourage
> maintainers not to gratuitously break them.  For example, aggressively
> removing compatibility code is a bad idea.  (It's bad for our
> downstreams too).

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 stable release cycle really 
feels like unnecessary delay, during which we pretend to maintain code 
that hardly anyone tests.

The problem is that there is no policy in place to make us support 
oldstable-to-testing upgrades. If there's interest, that'd need to be 
decided with a more firm policy than "encourage maintainers".

Cheers,
OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/69734414.qmXaMjuj1O@gyllingar

Re: Bits from the Security Team

[Simon McVittie]

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 like Ubuntu LTS than Ubuntu non-LTS, and
Debian doesn't really have an equivalent of Ubuntu non-LTS releases.

Upgrading between 6-monthly Ubuntu releases is presumably rather
easier to support, since there's only 6 months' development churn to
deal with. Similarly, Ubuntu supporting an upgrade from old-LTS to
current-LTS is a lot like Debian supporting an upgrade from oldstable
to stable - either way it's a matter of about 2 years' development.

If people want to support oldstable for more than (1 release cycle + 1
year) but still disallow skipping releases, then the upgrade is still
feasible - it still pulls in about two years' worth of development,
and the only difference is that those two years were longer ago.

On the other hand, going directly from oldoldstable to stable pulls in
4 years of changes, and I think that's likely to result in having to
keep too many workarounds and too much cruft for too long, and having
to hold back progress for too long. For instance, wanting to be able
to do the upgrade from oldstable to stable using oldstable's apt and
dpkg means it already takes us 2 years to deploy an archive-wide
feature like dpkg multiarch - I wouldn't want it to take 4.

Does Ubuntu support upgrading directly from old-old-LTS to
current-LTS, e.g. from hardy to precise or from lucid to trusty?
Ubuntu's Wikipedia page doesn't seem to think so. A direct upgrade
from squeeze to jessie would be of a similar magnitude.

(With upstream hat on, my co-maintainers already think I'm going a bit
far by doing security releases for 2 year old D-Bus and Telepathy code
to support Debian stable, and I don't intend to extend that to a
longer-lived oldstable.)

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/531de47b.6000...@debian.org

Re: Bits from the Security Team

[Matthias Urlichs]

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 magnitude.
> 
Well, yes, except that I continue to hope that with a LTS release in our
archive the non-LTS releases would appear somewhat more often.

If not, I'd consider the exercise to be pointless, to be frank.

> (With upstream hat on, my co-maintainers already think I'm going a bit
> far by doing security releases for 2 year old D-Bus and Telepathy code
> to support Debian stable, and I don't intend to extend that to a
> longer-lived oldstable.)
> 
'xactly.
-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

jquery debate with upstrea

[Joachim Breitner]

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 should also point out the least effort required to satisfy us
(which, I believe, is downloading the corresponding source and dumping
it in the tarball).


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)? If we had
this I would neither have to bug upstream about their convenience copies
nor mess with tarball repackaging (which I consider ugly, a cludge, and
to be avoided if possible) and simply make sure in the packaging that I
use libjs-jquery instead of the included file.

Greetings,
Joachim


-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


signature.asc
Description: This is a digitally signed message part

Re: jquery debate with upstrea

[Steve M. Robbins]

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.  If there's a concern about tainting the 
binary package, then I put a rule in debian/rules to make sure the offending 
file is removed before building.


-Steve


signature.asc
Description: This is a digitally signed message part.

Re: jquery debate with upstrea

[Marcin Kulisz]

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 the binary packages)? 
> 
> I generally take that approach.  If there's a concern about tainting the 
> binary package, then I put a rule in debian/rules to make sure the offending 
> file is removed before building.

Hi all,
Some time ago there was discussion about minified js on d-mentors and from what
I know conclusion was that if orig.tar.gz contains any of this type of files it
should be repacked and version should be +dfsg.
Explanation about it should be in README.source.
-- 

|_|0|_|  |
|_|_|0| "Heghlu'Meh QaQ jajVam"  |
|0|0|0|  kuLa -  |

gpg --keyserver pgp.mit.edu --recv-keys 0x58C338B3
3DF1 A4DF C732 4688 38BC F121 6869 30DD  58C3 38B3


signature.asc
Description: Digital signature

Re: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!

[Gunnar Wolf]

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, this was my thoughts, too.
> 
> Or, to rephrase it: 1024D keys will "soon" be breakable (let's say in
> few years), but at this present time, they are still trustworthy enough
> to allow transition.
> 
> It doesn't mean that eventually, they'll be considered untrustworthy, later.

Right. But we do want to phase them out *completely* before they are
considered untrustworthy: We want to push gently as far as possible so
that most active DDs have 4096R, and then only deal with the long tail
of deprecated keys *while still not exposing ourselves* to impersonation.


signature.asc
Description: Digital signature

Re: jquery debate with upstrea

[Philipp Kern]

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 expectations, so that I can point them to it?
That page should also point out the least effort required to satisfy us
(which, I believe, is downloading the corresponding source and dumping
it in the tarball).


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)? If we had
this I would neither have to bug upstream about their convenience 
copies

nor mess with tarball repackaging (which I consider ugly, a cludge, and
to be avoided if possible) and simply make sure in the packaging that I
use libjs-jquery instead of the included file.


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. But I guess the latter is not commonly happening?


Kind regards
Philipp Kern


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/3bf683cdfbaab11625a69edecad8a...@hub.kern.lc

Re: Bits from the Security Team

[Philipp Kern]

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 appear somewhat more often.

If not, I'd consider the exercise to be pointless, to be frank.


I'd still buy us releases where you don't need to upgrade one year after 
another release happened, which is relatively painful. For Ubuntu it's a 
new release after two years, and then you still enjoy three more years 
of support. (Of course for main only, which needs to be reiterated quite 
often.)


Kind regards
Philipp Kern


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8b0096a400aa04d6e1995eb8abba8...@hub.kern.lc

Re: Bits from the Security Team

[Christoph Biedl]

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 stable release cycle really 
> feels like unnecessary delay, during which we pretend to maintain code 
> that hardly anyone tests.

The missing tests are indeed a problem. For migration code in
(usually) postinst or transitional packages I don't see the big issue,
besides a maintainer's notion of "I'd like to get rid of that old
stuff".


Face the fact: Users *will* skip upgrade from squeeze-lts to (then
stable) jessie, you cannot bar them from doing this. If they break
their system, any "That was not supported, told you so" is not
helping, neither them nor Debian's reputation. Better support such
upgrades from the beginning.

So I was thinking whether there was a way packages that do not support
skip upgrade may enforce an upgrade path via the intermediate
distribution. First idea was a new Pre-Conflicts: package
relationship, then I was wondering whether it shouldn't be simply
possible to write (for a package in jessie):

Package: foo
Conflicts: foo (<< $[wheezy-version]~)

But Policy 7.4 has the answer, it's "no".

Assuming we could somehow turn off that exception, a skip upgrade is
impossible for that package, but it's blocked /before/ things break.
The solution for the user then was to add the skipped release to
sources.list temporarily, and go on. The search engines soon will
learn that trick from the first bug reports, and users can find it
using the specific error message they see.

Benefit: Only the packages that do not support skip upgrades will need
that step, also reducing bandwidth usage and walltime needed for the
skip upgrade.

> The problem is that there is no policy in place to make us support 
> oldstable-to-testing upgrades. If there's interest, that'd need to be 
> decided with a more firm policy than "encourage maintainers".

Would you have preferred to read something "putting the burden onto
the maintainers"?

Christoph


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1394480...@msgid.manchmal.in-ulm.de

Re: Bits from the Security Team

[Salvatore Bonaccorso]

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
> >   the security team to release security updates on their own. This
> >   applies to packages which have frequent vulnerabilities and where
> >   the maintainers are involved in the update process anyway.
> 
> The current model at least theoretically allows someone (read: the
> security team) to review the patch provided by the maintainer. I like
> that four-eyes principle and wouldn't want to give it away.
> 
> But perhaps you plan is rather about moving the task of the actual
> upload to the maintainer *after* some discussion? Or will you stand
> being surprising by an unannounced security upload? (This is none of
> my business, I'm just curious.)

Disclaimer: there is no actual implementation for this yet, so only a
comment on that: The idea is to have something like the DM upload
permissions. There are packages which recieve frequent updates trough
security, where already now the maintainer is the one doing all the
packaging work, has the most knowledge and testing tme, but then the
bottleneck to actual release the package is the load/time missing on
the team. As Moritz writes, this will apply only to some specific
packages.

Hope that clarifies,

Regards,
Salvatore


signature.asc
Description: Digital signature

Re: jquery debate with upstream

[Joachim Breitner]

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 see why not. But I guess the latter is not commonly happening?

The most common case is that the file
http://code.jquery.com/jquery-1.11.0.min.js
is included without
http://code.jquery.com/jquery-1.11.0.js

The minified file contains a copyright header, and the license is MIT,
so I believe shipping jquery-1.11.0.min.js without query-1.11.0.js is
allowed.

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?

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


signature.asc
Description: This is a digitally signed message part

Re: jquery debate with upstream

[Ben Finney]

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 not on the ftp-team) is contrary to
that. Rather, a file that is in a non-source form – such as an
obfuscated (minified) JS file – must be removed from the source package.

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.

-- 
 \  “Nothing is more sacred than the facts.” —Sam Harris, _The End |
  `\   of Faith_, 2004 |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85y50htyay@benfinney.id.au

Re: jquery debate with upstrea

[Paul Wise]

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 concise wiki page with all that upstream
>> needs to know about our expectations, so that I can point them to it?
>> That page should also point out the least effort required to satisfy us
>> (which, I believe, is downloading the corresponding source and dumping
>> it in the tarball).
>>
>>
>> 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)? If we had
>> this I would neither have to bug upstream about their convenience copies
>> nor mess with tarball repackaging (which I consider ugly, a cludge, and
>> to be avoided if possible) and simply make sure in the packaging that I
>> use libjs-jquery instead of the included file.
>
>
> 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. But I guess the latter is not commonly happening?
>
> Kind regards
> Philipp Kern
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive:
> https://lists.debian.org/3bf683cdfbaab11625a69edecad8a...@hub.kern.lc
>



-- 
bye,
pabs

http://wiki.debian.org/PaulWise
http://bonedaddy.net/pabs3/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6Eu9gywVd_in=v+h+gcvyn9-johsh2vbaaj0k4itdx...@mail.gmail.com

Re: jquery debate with upstrea

[Paul Wise]

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. But I guess the latter is not commonly happening?

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

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

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6H4E0sm=zUp4Gft1YggfRoBPYs=uvjpx07lexywix2...@mail.gmail.com

Re: jquery debate with upstrea

[Russ Allbery]

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 not) repack upstream source for embedded
code copies that are not used in the build, if there are no other issues
with those copies.  It's sufficient to just not use them.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8761nltqg9@windlord.stanford.edu

Re: jquery debate with upstrea

[Paul Wise]

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/copyright.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6hg9yjzbw+uyetof8s65axyfacejcjvc8bgtquanwg...@mail.gmail.com

Re: jquery debate with upstream

[Paul Wise]

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 not have it. These
include PDF and PS files in the documentation, or auto-generated
files.

Generated files

Your package contains generated files (such as compressed .js
libraries) without corresponding original form. They're not considered
as the preferred form of modification, so you will either have to
provide corresponding original form, or remove them from your tarball,
eventually depending on an already available packages to provide
missing features.

1. https://ftp-master.debian.org/REJECT-FAQ.html

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6HtQ5k_-APj8msrDq=k_qkcsr74ypn5hwsg6c5-kve...@mail.gmail.com

Re: Debian Project Leader Elections 2014: Candidates

[Daniel Pimentel (d4n1)]

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 at:
> http://www.debian.org/vote/2014/vote_001
>
> I will make the platforms of the candidates available there
> as I receive them.
>
>
> Kurt Roeckx
> Debian Project Secretary
>
>


-- 
Me. Daniel Pimentel (d4n1 )

Re: jquery debate with upstrea

[Ben Finney]

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 that document doesn't appear
to have an addressible structure.

Which item in that FAQ document are you referring to?

-- 
 \  “You say “Carmina”, and I say “Burana”, You say “Fortuna”, and |
  `\I say “cantata”, Carmina, Burana, Fortuna, cantata, Let's Carl |
_o__)the whole thing Orff.” —anonymous |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85lhwhtmjm@benfinney.id.au

Re: jquery debate with upstream

[Steve M. Robbins]

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 the question was whether "it is acceptable to 
leave ${some file} in a tarball if it is unused" ...


> Source missing
> 
> Your package contains files that need source but do not have it. These
> include PDF and PS files in the documentation, or auto-generated
> files.

... I guess if a file is not needed for the build, then that file does not 
"need source" either. 

> Generated files
> 
> Your package contains generated files (such as compressed .js
> libraries) without corresponding original form. They're not considered
> as the preferred form of modification,

Nor would it need to be modified, so it shouldn't matter that it's not the 
"preferred form for modification".


I can understand that it is nicer if upstream can be persuaded to clean things 
up and not do either of the above.  I also realize that some folks may prefer 
to re-pack a tarball for "cleanliness" objectives.  But are you really 
suggesting a distributable but "non source" file in the tarball can't simply be 
ignored?  What objective would that serve?

Regards,
-Steve


signature.asc
Description: This is a digitally signed message part.