Re: jquery debate with upstrea

[Joachim Breitner]

Hi,

Am Dienstag, den 11.03.2014, 10:34 +0800 schrieb 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.

ah, that’s news to me and has been on my secret wish list for long (and
wasn’t the case when I last looked)! That solves half of my issues with
this.

It’s not well documented in man uscan, which only tells me how to
disable that feature.

Do you (or anyone) know if it repacks the file consistently? I.e. will
two developers, who both use uscan to get the original tarball for the
same version and with the same File-Excluded get identical results?

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: Bits from the Security Team

[Didier 'OdyX' Raboud]

Le lundi, 10 mars 2014, 22.00:09 Christoph Biedl a écrit :
> > 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"?

Re-reading my statement again after hitting the send button made me 
admit that I didn't express what I intended to…

I was trying to say that there is no policy currently in place to ensure 
that skip-upgrades actually work, and at least one maintainer has 
already started to cleanup pre-wheezy stuff from his packages [0]. 
People "encouraging maintainers not to gratuitously break skip-upgrades" 
on debian-devel is by far not equivalent to a Release Team decision on 
bug severity for a failure to skip-upgrade for example.

Cheers,
OdyX

[0] I'd be surprised to be the only one, who knows.


--
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/7312246.zXeI0qdFfj@gyllingar

Re: jquery debate with upstrea

[Olivier Berger]

Hi.

Joachim Breitner  writes:

> 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).
>

It seems no one mentioned it, so may the following page suit your needs:

 https://wiki.debian.org/UpstreamGuide

Maybe it lacks specific directions about the minimized JS files, or
should point at a dedicated page.

My 2 cents,

Best regards,
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
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/871ty9rrfh@inf-8660.int-evry.fr

Re: jquery debate with upstream

[Jonas Smedegaard]

Quoting Steve M. Robbins (2014-03-11 07:11:36)
> 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" ...

Yes.  Leaving in tarball (as opposed to repackaging tarball to exclude a 
file) relates to *source* package, not produced binary packages.


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

Whether it is needed for build or not is related to production and 
Debian redistribution of *binary* packages.


>> 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?

I believe it is exactly the case that Debian do not allow 
(re)distribution of "source" which is not in the preferred form of 
editing.

Debian have a certain definition of Freedoms that we uphold which is 
largely compatible with other parts of the FOSS community, but not 
always identical - which leads to oddities like this need to repackage 
and strip parts of code that is properly licensed by upstream but still 
do not fit our definition of how things are acceptable to _us_ to 
distribute.

When approaching upstreams about this, we should be careful to not try 
impose our World views onto them, but only share with them how we treat 
their code that they have chosen to share with us, and how it would be 
more convenient for us that they share it slightly different.  They are 
commonly not doing anything "wrong", just by a different freedom logic 
than ours.


 - 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: jquery debate with upstrea

[Jonas Smedegaard]

Quoting Russ Allbery (2014-03-11 03:32:54)
> 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.

I agree that there are better ways than repackaging.

I disagree that "just not using [parts lacking true source]" is one of 
them.  Instead I find that the combination of these is acceptable:

 a) Include the "true source" in our addendum (the diff for v1 or the
tarball for v3 source formats)
 b) Ensure that "reformulated source" in the tarball we redistribute
pristine is indeed a reformulation of the "true source" (e.g. by 
comparing checksum against same processing done once)

That's more elegant in that we ship pristine upstream tarball, but not 
simpler because it puts the burden on the package maintainer to prove 
that the source we redistribute was not altered only reformulated.


 - 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: jquery debate with upstrea

[Joachim Breitner]

Hi,

Am Dienstag, den 11.03.2014, 11:22 +0100 schrieb Jonas Smedegaard:
> Quoting Russ Allbery (2014-03-11 03:32:54)
> > 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.
> 
> I agree that there are better ways than repackaging.
> 
> I disagree that "just not using [parts lacking true source]" is one of 
> them.  Instead I find that the combination of these is acceptable:
> 
>  a) Include the "true source" in our addendum (the diff for v1 or the
> tarball for v3 source formats)
>  b) Ensure that "reformulated source" in the tarball we redistribute
> pristine is indeed a reformulation of the "true source" (e.g. by 
> comparing checksum against same processing done once)
> 
> That's more elegant in that we ship pristine upstream tarball, but not 
> simpler because it puts the burden on the package maintainer to prove 
> that the source we redistribute was not altered only reformulated.

I see how that is solves the problem, and how it is idiologically
desirable, but is it worth it? Consider this:

I find a package that ships some-lib.min.js without source. It happens
that we have libsomelib-js in Debian. So I 

 1. Make debian/rules not install some-lib.min.js into the binaries.
 2. Change e.g. the HTML files to point to the file in
libsomelib-js.
 3. Try to find out what precise version some-lib.min.js is.
 4. Hunt down the source package for that version and include it in
debian/
 5. Build that to get another copy of some-lib.min.js is.
 6. Compare it with the one shipped by upstream.
 7. Possibly tweak build settings until the results are the same,
trying out various minimizers and options.

Of these 7 steps, only the first two actually affect the resulting
package, i.e. our users. From a practical point of view, I don’t believe
that we should spend time on 3-7, and instead replace it by

  3. Ensure that we can legally distribute libsomelib-js
  4. Add it to debian/clean (or maybe Excluded-Files), and be done with 
 it.

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

[cjwat...@debian.org: Accepted grub2 2.02~beta2-7 (source i386)]

[Colin Watson]

"Distribution: unstable".  Whoops.  It is far too easy to make this
mistake with sbuild if you're not quite paying absolutely perfect
attention.  My apologies ...

