Re: Would an ABI change of apt for DDTP support still be accepted?
Hi, * Otavio Salvador ([EMAIL PROTECTED]) [060928 08:47]: > I would like to ask you to review again your position. This code is > around since 3 years ago and in use on Ubuntu too. Are too few > packages that will need recompile. How does it come that the code isn't promoted at the beginning of a release cycle, but at a time where the base freeze has happened? Is the code already uploaded to experimental? If so, for how long? The problem with "only a few packages" is - almost every change "only affects a few packages", but if we cannot reduce the number of changes, there is no way to release. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to deal with teTeX's and texlive's RC licensing bugs
Steve Langasek <[EMAIL PROTECTED]> wrote: > The guidelines I believe we should be using when deciding such a bug is RC > as follows: Thank you for your answer. > Have I overlooked any other outstanding issues in these bugs, or missed > important details about any of the files? Not in the bugs, but since this all got very confusing, I stopped forwarding to the bug all problems I found. They are all collected in the Wiki at http://wiki.debian.org/ProblematicCtanPackages The ones not discussed so far are: , | euler: LPPL according changelog, but no indication in file. | | adrconv: No license at all for the documentation | | antp: PD according to catalogue, no statement in the files, no | sources; contacted upstream | | citesort.sty: no license statement | | index.doc: no license statement - probably unused | | dinbrief: lppl 1.1+, but with additional restrictions which are non-free | | a4wide.sty: no license statement, obsolete, uses a4.sty, should be removed | | bar.sty: no license statement except "don't modify", latex2.09, authors | are no longer at their listed affiliation => should be removed ` Plus some under the heading "less serious problems". > For the issues that remain listed as "RC" here, I think the prudent course > of action is to remove them immediately from the orig.tar.gz so that we can > cross these RC bugs off. If you do get feedback permitting one or more of > these files to be distributed under a DFSG-compliant license, I'm ok with > allowing those files to be re-added during the freeze. Thank you. > Once the files in question have been removed, are these things that can be > checked with rebuild tests? The main problem to worry about is packages > which need a style that's been removed and fail to build, correct? Yes, that's the main concern, and it should be testable by rebuild tests. The other problem is with packages that have an ordinary Depends, here tests cannot be automated. However, if the package is actually used by some people, but problems aren't detected immediately because the removed files are used rarely and a problem shows up only in certain circumstances, then I think the package can stay in main and only has a normal or important bug, correct? Bugs in mostly unused packages are likely to slip through, anyway... > If so, we can ask for help from debian-qa for a targetted rebuild test. > This makes it even more important to get these files removed sooner rather > than later, to give us enough time for those rebuilds. Okay. Will try to do it during the weekend. > On Wed, Sep 27, 2006 at 07:20:44PM +0200, Frank Küster wrote: > >> What about option c: > >> - Remove all problematic files at once from tetex-base's orig.tar.gz, > >> - but keep them installed with texlive until somewhen at (release - n >> weeks), n=2,3 > >> - state that bugs that affect texlive's ability to be used as a teTeX >> replacement may be NMU'ed. > > I don't understand, what's the advantage here? If the bugs are present in > both texlive and tetex, surely we want to treat them the same for the > release, which means we should try to treat them the same now as well. There would have been an advantage only if you had not said "If you do get feedback permitting one or more of these files to be distributed under a DFSG-compliant license, I'm ok with allowing those files to be re-added during the freeze.", because even without re-adding them to etch, they would be available to etch users if they choose texlive (or install texlive packages in parallel with tetex, as far as that is possible). With that statement from the Release Managers, there's no advantage left. >> These bugs are in most cases just Depends: lines that only mention teTeX >> and do not allow texlive as an alternative. Among the packages any >> texlive package conflicts with, there might be some more. Some other >> conflicts just indicate that the package is not up-to-date, and texlive >> installs the newer version contained by upstream. Norbert? > > Sorry, I don't follow at all how this has to do with licensing bugs. Well, in the hypothetical case that you wouldn't let removed, now-free files be re-added during the freeze, it wouldn't help our users if we tell them "they are still available in texlive" if at the same time they cannot use texlive because other packages they need just don't permit it. And as I understand, "Please change Depends: tetex-extra to Depends: tetex-bin | texlive-base-bin, tetex-extra | texlive-latex-recommended " is just a wishlist bug and doesn't ordinary justify an NMU. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: How to deal with teTeX's and texlive's RC licensing bugs
Hi all! On Mit, 27 Sep 2006, Frank Küster wrote: > and do not allow texlive as an alternative. Among the packages any > texlive package conflicts with, there might be some more. Some other > conflicts just indicate that the package is not up-to-date, and texlive > installs the newer version contained by upstream. Norbert? I am weeding through the conflicts to get rid of them, but as you said some of these packages are outdated, some do not provide the full functionality. > circ-tex not checked > dviutils the texlive tpm bin-seetexk provides more binaries, namely in addition dvibook and dvitodvi, and I didn't want to loose them > ethiop not checked > ivritex not checked > lacheck not checked > latex-beamer see below pgf > latex-svninfo not checked > latex-ucs > latex-ucs-contrib > latex-ucs-uninames in the process of checking, as in texlive this is one tpm, and in Debian 3 packages, I have to check the version and whether all files are provided. > latex-xcolor old version in Debian > lhs2tex not checked > octave-forge both provide a binary called mex ... I didn't have time to work this out until now > pbox-tex > pdfscreen > pgf old version in Debian with important bugs (backward compatibility is broken), I have prepared a new package for 1.01 and send all to the maintainers, no response > ptex-bin binary of the same name, ptex > rcs-latex > tex-chess > tex-skak > textopo not checked Furthermore, the problem is that all these packages depend only on tetex, so as long as the maintainers don't upload new packages I cannot change the dependency order. Best wishes Norbert --- Dr. Norbert Preining <[EMAIL PROTECTED]>Università di Siena Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- POTT SHRIGLEY (n.) Dried remains of a week-old casserole, eaten when extremely drunk at two a.m. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to deal with teTeX's and texlive's RC licensing bugs
Hi all! On Mit, 27 Sep 2006, Steve Langasek wrote: > - If a component of a package lists a non-free license, but is distributed > as part of a larger work that includes a blanket license statement, > resulting in ambiguity about which license the component is distributed > under, the bug is not RC with the condition that the maintainer is > expected to seek a clarification. This would mean that a priori we can assume that these bugs are not RC for TeX live, as this is a blanket license statement of following the DFSG in inclusion of packages (plus GFDL documents which have already been removed from the packages). For those problems surfacing we are contacting upstream (=texlive dev list) and up-upstream (original authors) normally. Best wishes Norbert --- Dr. Norbert Preining <[EMAIL PROTECTED]>Università di Siena Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- LLANELLI (adj.) Descriptive of the waggling movement of a person's hands when shaking water from them or warming up for a piece of workshop theatre. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to deal with teTeX's and texlive's RC licensing bugs
Hi Frank, hi all!
On Don, 28 Sep 2006, Frank Küster wrote:
> ,
> | euler: LPPL according changelog, but no indication in file.
euler v4 fixed this with a manifest afair.
> | citesort.sty: no license statement
This is Donald Arsenau. It was removed on CTAN and TeX live and I asked
him to reinclude a wrapper which gives a warning and otherwise calls
\usepackage[sort]{cite}
He agreed. We could include this wrapper and forget about the original.
> | dinbrief: lppl 1.1+, but with additional restrictions which are non-free
Strange, I have in my dinbrief version in texlive:
%% It may be distributed under the terms of the LaTeX Project Public
%% License (LPPL), as described in lppl.txt in the base LaTeX distribution.
%% Either version 1.1 or, at your option, any later version.
without any additional comments. Only:
%% For error reports in case of UNCHANGED versions see readme files.
> | bar.sty: no license statement except "don't modify", latex2.09, authors
> | are no longer at their listed affiliation => should be removed
yes, also from texlive ... done ...
Best wishes
Norbert
---
Dr. Norbert Preining <[EMAIL PROTECTED]>Università di Siena
Debian Developer <[EMAIL PROTECTED]> Debian TeX Group
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
---
HARPENDEN (n.)
The coda to a phone conversion, consisting of about eight exchanges,
by which people try gracefully to get off the line.
--- Douglas Adams, The Meaning of Liff
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to deal with teTeX's and texlive's RC licensing bugs
On Thu, Sep 28, 2006 at 11:05:01AM +0200, Norbert Preining wrote: > On Mit, 27 Sep 2006, Steve Langasek wrote: > > - If a component of a package lists a non-free license, but is distributed > > as part of a larger work that includes a blanket license statement, > > resulting in ambiguity about which license the component is distributed > > under, the bug is not RC with the condition that the maintainer is > > expected to seek a clarification. > This would mean that a priori we can assume that these bugs are not RC > for TeX live, as this is a blanket license statement of following the > DFSG in inclusion of packages (plus GFDL documents which have already > been removed from the packages). A statement that "the work must be DFSG-compliant to be accepted" is not the same thing as saying "this tarball is distributed under license ". It's the latter that introduces ambiguity. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: release update: release notes, base freeze
* Andreas Barth | Now it's time for the next stage of the freeze. As of today, base packages | are frozen, along with the following "non-essential" toolchain packages: | * debhelper | * cdbs | * bison | * python and python2.4 | * gcj | * autoconf* && automake* Not that I'm planning on changing pkg-config much before etch, but shouldn't it be on this list? Please Cc me on replies, I'm not subscribed to -release. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ICU transition
On Tue, Sep 19, 2006 at 01:24:14PM -0400, Jay Berkenbilt wrote: > I have uploaded ICU 3.6 to sid today and have had the libicu36-dev > package Provide libicu34-dev as previously discussed. Please schedule > binary NMUs for the packages that build depend upon libicu34-dev once > libicu36-dev appears on all the buildds. By my calculation, this > includes the following: > boost, ibm-3270, openoffice.org, parrot, xerces27 > I have also notified the maintainers of the packages that they should > update their build dependencies but need not do a special upload since > I have requested binary NMUs. I assume you will schedule the binary > NMUs for the right time, so unless I hear otherwise, I won't make any > attempt to ask again once libicu36-dev is installed on all > architectures. Probably a bit later than was strictly necessary, but these have been scheduled for binNMUs now. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to deal with teTeX's and texlive's RC licensing bugs
Hi Steve! On Don, 28 Sep 2006, Steve Langasek wrote: > A statement that "the work must be DFSG-compliant to be accepted" is not the > same thing as saying "this tarball is distributed under license ". > It's the latter that introduces ambiguity. To cite from TeX live's "COPYING CONDITIONS": -- To the best of our knowledge, all software in this distribution is freely redistributable (libre, that is, not necessarily gratis), within the Free Software Foundation's definition and Debian Free Software Guidelines. If you find any non-free files included, please contact us (references given below). --- What does this mean? Anyway, we are trying to track down all those problematic files and there is (IMHO) a good response, but as Frank said, and this is valid on much greater level for TeX live due to its huge size, there are probably always files to be found which are just so plain old that at the time of writing nobody cared for stating anything in the file about licenses. Best wishes Norbert --- Dr. Norbert Preining <[EMAIL PROTECTED]>Università di Siena Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- OUNDLE (vb.) To walk along leaning sideways, with one arm hanging limp and dragging one leg behind the other. Most commonly used by actors in amateur production of Richard III, or by people carrying a heavy suitcase in one hand. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
debugging output in apt-get update
hello, apt-get update is still very verbose about the pdiff updates: [about 300 lines with "Get: ..."] Get:334 2006-09-26-1322.12.pdiff [10.7kB] Get:335 2006-09-26-1322.12.pdiff [10.7kB] Get:336 2006-09-27-1319.38.pdiff [4821B] Get:337 2006-09-26-1322.12.pdiff [10.7kB] Get:338 2006-09-27-1319.38.pdiff [4821B] Get:339 2006-09-27-1319.38.pdiff [4821B] Get:340 2006-09-27-1319.38.pdiff [1720B] Get:341 2006-09-27-1319.38.pdiff [1720B] Get:342 2006-09-27-1319.38.pdiff [1720B] Get:343 2006-09-27-1319.38.pdiff [27.4kB] Get:344 2006-09-27-1319.38.pdiff [27.4kB] Get:345 2006-09-27-1319.38.pdiff [27.4kB] Get:346 2006-09-27-1319.38.pdiff [8054B] Get:347 2006-09-27-1319.38.pdiff [8054B] Get:348 2006-09-27-1319.38.pdiff [8054B] Fetched 1313kB in 1m10s (18.5kB/s) Reading package lists... Done if i didn't run 'apt-get update' for some weeks, i get hundreds of lines, three lines for each pdiff file. I hope that the verbosity will be reduced before etch is released. I would also love to see some some automatics in apt to download the full Packages file when pdiffs for more than, lets say two weeks would be needed instead. While load on system and network is reduced for frequent apt-get update runs with pdiff support, it increases for infrequent updates. ... jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
please build the mew-beta package for mips and m68k
Hi, release team, (Cc: buildd admins for mips and m68k) I want to update the mew-beta package for testing, but buildd for mips and m68k don't build the mew-beta package. The buildd status: http://people.debian.org/~igloo/status.php?packages=mew-beta | m68k | | mail/mew-beta_5.1.50-1: Dep-Wait by buildd_m68k-vault13 [extra:out-of-date] | Dependencies: emacs21-bin-common (>= 21.4a-6) | Previous state was Building until 2006 Jun 12 12:43:25 | | mips | | mail/mew-beta_5.1.50-1: Dep-Wait by buildd_mips-mayr [extra:out-of-date] | Dependencies: emacs21 (>= 21.4a-6) | Previous state was Building until 2006 Jun 14 16:03:34 seems that the dependency for emacs21 is blocker. However mew-beta 5.1.50's doesn't require emacs21 at build time. (Though old version mew-beta 5.0.53+5.1rc1-1 bulid-depends `emacs21 | emacsen'.) Could anyone remove the Dep-Wait status to build the mew-beta package? Thanks, -- Tatsuya Kinoshita pgpYVQltJvqs4.pgp Description: PGP signature
Re: please build the mew-beta package for mips and m68k
On Thu, Sep 28, 2006 at 10:00:20PM +0900, Tatsuya Kinoshita wrote: > seems that the dependency for emacs21 is blocker. However > mew-beta 5.1.50's doesn't require emacs21 at build time. (Though old > version mew-beta 5.0.53+5.1rc1-1 bulid-depends `emacs21 | emacsen'.) > > Could anyone remove the Dep-Wait status to build the mew-beta package? done for m68k. Thanks, Stephen -- Stephen R. Marenka If life's not fun, you're not doing it right! <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Would an ABI change of apt for DDTP support still be accepted?
Andreas Barth <[EMAIL PROTECTED]> writes: > Hi, > > * Otavio Salvador ([EMAIL PROTECTED]) [060928 08:47]: >> I would like to ask you to review again your position. This code is >> around since 3 years ago and in use on Ubuntu too. Are too few >> packages that will need recompile. > > How does it come that the code isn't promoted at the beginning of a > release cycle, but at a time where the base freeze has happened? I personally think that Michael took too long time to upload it to unstable. Unfortunatelly. It's out of my hands to push it since he's the maintainer. > Is the code already uploaded to experimental? If so, for how long? Yes, it's. The first upload to experimental that I can locate is: http://packages.qa.debian.org/a/apt/news/20051023T113205Z.html > The problem with "only a few packages" is - almost every change "only > affects a few packages", but if we cannot reduce the number of changes, > there is no way to release. I'm sad to agree with you but it's true :( -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - "Microsoft gives you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Would an ABI change of apt for DDTP support still be accepted?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey! :-) On 09/28/2006 04:13 AM, Andreas Barth wrote: > * Otavio Salvador ([EMAIL PROTECTED]) [060928 08:47]: > >>I would like to ask you to review again your position. This code is >>around since 3 years ago and in use on Ubuntu too. Are too few >>packages that will need recompile. > > How does it come that the code isn't promoted at the beginning of a > release cycle, but at a time where the base freeze has happened? The upload of apt with support to translated package description is recent, but the code is old. What happens is that during i18n Extremadura (Sept. 7th-10th) we discusses that having apt in "etch" should be a good idea to have it supported and tested for etch+1, but I remember that our discussions in Extremadura always consider the Release Team opinion on the matter. After DebConf, Christian requested to have support for translated packages descriptions as a "pet release goal", some time later the experimental upload took place, the DDTS was revived, a web interface was created and we thought that asking Release Team for apt transition is the right thing to do. It is sad that we don't have time to include apt in etch? Yes, it is. But the i18n/l10n teams will understand the reasons. If the transition is not suitable, ok, we will work hard to get it just after etch release, and to support other ideas for i18n in Debian. :-) I don't think we need to "fight" in that matter, as I said, it is OK to not have apt with translations in etch (it's sad but it's OK, nobody will get hurt and no SuperCows will die). And I do think it's possible to workaround it, at least for CDDs using backports.org or something in that matter. We are late at the release cycle, if it is still possible, I'm sure that everybody involved in i18n will do their best to help release team with regards to the apt. If Release Team thinks we should wait etch+1, so let's work hard to have etch on December and we can have apt supporting translations for package descriptions in unstable by the end of the year. ;) [...] > Cheers, > Andi Kind regards, - -- Felipe Augusto van de Wiel (faw) "Debian. Freedom to code. Code to freedom!" -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFFG+57CjAO0JDlykYRAhJ5AKCEV76NYO4QrzCNdueCH+b9j0trdQCbBV74 Rg6XnODDy0A7kjO6dCUPQM0= =DeO4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How are things going?
Steve Langasek wrote: > Since "Breaks field" here means "doesn't complain about the Breaks field", > rather than "honors the Breaks field", these changes look ok. > > As far as *implementing* Breaks, I don't think a new feature of that level > should be introduced during a freeze. Couldn't it be potentially dangerous to have a dpkg in a released version of Debian that silently ignores Breaks? It seems it would both allow for much foot-shooting by anyone who tries to install packages from another source that use Breaks, as well as prevent us from using Breaks in any packages in etch+1, since upgrades won't work. -- see shy jo signature.asc Description: Digital signature
kernel-related release notes for etch
I was looking to submit some individual bugs to update the kernel release notes for etch, but I think enough has changed that we should rewrite this section from scratch. I've started a draft in kernel svn in people/dannf/etch-release-notes - if the kernel team is cool with working together on this file, I'll volunteer to sgmlify it and submit it to the release team once we've come to rough consensus. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: release update: release notes, base freeze
On Thu, Sep 28, 2006 at 12:17:16PM +0200, Tollef Fog Heen wrote: > | Now it's time for the next stage of the freeze. As of today, base packages > | are frozen, along with the following "non-essential" toolchain packages: > | * debhelper > | * cdbs > | * bison > | * python and python2.4 > | * gcj > | * autoconf* && automake* > Not that I'm planning on changing pkg-config much before etch, but > shouldn't it be on this list? Yes. Welcome to the freeze :-) I think we'll want to get libtool in there as well.. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How are things going?
On Thu, Sep 28, 2006 at 03:59:14PM -0400, Joey Hess wrote: > Steve Langasek wrote: > > Since "Breaks field" here means "doesn't complain about the Breaks field", > > rather than "honors the Breaks field", these changes look ok. > > As far as *implementing* Breaks, I don't think a new feature of that level > > should be introduced during a freeze. > Couldn't it be potentially dangerous to have a dpkg in a released > version of Debian that silently ignores Breaks? It seems it would both > allow for much foot-shooting by anyone who tries to install packages > from another source that use Breaks, as well as prevent us from using > Breaks in any packages in etch+1, since upgrades won't work. Hmm, good point. The logical consequence of supporting Breaks is that we will start to see packages that use Breaks instead of Conflicts, so silently ignoring the contents of the Breaks field will result in packages being co-installed that should not have been. So indeed, I think we want Breaks support to be all or nothing. Dpkg maintainers, do you agree? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to deal with teTeX's and texlive's RC licensing bugs
On Thu, Sep 28, 2006 at 12:49:14PM +0200, Norbert Preining wrote: > On Don, 28 Sep 2006, Steve Langasek wrote: > > A statement that "the work must be DFSG-compliant to be accepted" is not the > > same thing as saying "this tarball is distributed under license ". > > It's the latter that introduces ambiguity. > To cite from TeX live's "COPYING CONDITIONS": > -- > To the best of our knowledge, all software in this distribution is > freely redistributable (libre, that is, not necessarily gratis), within > the Free Software Foundation's definition and Debian Free Software > Guidelines. If you find any non-free files included, please contact us > (references given below). > --- > What does this mean? It's not a license statement, that's for sure. It's a statement that someone *thinks* the works are all DFSG free; it is not a statement from a licensor that the works are all distributed under a *specific* license which is DFSG-free. So a claim that "everything is DFSG-compliant" when, say, one of the styles is known to be distributed under a license prohibiting modification is a false statement, not a licensing ambiguity. That doesn't mean texlive needs a full license audit before release, any more than any other package does; it does mean that any license problems you find don't get a pass for etch just because of this statement. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to deal with teTeX's and texlive's RC licensing bugs
On Thu, Sep 28, 2006 at 09:35:11AM +0200, Frank Küster wrote: > > Have I overlooked any other outstanding issues in these bugs, or missed > > important details about any of the files? > Not in the bugs, but since this all got very confusing, I stopped > forwarding to the bug all problems I found. They are all collected in > the Wiki at http://wiki.debian.org/ProblematicCtanPackages > The ones not discussed so far are: > , > | euler: LPPL according changelog, but no indication in file. > | > | adrconv: No license at all for the documentation > | > | antp: PD according to catalogue, no statement in the files, no > | sources; contacted upstream > | > | citesort.sty: no license statement > | > | index.doc: no license statement - probably unused > | > | dinbrief: lppl 1.1+, but with additional restrictions which are non-free > | > | a4wide.sty: no license statement, obsolete, uses a4.sty, should be removed > | > | bar.sty: no license statement except "don't modify", latex2.09, authors > | are no longer at their listed affiliation => should be removed > ` These seem to have all been analyzed already. I guess there's no need for me to say which ones are RC or not, the proposed guidelines should be clear enough? If not, please ask. > > Once the files in question have been removed, are these things that can be > > checked with rebuild tests? The main problem to worry about is packages > > which need a style that's been removed and fail to build, correct? > Yes, that's the main concern, and it should be testable by rebuild > tests. The other problem is with packages that have an ordinary > Depends, here tests cannot be automated. However, if the package is > actually used by some people, but problems aren't detected immediately > because the removed files are used rarely and a problem shows up only in > certain circumstances, then I think the package can stay in main and > only has a normal or important bug, correct? Bugs in mostly unused > packages are likely to slip through, anyway... Right, if a package (or feature of a package) doesn't get enough use for these bugs to be caught during a 1-2 month freeze, well, the bug will be there until someone does use it and reports the problem. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How are things going?
On Thu, 2006-09-28 at 16:51:33 -0700, Steve Langasek wrote: > On Thu, Sep 28, 2006 at 03:59:14PM -0400, Joey Hess wrote: > > Steve Langasek wrote: > > > Since "Breaks field" here means "doesn't complain about the Breaks field", > > > rather than "honors the Breaks field", these changes look ok. Argh, I should have corrected this one, sorry. From the changelog: * Add initial support for the Breaks field, by parsing but rejecting it. > > > As far as *implementing* Breaks, I don't think a new feature of that > > > level should be introduced during a freeze. I'd feel really unconfortable introducing full support at this time. > > Couldn't it be potentially dangerous to have a dpkg in a released > > version of Debian that silently ignores Breaks? It seems it would both > > allow for much foot-shooting by anyone who tries to install packages > > from another source that use Breaks, as well as prevent us from using > > Breaks in any packages in etch+1, since upgrades won't work. This should not be the case. > Hmm, good point. The logical consequence of supporting Breaks is that we > will start to see packages that use Breaks instead of Conflicts, so > silently ignoring the contents of the Breaks field will result in packages > being co-installed that should not have been. > So indeed, I think we want Breaks support to be all or nothing. No, I'd say we want partial then full support. And we definitely want that the dpkg in the next release understands the field and rejects it, so that we don't get an upgrade path where suddenly the system has got unsatisfiable dependencies due to dpkg not understanding the field previously. There's two ways to introduce it that I can think of now, but I'd opt for the first one, otherwise we'll need to wait a lot for this. Fast: * etch - dpkg parse but reject. * etch+1: - dpkg full support. - require to upgrade dpkg first from etch to etch+1. - packages using the field in the archive (not the ones that dpkg (pre-)depends on though). Slow: * etch - dpkg parse but reject. * etch+1 - dak disallows packages in the archive with such field. - dpkg full support. * etch+2 - dak allows packages in the archive with such field. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
