Bug#907895: contributors.debian.org: Second "To create a new one" link on /sources page returns 404 Not Found error

[Joseph R. Justice]

Package: nm.debian.org
Version: 2018-07-30 19:28:39
Severity: minor
Tags: patch

At the instant this message is written, on the page
https://contributors.debian.org/sources/ ("Debian Contributors data
sources"), in the section about how to create a new data source, the second
link there (which is currently to the URL "
https://anonscm.debian.org/cgit/nm/python-debiancontributors.git/tree/README.md;)
goes to a 404 Not Found error page with text "The requested URL
/cgit/nm/python-debiancontributors.git/tree/README.md was not found on this
server."

Going to the root site page "https://anonscm.debian.org/;, there is text
about how alioth has been discontinued in favor of repositories at
salsa.debian.org .

After poking around some, it looks like the new link *might* possibly be
https://salsa.debian.org/python-team/modules/python-debiancontributors/blob/master/README.md
?

Hope this is of some use, interest.  Thanks for your time.  FWIW, I did
first check to see if this had already been reported; AFAICT it has not
been.

Joseph

Bug#882561: pyelliptic: Please migrate to openssl1.1 in Buster

[Joseph R. Justice]

In random web surfing related to this bug, I noticed the following based on
the "homepage" link for this package (
https://github.com/yann2192/pyelliptic/) as shown on the packages page for
python-pyelliptic for sid (https://packages.debian.org/sid/python-pyelliptic
).

Specifically, that pyelliptic is (currently) _deprecated_ by its upstream
maintainer, specifically _because_ pyelliptic doesn't work with OpenSSL
v1.1 and the upstream is unwilling / unable to modify it to work with
OpenSSL v1.1.  See, for instance,
https://github.com/yann2192/pyelliptic/blob/master/README.md (its README
file) and https://github.com/yann2192/pyelliptic/issues/50 (Add support
OpenSSL 1.1).

Given this, I suspect that pyelliptic will never migrate to OpenSSL 1.1
(unless someone desires to fork it and maintain the fork as a
"pyelliptic-ng" sort of thing), and that accordingly it will be necessary
to remove it from Debian for the Buster release and modify anything
depending on it to depend on something else instead.

FWIW, I do see that there is a 1.5.8 release of pyelliptic (Debian has
1.5.7-1.1) which removes ECC support, apparently that is something
problematic with the < 1.1 version of OpenSSL.  I don't know if this would
be sufficient to keep pyelliptic in the current Debian Stable release or
not.

Thanks for your time.  Hope this is of some use, interest.

Joseph

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Joseph R. Justice]

For the record for this bug / discussion:

I note Didier 'OdyX' Raboud 's mail to the Debian Secretary, CC'd to the TC
list and the FTP Master list, requesting a general interpretation of the
TC's ability (if any) to override the decisions made by various Debian
delegate teams and individuals.  A copy of the mail can be found at
https://lists.debian.org/debian-ctte/2016/10/msg00060.html .  If the
request had been made as a bug filed to the bug tracking system, perhaps to
a "secretary" meta-package, I'd have suggested this bug be blocked by that
bug.

(As an aside, perhaps there should be a wishlist bug to create such a
meta-package, for use in similar situations in the future?)

While the request for interpretation was clearly prompted by the discussion
in this bug (indeed, the request explicitly says as much!), it is phrased
to be very general in nature, which I personally think is a good idea.

I look forward to any discussion on that request for interpretation.  (I
suspect I'll have to subscribe to the secretary mailing list, if there is
one such, to make sure I see all of it.)



To all: Should Mr's Raboud's request for interpretation be expanded to
include clarification on whether, and if so when and how, the TC can
require some other delegate to take a particular action or actions, even if
the delegate has not made a decision (or perhaps even been asked to make a
decision) on the action?  (This, presumably if and only if the TC is
capable of overriding a delegate's decision in the first place; if the TC
cannot override a delegate's decision, it does not make sense then that
they could require a delegate to decide to take an action!)

The particular specific case here would be as to whether the TC can require
the release masters to add stretch-ignore tags either to bugs for
individual packages affected by the "browserified Javascript" issue
(whatever it is determined that "browserified Javascript" is ultimately
defined to mean; in particular, I am *not* claiming at this time that the
definition of browserified Javascript does include or should include
packages affected by the includes generated lexer/parser code / jison (?)
issue) and/or for all bugs which fall under this issue (e.g. bugs which are
determined to block a meta-bug "resolution of browserified Javascript"
issue and/or which are determined to be blocked by a "ITP: grunt" or "IT
Create and Package: sufficiently capable replacement for grunt" bug.

I realize that the idea of the TC overriding a delegate's decision *can* be
interpreted to include this sort of thing, too.  However, I do not know if
it is sufficiently obvious that such an interpretation should be made (the
obvious counter-question is "How can the TC override a decision which has
not yet been made, or which has not yet been requested to be made, or which
perhaps is not a request-able decision in the first place (e.g. that there
is no procedure in place to request that such a decision be made)?").

I am tempted to write the secretary to request just such an expanded
consideration of Mr. Raboud's request.  However, before I do so, I think it
is prudent to seek the counsel of older and wiser heads as to whether or
not this is a good idea or if it will instead just confuse things and muddy
the waters.

So...  What, if anything, do all'y'all think?



Thanks for your time.  Hope this is of some use, interest.



Joseph

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Joseph R. Justice]

On Wed, Oct 5, 2016 at 12:04 AM, Pirate Praveen  wrote:

A quick update, I have asked ftp masters to make a ruling on the issue.
> #839801.
>

Forgot to mention in my other response to this message...

Should this bug (839570) depend on the FTPmaster ruling request bug
(839801), or vice versa, so as to indicate that the TC is waiting on any
response from the FTP team before making a decision?  (Since, after all,
the FTP team might make a decision which satisfies Mr. Praveen, making
what's been asked of the TC moot.)

If this should be done, I encourage someone with the right to do this to do
so.  I certainly do not feel I have the right myself, and even if I did I
am unfamiliar enough with the bug tracking software to feel I should
attempt to do this.

Thanks for your time.  Hope this is of some use, interest.



Joseph

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Joseph R. Justice]

On Thu, Oct 6, 2016 at 12:55 AM, Tollef Fog Heen <tfh...@err.no> wrote:

> ]] "Joseph R. Justice"
>