Anyway, while this was unintentional, I don't think it's actually
dreadful.  testing has 2.00-22, which is reasonably solid, and I wanted
to make sure wheezy ships with at least GRUB 2.02 anyway, so I might as
well just forge ahead now rather than trying to figure out how to back
this out.

-- 
Colin Watson   [cjwat...@debian.org]
--- Begin Message ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 10 Mar 2014 13:39:33 +
Source: grub2
Binary: grub2 grub-linuxbios grub-efi grub-common grub2-common grub-emu 
grub-emu-dbg grub-pc-bin grub-pc-dbg grub-pc grub-rescue-pc grub-coreboot-bin 
grub-coreboot-dbg grub-coreboot grub-efi-ia32-bin grub-efi-ia32-dbg 
grub-efi-ia32 grub-efi-amd64-bin grub-efi-amd64-dbg grub-efi-amd64 
grub-efi-ia64-bin grub-efi-ia64-dbg grub-efi-ia64 grub-efi-arm-bin 
grub-efi-arm-dbg grub-efi-arm grub-efi-arm64-bin grub-efi-arm64-dbg 
grub-efi-arm64 grub-ieee1275-bin grub-ieee1275-dbg grub-ieee1275 
grub-firmware-qemu grub-uboot-bin grub-uboot-dbg grub-uboot grub-xen-bin 
grub-xen-dbg grub-xen grub-yeeloong-bin grub-yeeloong-dbg grub-yeeloong 
grub-theme-starfield grub-mount-udeb
Architecture: source i386
Version: 2.02~beta2-7
Distribution: unstable
Urgency: medium
Maintainer: GRUB Maintainers 
Changed-By: Colin Watson 
Description: 
 grub-common - GRand Unified Bootloader (common files)
 grub-coreboot - GRand Unified Bootloader, version 2 (Coreboot version)
 grub-coreboot-bin - GRand Unified Bootloader, version 2 (Coreboot binaries)
 grub-coreboot-dbg - GRand Unified Bootloader, version 2 (Coreboot debug files)
 grub-efi   - GRand Unified Bootloader, version 2 (dummy package)
 grub-efi-amd64 - GRand Unified Bootloader, version 2 (EFI-AMD64 version)
 grub-efi-amd64-bin - GRand Unified Bootloader, version 2 (EFI-AMD64 binaries)
 grub-efi-amd64-dbg - GRand Unified Bootloader, version 2 (EFI-AMD64 debug 
files)
 grub-efi-arm - GRand Unified Bootloader, version 2 (ARM UEFI version)
 grub-efi-arm-bin - GRand Unified Bootloader, version 2 (ARM UEFI binaries)
 grub-efi-arm-dbg - GRand Unified Bootloader, version 2 (ARM UEFI debug files)
 grub-efi-arm64 - GRand Unified Bootloader, version 2 (ARM64 UEFI version)
 grub-efi-arm64-bin - GRand Unified Bootloader, version 2 (ARM64 UEFI binaries)
 grub-efi-arm64-dbg - GRand Unified Bootloader, version 2 (ARM64 UEFI debug 
files)
 grub-efi-ia32 - GRand Unified Bootloader, version 2 (EFI-IA32 version)
 grub-efi-ia32-bin - GRand Unified Bootloader, version 2 (EFI-IA32 binaries)
 grub-efi-ia32-dbg - GRand Unified Bootloader, version 2 (EFI-IA32 debug files)
 grub-efi-ia64 - GRand Unified Bootloader, version 2 (IA64 version)
 grub-efi-ia64-bin - GRand Unified Bootloader, version 2 (IA64 binaries)
 grub-efi-ia64-dbg - GRand Unified Bootloader, version 2 (IA64 debug files)
 grub-emu   - GRand Unified Bootloader, version 2 (emulated version)
 grub-emu-dbg - GRand Unified Bootloader, version 2 (emulated debug files)
 grub-firmware-qemu - GRUB firmware image for QEMU
 grub-ieee1275 - GRand Unified Bootloader, version 2 (Open Firmware version)
 grub-ieee1275-bin - GRand Unified Bootloader, version 2 (Open Firmware 
binaries)
 grub-ieee1275-dbg - GRand Unified Bootloader, version 2 (Open Firmware debug 
files)
 grub-linuxbios - GRand Unified Bootloader, version 2 (dummy package)
 grub-mount-udeb - export GRUB filesystems using FUSE (udeb)
 grub-pc- GRand Unified Bootloader, version 2 (PC/BIOS version)
 grub-pc-bin - GRand Unified Bootloader, version 2 (PC/BIOS binaries)
 grub-pc-dbg - GRand Unified Bootloader, version 2 (PC/BIOS debug files)
 grub-rescue-pc - GRUB bootable rescue images, version 2 (PC/BIOS version)
 grub-theme-starfield - GRand Unified Bootloader, version 2 (starfield theme)
 grub-uboot - GRand Unified Bootloader, version 2 (ARM U-Boot version)
 grub-uboot-bin - GRand Unified Bootloader, version 2 (ARM U-Boot binaries)
 grub-uboot-dbg - GRand Unified Bootloader, version 2 (ARM U-Boot debug files)
 grub-xen   - GRand Unified Bootloader, version 2 (Xen version)
 grub-xen-bin - GRand Unified Bootloader, version 2 (Xen binaries)
 grub-xen-dbg - GRand Unified Bootloader, version 2 (Xen debug files)
 grub-yeeloong - GRand Unified Bootloader, version 2 (Yeeloong version)
 grub-yeeloong-bin - GRand Unified Bootloader, version 2 (Yeeloong binaries)
 grub-yeeloong-dbg - GRand Unified Bootloader, version 2 (Yeeloong debug files)
 grub2  - GRand Unified Bootloader, version 2 (dummy package)
 grub2-common - GRand Unified Bootloader (common files for version 2)
