Re: About license compatibility

[Andrey Rahmatullin]

On Sun, Dec 08, 2019 at 04:37:28PM +0900, JungHwan Kang wrote:
> Thank you for your detailed answer. :)
> I'm gonna ask one more question, please.
I don't see a question below.

> I was confused Ubuntu cannot have an overall license, because of the
> license of Ubuntu as below.
> "Ubuntu operates under the GNU General Public License (GPL) and all of the
> application software installed by default is free software.
> In addition, Ubuntu installs some hardware drivers that are available only
> in binary format, but such packages are clearly marked in the restricted
> component."
> (https://en.wikipedia.org/wiki/Ubuntu)
Wikipedia is not a source and "Ubuntu operates under the GNU General
Public License (GPL)" sounds like nonsense.

> But, I can get it clearly now after I know there is no mention of GPL at
> the Ubuntu's license page.
> (https://ubuntu.com/licensing)
This page is correct and says almost the same words as Debian says about
itself: "Ubuntu is a collection of thousands of computer programs and
documents [...] Each of these programs may come under a different
licence.".

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Another question for a license

[JungHwan Kang]

Hi, forks.
I appreciate your previous answer to my question about the open-source
licenses.
May I ask another question?

1. Is it no matter who releases his Linux distribution under his license
for commercially?
the distribution is made of modified and unmodified packages from
upstream.

2. Following question #1,
I think if I were him, I'll be careful only about the license conflict
of the modified packages.
He needs to consider the original upstream license to make his license
for the modified
packages to avoid the license incompatibility issue.

3. Is there any Linux distribution released under a certain license, really?
I just want to check it one more time.

Best regards

Re: Another question for a license

[Andrew M.A. Cater]

On 08/12/2019 13:27, JungHwan Kang wrote:

Hi, forks.
I appreciate your previous answer to my question about the open-source 
licenses.

May I ask another question?

1. Is it no matter who releases his Linux distribution under his license 
for commercially?
     the distribution is made of modified and unmodified packages from 
upstream.




In what I write below: "you" is a general you - equivalent to "anybody who"

If you put together a Linux distribution, you can choose how to 
distribute it as a collected work. In each case, however, each program 
will be under it's own licnce. Packaging software may involve modifying 
it - you need to take that into account and make sure that any software 
you package allows modification. The Debian Free Software Guidelines 
specify that software should allow modification.



2. Following question #1,
     I think if I were him, I'll be careful only about the license 
conflict of the modified packages.
     He needs to consider the original upstream license to make his 
license for the modified

     packages to avoid the license incompatibility issue.


See above: if the softwrae doesn't allow modifcation, it can't be 
included. Each program is under it's own licence: packagers need to be 
sure that that program is suitable. That includes checking that 
packaging and use takes care of any licence conflicts in individual 
components. That's one reason why Debian suggest that some licences are 
acceptable but leaves it up to each individual packager to be responsible.




3. Is there any Linux distribution released under a certain license, really?
     I just want to check it one more time.

I doubt there's any complete Linux distribution released under only one 
licence



Best regards

Re: d/changelog and experimental

[Guillem Jover]

Hi!

On Tue, 2019-12-03 at 08:15:19 +0100, Paolo Greppi wrote:
> What is the best approach for d/changelog when releasing a package
> to unstable after it has been through a few iterations to experimental ?
>
> It would seem that the right thing to do is to keep all experimental
> changelog entries, and add a new one for unstable.

That really depends on how one manages these branches and uploads.

I think there are two important properties that need to be preserved
so that debian/changelog entries keep making sense both for humans
and machines alike. The first is that the parseable format entries
should be sorted by version, otherwise things that parse the file
might get confused when doing range checks or filtering things. The
second is to preserve the timeline of the changes, so that when a
human (or even a parser that extracts semantic meaning like with bug
closures) reads them they should still makes sense.

> But sometimes experimental uploads are, well ... experimental, there
> may be changes that cancel out (I tried this but it did not work, then
> I tried that etc.).
> So another way is to consolidate all experimental changelog entries
> into the unstable one, tidying it up.
> Also as most people never see the experimental releases, they only
> care for what's new since the last release to unstable / stable.

I think the two main ways to handle these are either based on
something ressembling the shape of «git cherry-pick» or «git merge».

* For a «git cherry-pick» kind of approach, an upload to experimental
  does not imply that the changes there should or might end up all in
  unstable, it might end up being, say, a dead-end diverging VCS branch,
  and you could simply backport the various atomic changes in atomic
  squashed logical units into unstable to drop any intermediate
  changes/commits.

  Or another similar approach might keep them in sync, by doing the same
  packaging changes to both the unstable and experimental branches, and
  upload both at around the same time. Then you could eventually just
  upload the package from experimental into unstable. You'd lose upload
  information, but not change information. The former can easily happen
  within stable vs testing/unstable anyway, or with not ACKed NMUs for
  example, so I don't think it's a big deal, and the upload information
  is anyway tracked in DAK or tracker.d.o.

* For a «git merge» kind of approach, then what can happen is that
  you've got changes reverted in one place and reintroduced in another,
  so how you sort the entries in debian/changelog is even more important
  to avoid confusing people reading the entries. In this case, if using
  version-sorted entries, it can make them stop making sense, and
  date-sorting would confuse automated parsing, neither of these would
  really represent the actual timeline of the changes, so I'd recommend
  injecting the entries as sub entries. So as an example, it could look
  something like this:

  ,---
  pkg (1.0.0-11) unstable; urgency=medium

* Enable feature foo.

   -- Name   Date N + 6

  pkg (1.0.0-10) unstable; urgency=medium

* Merge from experimental:

pkg (2.0.0-5) experimental; urgency=medium

  * Disable feature foo.
  * Some other change Z.

 -- Name   Date N + 3

pkg (2.0.0-4) experimental; urgency=medium

  * Enable feature foo.
  * Some other change Y.

 -- Name   Date N + 1

* Some other change B.

   -- Name   Date N + 5

  pkg (1.0.0-9) unstable; urgency=medium

* Some other change A.

   -- Name   Date N + 2

  pkg (1.0.0-8) unstable; urgency=medium

* Disable feature foo.

   -- Name   Date N + 0
  `---

  Of course if “Enable feature foo” would have happened already in
  1.0.0-9, then that'd be reather confusing, but would imply a mix
  of different merge strategies. :)

Thanks,
Guillem

Bug#946423: ITP: ruby-optimist -- Commandline option parser for Ruby that just gets out of your way.

[Stig Sandbeck Mathisen]

Package: wnpp
Severity: wishlist
Owner: Stig Sandbeck Mathisen 

* Package name: ruby-optimist
  Version : 3.0.0
  Upstream Author : William Morgan, Keenan Brock, Jason Frey
* URL : https://www.manageiq.org/optimist/
* License : MIT/Expat
  Programming Lang: Ruby
  Description : Commandline option parser for Ruby that just gets out of 
your way.


Upstream description


Optimist is a commandline option parser for Ruby that just gets out of your
way.  One line of code per option is all you need to write. For that, you get a
nice automatically-generated help page, robust option parsing, and sensible
defaults for everything you don't specify.

Features:

- Dirt-simple usage.
- Sensible defaults. No tweaking necessary, much tweaking possible.
- Support for long options, short options, subcommands, and automatic type
  validation and conversion.
- Automatic help message generation, wrapped to current screen width.


Packaging and maintenance
-

The upstream project name has been changed from trollop to optimist.
(https://github.com/ManageIQ/optimist/issues/92)

ruby-optimist is a dependency for hiera-eyaml >= 3.0.0, and needs to be
available before newer versions of hiera-eyaml can be imported.

ruby-optimist will be maintained under the debian-ruby team umbrella.

Re: d/changelog and experimental

[Bernd Zeimetz]

On 12/3/19 8:21 AM, Russ Allbery wrote:
> Paolo Greppi  writes:
> 
>> What is the best approach for d/changelog when releasing a package to
>> unstable after it has been through a few iterations to experimental ?
> 
>> It would seem that the right thing to do is to keep all experimental
>> changelog entries, and add a new one for unstable.
> 
> This is the typical practice, including all the intermediate experiments
> or false starts in experimental.
> 
> [.]

I'm all in favour of keeping the upload history, but recently I had to
do a major rework of the packaging in experimental while updating
unstable at the same time. So over several weeks, unstable got various
cherry-picks from experimental and at some point a big merge happened,
which made it more or less impossible to keep the changelog from
experimental as lots of changes would be documented twice and, even
worse, there would be a mix of version X and X+1 entries in the
changelog as the uploads were not linear.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: d/changelog and experimental

[Simon Richter]

Hi,

On 08.12.19 22:29, Guillem Jover wrote:

> I think there are two important properties that need to be preserved
> so that debian/changelog entries keep making sense both for humans
> and machines alike. The first is that the parseable format entries
> should be sorted by version, otherwise things that parse the file
> might get confused when doing range checks or filtering things. The
> second is to preserve the timeline of the changes, so that when a
> human (or even a parser that extracts semantic meaning like with bug
> closures) reads them they should still makes sense.

For backports, we already have cases where entries aren't sorted,
because the changelog still lists the version from sid, and the entry
for the backports version is then prepended with a lower version number.

Bugs are closed based on the changes file, which is generated from the
topmost entry, always.

The rest of the changelog only exists to preserve history. When you make
an upload to experimental closing a bug, and you later upload the
package to unstable, you have to close the bugs again in the changelog
entry for unstable. At this point, it makes sense to condense the
changelog to things that have actually changed.

The target audience of the Debian changelog is a skilled system
administrator who wants to know what changes in behavior to expect from
the new version, especially deviations from what is described in
upstream documentation (because Debian applied a patch).

The format is too terse to serve as a full history of the package
itself, it can only provide pointers to more documentation, ideally
inside the BTS so it is archived within Debian and crosslinked.

The example you give for a merged changelog is confusing, and there is
no way to make it less so save for a dedicated tool to visualize it --
but such a tool could also access the git history of the package instead.

   Simon



signature.asc
Description: OpenPGP digital signature

sysusers and tmpfiles

[Zbigniew Jędrzejewski-Szmek]

Hi,

[disclaimer: on work on systemd upstream, I'm not an active Debian
user anymore.]

Using systemd-sysusers and systemd-tmpfiles more widely was mentioned
a few times, along with a statement that an implementation for
non-systemd systems would need to be provided. Both those programs
work just fine without systemd not running as PID1. (systemd has unit
files to start them automatically during boot and at regular
intervals, so that part would need to be reimplemented appropriately
for a given init system if desired. The programs themselves don't care
at all how they are started.)

For example, upstream distributes rpm scriptlets [1] to invoke them
from an rpm transaction, i.e. possibly without any programs running in
the install root.

[1] 
https://github.com/systemd/systemd/blob/master/src/core/macros.systemd.in#L123

Zbyszek

Re: sysusers and tmpfiles

[Russ Allbery]

Zbigniew Jędrzejewski-Szmek  writes:

> Using systemd-sysusers and systemd-tmpfiles more widely was mentioned a
> few times, along with a statement that an implementation for non-systemd
> systems would need to be provided. Both those programs work just fine
> without systemd not running as PID1. (systemd has unit files to start
> them automatically during boot and at regular intervals, so that part
> would need to be reimplemented appropriately for a given init system if
> desired. The programs themselves don't care at all how they are
> started.)

Hi Zbigniew,

Do you know if systemd upstream would be willing to commit to that
continuing to be the case?  I wasn't sure if that would be an acceptable
limitation; if not, that's certainly an easy solution for those two
facilities.

I admit that I can't think of any reason why they wouldn't run without
systemd as PID 1, but I wasn't sure I was anticipating possible future
changes.

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

Re: d/changelog and experimental

[Ben Hutchings]

On Sun, 2019-12-08 at 23:24 +0100, Simon Richter wrote:
[...]
> The rest of the changelog only exists to preserve history. When you make
> an upload to experimental closing a bug, and you later upload the
> package to unstable, you have to close the bugs again in the changelog
> entry for unstable.
[...]

So long as the experimental versions are listed in the changelog, so
that the BTS recognises the new version as based on them, you don't
need to close the bugs again.

Ben.

-- 
Ben Hutchings
Humour is the best antidote to reality.




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