> > Could the TC offer guidance, or issue a statement, on if (and if so
> > when) it should ever be permissible to allow a waiver from RC-bug
> > status for software whose source code is available but determined to
> > be insufficiently free for the DFSG while active efforts are underway
> > to get the source code into a state determined to be fully compliant
> > with the DFSG?
>
> This is very clearly release team territory and they have an RC bug
> policy already: https://release.debian.org/stretch/rc_policy.txt If this
> isn't clear enough or sufficient enough, that policy should be improved.
> The TC should not go out and overrule the release team's RC bug policy
> unless we have a really good reason (and it's still not completely clear
> that we can overrule them as a team either, but that entire discussion
> is unneeded unless we want/need to override them).
>

Read it.  Thank you.

Clearly (to me) what Mr. Praveen is asking for is stretch-ignore tags by a
release manager for software which has the browserified Javascript issue.
This software might and/or might not include software with the generated
lexer/parser code issue and/or other as yet unknown issues, depending on
what exactly browserification is defined to mean, which I will agree for
now has not yet been done.  E.g. it is not clear, there is not a hard and
firm definition, of what it means to browserify Javascript, such that one
can say "this software is merely browserified" or "that software is
browserified *and* *also* ..."

Is there any information yet on what formal policy (if any) will be used by
the release managers for allowing bugs to be tagged stretch-ignore?  *Was*
there any formal policy ever set in place for the prior (the current
stable) release of Debian, e.g. Jessie, or prior to that Wheezy?  Was it /
will it be entirely ad-hoc and at the discretion of the release team?

If the TC as a body does not feel it can, or does not feel it should,
override the release team in terms of granting stretch-ignore tags for
certain bugs or classes of bugs (and, I am not saying the TC *should* feel
it can or should do this, mind you!), still the TC as a body can, if a
developer so requests and if the TC as a body agrees it should do so, offer
an advisory opinion concerning particular bugs / bug classes to the release
team and/or offer a show of support to the affected developer, in terms of
saying "we believe stretch-ignore tags should be applied to the following
bugs / classes of bugs, because ..."  Correct?

Question of bug process, I guess ...  For purpose of stretch-ignore tags
(should they be granted, of course!), would it make sense to create a
meta-bug, say "Browserified Javascript in Stretch", make all the individual
package bugs somehow depend on or refer to this meta bug, and then apply a
stretch-ignore tag to the meta-bug and allow it to propagate somehow to all
the individual bugs?  Or would it be better to just apply the
stretch-ignore tag to each separate individual package bug?  I'm thinking
as to what will be most effective in making sure nothing gets missed,
overlooked, forgotten about, either pre-Stretch or post-Stretch.

Thanks for your time.  Hope this is of some use, interest.



Joseph

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Joseph R. Justice]

On Wed, Oct 5, 2016 at 12:04 AM, Pa irate Praveen 
wrote:

> On 2016, ഒക്‌ടോബർ 4 7:49:28 PM IST, Sam Hartman 
> wrote:
>


> >You're asking questions that don't make sense from a p.process
> >standpoint, doing things that have a very low probability of making
> >anyone happy,
>
> A quick update, I have asked ftp masters to make a ruling on the issue.
> #839801.
>

I saw that.  I look forward to any response they (or others) care to make
concerning that bug.

FWIW, I for one was under the impression (in part based on what you
originally wrote when you opened this bug, and looking at the bugs you
referenced in that message) that there had already been a decision by them
to declare browserified Javascript as failing to be DFSG-free on the
grounds of failing source code availability (because grunt is not currently
available in the Debian main archive).  If this was not the case, then I'll
agree with others it's important you get an explicit ruling from them one
way or another, so that if the ruling goes against you you can go to the TC
and say "This is what was decided, and this is why I disagree", and you
actually *have* something to point to in terms of what was decided!