Changes: 
 grub2 (2.02~beta2-7) experimental; urgency=medium
 .
   * Fix shift-held-down test not to clear other modifier key states
 (LP: #843804).
   * Explicitly pass an appropriate --target to grub-install in the postinst
 (suggested by Jordan Uggla).
   * Back

Re: jquery debate with upstrea

[Jonas Smedegaard]

Quoting Joachim Breitner (2014-03-11 11:29:31)
> Am Dienstag, den 11.03.2014, 11:22 +0100 schrieb Jonas Smedegaard:
> > Quoting Russ Allbery (2014-03-11 03:32:54)
> > > 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.
> > 
> > I agree that there are better ways than repackaging.
> > 
> > I disagree that "just not using [parts lacking true source]" is one of 
> > them.  Instead I find that the combination of these is acceptable:
> > 
> >  a) Include the "true source" in our addendum (the diff for v1 or the
> > tarball for v3 source formats)
> >  b) Ensure that "reformulated source" in the tarball we redistribute
> > pristine is indeed a reformulation of the "true source" (e.g. by 
> > comparing checksum against same processing done once)
> > 
> > That's more elegant in that we ship pristine upstream tarball, but not 
> > simpler because it puts the burden on the package maintainer to prove 
> > that the source we redistribute was not altered only reformulated.
> 
> I see how that is solves the problem, and how it is idiologically
> desirable, but is it worth it? Consider this:
> 
> I find a package that ships some-lib.min.js without source. It happens
> that we have libsomelib-js in Debian. So I 
> 
>  1. Make debian/rules not install some-lib.min.js into the binaries.
>  2. Change e.g. the HTML files to point to the file in
> libsomelib-js.
>  3. Try to find out what precise version some-lib.min.js is.
>  4. Hunt down the source package for that version and include it in
> debian/
>  5. Build that to get another copy of some-lib.min.js is.
>  6. Compare it with the one shipped by upstream.
>  7. Possibly tweak build settings until the results are the same,
> trying out various minimizers and options.
> 
> Of these 7 steps, only the first two actually affect the resulting
> package, i.e. our users. From a practical point of view, I don’t believe
> that we should spend time on 3-7, and instead replace it by
> 
>   3. Ensure that we can legally distribute libsomelib-js
>   4. Add it to debian/clean (or maybe Excluded-Files), and be done with 
>  it.

Yes, I did not mean to say that the tedious 7-step process is the only 
possible way, just that it was _a_ possible way to avoid repackaging 
upstream tarball but redistribute it pristine.

Your alternate 4-step process is an easier but uglier alternative.

If you care only about those of our users that consume binary packages, 
you may not even recognize the 4-step procedure as uglier ;-)


 - 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: [cjwat...@debian.org: Accepted grub2 2.02~beta2-7 (source i386)]

[Colin Watson]

On Tue, Mar 11, 2014 at 10:50:46AM +, Colin Watson wrote:
> Anyway, while this was unintentional, I don't think it's actually
> dreadful.  testing has 2.00-22, which is reasonably solid, and I wanted
> to make sure wheezy ships with at least GRUB 2.02 anyway,

Cyril points out that I mean jessie here.  Sigh.

-- 
Colin Watson   [cjwat...@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/2014030202.ga3...@riva.ucam.org

Re: [cjwat...@debian.org: Accepted grub2 2.02~beta2-7 (source i386)]

[Simon McVittie]

On 11/03/14 10:50, Colin Watson wrote:
> "Distribution: unstable".  Whoops.  It is far too easy to make
> this mistake with sbuild if you're not quite paying absolutely
> perfect attention.  My apologies ...

On the Lintian side of things, I attached a patch to
 in 2010 and
am still waiting for comments.

My patch just looks for Distribution=unstable, Changes=experimental
because that's the most annoying case ("I uploaded a version that
wasn't ready and now I have to use an epoch to roll it back").

On the other bug, Thorsten said:
> a) Distribution=unstable, Changes=experimental b)
> Distribution=experimental, Changes=unstable c) Distribution=*,
> Changes=UNRELEASED
> 
> All other mismatch cases should probably be a W, but for these
> three, I think not just an E but an autoreject could, maybe, be
> justified.

which I think is also reasonable.

Russ said
> I think we only want to do this check if the first line of the
> Changes file says UNRELEASED, since there are valid use cases for a
> mismatch otherwise.

but I don't know what those valid use-cases are. BinNMUs in testing
for a package uploaded to experimental, possibly? Anything else?

On the sbuild side:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=529281

tl;dr: extensive discussion of why this mistake is easy to make and
why sbuild can't trivially fix it; Raphael Hertzog suggests making
"sbuild foo_source.changes" do the right thing; Thorsten Glaser
suggests lintian autorejects for certain particularly bad and likely
combinations; Roger Leigh points out that just "sbuild" with no .dsc
file will now do the right thing.

Regards,
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/531ef1a5.2010...@debian.org

Bug#741345: ITP: mathematical-components -- Mathematical Components library for the Coq proof system

[Enrico Tassi]

Package: wnpp
Severity: wishlist
Owner: Enrico Tassi 

* Package name: mathematical-components
  Version : 1.4.0
  Upstream Author : Mathematical Components team
* URL :  http://www.msr-inria.fr/projects/mathematical-components/
* License : BSD
  Programming Lang: Coq
  Description : Mathematical Components library for the Coq proof system

