Bug#966373: Please stop reopening bugs that maintainers have closed

[Javier Serrano Polo]

On Wed, 17 Mar 2021 16:12:37 -0700 Don Armstrong 
wrote:
> Please stop reopening bugs which have been closed by Debian
Maintainers.

Please, Don, could you guide me on this matter?
The bug focus has changed, thus I retitled the bug and I thought
wontfix was not valid now. Should I open a new report instead?
What should I do when maintainers are unresponsive or do not explain
their actions?
Should I never reopen a report?

Thank you.

smime.p7s
Description: S/MIME cryptographic signature

Bug#966373: general: Version for derivatives between binNMU and stable update

[Javier Serrano Polo]

On Thu, 15 Oct 2020 21:25:51 +0200 Javier Serrano Polo  wrote:
> Thus, there are three choices:
> 
>1. Before binNMU (case 1.0-1deriv1).
>2. After stable update (case 1.0-1+deriv1).
>3. Between binNMU and stable update. This is what I am asking for.
> 
> Would you agree to preserve this third choice if it is currently
> feasible?

Dear Paul Wise,

Package linux parses the Debian version. Could we settle on a version
pattern for derivatives that lies between binNMU and stable update?

smime.p7s
Description: S/MIME cryptographic signature

Bug#954794: Permit packages to declare dependencies on Essential packages

[Javier Serrano Polo]

On Mon, 16 Nov 2020 16:11:53 -0800 Jonathan Nieder 
wrote:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=nonessentiale2fsprogs;users=helm...@debian.org
> shows that people are already adding explicit dependencies on it,
> which means that
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954794;msg=111 is
> the de facto policy / what people believe policy to say.

So, should policy change? Currently, it says that packages "should not"
declare essential dependencies, which is more permissive than "must
not". Is the workflow with e2fsprogs the path to follow?

smime.p7s
Description: S/MIME cryptographic signature

Bug#890834: gtk+2.0: Add build profiles to skip flavors and packages

[Javier Serrano Polo]

Control: tags -1 - moreinfo

More information was provided.

smime.p7s
Description: S/MIME cryptographic signature

Bug#890556: aptitude: Add build profile to skip documentation packages

[Javier Serrano Polo]

Control: tags -1 - moreinfo

More information was provided.

smime.p7s
Description: S/MIME cryptographic signature

Bug#837723: Removing/Disabling the general psuedo package; refering to debian-u...@lists.debian.org

[Javier Serrano Polo]

On Mon, 26 Oct 2020 22:10:56 +0100 Javier Serrano Polo  wrote:
> I am trying to solve a bug,

Perhaps this should be a permanent bug without the wontfix tag. I do
not know why wontfix would not be correct, but I will leave the tagging
to other users. I have provided a patch; without feedback, I think I
have helped as much as possible with this issue.

--
"We saw how there is peace even in the storm."
Famous painter

smime.p7s
Description: S/MIME cryptographic signature

Bug#966373: general: Higher version for uploads to stable and oldstable distributions

[Javier Serrano Polo]

On Mon, 19 Oct 2020 12:33:09 +0200 Julien Cristau 
wrote:
> tags 966373 + wontfix
> close 966373

Another closure, this time without excuse. It is obviously a mistake,
because Debian derivatives are welcome, right? I will correct this.

Adam D. Barratt did not answer my previous questions, thus she needs
more time.

smime.p7s
Description: S/MIME cryptographic signature

Bug#854973: lists.debian.org: Create debian-banned

[Javier Serrano Polo]

Control: reopen -1

El dg 18 de 10 de 2020 a les 22:40 +0200, Javier Serrano Polo va
escriure:
> Otherwise, I will reopen this report.

Reopening.

smime.p7s
Description: S/MIME cryptographic signature

Bug#837723: Removing/Disabling the general psuedo package; refering to debian-u...@lists.debian.org

[Javier Serrano Polo]

On Sat, 24 Oct 2020 11:53:44 +0800 Paul Wise  wrote:
> # It is not up to people who are not submitters or BTS admins to
determine the outcome for this bug

What do you mean? Are you the submitter? No, you refused to be. Are you
a BTS admin? No, you are not listed as a member. You determine the
outcome, thus you do not follow your own guideline.

I am trying to solve a bug, you are sabotaging this effort. So, either
give a solution to this bug or let the submitter or BTS admins reply.
Otherwise, I will tag this report as wontfix again and, if you undo
this action, I may submit a complaint.

smime.p7s
Description: S/MIME cryptographic signature

Bug#854973: lists.debian.org: Create debian-banned

[Javier Serrano Polo]

Control: submitter -1 !

On Sun, 18 Oct 2020 22:10:47 +0200 Geert Stappers 
wrote:
> Closing this "new list request"
> because in three years no one second the request.

Closing this report does not make these Debian users disappear. Please
clarify if you are officially recognizing your hate against such users.
Otherwise, I will reopen this report.

smime.p7s
Description: S/MIME cryptographic signature

Bug#966373: general: Higher version for uploads to stable and oldstable distributions

[Javier Serrano Polo]

On Sat, 10 Oct 2020 09:00:48 +0100 "Adam D. Barratt"  wrote:
> This has nothing specifically to do with updates to stable, and
> changing the versioning used for source updates to stable will not
> change it. If stable released with version 1.0-1 of package foo, then
> it is entirely feasible that a binNMU will be required at some point,
> and that will be versioned as 1.0-1+b1.

Please make up your mind. If you are not interested in knowing the
problem with 1-1+b1foo1 and 1-1+b1foo1+b1, then stop with the
"ugliness" stuff.

> It also conflicts with your original claims that you were trying to
> avoid having a stable update - which would be a source change

When did I say such a thing?
 
> There are two choices for the derivative when making source changes.

There are two patterns:

   1. binNMU
   2. stable update

Thus, there are three choices:

   1. Before binNMU (case 1.0-1deriv1).
   2. After stable update (case 1.0-1+deriv1).
   3. Between binNMU and stable update. This is what I am asking for.

Would you agree to preserve this third choice if it is currently
feasible?

smime.p7s
Description: S/MIME cryptographic signature

Bug#954794: New packages must not declare themselves Essential

[Javier Serrano Polo]

On Wed, 07 Oct 2020 18:43:22 -0400 Sam Hartman 
wrote:
> C) I'd support non-normative documentation that we don't expect to
> approve new essential packages in the future in policy.

Worthless documentation, I think.

> A) I do support reducing the essential set over time

Fine, then you should choose one essential package and remove it from
the set for bullseye or bookworm.

smime.p7s
Description: S/MIME cryptographic signature

Bug#954794: New packages must not declare themselves Essential

[Javier Serrano Polo]

On Wed, 30 Sep 2020 18:34:06 -0700 Jonathan Nieder 
wrote:
> Even so, some *rough* consensus on the plan is very useful for
> helping people evaluate that first step.

Here is a rough plan:

   1. Policy: Packages should declare all their dependencies, even
  essential ones.
   2. Make easier this task: document dependencies, add Lintian checks,
  etc.
   3. Policy: Packages must declare all their dependencies.
   4. Wait until previous Debian releases become unsupported.
   5. Drop support for Essential.

smime.p7s
Description: S/MIME cryptographic signature

Bug#966373: general: Higher version for uploads to stable and oldstable distributions

[Javier Serrano Polo]

El dl 21 de 09 de 2020 a les 16:50 +0200, Javier Serrano Polo va
escriure:
> I will elaborate on the problem with 1-1+b1foo1 and 1-1+b1foo1+b1 if
> you are willing to help.

First, a binNMU in Debian may be unnecessary in the derivative.
Following Debian binNMUs means unnecessary builds in architectures
supported by the derivative and a burden for users in unsupported
architectures. Moreover, the derivative would need to track all binary
changes instead of source changes only.

smime.p7s
Description: S/MIME cryptographic signature