Based on what Mr. Hartman has written, I would encourage you to explain for
everyone involved just exactly what you mean by "browserified Javascript",
what sort of processes and transformations are included by that term and
what are not.  Try to be as specific and precise as possible, not just
handwavy.  I've seen some stuff that makes it sound like it's merely
concatenation of files, but then I've seen other stuff that makes it sound
like it's *not* just that.  So I'm confused.  Remember, the people on the
TC are generally technically adept, but they're *not* specialists in
Javascript as you apparently are!  You need to teach them some stuff, so
they can make an educated and informed decision.

I would also suggest you explain exactly how the issue raised in bugs
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830986 and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830987 (the bugs related
to the generated lexer/parser code issue) relate to the concept of
browserified Javascript in general?  Is part of what's described in these
bugs routinely considered to be part of what it means to browserify
Javascript, so that if browserified Javascript is (temporarily) declared to
not be RC-buggy for Stretch, that means this stuff is not RC-buggy for
Stretch?  Or, is what's described by these bugs entirely separate and apart
from the process of browserification, such that even if browserification is
not RC-buggy for the moment, software with these bugs is still RC-buggy and
needs to have the bug resolved or else have the software go to the non-free
archive?





> I feel these responses make TC more like a bureaucracy, where focus is
> given on process and having people to go around asking many people.
>

>From what I understand of Mr. Hartman, he is particularly interested in
process.

But, for your purposes, that is not a *bad* thing!  He's not necessarily
interested in simply denying your request (tho, he *is* interested in
making sure your request is seen by him only after the people who should
see and decide on your request first have had a chance to do so).

That doesn't mean he'll necessarily agree with your position.  But, I think
it's important to him that you get a fair hearing and be treated as fairly
as possible.

It's important however for *you*, if you are to get what you want (which as
far as I can tell is a temporary variance for the duration of Stretch for
browserified Javascript files from being considered RC-buggy while you work
to package grunt for Stretch+1), to explain *why* this variance should be
granted.  And what you're going to do to permanently resolved this issue
for Stretch+1, so it doesn't come up again as a problem.  You have to
convince the TC to take your side; it's not enough for you to say "Well,
you should do what I want because ... Just because."

I'm sorry if you feel like this is a bureaucracy.  For what it's worth, I
think people are just trying to make sure they're doing what's right or
what's best, not just what's convenient or expedient at the moment.



Hope this is of some use, interest.  Thanks for your time.



Joseph

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Joseph R. Justice]

For the record, I wish the message I am now responding to, and other
subsequent responses and discussion, were being sent to the bug mail
address *in addition to* all the other addresses they're being sent to.  I
am choosing to send my response here to the bug mail address, at least in
part so there is a record there that not all the discussion related to this
bug is available at the bug itself, but instead is only found in the
debian-ctte list archives.



On Tue, Oct 4, 2016 at 11:31 AM, Adrian Bunk  wrote:

> On Tue, Oct 04, 2016 at 10:30:01AM -0400, Sam Hartman wrote:
>


> > Here are some factors to consider:
>

[...]


> In other words, the best way forward for getting any decision would be
> an RC bug against perl claiming that the Configure script is not DFSG-free.
>

For the record, having read Mr. Hartman's draft analysis at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978#217 , and some
other things related to the perl Configure script source code availability
issue, I admit that I would be ... "amused", for a suitable definition of
the word amused, if this issue were brought up.  (*cough*).




> If anyone thinks that this hardball approach would not be necessary,
> please describe to Pirate Praveen a better way for getting an explicit
> decision in time for stretch.
>

Get a variance from RC-buggyness for browserified Javascript for Stretch,
and package grunt and/or alternative for Stretch+1.  That's what he's asked
for, anyway.

Admittedly, if grunt et al fails to be successfully packaged for Stretch+1,
and/or if packaging grunt et al proves to be insufficient for the
browserified Javascript source code availability issue, then the RC-bug
issue reappears for Stretch+1, with an even more tangled thicket around it
 But, that's the risk one takes.



Hope this is of some use, interest.  Thanks for your time.  Be well.



Joseph

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Joseph R. Justice]

On Tue, Oct 4, 2016 at 10:30 AM, Sam Hartman  wrote:

First off, I would like to, sincerely and truly, thank you for responding
to my message.  I'd been wondering if maybe they were going into a black
hole of some sort.  You give me some reassurance that they are not, or at
least not entirely.



Thanks for your detailed message.  I don't agree with all of it, but I
> find it a lot easier to interact with than some of the requests we've
> gotten related to this issue.
>

No problem, thanks back, and fair enough that you don't agree with all of
it.

FWIW, in some ways, it might be easier for me dealing with this than it is,
say, Mr. Praveen.  He is (inevitably!) emotionally invested in this issue,
since it's something important to him, something he's working on.  It's not
something I'm particularly invested in; if anything, this is something I'm
doing "pour le sport".  He is intimately familiar with this stuff; I am
not, so stuff that's obvious to him isn't obvious to me.  And, no
disrespect intended to him (or anyone), but I think I write mor gud (or at
least more verbosely!) than he does.

Just think of me as a roaming mercenary volunteer hired gun lawyer /
advocate / mouthpiece, here to right wrongs, keel keel keel the bad guys,
and sneak off into a haystack in the back barn with the comely schoolmarm
before I ride off into the sunset on my faithful steed, Horse.  (We're
still trying to figure out which of us is smarter.  My vote is on the guy
with four legs, myself.)