>From version 1.5, the ssreflect source package was split in two by the
aupstrem:
- ssreflect (OCaml plugin for Coq, plus a small set of Coq files)
- mathcomp (the rest of the Coq files)
While the former is in debian, the latter is not (yet).


-- 
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/20140311124134.27670.70473.reportbug@birba.invalid

Re: Bits from the Security Team

[Ian Jackson]

Simon McVittie writes ("Re: Bits from the Security Team"):
> 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.

Package management tools are a special case.  I imagine the way you'd
do it would be to ship the new tools, built against oldoldstable, in a
special skip-upgrade partial suite.

I don't think this is at all impossible.

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/21279.10020.796829.209...@chiark.greenend.org.uk

Re: Bits from the Security Team

[Ian Jackson]

Didier 'OdyX' Raboud writes ("Re: Bits from the Security Team"):
> I was trying to say that there is no policy currently in place to ensure 
> that skip-upgrades actually work, and at least one maintainer has 
> already started to cleanup pre-wheezy stuff from his packages [0]. 
> People "encouraging maintainers not to gratuitously break skip-upgrades" 
> on debian-devel is by far not equivalent to a Release Team decision on 
> bug severity for a failure to skip-upgrade for example.

We could start small, by putting the encouragement in the policy
manual rather than on -devel.

I don't think this needs to involve release team decisions on bug
severity, unless we want to go as far as declaring failure to support
a skip upgrade an RC bug (which I think is probably impractical right
now).

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/21279.10153.492761.105...@chiark.greenend.org.uk

Re: jquery debate with upstream

[Ian Jackson]

Jonas Smedegaard writes ("Re: jquery debate with upstream"):
> Quoting Steve M. Robbins (2014-03-11 07:11:36)
> > 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?

None.  I think the file can be disregarded, provided we're sure it's
not used during the build.

> I believe it is exactly the case that Debian do not allow 
> (re)distribution of "source" which is not in the preferred form of 
> editing.

You have conspicuously failed to answer Jonas's question.  What
objective does removing these files and repacking the tarballs serve ?

> Debian have a certain definition of Freedoms [...]

Whose freedom is impaired, and in what way, by the presence of these
useless but ignored files in the tarball ?

> When approaching upstreams about this, we should be careful to not try 
> impose our World views onto them, but only share with them how we treat 
> their code that they have chosen to share with us, and how it would be 
> more convenient for us that they share it slightly different.  They are 
> commonly not doing anything "wrong", just by a different freedom logic 
> than ours.

In this subthread I think we are having an internal conversation about
what our own logic is, within Debian.  I'm sorry to say that I still
fail to see the logic behind your apparent (but not explicitly stated)
point of view.

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/21279.10430.860867.946...@chiark.greenend.org.uk

Re: [cjwat...@debian.org: Accepted grub2 2.02~beta2-7 (source i386)]

[Ian Jackson]

Simon McVittie writes ("Re: [cjwat...@debian.org: Accepted grub2 2.02~beta2-7 
(source i386)]"):
> On the sbuild side:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=529281
> 
> tl;dr: extensive discussion of why this mistake is easy to make and
> why sbuild can't trivially fix it; Raphael Hertzog suggests making
> "sbuild foo_source.changes" do the right thing; Thorsten Glaser
> suggests lintian autorejects for certain particularly bad and likely
> combinations; Roger Leigh points out that just "sbuild" with no .dsc
> file will now do the right thing.

If you use dgit, you cannot make this mistake :-).