Bug#837723: Removing/Disabling the general psuedo package; refering to debian-u...@lists.debian.org

[Javier Serrano Polo]

Control: tags -1 wontfix

El dt 29 de 09 de 2020 a les 17:10 +0200, Javier Serrano Polo va
escriure:
> Thus, I will tag this report as wontfix.

Tagging.

smime.p7s
Description: S/MIME cryptographic signature

Bug#954794: New packages must not declare themselves Essential

[Javier Serrano Polo]

El dt 29 de 09 de 2020 a les 15:08 -0700, Josh Triplett va escriure:
> I want to avoid letting the problem get any worse.

So Essential packages are a problem. Do you want to remove Essential in
the long-term? If this goal is not clear, there is little point in
changing policy. New Essential packages will exist if there is a good-
enough reason.

smime.p7s
Description: S/MIME cryptographic signature

Bug#971379: libnss3: Make CERT_AddCertToListTailWithData available

[Javier Serrano Polo]

Package: libnss3
Version: 2:3.56-1
Severity: wishlist

Function CERT_AddCertToListTailWithData is available in headers. Please
make this function available in the library too.

smime.p7s
Description: S/MIME cryptographic signature

Bug#954794: New packages must not declare themselves Essential

[Javier Serrano Polo]

El dl 21 de 09 de 2020 a les 17:15 +0200, Javier Serrano Polo va
escriure:
> Do you want to remove Essential?

Since it looks like you do not try to eliminate Essential, I will close
this report.

smime.p7s
Description: S/MIME cryptographic signature

Bug#966373: general: Higher version for uploads to stable and oldstable distributions

[Javier Serrano Polo]

Control: reopen -1

El dl 21 de 09 de 2020 a les 16:50 +0200, Javier Serrano Polo va
escriure:
> Would you show your good intention by letting this discussion
> happen in an opened report?

Let us test your good intention.

smime.p7s
Description: S/MIME cryptographic signature

Bug#837723: Removing/Disabling the general psuedo package; refering to debian-u...@lists.debian.org

[Javier Serrano Polo]

On Sat, 26 Sep 2020 10:47:52 +0800 Paul Wise  wrote:
> submitter 837723 Don Armstrong 

Paul Wise is not helping, since he undoes my work without any
explanation.

Let us continue. This bug is four years old, a patch has been
submitted, and maintainers show no will to fix the bug. Thus, I will
tag this report as wontfix.

smime.p7s
Description: S/MIME cryptographic signature

Bug#954794: New packages must not declare themselves Essential

[Javier Serrano Polo]

On Mon, 23 Mar 2020 08:00:04 -0700 Josh Triplett  wrote:
> This change does not propose eliminating the concept of Essential,

What is the point of Essential? To omit declaring dependencies on the
false assumption that some packages are always required by all systems;
the concept is essentially ill. Thus, if you are not pursuing the
elimination of Essential, your effort is virtually useless. Do you want
to remove Essential?

smime.p7s
Description: S/MIME cryptographic signature

Bug#966373: general: Higher version for uploads to stable and oldstable distributions

[Javier Serrano Polo]

El dl 21 de 09 de 2020 a les 15:29 +0100, Adam D. Barratt va escriure:
> You said disruptive.

You are not addressing the reason I have given. I will elaborate on the
problem with 1-1+b1foo1 and 1-1+b1foo1+b1 if you are willing to help.
Closing bugs immediately and repeatedly seem the opposite to a desire
to help. Would you show your good intention by letting this discussion
happen in an opened report?

smime.p7s
Description: S/MIME cryptographic signature

Bug#966373: general: Higher version for uploads to stable and oldstable distributions

[Javier Serrano Polo]