> Here are some factors to consider:
>
> 1)  It's not clear to several TC members that the FTP team has decided
> on this question.  It seems fairly clear how they would decide if they
> did decide, but from a process standpoint, it's important to have a
> formal dialogue with them before they are overruled.
>

I'll be honest, I assumed from what I've read that a decision had already
been made by the FTP team against Mr. Praveen.  I figured that it must have
been, or else why would he be raising this bug with the TC now?

I do note however that Mr. Praveen has subsequent to your message stated
that he has filed a formal request with the FTP team concerning
browserified Javascript in general (although IMO he hasn't clearly stated
that in his message opening the bug, tho I do believe that's what he means).

To make life easier for anyone reading the bug log, the full link to the
bug is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839801 .

I've looked at it as I write this response; there's been no response to
that bug yet (tho I hardly would expect one, it hasn't even been a day
since the bug was filed, after all, and this is a non-trivial decision
being asked for).




> 2) It's not clear constitutionally that the TC can overrule the ftp
> team's decision regarding whether something is DFSG-free.  Even if we
> could, it's not clear that is a technical decision in our scope.
> So, asking the TC to overrule such a decision is asking for the hardest
> political choice possible in such a situation--a really hard sell within
> the project and the TC.
>

Mmmm.  I respect that.

FWIW, I don't think Mr. Praveen necessarily wants a ruling that
browserified Javascript meets the full definition as-interpreted of "source
code available".  (Or, rather, I think *he* thinks browserified Javascript
by itself is "good enough as-is", but he's willing to concede that
something better is possible and preferable.  He's said as much.  He's just
hoping to avoid the stigma of having to be in contrib / non-free for the
release of Debian Stretch, by seeking a variance that this issue is
RC-buggy *for now* so that the various pieces of software can be in main,
while he works on achieving that possible, preferable outcome during the
preparation of Stretch+1 which will permanently resolve the issue of
whether this issue is RB-buggy.)



Mmmm...  With respect to politics...  I fully agree that this is / will be,
at least in part and possibly in large part, a political decision.  Mr.
Praveen has already started that ball in motion, by suggesting that this
issue will cause many (presumably) important pieces of web-based software
to have to be moved to contrib and the libraries they depend on be moved to
non-free, at least until and if grunt (or a sufficiently capable
replacement) can be added to the main archive.  I'm aware that, for many
people, *not* being in main is like saying "You're not *really* part of
Debian Linux".

I'm not a web developer.  I have absolutely no idea how important these
applications are in actual practice.  They may have little use in the Real
World.  They may have tons of use.  It may have strong adverse effects on
users or potential users of Debian if these applications are not in Debian
main; it may have little or no effect at all.  In the worst possible case,
potential users (be they individuals, or end user companies, or people
selling software and services making use of Debian stable) maybe decide to
use 

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Joseph R. Justice]

On Tue, Oct 4, 2016 at 9:18 AM, Sam Hartman  wrote:

> > "Didier" == Didier 'OdyX' Raboud  writes:
>

I do think there are things we could do in this space.
> We could set policy consistent with the DFSG on what the definition of
> source code in Debian is.
>

Could the TC offer guidance, or issue a statement, on if (and if so when)
it should ever be permissible to allow a waiver from RC-bug status for
software whose source code is available but determined to be insufficiently
free for the DFSG while active efforts are underway to get the source code
into a state determined to be fully compliant with the DFSG?

That's what Mr. Praveen is actually asking for, after all.  (IMO, of
course.)  He wants the software he is interested in in the Debian main
archive at the time Debian Stretch is released (because, politically and
... I can't think of the right word, but in terms of advertising
capabilities, it's undesirable for the software to have to be relegated to
the contrib and non-free archives, those don't count for many as being part
of "Debian").  But, in practical terms, while the source code for the
software may effectively be available within Debian now, it does not meet
the full and pristine interpretation of the DFSG in terms of what it means
to have source code available.  So, while he works on that (by packaging
grunt), he's seeking a waiver from RC-bug status for this issue for the
in-preparation release.

Mmmm.  I believe I saw ...  Found it.

https://lists.debian.org/debian-devel/2016/07/msg00253.html .

Quoting from that message (first paragraph from Mr. Praveen, remainder by
Philip Hands ):

=
> And why is the people who are so strict about packaging the build tool
> not stepping up to package it? FRP for node-grunt was filed in 21 May
> 2012 and it is still not complete. So removing these packages until
> grunt is packaged makes debian better?

They should be in contrib.

Allowing them in main removes any incentive to do the work to fix this
problem, which I'd imagine is the reason it's not been done.

When this was last raised, I looked into it and concluded that grunt is
a tangled mess.

[...]

Simply letting them [ed: packages ultimately depending on the presence of
grunt] into main removes that pressure [ed: to deal with the tangled mess
of grunt either directly or else indirectly by finessing / replacing it,
and/or by getting upstreams to alter their use of grunt, etc], it also
means that
we're deceiving our users, since they expect buildable source for all
packages in main.
=

That's a political decision, too.  (I'm not claiming or implying it's a
wrong decision, mind you!  I'm simply noting it as an observation, I was
impressed by it the first time I read it.)