(Of course I'm aware that there are reasons why a maintainer might not
want to use dgit right now, principally the poor interoperation with
`3.0 (quilt)'.)

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/21279.10701.452890.888...@chiark.greenend.org.uk

Re: jquery debate with upstream

[Paul Tagliamonte]

[ not as ftpteam -- man, I'm saying this a lot lately ]

On Tue, Mar 11, 2014 at 03:16:14PM +, Ian Jackson wrote:
> You have conspicuously failed to answer Jonas's question.  What
> objective does removing these files and repacking the tarballs serve ?

We distribute source. The question is, do we want to distribute binaries
in the source to which we have no, well, source. This means, do we want
to break the DFSG on the distribution of source packages?

> > Debian have a certain definition of Freedoms [...]
> 
> Whose freedom is impaired, and in what way, by the presence of these
> useless but ignored files in the tarball ?

We distribute them. The challenge here is does anyone use them. I leave
that question up to the reader.

> In this subthread I think we are having an internal conversation about
> what our own logic is, within Debian.  I'm sorry to say that I still
> fail to see the logic behind your apparent (but not explicitly stated)
> point of view.

Hopefully you can grok mine :)

> 
> Ian.

Cheers,
  Paul


-- 
 .''`.  Paul Tagliamonte   |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature

Re: jquery debate with upstream

[Thomas Goirand]

On 03/11/2014 11:16 PM, Ian Jackson wrote:
>> Debian have a certain definition of Freedoms [...]
> Whose freedom is impaired, and in what way, by the presence of these
> useless but ignored files in the tarball ?

In one of my package, I had openssl.dll in the source tarball (it was of
course removed later on).

Would you consider it ok as well to have it in a source package, as long
as it's not used during the build? And what about a windows .exe? Is it
different from having a minified .js that is also not in use?

Cheers,

Thomas

(note: this is not sarcasm or whatever, this is a real case that I'm
talking about, and I'm really interested in the opinion of 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/531f37bb.9050...@debian.org

Bug#741205: marked as done (general: the GUI freeze regularly, you can not move the mouse or enter a key)

[Debian Bug Tracking System]

Your message dated Tue, 11 Mar 2014 16:36:00 +0100
with message-id <201403111636.02939.hol...@layer-acht.org>
and subject line Re: Bug#741205: general: the GUI freeze regularly, you can not 
move the mouse or enter a key
has caused the Debian Bug report #741205,
regarding general: the GUI freeze regularly, you can not move the mouse or 
enter a key
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
741205: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741205
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: general
Severity: important

Dear Maintainer,
 * What led up to the situation?
basic use of the GUI such as use of iceweasel
* What exactly did you do (or not do) that was effective (or
 ineffective)?
I read a web page with iceweasel elevator use to scroll the page
I select text
* What was the outcome of this action?
the system freeze completely

-- System Information:
Debian Release: 7.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- End Message ---
--- Begin Message ---
Hi David,

I'm sorry but I'm closing your bug report (as unreprodicible) as it contains 
very little information, thus it's basically impossible to do something about 
it.

If  you can provide sufficient information to this bug report, I'd be happy to 
reopen the bug. Just reply to 741...@bugs.debian.org :-)

On Sonntag, 9. März 2014, David MAURER wrote:
>  * What led up to the situation?
> basic use of the GUI such as use of iceweasel

does this problem also occur with applications other than iceweasel?

whats the output of "dpkg -l iceweasel" on your system?

> * What exactly did you do (or not do) that was effective (or
>  ineffective)?
> I read a web page with iceweasel elevator use to scroll the page
> I select text
> * What was the outcome of this action?
> the system freeze completely

does the freeze only occor on a specific website?

which?

do you have non free flash installed?


cheers,
Holger


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

Re: jquery debate with upstream

[Ian Jackson]

Paul Tagliamonte writes ("Re: jquery debate with upstream"):
> On Tue, Mar 11, 2014 at 03:16:14PM +, Ian Jackson wrote:
> > You have conspicuously failed to answer Jonas's question.  What
> > objective does removing these files and repacking the tarballs serve ?
> 
> We distribute source. The question is, do we want to distribute binaries
> in the source to which we have no, well, source. This means, do we want
> to break the DFSG on the distribution of source packages?

I don't think this is a significant breach of the DFSG.

The whole point of the project is to enhance people's software
freedom.  Repackaging these tarballs to remove these useless and
unused files does not enhance anyone's freedom.

> > > Debian have a certain definition of Freedoms [...]
> > 
> > Whose freedom is impaired, and in what way, by the presence of these
> > useless but ignored files in the tarball ?
> 
> We distribute them. The challenge here is does anyone use them. I leave
> that question up to the reader.

Why would anyone take the Debian package and then go out of their way
to use sourceless files they find in it ?  I don't think these kind of
hypotheticals are answering the question.

Repackaging these tarballs for this reason is utterly pointless.
No-one has been able to explain what the benefit is, to anyone.  All
we get when we challenge it is, I'm sad to say, vague and abstract
responses like this one.

We should stop this makework and get on with doing something useful.

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/21279.20836.500723.92...@chiark.greenend.org.uk

Bug#741367: ITP: libowasp-antisamy-java -- OWASP AntiSamy

[Matthew Vernon]

Package: wnpp
Severity: wishlist
Owner: Matthew Vernon 

  Package name: libowasp-antisamy-java
  Version : 1.5.3
  Upstream Author : Arshan Dabirsiaghi 
  URL : https://code.google.com/p/owaspantisamy/
  License : BSD
  Programming Lang: Java
  Description : OWASP AntiSamy

 The OWASP AntiSamy project is a collection of APIs for safely allowing
 users to supply their own HTML and CSS without exposing the site to XSS
 vulnerabilities


-- 
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/20140311180735.4898.9415.report...@pick.csi.cam.ac.uk

Re: jquery debate with upstream

[Paul Tagliamonte]

[not ftpteam]

On Tue, Mar 11, 2014 at 06:09:40PM +, Ian Jackson wrote:
> I don't think this is a significant breach of the DFSG.

Ah, but you do acknowledge this *is* a breach, even if a small one.


So this comes down to where the line is, like I said.


You may think a line is somewhere, but the DFSG is interpreted by the
ftp-masters, so the question isn't what paultag or ian says, but what
the ftp-masters say :)


Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte   |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature

Re: jquery debate with upstream

[Don Armstrong]

On Tue, 11 Mar 2014, Ian Jackson wrote:
> Repackaging these tarballs for this reason is utterly pointless.
> No-one has been able to explain what the benefit is, to anyone. All we
> get when we challenge it is, I'm sad to say, vague and abstract
> responses like this one.

The point of repacking the tarballs is to avoid ever distributing things
for which we do not have the source. We do that for multiple reasons:

1) We promise that all of the components of Debian will be free, and
thus will have source available.

2) Stripping out the non-source means that the binary package won't ever
accidentally distribute it.

The primary reason not to strip is because repacking is annoying, but
with uscan's support of Files-Excluded, and other utility scripts[1]
this is largely resolved.

Even if you don't strip, you still have to do all the work to make sure
that the embedded non-source copy isn't built against or distributed.

1: I personally use the perl team's repack.sh, but I'll probably
transition to Files-Excluded.
-- 
Don Armstrong  http://www.donarmstrong.com

"Ban cryptography! Yes. Let's also ban pencils, pens and paper, since
criminals can use them to draw plans of the joint they are casing or
even, god forbid, create one time pads to pass uncrackable codes to
each other. Ban open spaces since criminals could use them to converse
with each other out of earshot of the police. Let's ban flags since
they could be used to pass secret messages in semaphore. In fact let's
just ban all forms of verbal and non-verbal communication -- let's see
those criminals make plans now!"