On Mon, 21 Sep 2020 14:53:33 +0100 "Adam D. Barratt"  wrote:
> ("These version numbers are ugly"

Who did say that? Please reopen the bug and answer to the reason I have
given, unless you admit that Debian derivatives are not welcome.

smime.p7s
Description: S/MIME cryptographic signature

Bug#970682: debian-policy: 5.6.12, temporarily forbid versions ending with zero

[Javier Serrano Polo]

Package: debian-policy
Version: 4.5.0.3
Severity: wishlist

For those who care about Debian derivatives:

Until #966373[1] is fixed, I propose adding this text to section
5.6.12:

As a temporary measure to support Debian derivatives, versions must
not explicitly end with zero (i.e., -0 or .0).

--
[1] https://bugs.debian.org/966373

smime.p7s
Description: S/MIME cryptographic signature

Bug#837723: Removing/Disabling the general psuedo package; refering to debian-u...@lists.debian.org

[Javier Serrano Polo]

Control: submitter -1 p...@debian.org
Control: tags -1 patch

El dl 14 de 09 de 2020 a les 08:40 +0200, Javier Serrano Polo va
escriure:
> you should become the new submitter.

Changing then.

> Could you explain your reason for reopening this bug?

I assume you are not satisfied with current situation, so I will
provide a procedure for fixing this bug:

   1. "general" should be disabled.
   2. "multiple-packages" should handle bugs about multiple packages.
  Maintainer should be debian-de...@lists.debian.org.
   3. "dont-know" should handle bugs where the submitter does not know the
  right package. Maintainer should be debian-u...@lists.debian.org.

"general" could be kept instead of "multiple-packages" if you accept
the risk of confusion with "dont-know".

smime.p7s
Description: S/MIME cryptographic signature

Bug#966373: general: Higher version for uploads to stable and oldstable distributions

[Javier Serrano Polo]

Control: reopen -1

El dg 06 de 09 de 2020 a les 22:50 +0200, Javier Serrano Polo va
escriure:
> Otherwise, I will reopen this report.

Reopening then.

smime.p7s
Description: S/MIME cryptographic signature

Bug#837723: Removing/Disabling the general psuedo package; refering to debian-u...@lists.debian.org

[Javier Serrano Polo]

On Mon, 14 Sep 2020 13:40:48 +0800 Paul Wise  wrote:
> reopen 837723 

Since the original submitter does not care anymore, you should become
the new submitter. Could you explain your reason for reopening this
bug? What is your request to the Debian bug tracking team?

smime.p7s
Description: S/MIME cryptographic signature

Bug#966373: general: Higher version for uploads to stable and oldstable distributions

[Javier Serrano Polo]

El dg 06 de 09 de 2020 a les 11:59 +0200, Ansgar va escriure:
> I didn't say that,

Yes, Ansgar literally did:[1] If I were anyone else, "I would recommend
to discuss on debian-devel@." Filing a bug against general was the
right way; submitter's identity is irrelevant.

> This
> includes filing bugs that end up forwarded to said mailing lists.

My reports to the BTS do not end up forwarded to mailing lists, which
is known by their administrators. Ansgar's "recommendation" comes from
intolerance and her closing of this report is out of place.

> Please don't send me further mails.

I will send messages to Ansgar if it is required to solve a Debian
issue like this one.

BTS managers: Please clarify whether I am banned from the BTS.
Otherwise, I will reopen this report.

--
[1] https://bugs.debian.org/966371#10

smime.p7s
Description: S/MIME cryptographic signature

Bug#966373: general: Higher version for uploads to stable and oldstable distributions

[Javier Serrano Polo]

On Sun, 30 Aug 2020 11:53:59 +0200 Chris Hofstaedtler 
wrote:
> Filing this against the `general` package does nothing
> useful for this discussion,

On Mon, 27 Jul 2020 16:28:25 +0200 Ansgar  wrote:
> I would recommend to
> discuss on debian-devel@.

smime.p7s
Description: S/MIME cryptographic signature

Bug#837723: Removing/Disabling the general psuedo package; refering to debian-u...@lists.debian.org

[Javier Serrano Polo]

On Mon, 19 Sep 2016 13:18:39 +0100 Ian Jackson
 wrote:
> If that doesn't work, might it be possible to make it impossible to
> _report_ a bug against general, but still retain the ability to
> _reassign_ a bug to general ?

This would only complicate the handling of general bugs.

As said, we need a place in the BTS for bugs which affect lots of
packages. Perhaps you should rename "general" to "multiple-packages".

Anyway, you are living with general four years later. May I close this
report?

smime.p7s
Description: S/MIME cryptographic signature

Bug#883133: general: Add new package header Upstream-Version:

[Javier Serrano Polo]

On Sat, 2 Dec 2017 11:08:32 + Simon McVittie 
wrote:
> If you want to avoid packaging-system-specific code, you'll need to
> query version numbers in a way that only relies on the upstream
> software,

The issue has been answered correctly. May I close this report?

smime.p7s
Description: S/MIME cryptographic signature

Bug#966357: security.debian.org: Higher version for security updates

[Javier Serrano Polo]

See https://bugs.debian.org/966373.

smime.p7s
Description: S/MIME cryptographic signature

Bug#966371: project: Higher version for uploads to stable and oldstable distributions

[Javier Serrano Polo]

See https://bugs.debian.org/966373.

smime.p7s
Description: S/MIME cryptographic signature

Bug#966373: general: Higher version for uploads to stable and oldstable distributions

[Javier Serrano Polo]

Package: general
Severity: wishlist

For those who care about Debian derivatives:

A derivative may be deployed as an overlay rather than a full archive.
Modifications from the derivative live together with originals from
Debian, but modifications must have a higher version.

Full archives use this approach to increase the version:
1-1 → 1-1foo1

This does not work with overlays because of binNMUs:
1-1+b1 > 1-1foo1
1-1+b1 > 1-1foo1+b1

A binNMU may be unnecessary in the derivative. Also, these versions are
disruptive:
1-1+b1foo1
1-1+b1foo1+b1

Thus, overlays should use this approach:
1-1 → 1-1.0foo1

However, regular uploads to stable and oldstable distributions may use
the same signalization ("+") as binNMUs, so:
1-1+deb1u1 < 1-1.0foo1

Therefore, please use a higher version for these uploads, such as:
1-1 → 1-1.0+deb1u1

smime.p7s
Description: S/MIME cryptographic signature

Bug#966371: project: Higher version for uploads to stable and oldstable distributions

[Javier Serrano Polo]

Package: project
Severity: wishlist

For those who care about Debian derivatives:

A derivative may be deployed as an overlay rather than a full archive.
Modifications from the derivative live together with originals from
Debian, but modifications must have a higher version.

Full archives use this approach to increase the version:
1-1 → 1-1foo1

This does not work with overlays because of binNMUs:
1-1+b1 > 1-1foo1
1-1+b1 > 1-1foo1+b1

A binNMU may be unnecessary in the derivative. Also, these versions are
disruptive:
1-1+b1foo1
1-1+b1foo1+b1

Thus, overlays should use this approach:
1-1 → 1-1.0foo1

However, regular uploads to stable and oldstable distributions may use
the same signalization ("+") as binNMUs, so:
1-1+deb1u1 < 1-1.0foo1

Therefore, please use a higher version for these uploads, such as:
1-1 → 1-1.0+deb1u1

smime.p7s
Description: S/MIME cryptographic signature

Bug#966357: security.debian.org: Higher version for security updates

[Javier Serrano Polo]

Package: security.debian.org
Severity: wishlist

For those who care about Debian derivatives:

A derivative may be deployed as an overlay rather than a full archive.
Modifications from the derivative live together with originals from
Debian, but modifications must have a higher version.

Full archives use this approach to increase the version:
1-1 → 1-1foo1

This does not work with overlays because of binNMUs:
1-1+b1 > 1-1foo1
1-1+b1 > 1-1foo1+b1

A binNMU may be unnecessary in the derivative. Also, these versions are
disruptive:
1-1+b1foo1
1-1+b1foo1+b1

Thus, overlays should use this approach:
1-1 → 1-1.0foo1

However, security updates may use the same signalization ("+") as
binNMUs, so:
1-1+deb1u1 < 1-1.0foo1

Therefore, please use a higher version for security updates, such as:
1-1 → 1-1.0+deb1u1

smime.p7s
Description: S/MIME cryptographic signature

Bug#947672: lists.debian.org: Javier Serrano Polo is banned

[Javier Serrano Polo]

Empty words from a politician.

smime.p7s
Description: S/MIME cryptographic signature

Bug#947672: lists.debian.org: Javier Serrano Polo is banned

[Javier Serrano Polo]

Package: lists.debian.org
Severity: wishlist

This user is permanently banned from all lists. Facts start at:
https://lists.debian.org/debian-user-catalan/2013/12/msg00034.html

To those less gifted in computer science: I am Javier Serrano Polo.

To those third-person speech impaired: I am this user.

smime.p7s
Description: S/MIME cryptographic signature

Bug#946576: Mention the word "QR" in the one-line descriptions

[Javier Serrano Polo]

El dc 11 de 12 de 2019 a les 14:25 +0800, 積丹尼 Dan Jacobson va escriure:
> Now that QR codes are becoming more and more important,

ZBar is not only about QR codes.

> Else the user might not even know he has a QR code reader already
> installed, or downloadable.

There are better ways to achieve this.

smime.p7s
Description: S/MIME cryptographic signature

Bug#900451: fenix: please upload pending changes from git, or remove from Debian

[Javier Serrano Polo]

On Wed, 30 May 2018 23:31:40 +0100 Simon McVittie 
wrote:
> src:fenix has had pending changes in git since 2015 which have
> not been uploaded.

On 2019-02-13, fenix 0.92a.dfsg1-12 was accepted into unstable. Please
close the report if you feel all significant issues have been solved.

> I can't help questioning whether a project that still isn't 64-bit
> clean is suitable for a stable release in 2018.

Debian's structural policies may be the fault.

smime.p7s
Description: S/MIME cryptographic signature

Bug#888073: glibc: Support amd64 systems without /lib64

[Javier Serrano Polo]

El dl 16 de 09 de 2019 a les 22:53 +0200, Samuel Thibault va escriure:
> How can it start without its interpreter in /lib64?

This is explained in the report. It uses an "ugly solution" that
happens to be the only way for a regular user to override interpreters,
as far as I know.

> What does
> ldd ./true print?

linux-vdso.so.1 (0x7ffddd5a2000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f8c935f4000)
/lib64/ld-linux-x86-64.so.2 => 
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 (0x7f8c93b9a000)

smime.p7s
Description: S/MIME cryptographic signature

Bug#888073: glibc: Support amd64 systems without /lib64

[Javier Serrano Polo]

El dv 26 de 01 de 2018 a les 19:18 +0100, Samuel Thibault va escriure:
> Can you run the attached program?

Yes, I can. It looks like the program is true from GNU coreutils 8.28.

smime.p7s
Description: S/MIME cryptographic signature

Bug#925771: lmms: ftbfs with GCC-9

[Javier Serrano Polo]

On Wed, 27 Mar 2019 19:46:58 + Matthias Klose 
wrote:
> /<>/plugins/LadspaEffect/calf/src/calf/giface.h:458:15: error: 
> 'memset' used with length equal to number of elements without multiplication 
> by element size [-Werror=memset-elt-size]
>   458 | memset(ins, 0, sizeof(ins));
>   | ~~^

Compiler is wrong.

smime.p7s
Description: S/MIME cryptographic signature

Bug#762209: /usr/bin/zbarcam: zbarcam crashes immediately

[Javier Serrano Polo]

I have tested zbarcam from future version 0.21.1. It works. Uploading
the new release should close this report.

smime.p7s
Description: S/MIME cryptographic signature

Bug#762114: monkeysign: monkeyscan fails to start with IndexError: list index out of range

[Javier Serrano Polo]

I have tested zbarcam from future version 0.21.1. It works without
warnings. Uploading the new release should close this report.

smime.p7s
Description: S/MIME cryptographic signature

Bug#920393: lmms: Find Wine 4 headers

[Javier Serrano Polo]

Source: lmms
Version: 1.1.3-8
Severity: wishlist
Tags: patch

Wine headers' location has changed in version 4.

This patch fixes the build for i386.Description: Find Wine 4 headers
 Wine headers' location has changed in version 4.
 .
 Fixed upstream in 1.2.0.
Author: Javier Serrano Polo 

Index: lmms-1.1.3/cmake/modules/FindWine.cmake
===
--- lmms-1.1.3.orig/cmake/modules/FindWine.cmake
+++ lmms-1.1.3/cmake/modules/FindWine.cmake
@@ -7,7 +7,7 @@
 #  WINE_DEFINITIONS - Compiler switches required for using wine
 #
 
-FIND_PATH(WINE_INCLUDE_DIR windows/windows.h PATH_SUFFIXES wine)
+FIND_PATH(WINE_INCLUDE_DIR windows/windows.h PATH_SUFFIXES wine wine/wine)
 FIND_LIBRARY(WINE_LIBRARY NAMES wine PATH_SUFFIXES wine)
 FIND_PROGRAM(WINE_CXX NAMES wineg++)
 


smime.p7s
Description: S/MIME cryptographic signature

Bug#918242: Take over lmms maintanenace

[Javier Serrano Polo]

El dg 20 de 01 de 2019 a les 13:20 +0100, Ross Gammon va escriure:
> Would you like me to remove you from the uploaders list?

Do as you wish, I do not have upload permission.

smime.p7s
Description: S/MIME cryptographic signature

Bug#918242: Lmms Review

[Javier Serrano Polo]

You seem to know what you want. Do you want to take over maintenance?
Go ahead.

smime.p7s
Description: S/MIME cryptographic signature

Bug#918242: ITS: lmms

[Javier Serrano Polo]

El dv 04 de 01 de 2019 a les 17:57 +0100, Ross Gammon va escriure:
> And he has been recently adding information to some of the bugs,
> including
> asking for help to upload something.

Indeed, I am still waiting. Boyuan Yang offered to sponsor too. I am
fine if you do the upload.

Next upstream version, namely 1.2.0, is not ready.

> I am wondering if it would be a good idea to move lmms into the
> Debian
> Multimedia team where I could help with the maintenance.

This is for Debian Edu developers to decide.

smime.p7s
Description: S/MIME cryptographic signature

Bug#897806: lmms: ftbfs with GCC-8

[Javier Serrano Polo]

El dl 24 de 12 de 2018 a les 11:42 +0800, Boyuan Yang va escriure:
> Could you provide a reference to it, especially an URL for the source
> package?

Request is at
https://alioth-lists.debian.net/pipermail/debian-edu-pkg-team/Week-of-Mon-20181203/002400.html

smime.p7s
Description: S/MIME cryptographic signature

Bug#897806: lmms: ftbfs with GCC-8

[Javier Serrano Polo]

I asked for an upload two weeks ago.

smime.p7s
Description: S/MIME cryptographic signature

Bug#910899: zbar: SQ code support

[Javier Serrano Polo]

El dv 19 de 10 de 2018 a les 00:57 +0200, Bernd Zeimetz va escriure:
> That is NOT an upstream project, that is just the packaging of zbar.

Nevertheless, further discussion should be in GitHub.[2] We should be
in coordination if you accept this new upstream source.

--
[2] https://github.com/jasp00/zbar

smime.p7s
Description: S/MIME cryptographic signature

Bug#910899: zbar: SQ code support

[Javier Serrano Polo]

El ds 13 de 10 de 2018 a les 02:40 +0200, Javier Serrano Polo va
escriure:
> Is it fine if I upload the project to GitHub?

Bernd did already.[1] Further discussion should be in GitHub.

--
[1] https://github.com/bzed/pkg-zbar

smime.p7s
Description: S/MIME cryptographic signature

Bug#893852: lmms: Please package new version and migrate to Qt5

[Javier Serrano Polo]

This report is premature.

smime.p7s
Description: S/MIME cryptographic signature

Bug#870473: calf-ladspa: Conflicts with calf-plugins in ardour

[Javier Serrano Polo]

I fail to see how this is a bug from LMMS and not from Ardour.

smime.p7s
Description: S/MIME cryptographic signature

Bug#875038: [lmms] Future Qt4 removal from Buster

[Javier Serrano Polo]

On Fri, 23 Mar 2018 18:23:51 +0800 Boyuan Yang <073p...@gmail.com>
wrote:
> lmms 1.2.0 is on its way.

I will not package a candidate version unless this bug becomes serious.
Efforts should be directed in helping upstream to release a stable
version.

smime.p7s
Description: S/MIME cryptographic signature

Bug#889042: lintian: Do not use dot as a separator in build profile names

[Javier Serrano Polo]

El ds 13 de 10 de 2018 a les 08:52 +0100, Chris Lamb va escriure:
> I still do not understand your unnecessary antagonism towards me (or
> anyone) here,

I will not explain side issues here because this report is meant for
lintian.

smime.p7s
Description: S/MIME cryptographic signature

Bug#897806: lmms: ftbfs with GCC-8

[Javier Serrano Polo]

El ds 13 de 10 de 2018 a les 11:14 +, Holger Levsen va escriure:
> why don't you attach your fix to this bug?

Because I am the lazy maintainer.

smime.p7s
Description: S/MIME cryptographic signature

Bug#910899: zbar: SQ code support

[Javier Serrano Polo]

El ds 13 de 10 de 2018 a les 02:16 +0200, Bernd Zeimetz va escriure:
> Debian is not the place where upstream
> development happens.

My offer to SourceForge did not get through.

> Best would be if somebody would fork it and start to work on it
> again,

Is it fine if I upload the project to GitHub? I cannot become an active
upstream, but I can watch over future efforts.

smime.p7s
Description: S/MIME cryptographic signature

Bug#889042: lintian: Do not use dot as a separator in build profile names

[Javier Serrano Polo]

El dv 13 de 07 de 2018 a les 10:18 +0100, Chris Lamb va escriure:
> > I do my job. Your position regarding humankind is
> > established already.
> 
> Sorry, I don't understand your response - can you elaborate?

Why? No one wants to hear it. So, let me go back to work.

smime.p7s
Description: S/MIME cryptographic signature

Bug#910899: zbar: SQ code support

[Javier Serrano Polo]

Source: zbar
Version: 0.10+doc-10.1
Severity: wishlist

I would like to offer the integration of SQ code support. This
technology is somewhat usable now.

smime.p7s
Description: S/MIME cryptographic signature

Bug#897806: lmms: ftbfs with GCC-8

[Javier Serrano Polo]

Someone should give me access to the repository, user jasp-guest.

smime.p7s
Description: S/MIME cryptographic signature

Bug#888073: glibc: Support amd64 systems without /lib64

[Javier Serrano Polo]

El dc 24 de 01 de 2018 a les 23:18 +0100, Aurelien Jarno va escriure:
> Just right a new ABI document for
> the x86-64 CPU and create a new architecture from it. Then this
> architecture can be supported by Debian.

Someone thinks that was a serious reply, so...

I would like to write an ABI document for the x86-64 CPU and create a
new architecture from it. Obviously, this is not as simple as writing a
document in my computer or starting a repository on GitHub. Could you
explain what this creation process actually means?

Thank you.

smime.p7s
Description: S/MIME cryptographic signature

Bug#897965: drascula: Clarify license and authors' intention

[Javier Serrano Polo]

On Sat, 4 Aug 2018 03:27:02 +0800 Markus Koschany 
wrote:
> Closing as not a bug.

Whatever you say.

However, there has been plenty of time for authors to respond. We can
conclude that authors agree with section 3 of the license being
ineffective.

You may want to close #897965 too.

smime.p7s
Description: S/MIME cryptographic signature

Bug#904725: firefox: Add-ons that open windows can get an empty window

[Javier Serrano Polo]

Package: firefox
Version: 61.0-1
Severity: wishlist
Tags: patch
Control: forwarded -1 https://bugzilla.mozilla.org/1408446

This patch works with Firefox 61. It is essentially the same as the one
for Firefox 60 in upstream report.Index: firefox-61.0/browser/components/extensions/parent/ext-windows.js
===
--- firefox-61.0.orig/browser/components/extensions/parent/ext-windows.js
+++ firefox-61.0/browser/components/extensions/parent/ext-windows.js
@@ -225,6 +225,10 @@ this.windows = class extends ExtensionAP
 if (createData.titlePreface !== null) {
   win.setTitlePreface(createData.titlePreface);
 }
+// Do a dummy resize (bug 1408446)
+window.addEventListener("DOMContentLoaded", () => {
+  window.resizeTo(window.outerWidth, window.outerHeight);
+});
 return win.convert({populate: true});
   });
 },