Thanks for your time.  Hope this is of some use, interest.



Joseph

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Joseph R. Justice]

On Tue, Oct 4, 2016 at 7:37 AM, Didier 'OdyX' Raboud 
wrote:

Would the following ballot be a better fit ?
> ==
> C: Decline to rule on #830978 'Browserified javascript and DFSG 2'
> FD: Further Discussion
> ==
>

I'd like to state again that, if you (the TC as a body) choose not to vote
in favor of Mr. Praveen's request, I believe he would be more satisfied if
you chose to express an active preference against his position and in favor
of the (presumable) FTP Team's position, rather than merely decline to make
a ruling and close the bug.  I believe, given his original message opening
the bug, that he would find the latter action by you all highly
unsatisfactory.  (Not that I claim he would be satisfied by an active
ruling against him, mind you!)

Thanks for your time.  Hope this is of some use, interest.



Joseph

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Joseph R. Justice]

[I realize there have been several messages subsequent to this, but I'm
working down the list in order of presentation by the GMail web interface.]

On Tue, Oct 4, 2016 at 4:13 AM, Didier 'OdyX' Raboud 
wrote:

> Le dimanche, 2 octobre 2016, 14.29:49 h CEST Pirate Praveen a écrit :
>


> > package: tech-ctte
> >
> > Following up on #830978. I would like this to be reopened and request
> > CTTE make a formal vote.
>
> The discussion that lead to closing #830978 happened on IRC [0] , see the
> full
> log from line 172 [1] , and Sam put a clear rationale in the mail closing
> the
> bug [2]. I'll quote on specific part of it:
> > With regard to the particular issue of Browserified javascript,
> > particularly in the libjs-handlebars package, the best way forward is
> > for the submitter to discuss the question with the FTP team.  Such a
> > discussion would be less confusing if it took place after #830986 is
> > resolved.
>
> (#830986 isn't resolved)
>

FWIW, it's not clear to me at least that ""browserified" Javascript"
necessarily includes the issue pointed out in 830986, e.g. the generated
lexer/parser code.  (I'm not saying it *doesn't* include the 830986 issue,
mind you!  I'm just not saying either that it *does* include it.  Reviewing
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978 , I see some
comments that, to me at least, imply that browserification does not
necessarily imply the 830986 issue in in play for any given instance of
browserified code.)

In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839570#5 , Mr. Praveen
lists bugs which ultimately refer to several other Javascript library
packages beyond that of libjs-handlebars.  I suppose it's possible that all
of them include generated lexer/parser code, but if there are some that do
not then apparently "browserification" does not necessarily involve use of
external lexer/parser generators (tho certainly it's possible that
browserification, in the form Mr. Praveen means it, might include always
having the capability to invoke a lexer/parser as part of the process of
browserifying Javascript libraries).  In any event, for any browserified
libraries which do *not* include code generated by a lexer/parser, the bug
at 830986 should not apply to them.

Further, in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839570#35 ,
Mr. Praveen says "the browserified javascript can be modified by anyone who
understand javascript without difficulty and can satisfy dfsg requirement
for source" where the browserified javascript refers to "libjs-handlebars,
libjs-fuzzaldrin-plus and other browserified javascript".  Given what I
understand about the sort of code typically generated by lexer/parsers,
e.g. that it typically can *not* be modified, in generated form, by
"anyone" "without difficulty", I have to think that either (a) Mr. Praveen
does not mean libraries of this sort (e.g. containing generated
lexer/parser code) when he is speaking of browserification in general, or
else (b) he is mistaken in his claim about how easy to modify such
libraries.

So...  If there can be / are browserified libraries which do not suffer
from an issue of containing generated lexer/parser code, then it may make
sense to consider whether such libraries are suitable for inclusion in the
"main" archive separately from the issue of any such libraries which *do*
suffer from an issue of containing generated lexer/parser code.  (For the
record, I myself do not know if there are any such libraries, nor am I
claiming that there are any such.  I'm just raising the possibility as a
"What if?" sort of thing.)




> Now, moving forwards… We decided to close the bug without a formal vote,
> because it was clear for all the present TC members that we were in
> agreement.
> We have also agreed (amongst us) to avoid the use of unnecessary
> bureaucracy
> when possible; hence our delegation to close the bug to Sam. Now, the
> offer to
> "repoen the bug and ask for a formal vote"  [3] stood to enable anyone to
> ask
> for the bug closure to respect our formal procedures (saying "please don't
> close the bug because you think you're in agreement, but run a formal
> vote").
>
> For what I'm concerned, the situation hasn't evolved, and the conclusion
> that
> Sam outlined still stands (FTP Team is responsible for DFSG, and has
> decided,
> Release Team has decided DFSG is RC and has deferred DFSG-compliance
> determination to FTP Team).
>

I'll go into this point in more detail in other responses, I expect, but
I'll at least say for now that I think it is possible to find that there
are differing levels or degrees of DFSG non-compliance, in terms of their
severity of non-compliance or the amount of harm that can be done by
distributing them despite the fact that they are not fully compliant with
*all* the terms of the DSFG and their current interpretation by Debian, and
that therefore it is possible that it might be reasonable in some
circumstances to decide that a 

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Joseph R. Justice]

On Mon, Oct 3, 2016 at 6:46 PM, Philip Hands <p...@hands.com> wrote:

> Pirate Praveen <prav...@debian.org> writes:
> > On 2016, ഒക്‌ടോബർ 3 8:22:20 AM IST, "Joseph R. Justice" <
> jayare...@gmail.com> wrote:
>


> >>If I have misunderstood in any way Mr. Praveen's position, or if I have
> >>misrepresented in any fashion whatsoever what it is he is trying to
> >>express, then I sincerely apologize for my error.
> >>
> >>Otherwise...  I hope this is of some use, interest, in resolving this
> >>issue.  If it is, then I'm glad I could help.  Thanks for your time in
> >>reading this.  Be well, and thanks for all of y'all's efforts in
> >>creating
> >>Debian!
> >
> > Thank you Joseph, that is a good summary of the situation.
>
> I think you need to try a little harder than that -- it is still unclear
> to me what you are even attempting to ask for.  Unless that changes I
> would think that the right response to this is to simply close the bug.
>
> As a bare minimum, try specifying what outcome you are hoping for, with
> respect to which package.
>

Errr.  Mr. Hands.  Did you perhaps not see Message #15 in this bug log,
which is what Mr's Praveen's message (which you quote) is itself referring
to?  (For the record, I myself wrote Message #15.)

If you did not see this message, you can find it at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839570#15 .

If you did indeed see this message, did you perhaps not see the points
labeled (8a), (8b1), and (8b2) in that message, near the bottom of it?
Those points, I believe, clearly signified two alternative outcomes, namely
either (8a) or else [the combination of (8b1) and (8b2) as a set], which I
was suggesting Mr. Praveen was requesting the TC decide between.



Given that Mr. Praveen responded to Message #15 by saying "that is a good
summary of the situation", I believe I can safely say that I have, in fact,
reasonably well expressed what it is he is achieving to desire as an
outcome from this bug.  E.g. he is attempting to achieve either the outcome
described in point (8a), or failing that the outcome described in the set
of points (8b1) and (8b2).  (For what it's worth, I think it's fair to say
that Mr. Praveen has a preference as to which outcome he's like to achieve,
namely that described in (8a).  However, I believe he'd settle for the
outcome described by (8b1) and (8b2) if he cannot achieve (8a).)



As I said in Message #15, "I don't have a horse in this race".  I don't
have a preference as to which of these outcomes comes to pass; it is
irrelevant to me.  I am a disinterested bystander.

I *am*, however, a little offended that you would write, in your response
to Mr. Praveen's response to my Message #15, "it is still unclear to me
what you are even attempting to ask for".  I went to some effort to express
what I believed to be Mr. Praveen's intentions and desires in as explicit
and detailed a fashion as I could achieve.  Given Mr. Praveen's response to
my message, I believe I have in fact reasonably well correctly expressed
and explained what it is he was attempting to express in his original
message opening this bug.  I believe my Message #15 fairly and accurately
represents his position, and what he wants the TC to do.

Therefore, sir, I ask you -- what if anything is unclear to you about the
outcomes expressed in points (8a), or else (8b1) and (8b2), in Message
#15?  I would be happy to try to explain them in a different fashion, or to
attempt to clarify them, if I knew what it was specifically that was
unclear to you.

If you are asking what effect the outcomes expressed in (8a) or else (8b1)
and (8b2) would have on specific packages, well, honestly, I think that
should be self-evident given what I wrote in Message #15 to anyone who read
the entire message carefully and comprehended what was written there.
However, if you need, I will be pleased to explain what I believe the
effect of each of these distinct outcomes, (8a) or else (8b1) and (8b2),
would be on the packages referred to in Message #15 (which is simply the
list provided by Mr. Praveen himself in his original message and the bugs
referred to in his original message).

If there is any further assistance I can provide regarding this matter,
I'll be happy to provide that as well as best as I can.  Just let me know.



Thanks for your time in reading this.  Hope you find it of some use,
interest.  Again, thanks as an end-user and an outside observer for your
(actually, all of y'all's) efforts in creating, maintaining, enhancing, and
promoting Debian.  Be well.



Joseph

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Joseph R. Justice]