-- 
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/20140311183927.gg7...@rzlab.ucr.edu

Re: jquery debate with upstream

[Ian Jackson]

Thomas Goirand writes ("Re: jquery debate with upstream"):
> In one of my package, I had openssl.dll in the source tarball (it was of
> course removed later on).
> 
> Would you consider it ok as well to have it in a source package, as long
> as it's not used during the build? And what about a windows .exe? Is it
> different from having a minified .js that is also not in use?

Yes, I think all of these things are tolerable, so long as the files
are in fact redistributable (which depending on the licence they might
not be).

I think that if we want a more convenient and reliable way to avoid
them being used during the build, we should have a way to make
dpkg-source remove the files from the tree as it unpacks the source.

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/21279.24031.252935.355...@chiark.greenend.org.uk

Re: [cjwat...@debian.org: Accepted grub2 2.02~beta2-7 (source i386)]

[Russ Allbery]

Simon McVittie  writes:
> On 11/03/14 10:50, Colin Watson wrote:

>> "Distribution: unstable".  Whoops.  It is far too easy to make this
>> mistake with sbuild if you're not quite paying absolutely perfect
>> attention.  My apologies ...

> On the Lintian side of things, I attached a patch to
>  in 2010 and
> am still waiting for comments.

> My patch just looks for Distribution=unstable, Changes=experimental
> because that's the most annoying case ("I uploaded a version that
> wasn't ready and now I have to use an epoch to roll it back").

[...]

> Russ said
>> I think we only want to do this check if the first line of the
>> Changes file says UNRELEASED, since there are valid use cases for a
>> mismatch otherwise.

> but I don't know what those valid use-cases are. BinNMUs in testing
> for a package uploaded to experimental, possibly? Anything else?

The use case that I was thinking of is not really a Debian use case.  It's
relatively common for people with separate repositories to build once and
upload multiple times to different distributions if the same package can
work on multiple distributions and their archive software requires that
(as debarchiver, for example, did, or at least it was the easiest way to
make the right thing happen).

That said, one, this is an outside-of-Debian use case, so per Lintian's
normal design philosophy, we should only take those into account if they
don't stand in the way of detecting bugs in Debian.  This clearly would
detect bugs in Debian.  Also, now that reprepro is more widespread and
doesn't require this sort of workaround for not having simple distribution
migration, it's not clear that use case is particularly important any
more.

-- 
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/87d2hslclm@windlord.stanford.edu

Re: jquery debate with upstream

[Jonathan Dowland]

On Tue, Mar 11, 2014 at 06:09:40PM +, Ian Jackson wrote:
> We should stop this makework and get on with doing something useful.

Thanks for providing me with my 'word of the day' (makework) which seems
to me to embody a growing collection of activities in Debian in modern
times.


-- 
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/20140311201424.ga32...@bryant.redmars.org

Re: [cjwat...@debian.org: Accepted grub2 2.02~beta2-7 (source i386)]

[Paul Tagliamonte]

Next time, dput-ng checks for this :)

Cheers,
  Paul


On Tue, Mar 11, 2014 at 6:50 AM, Colin Watson  wrote:

> "Distribution: unstable".  Whoops.  It is far too easy to make this
> mistake with sbuild if you're not quite paying absolutely perfect
> attention.  My apologies ...
>
> Anyway, while this was unintentional, I don't think it's actually
> dreadful.  testing has 2.00-22, which is reasonably solid, and I wanted
> to make sure wheezy ships with at least GRUB 2.02 anyway, so I might as
> well just forge ahead now rather than trying to figure out how to back
> this out.
>
> --
> Colin Watson   [cjwat...@debian.org]
>
>
> -- Forwarded message --
> From: Colin Watson 
> To: debian-devel-chan...@lists.debian.org
> Cc:
> Date: Mon, 10 Mar 2014 15:37:30 +
> Subject: Accepted grub2 2.02~beta2-7 (source i386)
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Format: 1.8
> Date: Mon, 10 Mar 2014 13:39:33 +
> Source: grub2
> Binary: grub2 grub-linuxbios grub-efi grub-common grub2-common grub-emu
> grub-emu-dbg grub-pc-bin grub-pc-dbg grub-pc grub-rescue-pc
> grub-coreboot-bin grub-coreboot-dbg grub-coreboot grub-efi-ia32-bin
> grub-efi-ia32-dbg grub-efi-ia32 grub-efi-amd64-bin grub-efi-amd64-dbg
> grub-efi-amd64 grub-efi-ia64-bin grub-efi-ia64-dbg grub-efi-ia64
> grub-efi-arm-bin grub-efi-arm-dbg grub-efi-arm grub-efi-arm64-bin
> grub-efi-arm64-dbg grub-efi-arm64 grub-ieee1275-bin grub-ieee1275-dbg
> grub-ieee1275 grub-firmware-qemu grub-uboot-bin grub-uboot-dbg grub-uboot
> grub-xen-bin grub-xen-dbg grub-xen grub-yeeloong-bin grub-yeeloong-dbg
> grub-yeeloong grub-theme-starfield grub-mount-udeb
> Architecture: source i386
> Version: 2.02~beta2-7
> Distribution: unstable
> Urgency: medium
> Maintainer: GRUB Maintainers 
> Changed-By: Colin Watson 
> Description:
>  grub-common - GRand Unified Bootloader (common files)
>  grub-coreboot - GRand Unified Bootloader, version 2 (Coreboot version)
>  grub-coreboot-bin - GRand Unified Bootloader, version 2 (Coreboot
> binaries)
>  grub-coreboot-dbg - GRand Unified Bootloader, version 2 (Coreboot debug
> files)
>  grub-efi   - GRand Unified Bootloader, version 2 (dummy package)
>  grub-efi-amd64 - GRand Unified Bootloader, version 2 (EFI-AMD64 version)
>  grub-efi-amd64-bin - GRand Unified Bootloader, version 2 (EFI-AMD64
> binaries)
>  grub-efi-amd64-dbg - GRand Unified Bootloader, version 2 (EFI-AMD64 debug
> files)
>  grub-efi-arm - GRand Unified Bootloader, version 2 (ARM UEFI version)
>  grub-efi-arm-bin - GRand Unified Bootloader, version 2 (ARM UEFI binaries)
>  grub-efi-arm-dbg - GRand Unified Bootloader, version 2 (ARM UEFI debug
> files)
>  grub-efi-arm64 - GRand Unified Bootloader, version 2 (ARM64 UEFI version)
>  grub-efi-arm64-bin - GRand Unified Bootloader, version 2 (ARM64 UEFI
> binaries)
>  grub-efi-arm64-dbg - GRand Unified Bootloader, version 2 (ARM64 UEFI
> debug files)
>  grub-efi-ia32 - GRand Unified Bootloader, version 2 (EFI-IA32 version)
>  grub-efi-ia32-bin - GRand Unified Bootloader, version 2 (EFI-IA32
> binaries)
>  grub-efi-ia32-dbg - GRand Unified Bootloader, version 2 (EFI-IA32 debug
> files)
>  grub-efi-ia64 - GRand Unified Bootloader, version 2 (IA64 version)
>  grub-efi-ia64-bin - GRand Unified Bootloader, version 2 (IA64 binaries)
>  grub-efi-ia64-dbg - GRand Unified Bootloader, version 2 (IA64 debug files)
>  grub-emu   - GRand Unified Bootloader, version 2 (emulated version)
>  grub-emu-dbg - GRand Unified Bootloader, version 2 (emulated debug files)
>  grub-firmware-qemu - GRUB firmware image for QEMU
>  grub-ieee1275 - GRand Unified Bootloader, version 2 (Open Firmware
> version)
>  grub-ieee1275-bin - GRand Unified Bootloader, version 2 (Open Firmware
> binaries)
>  grub-ieee1275-dbg - GRand Unified Bootloader, version 2 (Open Firmware
> debug files)
>  grub-linuxbios - GRand Unified Bootloader, version 2 (dummy package)
>  grub-mount-udeb - export GRUB filesystems using FUSE (udeb)
>  grub-pc- GRand Unified Bootloader, version 2 (PC/BIOS version)
>  grub-pc-bin - GRand Unified Bootloader, version 2 (PC/BIOS binaries)
>  grub-pc-dbg - GRand Unified Bootloader, version 2 (PC/BIOS debug files)
>  grub-rescue-pc - GRUB bootable rescue images, version 2 (PC/BIOS version)
>  grub-theme-starfield - GRand Unified Bootloader, version 2 (starfield
> theme)
>  grub-uboot - GRand Unified Bootloader, version 2 (ARM U-Boot version)
>  grub-uboot-bin - GRand Unified Bootloader, version 2 (ARM U-Boot binaries)
>  grub-uboot-dbg - GRand Unified Bootloader, version 2 (ARM U-Boot debug
> files)
>  grub-xen   - GRand Unified Bootloader, version 2 (Xen version)
>  grub-xen-bin - GRand Unified Bootloader, version 2 (Xen binaries)
>  grub-xen-dbg - GRand Unified Bootloader, version 2 (Xen debug files)
>  grub-yeeloong - GRand Unified Bootloader, version 2 (Yeeloong version)
>  grub-yeeloong-bin - GRand Unified Bootloader, version 2 (Yeeloong
> binaries)
>  grub-yeeloong-dbg - GR

Re: jquery debate with upstream

[Sune Vuorela]

On 2014-03-11, Paul Tagliamonte  wrote:
> On Tue, Mar 11, 2014 at 06:09:40PM +, Ian Jackson wrote:
>> I don't think this is a significant breach of the DFSG.
>
> Ah, but you do acknowledge this *is* a breach, even if a small one.
>
>
> So this comes down to where the line is, like I said.


"As a Debian Developer, I will uphold the DFSG except where it is
inconvenient"  ?

I actually think the DFSG is a great document and we shouldn't just
stray from it because it is inconvenient.

If I had to disregard the DFSG in some cases, I'd rather see rfc files
in our files than sourceless javascripts.

/Sune


-- 
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/lfnufq$f0n$1...@ger.gmane.org

Re: jquery debate with upstream

[Joachim Breitner]

Hi,

Am Dienstag, den 11.03.2014, 19:02 + schrieb Ian Jackson:
> I think that if we want a more convenient and reliable way to avoid
> them being used during the build, we should have a way to make
> dpkg-source remove the files from the tree as it unpacks the source.

debian/clean is sufficient for that, I’d say. Enough package building
tools clean before the build so that one would notice in due time that
the build accidentally uses it.


Before this thread gets too long and we hear too many opinion from
people  don’t have a say in this (like me), I’d like to hear an official
statement from the ftp-team on the question:

Does Debian tolerate files in upstream tarballs that are (1)
legally distributable and (2) not used in any way during the
build, even if they do not come with their preferred form of
modification?



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

[Charles Plessy]

Le Tue, Mar 11, 2014 at 08:14:24PM +, Jonathan Dowland a écrit :
> On Tue, Mar 11, 2014 at 06:09:40PM +, Ian Jackson wrote:
> > We should stop this makework and get on with doing something useful.
> 
> Thanks for providing me with my 'word of the day' (makework) which seems
> to me to embody a growing collection of activities in Debian in modern
> times.