Index: firefox-61.0/widget/gtk/nsWindow.cpp
===
--- firefox-61.0.orig/widget/gtk/nsWindow.cpp
+++ firefox-61.0/widget/gtk/nsWindow.cpp
@@ -1112,6 +1112,22 @@ nsWindow::Show(bool aState)
 NativeShow(aState);
 }
 
+// Add-ons may open windows that do not display their contents (bug 1408446), so
+// invalidate the related layer when doing a repaint
+static void
+InvalidateFirstChildLayer(LayerManager* manager)
+{
+Layer* root = manager->GetRoot();
+if (root) {
+Layer* layer = root->GetFirstChild();
+if (layer) {
+PaintedLayer *pLayer = layer->AsPaintedLayer();
+if (pLayer)
+pLayer->InvalidateWholeLayer();
+}
+}
+}
+
 void
 nsWindow::Resize(double aWidth, double aHeight, bool aRepaint)
 {
@@ -1131,6 +1147,9 @@ nsWindow::Resize(double aWidth, double a
 
 NativeResize();
 
+if (aRepaint)
+InvalidateFirstChildLayer(GetLayerManager());
+
 NotifyRollupGeometryChange();
 
 // send a resize notification if this is a toplevel
@@ -1159,6 +1178,9 @@ nsWindow::Resize(double aX, double aY, d
 
 NativeMoveResize();
 
+if (aRepaint)
+InvalidateFirstChildLayer(GetLayerManager());
+
 NotifyRollupGeometryChange();
 
 if (mIsTopLevel || mListenForResizes) {


smime.p7s
Description: S/MIME cryptographic signature

Bug#831104: xevil: FTBFS with GCC 6: stl_algobase.h:243:56: error: macro "min" passed 3 arguments, but takes just 2

[Javier Serrano Polo]

Control: tags -1 patch

Game works on stretch.Index: xevil-2.02r2/cmn/game.cpp
===
--- xevil-2.02r2.orig/cmn/game.cpp
+++ xevil-2.02r2/cmn/game.cpp
@@ -577,7 +577,7 @@ void GameObjects::level_reset(const Dim
   assert(maximums[weapons[n]->classId] == 0);
 
   // Don't allow objectWorldPercent values that are too small.
-  float objWPercent = (float)max(weapons[n]->objectWorldPercent,
+  float objWPercent = (float)MAX(weapons[n]->objectWorldPercent,
 			  OBJECT_WORLD_PERCENT_MIN);
 
   maximums[weapons[n]->classId] = (int)ceil(areaFactor * objWPercent);
@@ -590,7 +590,7 @@ void GameObjects::level_reset(const Dim
 for (n = 0; n < oItemsNum; n++) {
   // Check not already set.
   assert(maximums[oItems[n]->classId] == 0);
-  float objWPercent = (float)max(oItems[n]->objectWorldPercent,
+  float objWPercent = (float)MAX(oItems[n]->objectWorldPercent,
 			  OBJECT_WORLD_PERCENT_MIN);
 
   maximums[oItems[n]->classId] = (int)ceil(areaFactor * objWPercent);
Index: xevil-2.02r2/cmn/utils.h
===
--- xevil-2.02r2.orig/cmn/utils.h
+++ xevil-2.02r2/cmn/utils.h
@@ -98,11 +98,11 @@ extern "C" {
 #define MSEC_PER_CLOCK (1.0e3 / CLOCKS_PER_SEC) 
 #endif
 
-#ifndef max
-#define max(a,b)   (ab ? b : a)
+#ifndef MIN
+#define MIN(a,b)   (a>b ? b : a)
 #endif
 
 #if X11


smime.p7s
Description: S/MIME cryptographic signature

Bug#889042: lintian: Do not use dot as a separator in build profile names

[Javier Serrano Polo]

I can see through your polite answer.

I do my job. Your position regarding humankind is established already.

smime.p7s
Description: S/MIME cryptographic signature

Bug#889042: lintian: Do not use dot as a separator in build profile names

[Javier Serrano Polo]

Control: tags -1 patch

Fix works on 2.5.50.4. This patch is for 2.5.92.Bug-Debian: https://bugs.debian.org/889042

Index: lintian-2.5.92/checks/control-file.desc
===
--- lintian-2.5.92.orig/checks/control-file.desc
+++ lintian-2.5.92/checks/control-file.desc
@@ -285,7 +285,7 @@ Info: The restriction formula in Build-P
  "noudeb",
  "stage1",
  "stage2"
- and "pkg.srcpkg.anything".
+ and "pkg/srcpkg/anything".
 Ref: https://wiki.debian.org/BuildProfileSpec#Registered_profile_names
 
 Tag: multiline-architecture-field
Index: lintian-2.5.92/checks/control-file.pm
===
--- lintian-2.5.92.orig/checks/control-file.pm
+++ lintian-2.5.92/checks/control-file.pm
@@ -364,7 +364,7 @@ sub run {
 tag 'invalid-profile-name-in-build-profiles-field',
   $profile, $bin
   unless $KNOWN_BUILD_PROFILES->known($profile)
-  or $profile =~ /^pkg\.[a-z0-9][a-z0-9+.-]+\../;
+  or $profile =~ /^pkg\/[a-z0-9][a-z0-9+.-]+\/./;
 }
 }
 }
Index: lintian-2.5.92/checks/fields.desc
===
--- lintian-2.5.92.orig/checks/fields.desc
+++ lintian-2.5.92/checks/fields.desc
@@ -669,7 +669,7 @@ Info: The restriction formula in the sou
  "noudeb",
  "stage1",
  "stage2"
- and "pkg.srcpkg.anything".
+ and "pkg/srcpkg/anything".
 Ref: https://wiki.debian.org/BuildProfileSpec#Registered_profile_names
 
 Tag: build-depends-on-build-essential-package-without-using-version
Index: lintian-2.5.92/checks/fields.pm
===
--- lintian-2.5.92.orig/checks/fields.pm
+++ lintian-2.5.92/checks/fields.pm
@@ -1097,7 +1097,7 @@ sub run {
 tag 'invalid-profile-name-in-source-relation',
   "$prof [$field: $part_d_orig]"
   unless $KNOWN_BUILD_PROFILES->known($prof)
-  or $prof =~ /^pkg\.[a-z0-9][a-z0-9+.-]+\../;
+  or $prof =~ /^pkg\/[a-z0-9][a-z0-9+.-]+\/./;
 }
 }
 
Index: lintian-2.5.92/t/tests/fields-build-profiles-general/debian/debian/control.in
===
--- lintian-2.5.92.orig/t/tests/fields-build-profiles-general/debian/debian/control.in
+++ lintian-2.5.92/t/tests/fields-build-profiles-general/debian/debian/control.in
@@ -5,7 +5,7 @@ Maintainer: {$author}
 Standards-Version: {$standards_version}
 Build-Depends: {$build_depends},
  big , bpfail1 ,
- bpcomplicated   
+ bpcomplicated   
 Rules-Requires-Root: no
 
 Package: {$source}-wrong-syntax
@@ -23,7 +23,7 @@ Description: {$description} (wrong synta
 Package: {$source}-unknown-profile
 Architecture: {$architecture}
 Depends: $\{shlibs:Depends\}, $\{misc:Depends\}
-Build-Profiles:   
+Build-Profiles:   
 Description: {$description} (unknown profile)
  Check for unknown profile names
  .


smime.p7s
Description: S/MIME cryptographic signature

Bug#852494: wine: Add libwine.so and libwine.so.1 alternatives

[Javier Serrano Polo]

El ds 19 de 05 de 2018 a les 23:39 +0200, Jens Reyer va escriure:
> I definitely want the well-established system command
> "update-alternatives" to be used.

What are the requirements?
"update-alternatives --config wine" must work if wine or wine-
development are installed. Only this one?

smime.p7s
Description: S/MIME cryptographic signature

Bug#897961: drascula: Clarify license and authors' intention

[Javier Serrano Polo]

Dear Alcachofa Soft staff,

About the license for Drascula, section 3 states:

You may not charge a fee for the game itself.

But section 2 says:

and may distribute it in aggregate as part of a larger &
possibly commercial software distribution

Could you confirm that, when this license was suggested to you, you did
know this is a poor wording license that effectively allows to charge a
fee for the game itself?

Thank you.

smime.p7s
Description: S/MIME cryptographic signature

Bug#897965: flight-of-the-amazon-queen: Clarify license and authors' intention

[Javier Serrano Polo]

Dear John Passfield and Steven Stamatiadis,

About the license for Flight of the Amazon Queen, section 3 states:

You may not charge a fee for the game itself.

But section 2 says:

and may distribute it in aggregate as part of a larger &
possibly commercial software distribution

Could you confirm that, when this license was suggested to you, you did
know this is a poor wording license that effectively allows to charge a
fee for the game itself?

Thank you.

smime.p7s
Description: S/MIME cryptographic signature

Bug#897965: flight-of-the-amazon-queen: Clarify license and authors' intention

[Javier Serrano Polo]

Source: flight-of-the-amazon-queen
Version: 1.0.0-8
Severity: wishlist

Like in https://bugs.debian.org/854679, this report determines whether
authors agree with section 3 of the license being ineffective. In the
absence of contradictory evidence, they do.

smime.p7s
Description: S/MIME cryptographic signature

Bug#897961: drascula: Clarify license and authors' intention

[Javier Serrano Polo]

Source: drascula
Version: 1.0+ds2-3
Severity: wishlist

Like in https://bugs.debian.org/854679, this report determines whether
authors agree with section 3 of the license being ineffective. In the
absence of contradictory evidence, they do.

smime.p7s
Description: S/MIME cryptographic signature

Bug#890556: aptitude: Add build profile to skip documentation packages

[Javier Serrano Polo]

El dv 16 de 03 de 2018 a les 14:42 +0100, Manuel A. Fernandez Montecelo
va escriure:
> Precisely in the latest versions I moved stuff to Build-Depends-Indep,
> so you can just build the arch part, without the doc.

aptitude Depends: aptitude-common (= ${source:Version})
aptitude-common is Architecture: all.
If you build aptitude-common, you will build documentation packages too.

> What you're trying to achive?

Use modified software and reuse as many Debian packages as possible.


smime.p7s
Description: S/MIME cryptographic signature

Bug#854679: Clarify license for Beneath a Steel Sky

[Javier Serrano Polo]

X-Debbugs-CC: en...@scummvm.org

El dg 11 de 03 de 2018 a les 04:13 +0800, James 'Ender' Brown va
escriure:
> this issue has been discussed in detail now.

Yet you do not address the problem. Let me write it in another way. Were
the copyright holders of Flight of the Amazon Queen, Lure of the
Temptress, and Drascula aware that "It was pretty obvious [...] that the
license was weak, and there are certainly ways to break the spirit
legally"?

> I deny the license is 'deceptive'.

So there are no known ways to break the spirit legally?

> *You* (the user) have the freedom to act immorally, find a loophole
> and cheat, to intentionally ignore
> the express intent of the license.

Certainly, and the user may have their reasons, but the license allows
that and the designers knew it.

> All parties who actually have any invested stake in the license were
> and are still currently
> satisfied.

As long as authors know that "there are certainly ways to break the
spirit legally", it is fine.

Did they agree to release their games under this license knowing that
individual resale is possible? If they were not aware, would they still
accept this license now? Debian can sell the games, is it that terrible
that users sell the games individually?


smime.p7s
Description: S/MIME cryptographic signature

Bug#854679: Clarify license for Beneath a Steel Sky

[Javier Serrano Polo]

X-Debbugs-CC: en...@scummvm.org

El ds 10 de 03 de 2018 a les 19:54 +0100, Fabian Greffrath va escriure:
> Please don't do that for other people's addresses.

X-Debbugs-CC is meant for this purpose. If James says he is receiving
the messages through other paths, I will stop including his address.

> Since when do we need an extra confirmation from copyright holders that
> they meant the license exactly as it was written?

In this case, authors were presented a license that promises "You may
not charge a fee for the game itself", but fails to enforce it by
design. Revolution knew that, so they should not be surprised if the
game is being sold separately. However, it is not clear that other
authors were aware.

Is this a problem for Debian? Is Debian involved in any way in this
possible deception? Who assisted in the license design? Who was the
beneficiary for this license acceptance?


smime.p7s
Description: S/MIME cryptographic signature

Bug#854679: Clarify license for Beneath a Steel Sky

[Javier Serrano Polo]

X-Debbugs-CC: en...@scummvm.org

El ds 10 de 03 de 2018 a les 18:07 +, Simon McVittie va escriure:
> which is something that the copyright holders specifically didn't want!

> Also, intent matters in interpreting licensing, and if this ever
> went to court, it seems fairly plausible that a court would decide that
> this trick is stupid and the redistribution was copyright infringement.

As you can see, James, my points have been repeated. Please confirm that
game authors were not deceived by section 3 of the license.


smime.p7s
Description: S/MIME cryptographic signature

Bug#854679: Clarify license for Beneath a Steel Sky

[Javier Serrano Polo]

Control: tags -1 - wontfix
X-Debbugs-CC: en...@scummvm.org

El dg 11 de 03 de 2018 a les 00:19 +0800, James 'Ender' Brown va
escriure:
> Reading the other BTS bug you linked, my understanding of the DFSG (and the 
> commonly accepted interpretation)
> is the same as Ansgar supplied there:

I understand your interpretation now. When you say "it must be permitted
for Commercial Use" and DFSG #6 says "it may not restrict the program
from being used in a business", I understand a sale is commercial use
and use in a business, whereas you consider a sale is only conveyance.

From that point of view, your license is DFSG-compliant. However, it is
compliant because DFSG #1 renders section 3 ineffective. If you knew it,
why does section 3 exist?

Please confirm that copyright holders of Flight of the Amazon Queen,
Lure of the Temptress, and Drascula were not deceived by section 3.


smime.p7s
Description: S/MIME cryptographic signature

Bug#854679: Clarify license for Beneath a Steel Sky

[Javier Serrano Polo]

El ds 10 de 03 de 2018 a les 05:38 +0800, James 'Ender' Brown va
escriure:
>  I'm not really sure what outcome you are looking for here...

DFSG #6 warrants use in any field of endeavor. The outcome is either
software can be sold, both modified and unmodified, or it is non-free.

> Yes. It was pretty obvious to all parties that the license was "weak,
> and there are certainly ways to break the spirit legally. By design.

I take your word that Revolution was aware. It would help if you could
state the same for Flight of the Amazon Queen, Lure of the Temptress,
and Drascula.

> Without allowing that freedom, we couldn't honor the spirit of the
> DFSG.

DFSG allows to sell individual software, but the spirit of DFSG does not
encourage to break the spirit of licenses.

>   *  "We've decided to trust you and permit re-distribute it
> as freeware"
>   *  ".. oh, but we don't want people to sell the game
> individually for $$$"

This is my concern. You were entrusted with finding a way to effectively
forbid the sale of the game.

> (very very paraphrased) "Looks good, ship it!"

Then you seemed to have found the solution. Section 3 is clear: you may
not charge a fee for the game itself.

> To be perfectly honest - Debian-legal provided more input on the
> wording than Revolution.

Let me make this clear: you did nothing wrong by writing a custom
license; you asked for help, which is sensible. I do not find related
discussions in debian-legal, so I cannot judge what they told you.

> This is the same sort of exception already implemented in other
> DFSG-approved licenses,

They suffer from the same problem; Artistic License 1.0 is not
DFSG-compliant.[1] Propagating the error was not the right way. Again,
you asked for help, so I do not blame you.

>  * Honor Revolutions request to limit individual resale
>  * Satisfy the "fields of endeavor" clause of the DFSG to encourage
> Linux Distros able to ship

These are incompatible, limiting individual resale breaks the "fields of
endeavor" clause. Anyway, Debian can ship games under the non-free
component.

Debian accepts your license because section 3 is ineffective by using
tricks. If you know it, then you deceive by writing a non-binding
preamble describing author's intent and a binding section that you
present as enforceable. Conflict arises when a Debian user believes
section 3 does not really apply, but author believes it does.

I thank engine developers and game creators for all your efforts. You
provide culture and some freedoms. Now I ask for the right to use for
any commercial purpose.

Although this report is to clarify a license, I would like to convince
authors that individual resale is not a problem. I defend "scammy"
behavior because of these reasons:

 1. Selling unmodified games encourages conveyance to users unaware
of these games.
 2. Selling free games, modified or not, propagates free software to
users that otherwise are presented with non-free software.
 3. Selling modified versions allows to reach more users. E.g.,
"Bajo un cielo de acero" could be easier to sell in South
America.
 4. It demonstrates that anyone can make a living out of free
software. This reason may not appeal to authors, but it does to
free software defenders.

Furthermore, while discouraging "scammy" behavior, you also discourage
other possibilities which are more likely to happen if the effort can be
paid. Examples are full internationalization, source restoration, and
game editor.

In short, either copyright holders effectively allow to charge a fee for
the game itself or they do not. According to your answer, they do.

--
[1] https://bugs.debian.org/854825


smime.p7s
Description: S/MIME cryptographic signature

Bug#835211: beneath-a-steel-sky: Enable subtitles by default

[Javier Serrano Polo]

On Tue, 23 Aug 2016 16:35:00 +0200 Nils Dagsson Moskopp  wrote: 
> scummvm has a “-n” option to enable subtitles.
> I think those should be enabled by default.

This should be tackled from accessibility preferences. Please discuss
the matter in the proper list.


smime.p7s
Description: S/MIME cryptographic signature

Bug#854679: Clarify license for Beneath a Steel Sky

[Javier Serrano Polo]

Dear Revolution staff,

About the license for Beneath a Steel Sky, section 3 states:

You may not charge a fee for the game itself.

But section 2 says:

and may distribute it in aggregate as part of a larger &
possibly commercial software distribution

Could you confirm that, when this license was suggested to you, you did
know this is a poor wording license that effectively allows to charge a
fee for the game itself?

Thank you.


smime.p7s
Description: S/MIME cryptographic signature

Bug#853527: lmms: ftbfs with GCC-7

[Javier Serrano Polo]

X-Debbugs-CC: 073p...@gmail.com

El dv 09 de 03 de 2018 a les 19:10 +0800, Boyuan Yang va escriure:
> Are
> you going to fix the problem soon?

I cannot promise anything.

> If not, is it okay if someone prepares an NMU and upload the fix?

If master version still works, do not wait for me either.


smime.p7s
Description: S/MIME cryptographic signature

Bug#814156: Extra-Source-Only field in Sources index

[Javier Serrano Polo]

X-Debbugs-CC: a...@debian.org, ballo...@debian.org, r...@debian.org

On Mon, 08 Feb 2016 20:49:18 +0100 Ansgar Burchardt  wrote:
> the source is only
> there to fulfill the "provide the complete source" requirement.

apt-get downloads these new versions by default. These sources are part
of the stable release index. Are these sources officially supported?


smime.p7s
Description: S/MIME cryptographic signature

Bug#832564: debhelper: udeb packages should not be processed with noudeb

[Javier Serrano Polo]

On Wed, 27 Jul 2016 17:38:05 +0200 Helmut Grohne  wrote:
> Just
> adding those headers is more explicit and much harder to get wrong.

It is more explicit and redundant. If you do not add those headers, you
do not get wrong at all.

> It simply isn't worth the maintenance cost.

You described development cost, not maintenance one.

Adding Build-Profiles fields is not an option because maintainers are
reluctant to support build profiles; e.g.,
https://bugs.debian.org/890834 .

I know it is not worth your effort since you do not use noudeb and
similar build profiles; it is worth mine. It is far easier for me to
maintain this code than to add Build-Profiles fields to all packages.


smime.p7s
Description: S/MIME cryptographic signature

Bug#890834: gtk+2.0: Add build profiles to skip flavors and packages

[Javier Serrano Polo]

El dl 19 de 02 de 2018 a les 17:41 +, Simon McVittie va escriure:
> What goal(s) are you aiming to achieve by requesting this?

This is a mainstreaming request. Disk usage and build time decrease when
I apply this build profiles.

> The namespace for source-package-defined build profiles is
> pkg.some-source.foo, not pkg/some-source/foo.

See https://bugs.debian.org/889042 .

> >   * pkg/gtk+2.0/nostatic: Skip static flavor and packages, the
> > latter being libgtk$(APIVER)-static-dev and libgail-static-dev.
> 
> Those packages don't exist. If you are asking the GTK maintainers to
> split them out, that's an intrusive change.

Nevertheless, it is a wishlist request. I have done that change, you may
want to do it too. Users that need static libraries build-depend on the
new packages.


smime.p7s
Description: S/MIME cryptographic signature

Bug#890834: gtk+2.0: Add build profiles to skip flavors and packages

[Javier Serrano Polo]

Source: gtk+2.0
Version: 2.24.32-1
Severity: wishlist

Please consider adding the following build profiles:

  * noudeb: Skip udeb flavor and packages.
  * pkg/gtk+2.0/noexamples: Skip @EXAMPLES_PKG@.
  * pkg/gtk+2.0/nogir: Skip gir1.2-gtk-2.0.
  * pkg/gtk+2.0/nopixbuf: Skip @PIXBUF_PKG@.
  * pkg/gtk+2.0/nostatic: Skip static flavor and packages, the
latter being libgtk$(APIVER)-static-dev and libgail-static-dev.


smime.p7s
Description: S/MIME cryptographic signature

Bug#890556: aptitude: Add build profile to skip documentation packages

[Javier Serrano Polo]

Source: aptitude
Version: 0.8.10-6
Severity: wishlist

Please consider adding a build profile, such as pkg/aptitude/nodoc, to
skip building documentation packages.


smime.p7s
Description: S/MIME cryptographic signature

Bug#890555: aptitude: add apt-get -c functionality (2)

[Javier Serrano Polo]

Source: aptitude
Version: 0.8.10-6
Severity: wishlist

This was requested at https://bugs.debian.org/499204 . The patch in that
report works with version 0.8.7-1. Please consider adding the feature
and tell me if you want me to write related documentation.


smime.p7s
Description: S/MIME cryptographic signature

Bug#890132: glibc: Use built iconvconfig

[Javier Serrano Polo]

El dg 11 de 02 de 2018 a les 13:55 +0100, Aurelien Jarno va escriure:
> There is no need to X-Debbugs-CC everybody. Please stop doing that.

My messages do not reach debian-gl...@lists.debian.org . How do I know
that maintainers receive them? It would not be the first time a
maintainer misses my message because I do not use X-Debbugs-CC.


smime.p7s
Description: S/MIME cryptographic signature

Bug#890138: glibc: Allow to not build Xen packages

[Javier Serrano Polo]

Source: glibc
Version: 2.26-6
Severity: wishlist
X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net, aurel...@aurel32.net, 
sthiba...@debian.org

Please consider adding a pkg/glibc/noxen build profile to skip building
Xen files.


smime.p7s
Description: S/MIME cryptographic signature

Bug#890129: glibc: Support simpler multiarch systems

[Javier Serrano Polo]

X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net, sthiba...@debian.org

El dg 11 de 02 de 2018 a les 13:52 +0100, Aurelien Jarno va escriure:
> Those are not officially supported and might be removed at any moment.

Debian officially supports the main component of stable releases. Are
you going to remove multiarch interpreters from stretch?

Of course you may drop multiarch interpreters. Debian has dropped
support for some ports and machines. If you remove multiarch
interpreters just for the sake of incompatibility, I will provide them.

> As said many times, the program interpreter are part of the ABI.

And there are compatibility measures available.

> It's a
> pitty that there are some conflicts, but such is life.

Such is your choice. I can change and remain compatible, you do not want
to fix the issue because you want it that way.

> please stop opening new bugs or bothering upstreams
> about that.

New proposal, new report. It seems logical to me.


smime.p7s
Description: S/MIME cryptographic signature

Bug#890132: glibc: Use built iconvconfig

[Javier Serrano Polo]

Source: glibc
Version: 2.26-6
Severity: wishlist
X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net, aurel...@aurel32.net, 
sthiba...@debian.org

Please use $(CURDIR)/debian/tmp-libc/usr/sbin/iconvconfig instead
of /usr/sbin/iconvconfig in debian/rules.d/build.mk, since new
iconvconfig may behave differently.


smime.p7s
Description: S/MIME cryptographic signature

Bug#890131: glibc: Do not build-depend on multilib with nobiarch profile

[Javier Serrano Polo]

Source: glibc
Version: 2.26-6
Severity: wishlist
X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net

Please do not build-depend on g++-7-multilib when the nobiarch build
profile is active.


smime.p7s
Description: S/MIME cryptographic signature

Bug#890129: glibc: Support simpler multiarch systems

[Javier Serrano Polo]

Source: glibc
Version: 2.26-6
Severity: wishlist
X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net

One goal of a multiarch system is to make possible to run programs from
any other architecture. ELF executables depend on an interpreter that
should have a unique name; otherwise, loading the executable is
complicated.

Simpler multiarch systems use multiarch interpreter names. These
multiarch interpreters are officially supported in Debian,[1] despite
recent statements from Debian glibc maintainers.

Compatibility with third-party programs relies on the absence of
traditional interpreters because then there is no ambiguity about which
interpreter to invoke. Thus, I propose to support these simpler systems
by putting the traditional interpreters in the package elf-compat-links.

This way, file conflicts are solved; e.g., libc6 conflicts
on /lib/ld.so.1 on mips <-> mipsel. Of course, this may be enabled
through a build profile.

--
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173#c14


smime.p7s
Description: S/MIME cryptographic signature

Bug#889106: Multiarch interpreter names for traditional architectures

[Javier Serrano Polo]

El dv 09 de 02 de 2018 a les 16:03 +0100, Aurelien Jarno va escriure:
> I love the way you use "official" here.

Me too. It is precisely your policy not to include any unnecessary file
because "experience shows that users are very imaginative when you
provide a feature". You have taken steps to insure the existence of
multiarch interpreters and they have landed on stable releases.

> I don't care about compatibility within Debian and derivatives.

I do. Strange statement from a Debian developer.

> I care
> about the compatibility within the whole GNU/Linux ecosystem.

I do too. I even care about compatibility with non-Linux systems.

Give a solution like I do instead of complaining about the past.


smime.p7s
Description: S/MIME cryptographic signature

Bug#853527: lmms: ftbfs with GCC-7

[Javier Serrano Polo]

El dv 09 de 02 de 2018 a les 17:22 +0300, Dmitry Eremin-Solenikov va
escriure:
> Any progress on uploading
> 1.1.3-8 or packaging 1.1.90?

Pending upload.


smime.p7s
Description: S/MIME cryptographic signature

Bug#888073: Multiarch interpreter names for traditional architectures

[Javier Serrano Polo]

El dv 09 de 02 de 2018 a les 15:02 +0100, Aurelien Jarno va escriure:
> The notion of "multiarch interpreter" doesn't exist.

It does exist, but you do not accept it. You are now denying the
official support that exists in Debian.
Use /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 as the program
interpreter and the program will work perfectly in Debian and
derivatives.


smime.p7s
Description: S/MIME cryptographic signature

Bug#889820: debian-policy: 12.5, relaxed requirement for copyright location

[Javier Serrano Polo]

//X-Debbugs-CC:

-doc suffix cannot be used, e.g. acl2-doc. I am going with -doc-minimal
and Outdates, which is softer than Breaks. I will return when support is
ready.


smime.p7s
Description: S/MIME cryptographic signature

Bug#889820: debian-policy: 12.5, relaxed requirement for copyright location

[Javier Serrano Polo]

//X-Debbugs-CC:

El dc 07 de 02 de 2018 a les 22:45 +0100, Javier Serrano Polo va
escriure:
> What about a
> new Outdates field?

Forget Outdates. If there are two possible versions of a documentation
package, it should be possible to install both. That can be done with
different package names. So, the proposal is:

Every package must be accompanied by a verbatim copy of its
copyright information and distribution license in the
file /usr/share/doc/package/copyright
or /usr/share/doc/docpackage/copyright; docpackage is a package
providing source-doc and may not be installed. [...]

[...] and the first package Depends on the second.
Alternatively, /usr/share/doc/package may not exist if the
package Recommends docpackage, which comes from the same source.
[...]


smime.p7s
Description: S/MIME cryptographic signature

Bug#889820: debian-policy: 12.5, relaxed requirement for copyright location

[Javier Serrano Polo]

X-Debbugs-CC: a...@debian.org, ballo...@debian.org, spwhit...@spwhitton.name, 
r...@debian.org

El dc 07 de 02 de 2018 a les 20:01 +0100, Bill Allombert va escriure:
> > Versioned Recommends actually, but does a versioned Recommends make any
> > difference? 
> 
> That is why a versioned Depends: is needed.

A hard dependency on non-functional data makes no sense. What about a
new Outdates field? It would help to warn the user about outdated
documentation.

El dc 07 de 02 de 2018 a les 11:13 -0800, Russ Allbery va escriure:
> Then we can close this bug as unnecessary?  Since the *-doc mechanism is
> already specified.

I cannot make libc6 depend on glibc-doc.

> > I do not think so. Metadata is usually smaller than those files:
> > copyright, changelog, manpages, etc.
> 
> None of which you're addressing here except copyright.

True. What suffix would you use for copyright plus changelog?
-doc-minimal?

> I'm fairly sure about this, but feel free to do an experiment if you
> really want to check the numbers.

What metadata are you thinking of? What is the test you are suggesting?

El dc 07 de 02 de 2018 a les 12:25 -0700, Sean Whitton va escriure:
> Either way, please X-debbugs-CC the list rather than all four of us
> individually.

It would not work.
https://bugs.debian.org/831059


smime.p7s
Description: S/MIME cryptographic signature