[FWIW: I am not a Debian Developer.  I am not a Debian Maintainer.  I am
not someone who (currently) uses Debian (tho I subscribe to some of the
mailing lists), nor uses the software being discussed or referred to within
this bug.  I don't have a horse in this race.  I do, however, have Male
Answer Syndrome, and I'm not afraid to use it!]


On Sun, Oct 2, 2016 at 2:50 PM, Tollef Fog Heen  wrote:

> ]] Pirate Praveen
>
> > Following up on #830978. I would like this to be reopened and request
> > CTTE make a formal vote.
>
> What is the exact question you're trying to get us to answer?  Are you
> asking us for advice, are you asking us to overrule a developer or
> something else?'
>

Having reread the bug log for 830978 and I think most if not all of what's
referenced there (tho not any broader discussions in d-devel), I *believe*
what Mr. Praveen (my apologies if I'm referring to hir incorrectly) is
trying to get at is the following:

(1) The current position of the FTP team is that software proposed to be
distributed by Debian which:
(1a) has source code written in Javascript,
(1b) where the Javascript source code as distributed by Debian for the
software would be "browserified",
(1c) where the Javascript source code as released by the original author of
the software is *not* "browserified",
(1d) where there is no tool or set of tools currently packaged within the
Debian "main" archive which is capable of taking the Javascript source code
described by (1c) and transforming it into the form described by (1b),
(1e) is not suitable for distribution by Debian within the main archive,
because such software does not meet the requirements of the DFSG in terms
of source code availability.  However,
(1f) such software might be suitable for distribution in the "non-free"
archive if there is no reason prohibiting it from being distributed in
non-free.

One such software affected by this is a library package Mr. Praveen was
involved in packaging, libjs-handlebars.  (Its source is
ruby-handlebars-assets, and that source is currently in non-free.)
 Diaspora, which I believe Mr. Praveen was involved in packaging, depends
on libjs-handlebars.

There is apparently the software application "grunt" which is capable of
resolving the point in (1d) in a satisfactory fashion.  (E.g. if grunt
existed in main, (1d) and therefore (1) as a whole would be moot.)
 However, this application is not currently in the Debian main archive, and
presumably there is no hope of getting it into shape to be added to the
main archive in time for the release of Debian "Stretch".

There is also apparently no hope of creating some other software capable of
doing what grunt would do to resolve the point in (1d) in satisfactory
fashion in time for the release of Debian Stretch.

(2) There is other software currently in Debian (presumably in the main
archive), or proposed to be in Debian, which would be affected by the
reasoning in (1).

Bug 814871 refers to libjs-fuzzaldrin-plus, which is depended upon by
gitlab.  Apparently gitlab needs libjs-fuzzaldrin-plus to be in
browserified form and that form cannot yet be created within / by Debian.

Bug 829046 refers to unspecified Javascript libraries which depend on
"grunt" (which itself is not currently in Debian), which are bundled by and
therefore depended upon by pagure (which has an ITP); presumably the
dependency on grunt means that these unspecified Javascript libraries are
used in a browserified form.

Bug 835661 refers again to libjs-handlebars, this time being depended upon
by prometheus.

All these library packages would, per (1), have to be distributed in the
non-free archive.  Presumably at least some of these libraries are
currently being distributed in the main archive.

(3) The current position of the FTP team is that software proposed to be
distributed by Debian which
(3a) depends on software which is not available in the Debian main archive
(3b) cannot itself be distributed in the Debian main archive.  However,
(3c) such software might be suitable for distribution in the "contrib"
archive if the only reason it cannot be distributed in the main archive is
because it depends on software not found in the main archive.

(4) The software depending on the items affected by (1) and (2), e.g.
Diaspora, GitLab, Pagure, and Prometheus, will therefore have to be
distributed in the contrib archive, and moved from the main archive to
contrib if it is currently already in main.

Mr. Praveen further hypothesizes that there will be a number of other
important pieces of software, either already in main or that people would
like to distribute in main, which will have to be moved to contrib and/or
distributed in contrib because they are affected by the same issue: they
depend on other software written in Javascript which is affected by the
issues raised in (1) and (2) and which therefore can only be distributed in
non-free (assuming it is otherwise distributable in the first place).

(5) Mr. 

Bug#653158: www.debian.org: /y2k/ page is probably obsolete

[Joseph R. Justice]

On Sat, Dec 24, 2011 at 8:34 AM, Paul Wise p...@debian.org wrote:

 Since we are now well past Y2K, it is probably time to delete this:

 http://www.debian.org/y2k/

 Any objections?

I have three reasons / possibilities why this might not be desirable:

(1) Are there any major institutions which still care about Y2K
compliance?  I'm thinking specifically about governmental (or
corporate) procurement compliance policies, but there may be other
things also which care about this sort of thing.  If there are, this
page may still be helpful in addressing those policies.  Remember,
governments and corporations move ... slowly, in changing their
policies and practices once established.