I agree.  Debian is too much about some people telling others to do useless
things.

We can not at the same time glorify ourselves for our number of packages
and our universality, and on the other hand expect that all the upstream
sources have the same level of cleanness as core works such as the Linux
kernel, GCC, the coreutils etc.

Tarball repacking is a practice from the tarball world.  Our future if we stay
in the tarball world is to be the rock-solid base package supermarket on which
others build the real thing, because our intolerance for minor defects will
make us unable to collect complex ensembles of specialised packages.

Long time ago, one could see the Debian CD as a state-of-the-art multipurpose
software repository useful on other systems as Debian itself, but now, more
people would not find it useful and would rather clone an upstream Git
repository than apt-get-sourcing the not-always latest source from our archive.

Therefore, more than ever, it is on the binary packages that we must commit on
the highest level.  The upstream source tarball matters much less.

Cheers,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
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/20140311220829.ga8...@falafel.plessy.net

Re: jquery debate with upstream

[Russ Allbery]

Sune Vuorela  writes:

> If I had to disregard the DFSG in some cases, I'd rather see rfc files
> in our files than sourceless javascripts.

If they're in the source packages but not installed, I believe this is an
equivalent case, yes.  And it would certainly make some packages easier to
manage (openldap and heimdal come to mind just off the top of my head).

-- 
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/87a9cwjsk8@windlord.stanford.edu

Bug#741383: ITP: libthreads-lite-perl -- threads::lite provides actor model threading for Perl

[Peter Roberts]

Package: wnpp
Severity: wishlist
Owner: Peter Roberts 

* Package name: libthreads-lite-perl
  Version : 0.033
  Upstream Author : Leon Timmermans 
* URL : https://metacpan.org/release/threads-lite
* License : GPL, Artistic
  Programming Lang: Perl, C
  Description : threads::lite provides actor model threading for Perl

threads::lite implements threads for perl. One crucial difference from
threads.pm is that the threads are disconnected, except by message
queues. It thus facilitates message passing style multi-threading.


-- 
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/20140311223635.28465.56078.report...@pkg-deb.lan

Bug#741387: ITP: python-dugong -- HTTP 1.1 client module for Python supporting async io, pipelining and Expect: continue

[Nikolaus Rath]

Package: wnpp
Severity: wishlist
Owner: Nikolaus Rath 

* Package name: python-dugong
  Version : 1.0
  Upstream Author : Nikolaus Rath 
* URL : https://bitbucket.org/nikratio/python-dugong
* License : PSF (Python Software Foundation License)
  Programming Lang: Python
  Description : HTTP 1.1 client module for Python supporting async io, 
pipelining and Expect: continue

The Python Dugong module provides an API for communicating with HTTP
1.1 servers. It is an alternative to the standard library's
`http.client` (formerly *httplib*) module. In contrast to
`http.client`, Dugong:

- allows you to send multiple requests right after each other without
  having to read the responses first.

- supports waiting for 100-continue before sending the request body.

- raises an exception instead of silently delivering partial data if the
  connection is closed before all data has been received.

- raises one specific exception (`ConnectionClosed`) if the connection
  has been closed (while `http.client` connection may raise any of
  `BrokenPipeError`, `~http.client.BadStatusLine`,
  `ConnectionAbortedError`, `ConnectionResetError`,
  `~http.client.IncompleteRead` or simply return ``''`` on read)

- supports non-blocking, asynchronous operation and is compatible with
  the asyncio_ module.
  
- is not compatible with old HTTP 0.9 or 1.0 servers.



I'm packaging this because the new version of the s3ql package depends on it.

I intend to put this package under the Python team's umbrella.


-- 
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/20140312001700.6225.99595.report...@vostro.rath.org

Re: jquery debate with upstream

[Thomas Goirand]

On 03/12/2014 05:16 AM, Sune Vuorela wrote:
> On 2014-03-11, Paul Tagliamonte  wrote:
>> On Tue, Mar 11, 2014 at 06:09:40PM +, Ian Jackson wrote:
>>> I don't think this is a significant breach of the DFSG.
>>
>> Ah, but you do acknowledge this *is* a breach, even if a small one.
>>
>>
>> So this comes down to where the line is, like I said.
> 
> 
> "As a Debian Developer, I will uphold the DFSG except where it is
> inconvenient"  ?
> 
> I actually think the DFSG is a great document and we shouldn't just
> stray from it because it is inconvenient.
> 
> If I had to disregard the DFSG in some cases, I'd rather see rfc files
> in our files than sourceless javascripts.
> 
> /Sune

Oh, let's talk about this! :)

I had once a package rejected because the doc contained a logo in PNG
format, which had in its header clues that it has been generated. I
later on just removed the logo in a +dfsg package... Added benefits to
this? In my opinion, the package was just *less* good, it took some of
my time, and users don't have an (ugly and generated) logo in the doc,
and have instead a broken link in the HTML (cause I had better things to
do than to fix this as well...).

I think THAT went too far (but I do agree we should get rid of minified
javascript files).

As Paul wrote it, it's all about where we draw the line.

Thomas


-- 
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/531fc8e8.5030...@debian.org

Re: jquery debate with upstream

[Steve M. Robbins]

On Tue, Mar 11, 2014 at 02:34:47PM -0400, Paul Tagliamonte wrote:

> You may think a line is somewhere, but the DFSG is interpreted by the
> ftp-masters, so the question isn't what paultag or ian says, but what
> the ftp-masters say :)

I don't accept that.  The interpretation must come from a concensus of
Debian Developers.

Regards,
-Steve


signature.asc
Description: Digital signature