Re: Dask sourceless javascript passed by me.

[Paul Wise]

On Sat, Jun 9, 2018 at 2:05 AM, Diane Trout wrote:

> Using a screen shot is just to deal with our build from source rule and
> to avoid a privacy leak from loading a remote resource.

I believe that rule applies to all of Debian main, not just ELF binaries.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Dask sourceless javascript passed by me.

[Diane Trout]

On Fri, 2018-06-08 at 10:05 +0800, Paul Wise wrote:
> On Fri, Jun 8, 2018 at 5:59 AM, Diane Trout wrote:
> 
> > How do I replace the .orig.tar.gz that I already uploaded?
> 
> You will need a new upstream version, typically people use
> 0.1.2+dfsg1
> (for DFSG issues) or 0.1.2+ds1 (for other repack reasons) in these
> sort of situations.

Ah I see, if I adjust the changelog to +dfsg1-1, I can upload
a new .orig.tar.gz... 

> 
> > I was planning on replacing the plots with a screen shot until I
> > have a
> > solution to actually build the plots from source.
> 
> Screenshots are derivative works of the UI they are from, so
> theoretically you need to care about the source for screenshots too.
> In practice I guess everyone ignores this.

Wait a second... The pages that I want to replace with a screenshot are
in a BSD-3-clause licensed repository. Aren't I allowed to make
derivative works?

Using a screen shot is just to deal with our build from source rule and
to avoid a privacy leak from loading a remote resource.

Diane

Python 3.7 in testing/experimental

[Matthias Klose]

The Python 3.7 beta 5 packages are now in testing, and experimental has 
python3-defaults packages which add 3.7 as a supported version.  The release 
candidate is expected next week, only adding Unicode 11 support, and the final 
release is expected at the end of June.


I would appreciate it, if somebody could run a test rebuild using the 
python3-defaults from experimental.  Else, please test your packages using 
python3.7.


Matthias

Re: Updated PEP 394 (python and python2 commands)

[Matthias Klose]

On 19.05.2018 07:24, Stuart Prescott wrote:

Matthias Klose wrote:

The distro should get
out of the way of using the python symlink, and giving users the freedom /
choice what to do about the link.


I think I understand your rationale to stop shipping /usr/bin/python and
once the unversioned symlink disappears from use in Debian then at least
that particular avenue to breaking one's system disappears.

What I don't understand is why any changes to package names or dependencies
are required to achieve that goal.

It sounds like a reasonable amount of work in your proposal, but once we no
longer have any Python 2 applications left at some stage in the bullseye
cycle, isn't the following sufficient?

--- a/debian/rules
+++ b/debian/rules
@@ -247,12 +247,9 @@ binary-arch: build install stamp-doc
  
 : # provide the python and python.1 defaults

 mkdir -p debian/python-minimal/usr/bin
-   ln -sf python$(VER) debian/python-minimal/usr/bin/python
 ln -sf python$(VER) debian/python-minimal/usr/bin/python2
 mkdir -p debian/python-minimal/usr/share/man/man1
-   ln -sf python$(VER).1.gz \
-   debian/python-minimal/usr/share/man/man1/python.1.gz
 ln -sf python$(VER).1.gz \
 debian/python-minimal/usr/share/man/man1/python2.1.gz

and then either later in the bullseye or bookworm cycles, those python-
defaults simply go away along with all the other 'unversioned' python module
and interpreter packages.

What have I (and others!) missed that would make a rather elaborate
packaging dance preferable to this?


from my point of view this doesn't address:

 - being able to de-install the python command for buster, if
   people don't use it.  Most dependencies are auto-generated, so
   these could be replaced by dependencies on python2. I would
   assume that the majority of users won't have to install the
   python package anymore, unless they are doing python2
   development.

 - Not having a python package in bullseye (buster+1), but a
   python2 package doesn't point to any "default" anymore. Many
   users are installing just python, because it's the unversioned
   package.  So make it clear that this is another version, and
   with having the choice of python2 and python3, most users will
   install python3.

Note that with the command-not-found package installed (and using python3), and 
not having python installed, you get now a message


   $ python

   Command 'python' not found, but can be installed with:

   sudo apt install python3
   sudo apt install python

   You also have python3 installed, you can run 'python3' instead.

Assuming that you only have python2 installed in buster, you get this hint 
already in buster, pointing to python3. You can't do this without a separate 
python2 package.


Matthias