(2) Y2038.  A related issue to the Y2K mess was/is the Y2038 mess,
which specifically affects Unix and Unix-like OSen (like Debian
Linux), and more particularly ones which still have a definition of
time_t as a 32-bit value.  In a quick search of the Debian web site
(search.d.o, searching for term 2038 [not in quotes]), the only
thing I quickly find related to this is a page on Debian and the
Millennium Bug, at URL
http://www.debian.org/News/1998/19980104.en.html .  It seems to me
that the Y2K page might be helpful in constructing a page for Debian's
actions concerning and response to the Y2038 issue, if and when this
is done.  (I suspect it is likely that Debian will need to address
this at _some_ point, unless there is a decision made at some point to
not support any 32-bit architectures any more, which decision I
personally find ... unlikely, considering the ubiquity of Debian and
of Linux itself.)

Another interesting page I found in Google searching for Y2038 (I
couldn't remember if it was Y2038 or Y2036 or whatever) was the URL
http://www.y2038.com/ which at a very quick glance seems to be a more
general page on the issue, not Debian (or even Unix / Unix-like)
specific.

(3) Historical interest.  Even tho the actual date has come and gone,
and the issue has presumably already either been fully resolved or
else visibly manifested itself, people might still be interested in
the issue, even if for no other reason than because it _was_ in fact a
significant issue in the history of computing.  Or, perhaps,
interested in it as an example of what not to do in the future (e.g.
fail to think in a sufficiently long-term manner -- for instance, can
we perhaps expect to have a Y+1 issue, one day?)  I note, for
instance, the page at http://en.wikipedia.org/wiki/Y2k -- admittedly,
Debian is not attempting to be encyclopedic in the same sense as
Wikipedia (nor do I think it should make the attempt), but the
principle still applies.

More personally ... I, myself, am an information pack rat; I hate to
throw away information, because you never know if it'll be needed (or
just wanted) again one day.  Is there an actual _need_ to delete this
information, are the computers running the web site running out of
bits or name space?



Now, I would agree with augmenting or altering / rewriting the
existing page, to make it clear it's referring to a past event, it's
being retained primarily (or solely) for reasons of historical
interest, and it's unlikely (or certain) to not be updated any
further.  I could also see the page being moved to a different place,
say to www.d.o/archive/y2k or something similar (where it is still
indexable and findable by web spiders, e.g. Google, et al).  Either or
both of those things would seem reasonable to do, express the current
status of the page and the information it contains, but retain the
information for anyone who might still be interested in it now or in
the future.  (Note, if the page is moved, a pointer to its new
location from the existing page should be established for at least
some time.)



Hope this is of some use, interest.  Thanks for your time.  Be well.

Joseph



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#613072:

[Joseph R. Justice]

Package: bugs.debian.org
Severity: wishlist

In random surfing of the www.debian.org website, et al, I noticed that
the closed bug 610639 (at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610639 with title
Installation of winbind does not activate the winbindd daemon) has
an invalid value for the Package: header.

Specifically, the Package: header for this bug has a value of winbind
- Samba nameservice integration server, when presumably it should
have only had a value of winbind.

This causes spurious entries in
http://bugs.debian.org/cgi-bin/pkgindex.cgi?indexon=pkg .
Specifically, there are spurious entries for the non-existent packages
-, nameservice, integration, and server; samba however is a
real package.  I'm sure there's other spurious things out there caused
by this bad value, also.

Presumably some sort of sanity checking of the value of the Package:
field, upon receipt of a message sent to sub...@bugs.debian.org but
prior to its bug being added to bugs.d.o, could be done to prevent
this sort of thing in the future.  Note that it would be insufficient
to merely add sanity checking to the reportbug package, since that is
not the only way bug reports can be introduced into bugs.d.o.
(Indeed, this very bug report is being created as a raw e-mail message
and not via reportbug -- I hope I don't screw it up!)

I'm not entirely certain of what this sanity checking should entail,
or what should be done when it is determined that a message contains a
partially or entirely invalid value for the Package: field.  But, I'm
sure there's something useful that can and probably should be done.

Hope this is of some use, interest.  Thanks for your time.  Be well.

Joseph



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#613072: bugs.d.o should sanity check value of Package: header

[Joseph R. Justice]

retitle 613072 bugs.d.o should sanity check value of Package: header
# Forgot to put a Subject: line in the original message.  Oops.
stop


On 2/12/11, Joseph R. Justice jayare...@gmail.com wrote:

 (Indeed, this very bug report is being created as a raw e-mail message
 and not via reportbug -- I hope I don't screw it up!)

Errr...  *blush*.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#612239: sgml-data should suggest package w3-recs instead of missing package doc-html-w3

[Joseph R. Justice]

Package: sgml-data
Version: 2.0.3
Severity: minor

In random surfing around www.debian.org, etc, I noticed that the
sgml-data package as currently provided by all of old-stable (Debian
5.0), stable (6.0), and unstable suggests a package called
doc-html-w3, but this latter package is apparently not available in
any of these versions.  See for instance
http://packages.debian.org/sid/sgml-data (you can replace sid by
lenny or squeeze).  This affects versions 2.0.3, 2.0.4, and 2.0.5
of the package sgml-data.

A little research reveals that doc-html-w3 _used_ to exist within
Debian, but was first orphaned (see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=416033 ) and then
removed (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460906
).  Based on those bug reports and more research, it appears the
functional replacement for this package is now the package w3-recs,
which is available in all of old-stable, stable, and unstable in
non-free.  See for instance http://packages.debian.org/sid/w3-recs .

I believe that sgml-data's dependency on doc-html-w3 should be removed
(obviously), and furthermore probably replaced with a dependency on
w3-recs instead.  Because w3-recs is in non-free (as doc-html-w3
itself apparently used to be), this new dependency should probably
also be a Suggests, just as the old one was.

Further, if there are any other packages elsewhere in the archives
with a dependency on doc-html-w3, those packages should probably also
have that dependency replaced with one of a similar level on w3-recs
(assuming it made sense to have the doc-html-w3 dependency in the
first place).  However, that's something out of scope for this bug
report, of course.  (Is there an easy way, using the various web
services only, to see what packages depend on another package when
that other package does not itself exist anymore?  Should this be a
lintian check or something?  Note that I myself am not actually
running Debian at this time, so I cannot use any command-line tools or
data.)

Thanks for your time.  Hope this is of some use and interest.  My
apologies if this bug report is incorrectly formatted; I am formatting
it by hand in e-mail.  Let me know if there is further info I can
provide.

Joseph



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org