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 17:31 +0100, Bill Allombert va escriure:
> ... However  will have to have a versioned Depends: on
> -copyright for exactly the same reason: the copyright
> file might change between versions and we do not want to confuse users
> by allowing them to have an outdated -copyright package.

Versioned Recommends actually, but does a versioned Recommends make any
difference? The user knows there is an updated package with no
dependency problems. On the other hand, when having two versions of the
same package in multiarch (in the future), one of them will not match
the version of source-copyright. Is this a problem?

El dc 07 de 02 de 2018 a les 08:40 -0800, Russ Allbery va escriure:
> Why would you not use the existing *-doc package construction, which seems
> to accomplish exactly the same goal and is already fairly standard
> practice for packages with large documentation directories?

Flexibility: maintainer may want to provide *-doc-minimal, skip
documentation build dependencies, or whatever reason. But *-doc is fine
to me.
 
> The additional metadata required for the extra packages is going to
> eliminate any possible gain you would get here.

I do not think so. Metadata is usually smaller than those files:
copyright, changelog, manpages, etc.

> >  2. It helps to solve the Multi-Arch file refcounting problem.
> 
> We've already solved that by not allowing different versions of multi-arch
> packages to be simultaneously installed.

That is not a solution. The problems are described in the
TimeTravelFixes page.

> To relax that constraint would
> require dealing with far more than just the copyright file, and would need
> a more comprehensive solution.

Of course, I did not claim to fix the problem, only that it helps.

El dc 07 de 02 de 2018 a les 09:57 -0700, Sean Whitton va escriure:
> > Do you receive my messages from the list?
> > https://lists.debian.org/debian-policy/2018/02/threads.html
> 
> Yes.

I do not see them in the list. Are you sure? Did you check the mail
headers?

> This does not explain why it is problematic to have the (small)
> copyright files additionally installed.

To the user, it is not problematic because of disk usage, but there is
no problem switching Depends to Recommends either.

> > Yes, and package lists get bigger, I know. This scalability problem
> > should be discussed elsewhere.
> 
> Why elsewhere?  Policy would be the thing imposing the problem!

Does policy impose a limit on the number of packages Debian can host?


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 08:56 -0700, Sean Whitton va escriure:
> > X-Debbugs-CC:
> 
> This isn't needed.

Do you receive my messages from the list?
https://lists.debian.org/debian-policy/2018/02/threads.html

> >  1. Option to not install documentation files.
> 
> Could you expand on why this is worth doing?

Many users do not install documentation and do not care about copyright
and changelog files. I was going to propose this with Depends
source-copyright, but Recommends is technically more accurate and I see
no legal issues.

> I suspect it increases dak's workload, though, due to all the extra
> binary packages.

Yes, and package lists get bigger, I know. This scalability problem
should be discussed elsewhere.

> >  2. It helps to solve the Multi-Arch file refcounting problem.
> 
> I'm not aware of this; could you refer me to a description of the
> problem?

https://wiki.debian.org/Teams/Dpkg/TimeTravelFixes#Multi-Arch_file_refcounting


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 14:32 +0100, Bill Allombert va escriure:
> Let it be clear: this alternative is to ship an optional, extra arch-all
> package named -copyright that includes the copyright
> files and only the copyright files ?

The arch-all package Provides source-copyright. Most likely, it ships
a /usr/share/doc/source-copyright symlink to the package name, which is
source-doc, source-doc-minimal or an arbitrary name. The package
guarantees the copyright file and usually includes the changelogs,
manpages, examples, and more documentation. It does not contain
functional data.


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

Package: debian-policy
Version: 4.1.3.0
Severity: wishlist
X-Debbugs-CC: a...@debian.org, ballo...@debian.org, spwhit...@spwhitton.name, 
r...@debian.org

Copyright information, like changelogs and manuals, is not technically
required by software.

I propose this enhancement to section 12.5:

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/source-copyright/copyright; the latter may not
be installed. [...]

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

Satisfied needs:

 1. Option to not install documentation files.

Additional benefits:

 1. Putting this information in a separate architecture-independent
package reduces repository disk usage.
 2. It helps to solve the Multi-Arch file refcounting problem.


smime.p7s
Description: S/MIME cryptographic signature

Bug#889106: Multiarch interpreter names for traditional architectures

[Javier Serrano Polo]

Debian glibc officially supports multiarch interpreter names, even for
traditional architectures. For instance, the multiarch interpreter for
x86_64 is /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 . There is
consensus among Debian-based distros.


smime.p7s
Description: S/MIME cryptographic signature

Bug#614708: libc6 could just Recommends libc-bin

[Javier Serrano Polo]

libc6 does no longer depend on libc-bin. This bug is fixed.


smime.p7s
Description: S/MIME cryptographic signature

Bug#889106: gcc-6: Support simpler multiarch systems

[Javier Serrano Polo]

Please use the wontfix tag if appropriate.

> >  Missatge reenviat 
> > De: Bastian Blank 

> > You have been told that changing the interpreter.

What have I been told?

> > Closing as even upstream thinks this is bullshit.

Upstream is not so sure now.[2]

What is the position of Matthias Klose?

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


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 02 de 02 de 2018 a les 06:50 +0100, Helmut Grohne va escriure:
> A
> different solution (without requiring any package to change) would be to
> forbid dots in $anything.

This would break profiles with dots in $anything and it is less
flexible.

> Yes, Javier asked me on irc, but I didn't ack the change.

[11:33]  guillem: feel free to fix it
[11:33]  I don't think it is worth the effort
[11:33]  or rather *my* effort ;)

> So I state that:
> 1. I don't think this is worth fixing.

But you do not oppose.

> 2. There is an alternative and simpler fix available. => No consensus.

Replied above.

> 3. The idea of changing the separator is not completely insane, but the
>cost of performing it is very high.

sed -e "s#pkg.$sourcepackage.#pkg/$sourcepackage/#g"

> 4. You don't drive the discussion by filing bugs at lintian.

Yesterday:
[12:38]  guillem: I'll fix #889042 someday.

There is no further discussion on #debian-bootstrap.

> 5. Discussion this has already wasted too much time better spent on
>fixing real bugs. Can we stop it now?

I did not request your participation, feel free to stop.


smime.p7s
Description: S/MIME cryptographic signature

Bug#889106: gcc-6: Support simpler multiarch systems

[Javier Serrano Polo]

Source: gcc-6
Version: 6.4.0-12
Severity: wishlist
Control: forwarded -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173

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. Thus, I ask
if Debian could support such systems. Also, I would appreciate
recommendations about proper interpreter names for Debian architectures.

Upstream does not want to support these systems. glibc Debian
maintainers, despite interoperability advantages, think these systems
are ugly and must not be supported in Debian.[1]

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


smime.p7s
Description: S/MIME cryptographic signature

Bug#889104: gcc-6: Add README.cross-hppa64 to justify gcc-6-hppa64-linux-gnu

[Javier Serrano Polo]

Source: gcc-6
Version: 6.4.0-12
Severity: wishlist

Please consider adding a README.cross-hppa64 file that explains why
gcc-6-hppa64-linux-gnu is provided by gcc-6 instead of by
gcc-6-cross-ports. https://bugs.debian.org/800729 may be of interest.


smime.p7s
Description: S/MIME cryptographic signature

Bug#889103: gcc-6: Allow to run only one SSP test suite

[Javier Serrano Polo]

Source: gcc-6
Version: 6.4.0-12
Severity: wishlist

Please consider to support a pkg.gcc-6.1ssp-check build profile that
only runs one SSP test suite, since the derivative run may not be
interesting and the test suite takes much time. I have a patch for
version 6.3.0-18.


smime.p7s
Description: S/MIME cryptographic signature

Bug#889101: gcc-6: Allow to not build multilib packages

[Javier Serrano Polo]

Source: gcc-6
Version: 6.4.0-12
Severity: wishlist

Please consider in the future supporting the nobiarch build profile if
multilib packages still exist. I have a patch for version 6.3.0-18.


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 dj 01 de 02 de 2018 a les 22:16 +0100, Mattia Rizzolo va escriure:
> Or at least until https://wiki.debian.org/BuildProfileSpec is amended
> and somebody from the relevant group of people (Helmut, Josch, Guillem
> comes to my mind) ACKs it.

 Missatge reenviat 
De: Javier Serrano Polo <jav...@jasp.net>
Per a: 889...@bugs.debian.org
Data: Thu, 01 Feb 2018 20:05:19 +0100

We had some words at #debian-bootstrap. Helmut agrees. I will fix this
someday.


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

We had some words at #debian-bootstrap. Helmut agrees. I will fix this
someday.


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

Package: lintian
Version: 2.5.72
Severity: wishlist

Please switch the dot to a suitable character, such as slash, in
pkg.$sourcepackage.$anything build profile names, since dot is a valid
character in package names.


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net, m...@suse.de, j...@suse.cz, 
a...@suse.de

El dc 31 de 01 de 2018 a les 13:51 +, Michael Matz va escriure:
> hmm?  Here let me show you the interop problem with your suggestion:
> 
> % gcc -Wl,-dynamic-linker,/lib/ld-linux-x86-64.so.2 -o hello ~/src/hello.c

You are trying to run an unsupported binary without following the
installation procedure on a system without compatibility mode. Let me
remind my counterexample:[2]

$ sudo dpkg -i hello-nolib64_0.1_amd64.deb
Selecting previously unselected package hello-nolib64.
(Reading database ... 55548 files and directories currently installed.)
Preparing to unpack .../hello-nolib64_0.1_amd64.deb ...
Unpacking hello-nolib64 (0.1) ...
Setting up hello-nolib64 (0.1) ...
$ hello-nolib64
Hello, world!

> So, uhm, you think it's acceptable to force everyone else to create a 
> symlink because it's not acceptable to you?

No, I am not forcing anyone to do anything.[3] I respect your users that
love the /lib64 directory and find /lib/ld-linux-x86-64.so.2 ugly.

--
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888073#60
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888073#165


smime.p7s
Description: S/MIME cryptographic signature

Bug#757760: debian-policy: please document build profiles

[Javier Serrano Polo]

Where should I report issues about the spec in the meantime?


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net, m...@suse.de, j...@suse.cz, 
a...@suse.de

El dt 30 de 01 de 2018 a les 15:01 +, Michael Matz va escriure:
> we split the world (into those that do support it, as allowed, and those 
> that don't, as also allowed).

That is the point of giving an choice. My world is split into users that
support /lib64 binaries and those that do not; it is their choice.

> That must not happen.

That happened in 2010.

> Perhaps we still can do something about the x32 program interpreter 
> (currently defined to sit in /libx32/ld-linux-x32.so.2).

Fine.

> But I fear for /lib64/ld-linux-x86-64.so.2 it's too late,

It is never too late. Nowadays, there are no interoperability problems,
as I have proved in this bug report. Let us wait for your users to
complain about manually creating a symlink.


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net, m...@suse.de, j...@suse.cz, 
a...@suse.de

El dl 29 de 01 de 2018 a les 16:24 +, Michael Matz va escriure:
> Is does, but draft means many things, and for the psABI doesn't include 
> "making backward incompatible changes is okay".

I am asking people to be nice, not requiring them to modify their
systems. Let me try a new proposal:

5.2.1
Systems conforming to the AMD64 ABI may want to support
the /lib/ld-linux-x86-64.so.2 path name, which is preferred in
multiarch.

Appendix A.1
Systems conforming to the AMD64 ABI may want to support
lib/x86_64-linux-gnu subdirectories for the libraries, which are
preferred in multiarch.

This way, people that want to help will not be frowned upon.
Could you do another assessment?


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net, m...@suse.de, j...@suse.cz, 
a...@suse.de

El dl 29 de 01 de 2018 a les 13:43 +, Michael Matz va escriure:
> To see why that is so suppose I'm changing my compiler to use a different 
> calling convention in which the first argument is passed in %rsi and the 
> second in %rdi, and otherwise it's all the same.

Could you tell me why on earth would you want to do that? Is there any
speed advantage? You are comparing a function-calling convention with a
filesystem requirement. There is an interest in dropping /lib64 and
maintain interoperability, and I find it legitimate.

> I recompile my whole 
> system and I adjust all the various assembler snippets that have it 
> hard-coded.

Yet another person that believes I must recompile my whole system.

> Does it make 
> sense to encode this new calling convention in the psABI?

Give me the reason for the new calling convention and I will tell you
whether it makes sense.

> A psABI-compliant system then 
> suddenly wouldn't only have to provide /lib64/ld-linux-x86-64.so.2, but 
> also your proposed file; i.e. alternatives in an ABI are actually 
> additional requirements on the system (they're alternatives only for a 
> particular file).  If a system wouldn't do that then it can't claim to be 
> psABI-compatible anymore as there would exist executables which can't be 
> loaded on it.

That happens with any standard. A system can be POSIX.1-2001 compliant
and not POSIX.1-2008 compliant; it does not support the new features. An
AMD64 system that does not evolve can always claim to be compatible with
version 0.99.7.

> So, while you might say that putting the loader into an alternative path 
> is a maintainers choice, it's a (badly advised) maintainers choice of not 
> following the psABI, not a good reason to change it.

Cleaner filesystem and multiarch simplicity. We have different views of
what constitutes good advice.

> This is slightly different from the choice of not following the suggestion 
> in the psABI of putting libraries into **/lib64, like the multiarch 
> approach is doing.

Sorry for not CCing. You missed the bits about custom loaders and
DT_NEEDED.

> So, no, we can't change the psABI in that respect without repercussions 
> for all systems claiming to be conforming, which is a bad idea for an ABI 
> that's already nearly 20 years old.

Sorry, I thought "Draft Version" meant to be a draft. Also, I must have
misunderstood the following:

The System V Application Binary Interface will evolve over time
to address new technology and market requirements, and will be
reissued at intervals of approximately three years. Each new
edition of the specification is likely to contain extensions and
additions that will increase the potential capabilities of
applications that are written to conform to the ABI.

The only repercussion you are talking about is that systems will not be
able to make a claim if they do not adapt to the new version. There are
no real interoperability issues, as my previous counterexample proves.

I guess it is too much for distros to ship a symlink that would help
Debian-based systems to get rid of /lib64.


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

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

For the record, I have decided to make easier to support binaries
depending on lib64 directories. Also, I will provide a package that
handles lib64 links for users that prefer a filesystem-based
implementation; initially, there will be only the /lib64 interpreter.

Debian could offer libc6 free from /lib64, even by default, but Debian's
position looks firm: users are not allowed to have systems
without /lib64 even if there are no compatibility issues. A wontfix tag
would be coherent with this decision.


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

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

El ds 27 de 01 de 2018 a les 17:06 +0100, Samuel Thibault va escriure:
> > > Putting the interpreter meaning in the kernel means putting it where it
> > > is not expected to be found.
> > 
> > Do you know that the kernel is the component that loads the ELF
> > interpreter?
> 
> So what?

I expect to find this functionality in the ELF loader. Where do you
expect it to be found?

> People expect to be able to interpret these string as path names in the
> filesystem. Making it mean something else means hiding.

That is your point of view. To me, implementation details are hidden
from the interface. To know the implementation details, you must know
the specific implementation, which is available to the user.

"Invoke this interpreter" and "load this dependency" may not be the same
as "read this file" or "test this file's existence"; it is a user
decision. The latter operations will act as you expect, unless the user
chooses otherwise, because of interoperability or whatever reason.

> Period, no point answering me again.

Why? We are exchanging interesting ideas. I learn about Debian's
shortcomings and my own ones.


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

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

El ds 27 de 01 de 2018 a les 16:07 +0100, Samuel Thibault va escriure:
> Putting the interpreter meaning in the kernel means putting it where it
> is not expected to be found.

Do you know that the kernel is the component that loads the ELF
interpreter? It is not a generic file load.

> "path name" means on the usual filesystem, just like in the rest of the
> document.

Let us see another example of path names: DT_NEEDED. Again, this is just
an interface. If a program declares a dependency on "/lib64/libc.so.6",
I may choose a suitable alternative. Does Debian support this case?

We have different interpretations about the interface. Mine results in
more interoperability and control for the user.


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

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

El ds 27 de 01 de 2018 a les 09:41 +0100, Samuel Thibault va escriure:
> And you hide that in the kernel,

We have different concepts of the meaning of hiding. Following your
idea, binary formats are hidden in the kernel; to me, they are available
under /proc/sys/fs/binfmt_misc.

> while the ABI says it's a path.

Let us see the specification:[1]

PT_INTERP
The array element specifies the location and size of a
null-terminated path name to invoke as an interpreter.

This is exactly what I am doing: using a path name to "invoke as an
interpreter". No actual requirement is placed upon the filesystem.

> You can't always adapt tools.

As one of my users, could you give me a real example of such tool?

On the another hand, Debian does not follow specifications where it is
inconvenient. Does Debian support any AMD64 loaders that search
libraries only under lib64 subdirectories?

--
[1] http://www.sco.com/developers/gabi/latest/ch5.pheader.html


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

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

El ds 27 de 01 de 2018 a les 03:17 +0100, Samuel Thibault va escriure:
> So you are hiding some things.

I do not understand. What do you think I am hiding? There are no hidden
symlinks. The file /lib64/ld-linux-x86-64.so.2 does not exist, unless
you create it.

> > The way I see the ABIs, /lib64/ld-linux-x86-64.so.2, /lib/ld.so.1,
> > /libexec/ld-elf.so.1, etc. are magic strings, not requirements for the
> > filesystem.
> 
> That's hiding the actual ABI meaning.

I do not think so. The ABI is just an interface, it says: "My executable
will ask for this interpreter". I say: "Okay, let me handle the
implementation details".

I will not hide this fact. Tools like gdb and valgrind fail with /lib64
programs, which is not a problem since I usually recompile to fix a bug
or a leak. In the unusual case that I must audit /lib64 programs, I grab
a read-write environment and add a symlink. If there were complaints, I
would adapt those tools.


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

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

El dv 26 de 01 de 2018 a les 22:27 +0100, Aurelien Jarno va escriure:
> It's an ugly solution and clearly not
> something we want to support, even as a build profile.

We have different views about what is ugly. Anyway, it is a maintainer's
choice, no problem. A wontfix tag would be appreciated.


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net, m...@suse.de, j...@suse.cz, 
a...@suse.de

El dv 26 de 01 de 2018 a les 20:10 +0100, Aurelien Jarno va escriure:
> It's probably not clear, let me try again. Your package provides a
> /lib/ld-linux-x86-64.so.2 -> /lib64/ld-linux-x86-64.so.2 symlink. As 2
> packages or more can't provide the same file, I conclude that to be able
> to install your package your program interpreter should be installed in
> /lib64 (and not in /lib), which is exactly what you want to avoid.

You are forgetting the claim that the example is countering. No matter
how, can a /lib/ld-linux-x86-64.so.2 program run on your system? Does
the provided package work on your system or not?

El dv 26 de 01 de 2018 a les 20:42 +0100, Samuel Thibault va escriure:
> How did it find an interpreter?

Now the workings; you may not like how it works, but it does. My kernel
acknowledges the fact that third-party programs may require interpreters
that do not exist, which is a problem if the base filesystem cannot be
modified. If the interpreter does not exist, the kernel asks for
alternatives.

In the case of amd64, there is a module which handles the
well-known /lib64/ld-linux-x86-64.so.2. If I want to support those
programs, I load the module with the
alternative /lib/ld-linux-x86-64.so.2. It is like a symlink, but without
touching the base filesystem and just for the purpose of finding an
interpreter.

The way I see the ABIs,
/lib64/ld-linux-x86-64.so.2, /lib/ld.so.1, /libexec/ld-elf.so.1, etc.
are magic strings, not requirements for the filesystem. It is a kind of
binfmt-support solution.


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net, m...@suse.de, j...@suse.cz, 
a...@suse.de

El dv 26 de 01 de 2018 a les 19:18 +0100, Samuel Thibault va escriure:
> Count a sixth person :)

You are welcome.

> But what about the converse? Can you run the attached program?

Not yet:

./true: /lib/libc.so.6: version `GLIBC_2.14' not found (required by ./true)

But this has nothing to do with the interpreter. Of course, I could run
a sid chroot, but this is not the point. When I finish my upgrade
process (which may take months), I will try again your test.


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net, m...@suse.de, j...@suse.cz, 
a...@suse.de

El dv 26 de 01 de 2018 a les 08:39 +0100, Andreas Jaeger va escriure:
> No, this is not possible - it would break binary compatibility. The path
> is hardcoded into each binary and if you change it, your application
> will not run anywhere else,

It would be nice if you answered the question about appendix A.1.

So, we have five people who state or imply that either my amd64 systems
do not exist or they are unavoidably incompatible with systems depending
on a /lib64 directory.

My systems obviously exist. To the claim that I cannot run a /lib64
program without rebuilding, the answer is easy to say: try my system.
To the claim that applications from my system will not run anywhere
else, I can provide a counterexample: you can install the attached
package.

Would you accept the evidence? Is /lib64 still a mistake or rather a
maintainer's choice?


hello-nolib64_0.1_amd64.deb
Description: application/deb


hello-nolib64_0.1.tar.gz
Description: application/compressed-tar
Format: 3.0 (native)
Source: hello-nolib64
Binary: hello-nolib64
Architecture: any
Version: 0.1
Maintainer: Javier Serrano Polo <jav...@jasp.net>
Standards-Version: 3.9.1
Build-Depends: debhelper (>= 8)
Checksums-Sha1: 
 0cb0a6e9395ddfd9eec0694c27925a43815a2a97 9730 hello-nolib64_0.1.tar.gz
Checksums-Sha256: 
 78b16e6c70c246a71842c5d2fb2d6ce0b963f5fa7bb1ffe28b09834758013a5e 9730 
hello-nolib64_0.1.tar.gz
Files: 
 c001d3d99923344e11598a991ed878e5 9730 hello-nolib64_0.1.tar.gz


smime.p7s
Description: S/MIME cryptographic signature

Bug#888073: Suggestions about multiarch and AMD64 systems without /lib64, SVABI

[Javier Serrano Polo]

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

Dear editors,

I would appreciate if you could point me to the latest version of the
"System V Application Binary Interface: AMD64 Architecture Processor
Supplement", which seems to be draft version 0.99.7.

I run AMD64 Linux systems that do not have a /lib64 directory. These
systems follow a multiarch structure, which allows to run programs from
any architecture, e.g. Intel386 on PowerPC. All program interpreters
have unique names and are located under /lib. AMD64 has
the /lib/ld-linux-x86-64.so.2 interpreter.

Section 5.2.1 of the draft says:

There is one valid program interpreter for programs conforming
to the AMD64 ABI: /lib/ld64.so.1
However, Linux puts this in /lib64/ld-linux-x86-64.so.2

Could the following text be appended?

Multiarch systems may put this in /lib/ld-linux-x86-64.so.2

"may put" could be "puts" if a distro like Debian did this. Debian
follows a multiarch structure too. It does not follow appendix A.1,
which says:

Libraries conforming to the Intel386 ABI will live in the normal
places like /lib, /usr/lib and /usr/bin. Libraries following the
AMD64, will use lib64 subdirectories for the libraries,
e.g /lib64 and /usr/lib64.

In multiarch systems, Intel386 libraries are under /lib/i386-linux-gnu
or /usr/lib/i386-linux-gnu, and AMD64 ones are
under /lib/x86_64-linux-gnu or /usr/lib/x86_64-linux-gnu. Could the
appendix show this fact?

Thank you.


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

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

El dc 24 de 01 de 2018 a les 23:18 +0100, Aurelien Jarno va escriure:
> If you change the program interpreter path, you have no other choice.

If you say so...

El dc 24 de 01 de 2018 a les 22:29 +, Adam Conrad va escriure:
> you won't be ABI-compatible with the rest
> of the Linux world,

I can run those programs without recompiling.

> If you want to patch your local system and rebuild it all to
> avoid that, go nuts.

I only rebuild the necessary packages.

> As
> a Debian bug, however, even a wishlist one, this should be a wontfix.

As you wish. You do not want to support amd64 systems without /lib64. It
is your choice to live with a /lib64 directory.


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

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

El dc 24 de 01 de 2018 a les 22:40 +0100, Sven Joachim va escriure:
> Well, then you have to live with /lib64.

I do not live with /lib64. You do not have to live with /lib64 unless
you want to.


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

X-Debbugs-CC: cl...@debian.org

El dc 24 de 01 de 2018 a les 18:26 +0100, Aurelien Jarno va escriure:
> The dynamic linker path is part of the
> x86-64 ABI and is present in all ELF executables.

I am aware that the original specification has that quirk, but it was
made without multiarch in mind. Would you choose /lib64 if you could
decide? I would not. I think that if there is a will this can be fixed.

Other architectures are easy to see. For instance, m68k and powerpc
conflict with /lib/ld.so.1. amd64's interpreter does not conflict, but
all interpreters should be under /lib. I see /lib64 as a mistake that
can be fixed.

> Moving it means
> rebuilding all the packages.

We do not want that.

> Could you please explain it how it works and what would be the use case?

I will explain the workings later, but let us discuss the use case. This
scenario has been running since 2010. Why did I drop /lib64?

1. A cleaner root directory.
2. A consistent root directory among architectures.
3. To avoid future architectures to have their own root directories,
   such as /libx32.
4. Using /lib was the multiarch way.
5. Specs, standards and laws can eventually be amended.
6. Another challenge to accomplish something supposedly impossible.

It is all about transitions. You may think this use case is not worth
the interim compatibility measures, but it is my use case and I have
seen other people dislike /lib64. So, is this case worth a build profile
at least?


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

Source: glibc
Version: 2.26-4
Severity: wishlist

amd64 systems can work perfectly without a /lib64 directory. Since I am
unlikely to convince you to ship ld-linux-x86-64.so.2 under /lib instead
of /lib64 by default, could you allow this option with a build profile,
e.g. nolib64?


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

X-Debbugs-CC: k...@codeweavers.com

El dc 17 de 01 de 2018 a les 15:48 +0100, Jens Reyer va escriure:
> The second line is about the master, we always need it.  And I want the
> master to be "wine", not "libwine.so.0" (e.g. master's name is used in
> the user interfacing command "update-alternatives --config wine").

You want to configure with "update-alternatives --config wine", but I am
asking to configure with "update-wine-alternatives --config" instead.
The update-wine-alternatives script does not exist yet.

> https://www.winehq.org/pipermail/wine-devel/2016-October/114992.html
> "The reason for this is that libwine is not like other libraries where
> Debian's check may make sense.  It's not a general-purpose library.
> It's only really useful for Wine itself and for a program which wants to
> be an alternative Wine loader.  The client of libwine will want it to
> call exit() when needed."

When Ken made those statements, he obviously did not know about LMMS.
libwine is a general-purpose library to run software that uses Windows
API; this is the point of winegcc. libwine calls exit(), so what?
Although libwine could call wine_exit_handler() instead of exit().

> To sum up, these are the issues:
> - upstream considers libwine to not be a general-purpose library

First, this is only a statement from Ken, not documentation. Second, he
did not know about LMMS. Third, libwine is a Windows API provider.

> - I'm not sure how stable its api is

LMMS has been using Wine for more than ten years. API is stable enough.

> - Imo we should stay with pkg:wine(-development) providing the
>   master /usr/bin/wine

Jens, you should first understand what I am proposing. Is it fine to
configure with "update-wine-alternatives --config" and not have unneeded
wine packages installed?


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

> There are no reverse dependencies of libwine, so it is not clear to me
> how this would actually be helpful.

Sorry, I missed your message. lmms-vst-server depends on wine, but I
cannot help with lmms-related packaging right now.

El dc 10 de 01 de 2018 a les 19:51 +0100, Jens Reyer va escriure:
> I'm not sure if you suggest to make libwine (instead of wine) the
> alternatives-master for all Wine packages - I think that wouldn't work,
> because each arch has its own libwine, so we'd have multiple master.
> Feel free to prove me wrong.

Then make libwine depend on a wine-alternatives package that ships the
update-wine-alternatives script.


smime.p7s
Description: S/MIME cryptographic signature

Bug#884640: firefox: Internationalized extensions are broken

[Javier Serrano Polo]

Source: firefox
Version: 57.0.1-1
Severity: wishlist
Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1425662

Look at upstream for details. This also happens in firefox-esr
52.5.2esr-1. Is this bug specific to Debian?


smime.p7s
Description: S/MIME cryptographic signature

Bug#859793: Messages at cnpbagwell.com about bug

[Javier Serrano Polo]

Dear Chris Bagwell,

Could you check your messages at cnpbagwell.com about a bug that were
sent from my address?

Thank you.


smime.p7s
Description: S/MIME cryptographic signature

Bug#860312: lmms: please lower the indirect dependency on wine

[Javier Serrano Polo]

El dv 14 de 04 de 2017 a les 14:00 +0200, Graham Inggs va escriure:
> This means a typical installation (without --no-install-recommends) of
> lmms will install lmms-vst-server, libwine and all of libwine's
> dependencies.

These components are part of the recommended installation by upstream.

> Would you please consider lowering the Recommends:
> lmms-vst-server:i386 to Suggests: lmms-vst-server:i386 ?

I did consider what the right dependency is.

IMHO, this bug is wontfix and should be closed. However, I have no
authority to override a decision from a Debian developer.


smime.p7s
Description: S/MIME cryptographic signature

Bug#859793: fluidsynth: Package has infringed GPL

[Javier Serrano Polo]

El dl 10 de 04 de 2017 a les 23:06 +0200, Peter Hanappe va escriure:
> However, it seems that chorus.c is now under the LGPL license. From
> https://sourceforge.net/p/sox/code/ci/master/tree/COPYING:

As I understand, fluidsynth_chorus.c was imported from SoX rather than
the original project by Juergen Mueller. Thus, Chris Bagwell is the one
who can shed light on the origin.

> However, since fluidsynth was under LGPL
> with "Copyright (C) 2003 Peter Hanappe and others" from the
> beginning, I don't believe any contributors to
> fluidsynth_chorus.c would object to putting their changes to that
> file under the LGPL. I'll happily make my changes available under
> that license.

That makes sense. However, the main problem is the permission from
Juergen Mueller and related contributors.

> So, because SoX/chorus.c is now under the LGPL and all the
> changes that have been made between chorus.c and
> fluidsynth_chorus.c fall under the LGPL, I believe that
> fluidsynth_chorus.c can be put under the LGPL, too.

I see no evidence to support such relicensing. Original copyright should
be to dropped if there is no trace from the original file, but this does
not seem to be the case.


smime.p7s
Description: S/MIME cryptographic signature

Bug#859793: fluidsynth: Package has infringed GPL

[Javier Serrano Polo]

El dl 10 de 04 de 2017 a les 09:24 +0200, David Henningsson va escriure:
> What makes things slightly easier for us as upstream is that FluidSynth 
> is released under LGPL rather than GPL. LGPL allows linking to custom 
> licenses.

This is not the case because fluid_chorus.c is part of the library and
must respect rights under LGPL.

Rewriting fluid_chorus.c could be one first step. However, we could wait
some time until Chris Bagwell tells us about the original source; Chris
Bagwell or Peter Hanappe, it is not clear to me that fluid_chorus.c
comes from SoX.


smime.p7s
Description: S/MIME cryptographic signature

Bug#859793: fluidsynth: Package has infringed GPL

[Javier Serrano Polo]

Dear Chris Bagwell,

In 1999, you imported src/chorus.c to SoX on SourceForge.[6] File is
copyrighted by Juergen Mueller and sundry contributors. Could you tell
us where we could find the original project or how to contact Juergen
Mueller?

Thank you.

--
[6] 
https://sourceforge.net/p/sox/code/ci/98267de439714fcdff94c9588f34fb8a67df70c1/?page=1


smime.p7s
Description: S/MIME cryptographic signature

Bug#859793: fluidsynth: Package has infringed GPL

[Javier Serrano Polo]

Regarding SoX and Debian bug #92969, the copyright handling in wav.c is
dubious.[5] Assuming this modification is allowed, wav.c changes the
notice

XAnim Copyright (C) 1990-1997 by Mark Podlipec.
[...]
This software may be freely copied, modified and redistributed
without fee for non-commerical purposes

which is clearly incompatible with the original license, to

Thanks goes to Mark Podlipec's XAnim code.  It gave some real
life understanding of how the ADPCM format is processed.  Actual
code was implemented based off of various sources from the net.

So the code was from Mark Podlipec, but now it is only an inspiration
for Chris Bagwell, yet various sources from the net are needed? Or Mark
Podlipec's code was inspired by those sources from the net? Chris
Bagwell should clarify the origin of the code.

--
[5] 
https://sourceforge.net/p/sox/code/ci/613f50d018d73308428dda8c610066a726e1a95e/


smime.p7s
Description: S/MIME cryptographic signature

Bug#859793: fluidsynth: Package has infringed GPL

[Javier Serrano Polo]

El dv 07 de 04 de 2017 a les 19:13 +0100, James Cowgill va escriure:
> FYI the license in question is the SoX license which has been in Debian
> and basically all distributions for 20 years (as part of SoX)...

So SoX and derivatives are affected too. The problem was not
detected.[3]

> The SoX project relicensed some time ago to GPL so if you are to believe
> that that was OK, then there are no licensing problems with this file
> (but the copyright header should be updated to reflect that).

Upstream file still has the old copyright.[4] Where is this relicensing
process documented?

--
[3] https://bugs.debian.org/92969
[4] https://sourceforge.net/p/sox/code/ci/master/tree/src/chorus.c


smime.p7s
Description: S/MIME cryptographic signature

Bug#859793: fluidsynth: Package has infringed GPL

[Javier Serrano Polo]

Source: fluidsynth
Version: 1.1.6-4
Severity: wishlist

fluid_chorus.c is under a custom license, granting the following:

This source code is freely redistributable and may be used for
any purpose.

The license does not grant the right to modify the software. Therefore,
it is not compatible with GPL-2.1+ (sic) or LGPL-2.0+.

Whether intentionally or not, Debian has been distributing this software
without complying with GPL. Thus its rights have been automatically
terminated. Ceasing violation does not restore rights and a new license
should be acquired.

I will remind you of the scope of such infringement. Since Debian does
not have the right to distribute, it does not have the right to
propagate the license. All Debian-based distros and their users have not
automatically received a license through Debian.

Because of the avalanche effect of GPL, all works based on these
versions of FluidSynth have not received rights under GPL. The process
recurs: all Debian-based distros, their users, and depending works have
not received a license through this path.

I will remind you of the potential severity. Like the patent troll
phenomenon, some people profit from GPL reinstatements. The argument
exists:

If you have redistributed an application under GPLv2, but have
violated the terms of GPLv2, you must request a reinstatement of
rights from the copyright holders before making further
distributions, or else cease distribution and modification of
the software forever.[1]

There are real cases based on this reasoning; e.g., BusyBox related.[2]
Although the Software Freedom Law Center may not be interested in
infringements caused because of FluidSynth, other parties may be. Is
there anyone against successful free audio software?

--
[1] https://www.softwarefreedom.org/resources/2008/compliance-guide.html
[2] http://www.ecommercetimes.com/story/73241.html


smime.p7s
Description: S/MIME cryptographic signature

Bug#835838: pulseaudio: Do not intercept ALSA if environment variable is set

[Javier Serrano Polo]

El dt 14 de 02 de 2017 a les 19:35 -0300, Felipe Sateler va escriure:
> Could you check with the release team if this change would be OK for stretch?
> 
> Otherwise I can queue this up for buster.

We can wait.

> Could you propose such a patch to the upstream alsa developers?

I can try.


smime.p7s
Description: S/MIME cryptographic signature

Bug#854921: [gnu.org #1194507] ftp.debian.org: GNU General Public License 3 is not DFSG compliant

[Javier Serrano Polo]

X-Debbugs-CC: licens...@gnu.org

> >  Missatge reenviat 
> > De: Ansgar Burchardt <ans...@debian.org>
> > Javier Serrano Polo writes:
> > > If your rights have been terminated and not permanently
> > > reinstated, you do not qualify to receive new licenses for the
> > > same material under section 10.
> > 
> > That's not discrimination against persons or groups.

It is not obvious, I know, but the fact that GPLv3 forbids me to
distribute the program to former license violators is discrimination
against persons, unless you are implying that license violators are not
persons.

> > > Assuming he knows about the restriction, he may rightfully think that
> > > GPLv3-deny-Alice imposes a further restriction, thus he may remove it
> > > and convey under GPLv3. However, this would be a "poor wording" trick.
> > 
> > Interpreting a part of the original license as a "further restriction"
> > is very creative, but most likely not correct.

But it may be correct. It is most likely not intended by the license
designer.

GPLv3 does not explicitly restrict my ability to distribute software to
former offenders. It does not say that my section 10 can be modified
because of actions from other people; it does not say that some of my
recipients may not receive a license. There is no section 7.g about
"Prohibiting conveyance to previous license violators".

If I develop a program under GPLv3, I can distribute it to whoever I
want. But if some user has lost her rights for gnutls-openssl, for
instance, I cannot combine my program with gnutls-openssl and distribute
it to this user; there is a further restriction.

Furthermore, as I stated (the "more problematic to Bob" interpretation),
the only way for me not to transmit a license to an offender is to not
convey the covered work. So a copyright holder may pretend that I do not
convey such work to these persons, because conveying implies a new
license, and they do not qualify to receive new licenses under section
10. If I refuse and convey the work to people that do not qualify, I may
be regarded as a violator as well.

> > People using free software licenses in non-friendly ways is an entire
> > different problem from the license being free or not.

You are absolutely right, they are different problems. One problem is
how to forbid that offenders receive a new license without reinstatement
from the copyright holder. GPLv3 wants to accomplish this, but it is not
well-worded enough.

Another problem is whether the license is free. If GPLv3 effectively
prevents distribution to former license offenders, then it breaks
freedoms 2 and 3. It is a non-free license.

Yet another problem is whether the license is DFSG compliant. If GPLv3
effectively prevents distribution to these persons, as I call them, then
it discriminates against persons and breaks DFSG #5. It is not DFSG
compliant.

As I explain in #854825, it seems FTP masters are not the competent body
about the final interpretation of DFSG.[1] I would like to point that
the fact that many packages in the main component are under non DFSG
compliant licenses for so many years does not invalidate your work. The
issues I am raising are not evident.

I really appreciate your answer and would like to hear further from you,
but it looks like this is out of your jurisdiction, so I will understand
if you do not reply.

--
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854825#50


smime.p7s
Description: S/MIME cryptographic signature

Bug#854825: Bug#854721: ftp.debian.org: Artistic License 1.0 is not DFSG compliant

[Javier Serrano Polo]

> >  Missatge reenviat 
> > De: Ansgar Burchardt 
> > DFSG #1 specifically only requires "may not restrict any party from
> > selling or giving away the software as a component of an aggregate
> > software distribution containing programs from several different
> > sources".
> > 
> > (And DFSG #6 only talks about "making use" and not redistribution
> > anyway.)

Ansgar, you have not addressed any of the points I have raised. You
quote DFSG #1, which means that Debian itself does not infringe Artistic
License 1.0. I said: "Debian-based distros themselves are not threatened
because they are larger in scope".[1]

You say it: DFSG #6 only talks about "making use" and not
redistribution. This is exactly the problem: making use. Artistic
License 1.0 does not allow making use in specific fields of endeavor.
This affects Debian users.

You have not answered the question, whether the requirement
to not sell individual software is against DFSG #6.

Perhaps the FTP masters are not the competent body to judge DFSG
compliance? I do not read that function in your delegation message.[2]
According to your wiki page, it looks like you are only concerned "In
the case of the package potentially leaving Debian liable to
lawsuits".[3]

I think you have not read the report properly. If full DFSG compliance
is among your duties, I believe you should reopen this bug. Otherwise, I
will reassign to the body I believe is competent.

--
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854825#5
[2] https://lists.debian.org/debian-devel-announce/2012/10/msg4.html
[3] https://wiki.debian.org/Teams/FTPMaster?action=recall=43


smime.p7s
Description: S/MIME cryptographic signature

Bug#835838: pulseaudio: Do not intercept ALSA if environment variable is set

[Javier Serrano Polo]

X-Debbugs-CC: pkg-alsa-de...@lists.alioth.debian.org

El dc 21 de 09 de 2016 a les 10:36 -0300, Felipe Sateler va escriure:
> Alsa maintainers, what do you think?

Maintainers remain silent.

> Adding a similar check for a variable named
> like PULSE_DISABLE_ALSA_PLUGIN or something like that should be very
> simple.

Felipe, what do you prefer? To apply the patch with PULSE_ALSA_HOOK_CONF
in pulseaudio or if I implement PULSE_DISABLE_ALSA_PLUGIN in ALSA and
you do a NMU?


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

Package: lists.debian.org
Severity: wishlist
User: lists.debian@packages.debian.org
Usertags: newlist

I never understood why spam is allowed to reach the lists, but banned
users cannot send contributions. Since 2016, debian-upstream has nothing
but spam. Even debian-project has spam.

Please consider to create this list. I hope the rationale is not too
long.

* Basic purpose *

Keep the Debian community and outside world informed about banning
events, and work for rehabilitation of banned users.

* Interested audience *

Anyone interested in ban status of users, banning criteria, and real
examples; banned users seeking rehabilitation.

Statistics are not public; it looks like there are two or three bans per
year.[1] Besides non-banned users, there may be a modicum of banned
users interested.

* Name *

debian-banned

* Rationale *

Mischief, incivility, and misunderstanding are inherent to untrained
human interaction. As a result, some users are banned. Nevertheless,
with proper training and clarifications, these banned users could be
rehabilitated and reintegrated back.

I believe that the purpose of a ban is to protect the project rather
than to punish the offender. Every person has virtues and vices. The
goal is to take advantage of good conduct and reject bad behavior, while
following a constant training process. Rehabilitation is just one form
of education.

There are notable examples of banning events.[2] Technical skill of some
banned users is not questioned. Their rehabilitation would be a valuable
asset to the project.

One listmaster has stated that a history of positive contributions may
be viewed favorably.[3] That would be feasible for some programmers,
wiki editors, IRC assistants, etc. However, these users were not banned
because of their contributions in other areas. They were banned because
of their use of the lists. How can they prove they will not repeat the
mistake without using a list?

Newcomers and users that only write to lists would hardly use an
alternative path. If they are banned forever, they are lost forever. If
they only know about mailing lists, what possible positive contributions
could they do? Not everyone is able to adapt to another medium.

Even a reformed unskilled user could be useful. There is always need for
help in many areas. This user would gain experience, fall several times,
and rise again. Who knows? Maybe a naughty kid could become the best
project leader ever.

The proposed list would provide real examples: unwelcome behavior,
sources of confusion, redemption paths, success stories, etc. Volunteers
may help offenders understand why they were banned, guide them through
rehabilitation, and report when they are ready. Listmasters could send
banning events: new bans, liftings, adjustments, etc.

When a ban is issued, the message could say:

Your posting permissions are restricted to debian-banned until
your rehabilitation is confirmed. This notice will be anonymized
and posted to debian-banned; you may publish this message on
your own.

Regarding initial debate, I cannot discuss the matter on debian-devel or
debian-project.

* Short description *

Banning events and rehabilitation of banned users.

* Long description *

Banning events and rehabilitation activities. Banned users are allowed
to post. Volunteers may help. Be aware that you may find offensive
messages and people who may reply aggressively.

If you have been banned, this is your starting point through
rehabilitation. Behavior on this list may be grounds for ban extension.
Flooding will revoke your posting permissions for an increasing period.

* Category *

Users

* Subscription Policy *

open

* Post Policy *

open

* Web Archive *

yes

* Seconding users *

No Debian developers have been contacted regarding this request. Banned
users are unlikely to write to the BTS; furthermore, they are expected
to post to debian-banned anonymously, if they know how to do it. But I
guess you want to hear from non-banned users.

--
[1] https://lists.debian.org/debian-project/2013/10/msg00121.html
[2] https://lists.debian.org/debian-devel-announce/2006/01/msg9.html
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831059#35


smime.p7s
Description: S/MIME cryptographic signature

Bug#854942: bugs.debian.org: Case insensitive search

[Javier Serrano Polo]

Package: bugs.debian.org
Severity: wishlist

Please add a misc option to allow case insensitive searches or tell
whether this feature is wanted. Should this be reassigned to debbugs?


smime.p7s
Description: S/MIME cryptographic signature

Bug#854921: [gnu.org #1194507] ftp.debian.org: GNU General Public License 3 is not DFSG compliant

[Javier Serrano Polo]

X-Debbugs-CC: licens...@gnu.org

Some authors and related professionals profit from GPL reinstatements,
so I would understand that an eventual GPLv4 would not fix this issue.
GPLv3 has enabled this business and it would not be fair to end it
through a license upgrade, although GPLv4 could solve this for
non-upgraded works.

In order to be DFSG compliant, I would like to attach an additional
permission to all my GPLed contributions. I hope other authors with this
concern use the same text. Thus I would like to hear from other authors,
but I do not know how; debian-upstream looks dead. Of course, I would
appreciate the input from FSF; maybe this concern has been raised
already.

My draft is:

You are granted this additional permission:

Without waiving any right to claim damages because of your
copyright infringement, your license from the following
copyright holders is reinstated permanently if you cease all
violation of this License.

  * Alice
  * Bob
  * Coder Inc.
  * Authors listed in AUTHORS


smime.p7s
Description: S/MIME cryptographic signature

Bug#854921: ftp.debian.org: GNU General Public License 3 is not DFSG compliant

[Javier Serrano Polo]

Package: ftp.debian.org
Severity: wishlist
X-Debbugs-CC: licens...@gnu.org

Like in the Artistic case, the purpose of this report is not to turn a
great share of the main component into non-free. I am only presenting a
bug.

Just to make sure, I do not speak in the name of the Debian project.

Unlike Artistic, GPLv3 is not necessarily part of DFSG #10 because last
update is from 2004. Otherwise, it is still cataloged as "example", not
"override".

GPLv3 breaks DFSG #5 (no discrimination against persons or groups).
Section 8 states:

If your rights have been terminated and not permanently
reinstated, you do not qualify to receive new licenses for the
same material under section 10.

Section 10 says:

Each time you convey a covered work, the recipient automatically
receives a license

Consider an example. If Alice's rights are terminated, Bob's section 10
effectively turns into:

Each time you convey a covered work, the recipient automatically
receives a license except Alice

or (more problematic to Bob):

Each time you convey a covered work, the recipient automatically
receives a license
You may not convey to Alice.

This virtually means a license split: some software under
GPLv3-deny-Alice and the rest under GPLv3. Now Bob has developed some
software under GPLv3. What does happen if he combines both licenses?
Assuming he knows about the restriction, he may rightfully think that
GPLv3-deny-Alice imposes a further restriction, thus he may remove it
and convey under GPLv3. However, this would be a "poor wording" trick.

It looks like the intended combination is GPLv3-deny-Alice until Alice
gets a permanent reinstatement, which may not happen. Bob's ability to
effectively distribute software to Alice is prevented.

But Alice is not the only one affected. If she starts conveying covered
works in a seemingly GPLv3 compliant way, she does not really have that
right, and her recipients do not automatically receive a license.

As I said, DFSG #5 becomes broken. GPLv3 discriminates against users
with their rights terminated from one related copyright holder;
reinstatement may be not possible. GPLv3 is not DFSG compliant.
Furthermore, it is not even a free license because it breaks freedoms 2
and 3, since distributing copies to these users is restricted.

Note that GPLv2 does not have this problem because section 4 says
nothing about reinstatements, despite what I read in other web sites.
Curing a GPLv2 violation does not restore rights, but getting a new
license under section 6 and remaining in compliance does restore.

Regarding significance, I guess the termination clause is meant to
discourage repeated infringements. However, it could be misused;
reinstatement might be unreasonable or impossible. One example:

 1. Coder Inc. develops SuperFoo under GPLv3.
 2. Derivative Fdn. creates HyperFoo based on SuperFoo.
 3. HyperFoo becomes very popular.
 4. A developer from Derivative accepts a binary-only plug-in from a
contributor.
 5. Coder notifies of the violation, which is cured.
 6. Another developer from Derivative accepts a binary-only plug-in,
realizes his mistake and reverts.
 7. Coder explicitly and finally terminates Derivative's license.
 8. Coder demands an insane amount of money for reinstatement.

Of course, you may think that Coder's behavior is acceptable, since
violations are Derivative's responsibility. You may judge that DFSG #5
and freedoms 2 and 3 are not broken, since GPLv3 does not discriminate
because of reasons other than license violation, but GPLv2 and other
licenses do not make such discrimination.

If Debian agrees with this procedure, DFSG #5 should be replaced with:

The license must not discriminate against any person or group of
persons that have not violated the license.

Nevertheless, I believe DFSG #5 should not be modified. I would change
GPLv3 to not require reinstatements or to adopt limited periods of
disqualification depending on damages and reiteration. "Life sentence"
clauses are bad, but that is just an opinion.


smime.p7s
Description: S/MIME cryptographic signature

Bug#854721: ftp.debian.org: Artistic License 1.0 is not DFSG compliant

[Javier Serrano Polo]

Control: clone -1 -2
Control: reassign -2 ftp.debian.org
Control: retitle -2 ftp.debian.org: Artistic License 1.0 is not DFSG compliant
Control: reopen -2

El dj 09 de 02 de 2017 a les 18:10 -0800, Russ Allbery va escriure:
> We aren't the body in Debian that
> judges the DFSG compatibility of licenses (that's ftp-master), nor do we
> own or can modify the DFSG itself.

Then let us move this to ftp.debian.org. FTP team, please read #854679
and this report. The main issue is, in essence, whether the requirement
to not sell individual software is against DFSG #6 (no discrimination
against fields of endeavor).


smime.p7s
Description: S/MIME cryptographic signature

Bug#854721: debian-policy: Artistic License 1.0 is not DFSG compliant

[Javier Serrano Polo]

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

I forgot to CC.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854721#15


smime.p7s
Description: S/MIME cryptographic signature

Bug#854721: debian-policy: Artistic License 1.0 is not DFSG compliant

[Javier Serrano Polo]

The relevant points in #381729 are:

  * DFSG #10: "Artistic" is listed as an example the project
considers "free". This does not seem a reason because if the
license breaks another DFSG rule, then it is not an example, it
is an override.

  * DFSG #8: License must not be specific to Debian. "Artistic" is
not specific to Debian, it is specific to larger software
distributions. In fact, DFSG #8 is implied by DFSG #6 (the field
of endeavor is a non-Debian environment).

#458385 mentions "the AL1 is only DFSG-free by overruling decision".
Could anyone refer to the decision or related discussion? I cannot find
any general resolution or bug in tech-ctte about this.

So it is a DFSG #6 infringement against a DFSG #10 word qualified as
"example", not "override".


smime.p7s
Description: S/MIME cryptographic signature

Bug#854721: Acknowledgement (debian-policy: Artistic License 1.0 is not DFSG compliant)

[Javier Serrano Polo]

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

Sorry, the bug report search tool does not return results with
"artistic" in the subject. Reading existing reports...


smime.p7s
Description: S/MIME cryptographic signature

Bug#854721: debian-policy: Artistic License 1.0 is not DFSG compliant

[Javier Serrano Polo]

Package: debian-policy
Severity: wishlist
Version: 3.9.8.0
X-Debbugs-CC: a...@debian.org, ballo...@debian.org, jrnie...@gmail.com, 
r...@debian.org

Please read #854679; it is about the ScummVM-game-License. As I analyze,
that license breaks DFSG #6 (no discrimination against fields of
endeavor). Author's intent is clear since he states that using the game
"in things like commercial adventure game collections without asking is
just playing dirty". The preamble is not legally binding, but sections 3
and 4 of the license are.

This forbids this possible use case: a businessman hires some
developers, translators and voice actors to translate the game to his
language, and wants to sell the result.

The pattern "cannot sell the software itself" restricts commercial
purposes, thus it is not DFSG compliant. ScummVM-game-License, Bitstream
Vera font license, and Artistic License 1.0 are affected.

The question is whether the alleged poor wording of a clause is
internationally a solid defense in a copyright infringement suit.
Debian-based distros themselves are not threatened because they are
larger in scope, but commercial Debian users of this software are
menaced.

(This report will not reach the debian-policy list.)


smime.p7s
Description: S/MIME cryptographic signature

Bug#854679: beneath-a-steel-sky: DFSG compliance, commercial purpose

[Javier Serrano Polo]

X-Debbugs-CC: James 'Ender' Brown , Ian Jackson 


El dj 09 de 02 de 2017 a les 15:35 +0100, Markus Koschany va escriure:
> The game license is fully DFSG compliant. This has been discussed at
> length in the past, e.g. https://bugs.debian.org/478898

I have read again that bug report and its references. Discussion has
happened over the availability of source code, editors, trademarks, and
logos.

One relevant discussion in debian-legal is
https://lists.debian.org/debian-legal/2004/06/msg00546.html. It looks
like this is the same problem with Bitstream Vera font:

no copy of one or more of the Font Software typefaces may be
sold by itself.

Another one is
https://lists.debian.org/debian-legal/2003/08/msg9.html.
It seems to be a problem similar to the use of the Artistic license:

You may not charge a fee for this Package itself.

It appears these licenses are considered DFSG compliant because this
kind of clauses are deemed ineffective.
https://lists.debian.org/debian-legal/2003/08/msg00016.html

The Artistic license in base-files looks like Artistic License 1.0. The
GNU project has not made an extensive analysis of this license:
https://www.gnu.org/licenses/license-list.html#ArtisticLicense
and they recommend to avoid its use.

The Clarified Artistic License fixes this sentence:

You may not charge a license fee for the right to use this
Package itself.

If these clauses are indeed ineffective, why do authors include them
anyway?

It is said that you can effectively sell the software itself by applying
a trick: pretend to sell a "nifty screensaver", even sell a whole free
distro such as Debian. But as I am afraid, a judge may see through that
and conclude that you are applying a trick and effectively selling the
software itself.

Do you know about any actual sentences regarding this facet? Does this
make the licenses fit for international use?


smime.p7s
Description: S/MIME cryptographic signature

Bug#854679: beneath-a-steel-sky: DFSG compliance, commercial purpose

[Javier Serrano Polo]

Package: beneath-a-steel-sky
Severity: wishlist
Version: 0.0372-6
X-Debbugs-CC: James 'Ender' Brown , Ian Jackson 


The ScummVM-game-License is not DFSG compliant. Section 3 states:

You may not charge a fee for the game itself. This includes
reselling the game as an individual item.

This is against DFSG #6 (no discrimination against fields of endeavor)
because commercial purposes are restricted. You may not integrate this
game into a selling platform or a support service.

If you modify the game, license states in section 4:

You may also distribute modified versions under the terms set
forth in this license

Therefore, you cannot sell a modified game, either fixed, translated, or
enhanced.

Please close this bug if the scenarios I described are allowed by the
license. I cannot CC debian-legal.


smime.p7s
Description: S/MIME cryptographic signature

Bug#831059: lists.debian.org: Permanently banned users cannot send positive contributions to lists.debian.org

[Javier Serrano Polo]

El dv 03 de 02 de 2017 a les 11:25 -0600, Don Armstrong va escriure:
> communicated by Debian community members

Thanks for the answer, since it provides some kind of procedure.
However, bothering community members does not seem a way to improve
Debian. May I open a bug report about my case myself and elaborate?


smime.p7s
Description: S/MIME cryptographic signature

Bug#831059: lists.debian.org: Permanently banned users cannot send positive contributions to lists.debian.org

[Javier Serrano Polo]

When I filed this bug report, I was thinking about other banned users,
including a notable example.[3] I abstracted the individual from the
problem, because I am not the only one in this situation. I presented my
case as an example because it is the only one I am allowed to use; it is
obvious that it is my case and that I was not trying to fool anyone.

Another well-known collaborative international project has a banning
policy that guides users to reverse bans. I was asking whether Debian
could have such a procedure, whether this must be handled on a
case-by-case basis, or whether this can be solved at all.

It looks like:

 1. Alex will use anything I say as further excuse to justify my
status, no matter if there is a possible good faith
interpretation.
 2. No other listmaster cares or is willing to contradict another
one, even if the latter overreacted or did not understand the
messages.
 3. The Debian project is not aware about the problem I am bringing
up.

I have introduced a generic perspective, but it may be only me, since
there are few reports against lists.debian.org regarding bans. Do you
mind if I submit a bug report about my case and my point of view in due
time, and if I contact other developers to get advice and raise this
issue to the project?

--
[3] Mathieu O'Neil. "Cyberchiefs: Autonomy and Authority in Online
Tribes". ISBN 978-0-7453-2796-9.


smime.p7s
Description: S/MIME cryptographic signature

Bug#853975: qa.debian.org: Integrate clang.debian.net in PTS

[Javier Serrano Polo]

Package: qa.debian.org
Severity: wishlist
Tags: patch
Usertags: pts

Since debile.debian.net does not seem to be ready, please consider to
integrate clang.debian.net into the package tracking system instead of
buildd-clang.debian.net.

Be aware that this bug report will not reach debian...@lists.debian.org.
--- a/pts/www/xsl/pts.xsl	2017-02-02 18:33:07.0 +0100
+++ b/pts/www/xsl/pts.xsl	2017-02-02 18:36:32.0 +0100
@@ -1155,7 +1155,7 @@
  checks

, 
-   http://buildd-clang.debian.net/package.php?p={$escaped-package};>clang
+   http://clang.debian.net/pts.php?p={$escaped-package}format=html;>clang
 	
   
 	


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

Source: wine
Version: 1.8.6-3
Severity: wishlist

Please add a libwine.so.1 alternative to libwine packages, and
libwine.so to libwine-dev ones. These alternatives should be placed
under /usr/lib/MULTIARCH so that applications depending on libwine avoid
the use of RUNPATH and the binary-or-shlib-defines-rpath lintian error.

The alternatives should not be slaves in the wine package. I suggest to
move the slave alternatives from wine package to their respective
packages (wine32-tools and such), and to depend on an
update-wine-alternatives script (in libwine) that runs
update-alternatives for the installed packages.


smime.p7s
Description: S/MIME cryptographic signature

Bug#852276: libfltk1.3-dev: Fix FLTK-Targets-noconfig.cmake libdir

[Javier Serrano Polo]

This new patch fixes shared library names; it supersedes the previous
patch. Now configuration can finish.
--- fltk1.3-1.3.4.orig/debian/fix-fltk-targets-noconfig	2015-08-18 15:34:34.0 +0200
+++ fltk1.3-1.3.4/debian/fix-fltk-targets-noconfig	2017-01-23 09:59:06.0 +0100
@@ -3,9 +3,10 @@
 
 my $to_untag = '';
 while (<>) {
-s,(\${_IMPORT_PREFIX}/lib),$1/$ENV{DEB_HOST_MULTIARCH},g;
+s,(\${_IMPORT_PREFIX}/lib)(?!/$ENV{DEB_HOST_MULTIARCH}),$1/$ENV{DEB_HOST_MULTIARCH},g;
 s,\.so\.1\.3\.\d*,\.so,g;
 s,([^a-z]fltk\w*(?

smime.p7s
Description: S/MIME cryptographic signature

Bug#852276: libfltk1.3-dev: Fix FLTK-Targets-noconfig.cmake libdir

[Javier Serrano Polo]

Control: tags -1 patch

debian/FLTKLibraries-noconfig.cmake.in has nothing to do.
--- fltk1.3-1.3.4.orig/debian/fix-fltk-targets-noconfig	2017-01-23 08:08:32.0 +0100
+++ fltk1.3-1.3.4/debian/fix-fltk-targets-noconfig	2017-01-23 08:06:41.0 +0100
@@ -3,7 +3,7 @@
 
 my $to_untag = '';
 while (<>) {
-s,(\${_IMPORT_PREFIX}/lib),$1/$ENV{DEB_HOST_MULTIARCH},g;
+s,(\${_IMPORT_PREFIX}/lib)(?!/$ENV{DEB_HOST_MULTIARCH}),$1/$ENV{DEB_HOST_MULTIARCH},g;
 s,\.so\.1\.3\.\d*,\.so,g;
 s,([^a-z]fltk\w*(?

smime.p7s
Description: S/MIME cryptographic signature

Bug#852279: libfltk1.3-dev: Do not try to move fltk.spec if saved

[Javier Serrano Polo]

Control: tags -1 patch

The patch fixes the issue and allows to resume configuration.
--- fltk1.3-1.3.4.orig/debian/rules	2017-01-23 08:23:49.0 +0100
+++ fltk1.3-1.3.4/debian/rules	2017-01-23 08:18:30.0 +0100
@@ -20,7 +20,7 @@
 	dh $@
 
 override_dh_auto_clean:
-	mv fltk.spec fltk.spec.saved
+	[ -e fltk.spec.saved ] || mv fltk.spec fltk.spec.saved
 	dh_auto_clean
 	mv fltk.spec.saved fltk.spec
 
@@ -30,9 +30,9 @@
 	chmod +x debian/fix-fltk-targets-noconfig
 
 override_dh_auto_configure:
-	mv fltk.spec fltk.spec.saved
+	[ -e fltk.spec.saved ] || mv fltk.spec fltk.spec.saved
 ifneq "" "$(filter libfltk1.3-dev, $(shell dh_listpackages))"
-	mkdir CMakeTmp
+	mkdir -p CMakeTmp
 	cd CMakeTmp  &&  cmake -DCC:STRING="$(CC)" -DCXX:STRING="$(CXX)" \
 	-DCMAKE_INSTALL_PREFIX:STRING=/usr -DOPTION_CAIRO:BOOL=ON \
 	-DOPTION_BUILD_SHARED_LIBS:BOOL=ON -DOPTION_CREATE_LINKS:BOOL=ON \


smime.p7s
Description: S/MIME cryptographic signature

Bug#852279: libfltk1.3-dev: Do not try to move fltk.spec if saved

[Javier Serrano Polo]

Package: libfltk1.3-dev
Version: 1.3.4-1
Severity: wishlist

debian/rules runs
mv fltk.spec fltk.spec.saved

If later operations are interrupted, the target cannot be run again;
clean target will not work either. Please consider to test if
fltk.spec.saved exists already.


smime.p7s
Description: S/MIME cryptographic signature

Bug#852276: libfltk1.3-dev: Fix FLTK-Targets-noconfig.cmake libdir

[Javier Serrano Polo]

Package: libfltk1.3-dev
Version: 1.3.4-1
Severity: wishlist

FIND_PACKAGE(FLTK) triggers this error:

  The imported target "fltk_cairo_STATIC" references the file

 "/usr/lib/x86_64-linux-gnu/x86_64-linux-gnu/libfltk_cairo.a"

  but this file does not exist.

In debian/rules, you apply debian/fix-fltk-targets-noconfig to
FLTK-Targets-noconfig.cmake, which adds the multiarch component
to /usr/lib. This cmake file comes from
debian/FLTKLibraries-noconfig.cmake.in, which is based on @libdir@, but
you set libdir to the multiarch directory in debian/rules already.


smime.p7s
Description: S/MIME cryptographic signature

Bug#850188: autoconf: Allow checking function with conflicting types

[Javier Serrano Polo]

Package: autoconf
Version: 2.69-10
Severity: wishlist
Tags: upstream

Running configure with CFLAGS=-Werror, generated using AC_CHECK_LIB or
AC_SEARCH_LIBS, reveals this error in config.log (e.g., checking sqrt):

error: conflicting types for built-in function 'sqrt'

Ït would be nice if this syntax worked:

AC_CHECK_LIB([m], [double sqrt(double)])

or perhaps invoke gcc with -fno-builtin .


smime.p7s
Description: S/MIME cryptographic signature

Bug#850179: libgig-dev: ISO C++11 compliance

[Javier Serrano Polo]

Package: libgig-dev
Version: 3.3.0-5
Severity: wishlist
Tags: patch

Clang on C++11 mode complains:

ISO C++11 does not allow access declarations;
  use using declarations instead
DLS::Sampler::UnityNote;

This patch fixes the header.
Description: ISO C++11 compliance
 Fix compilation with Clang on C++11 mode.
Author: Javier Serrano Polo <jav...@jasp.net>

Index: libgig-3.3.0/src/gig.h
===
--- libgig-3.3.0.orig/src/gig.h	2015-08-04 23:22:14.0 +
+++ libgig-3.3.0/src/gig.h	2017-01-04 17:52:46.0 +
@@ -431,11 +431,11 @@
 uint8_tDimensionUpperLimits[8];   ///< gig3: defines the upper limit of the dimension values for this dimension region
 
 // derived attributes from DLS::Sampler
-DLS::Sampler::UnityNote;
-DLS::Sampler::FineTune;
-DLS::Sampler::Gain;
-DLS::Sampler::SampleLoops;
-DLS::Sampler::pSampleLoops;
+using DLS::Sampler::UnityNote;
+using DLS::Sampler::FineTune;
+using DLS::Sampler::Gain;
+using DLS::Sampler::SampleLoops;
+using DLS::Sampler::pSampleLoops;
 
 // own methods
 double GetVelocityAttenuation(uint8_t MIDIKeyVelocity);
@@ -452,8 +452,8 @@
 void SetVCFVelocityScale(uint8_t scaling);
 Region* GetParent() const;
 // derived methods
-DLS::Sampler::AddSampleLoop;
-DLS::Sampler::DeleteSampleLoop;
+using DLS::Sampler::AddSampleLoop;
+using DLS::Sampler::DeleteSampleLoop;
 // overridden methods
 virtual void SetGain(int32_t gain);
 virtual void UpdateChunks();
@@ -669,15 +669,15 @@
 class Instrument : protected DLS::Instrument {
 public:
 // derived attributes from DLS::Resource
-DLS::Resource::pInfo;
-DLS::Resource::pDLSID;
+using DLS::Resource::pInfo;
+using DLS::Resource::pDLSID;
 // derived attributes from DLS::Instrument
-DLS::Instrument::IsDrum;
-DLS::Instrument::MIDIBank;
-DLS::Instrument::MIDIBankCoarse;
-DLS::Instrument::MIDIBankFine;
-DLS::Instrument::MIDIProgram;
-DLS::Instrument::Regions;
+using DLS::Instrument::IsDrum;
+using DLS::Instrument::MIDIBank;
+using DLS::Instrument::MIDIBankCoarse;
+using DLS::Instrument::MIDIBankFine;
+using DLS::Instrument::MIDIProgram;
+using DLS::Instrument::Regions;
 // own attributes
 int32_t   Attenuation;   ///< in dB
 uint16_t  EffectSend;
@@ -688,7 +688,7 @@
 
 
 // derived methods from DLS::Resource
-DLS::Resource::GetParent;
+using DLS::Resource::GetParent;
 // overridden methods
 Region*   GetFirstRegion();
 Region*   GetNextRegion();
@@ -750,16 +750,16 @@
 static const DLS::version_t VERSION_3;
 
 // derived attributes from DLS::Resource
-DLS::Resource::pInfo;
-DLS::Resource::pDLSID;
+using DLS::Resource::pInfo;
+using DLS::Resource::pDLSID;
 // derived attributes from DLS::File
-DLS::File::pVersion;
-DLS::File::Instruments;
+using DLS::File::pVersion;
+using DLS::File::Instruments;
 
 // derived methods from DLS::Resource
-DLS::Resource::GetParent;
+using DLS::Resource::GetParent;
 // derived methods from DLS::File
-DLS::File::Save;
+using DLS::File::Save;
 // overridden  methods
 File();
 File(RIFF::File* pRIFF);


smime.p7s
Description: S/MIME cryptographic signature

Bug#849377: debsums: Replace MD5 with a more secure algorithm

[Javier Serrano Polo]

Package: debsums
Version: 2.1.3
Severity: wishlist
Tags: security

It would be nice if debsums worked with an algorithm more secure than
MD5. This issue is tracked at
https://wiki.debian.org/Sha256sumsInPackages , but it does not seem to
be any progress. While waiting for a proper solution, could you add this
text to the package description?

"MD5 is considered weak nowadays. Do not rely on debsums to detect
malicious changes."

This concern is because it is easy to craft programs with the same MD5
hash that follow different execution paths.


smime.p7s
Description: S/MIME cryptographic signature

Bug#837377: wine32-tools: Build with winegcc is not reproducible

[Javier Serrano Polo]

Package: wine32-tools
Version: 1.8.4-1
Severity: wishlist
Tags: upstream

RemoteVstPlugin from lmms-vst-server is compiled with wineg++. The build
is not reproducible because the name of a temporary file is included.[1]
The function that creates this file should try

char* tmp = strmake("%s%s", prefix, suffix);
fd = open(tmp, O_CREAT | O_EXCL, 0600);

before mkstemps().[2]

[1] 
https://tests.reproducible-builds.org/debian/dbd/unstable/i386/lmms_1.1.3-5.diffoscope.html
 ,
look for "spec.".
[2] 
http://source.winehq.org/git/wine.git/blob/HEAD:/tools/winegcc/winegcc.c#l265


smime.p7s
Description: S/MIME cryptographic signature

Bug#835838: pulseaudio: Do not intercept ALSA if environment variable is set

[Javier Serrano Polo]

El dv 02 de 09 de 2016 a les 22:40 -0300, Felipe Sateler va escriure:
> what this really does is load
> the file described in PULSE_ALSA_HOOK_CONF, and default to the known
> location?

Correct.



smime.p7s
Description: S/MIME cryptographic signature

Bug#835838: pulseaudio: Do not intercept ALSA if environment variable is set

[Javier Serrano Polo]

El dl 29 de 08 de 2016 a les 12:51 -0300, Felipe Sateler va escriure:
> Hmm. I wonder if instead of using an override pointing to a different
> file, it would be a simple disable flag (ALSA_PULSE_DISABLE). Is this
> possible in this configuration language?

As far as I know, there is no conditional processing. It does not seem
possible to configure with ALSA Lisp either. I guess ALSA_PULSE_DISABLE
could be implemented in the pulse_load_if_running function.


smime.p7s
Description: S/MIME cryptographic signature

Bug#835838: pulseaudio: Do not intercept ALSA if environment variable is set

[Javier Serrano Polo]

Package: pulseaudio
Version: 9.0-2
Severity: wishlist
Tags: patch

There should be a way for an ALSA application not to be intercepted by
PulseAudio; for instance, by setting an environment variable. One
example is the ALSA back end of LMMS, where the interception is buggy
( https://bugs.debian.org/781479 ). With this patch, setting
PULSE_ALSA_HOOK_CONF=/dev/null disables the interception.
diff -Nru pulseaudio-9.0.orig/debian/pulse-alsa.conf pulseaudio-9.0/debian/pulse-alsa.conf
--- pulseaudio-9.0.orig/debian/pulse-alsa.conf	2016-08-13 04:40:38.0 +0200
+++ pulseaudio-9.0/debian/pulse-alsa.conf	2016-08-28 18:57:34.0 +0200
@@ -1,5 +1,5 @@
-# This file is referred to by /usr/share/alsa/pulse.conf to set pulseaudio as
-# the default output plugin for applications using alsa when PulseAudio is
+# This file is referred to by /usr/share/alsa/pulse-hook.conf to set pulseaudio
+# as the default output plugin for applications using alsa when PulseAudio is
 # running.
 
 pcm.!default {
diff -Nru pulseaudio-9.0.orig/debian/pulse.conf pulseaudio-9.0/debian/pulse.conf
--- pulseaudio-9.0.orig/debian/pulse.conf	2016-08-13 04:40:38.0 +0200
+++ pulseaudio-9.0/debian/pulse.conf	2016-08-28 19:01:55.0 +0200
@@ -1,15 +1,15 @@
-# PulseAudio alsa plugin configuration file to set the pulseaudio plugin as
-# default output for applications using alsa when pulseaudio is running.
-hook_func.pulse_load_if_running {
-	lib "libasound_module_conf_pulse.so"
-	func "conf_pulse_hook_load_if_running"
-}
-
+# Enable PulseAudio hook if PULSE_ALSA_HOOK_CONF is not set.
 @hooks [
 	{
-		func pulse_load_if_running
+		func load
 		files [
-			"/usr/share/alsa/pulse-alsa.conf"
+			{
+@func getenv
+vars [
+	PULSE_ALSA_HOOK_CONF
+]
+default "/usr/share/alsa/pulse-hook.conf"
+			}
 		]
 		errors false
 	}
diff -Nru pulseaudio-9.0.orig/debian/pulse-hook.conf pulseaudio-9.0/debian/pulse-hook.conf
--- pulseaudio-9.0.orig/debian/pulse-hook.conf	1970-01-01 01:00:00.0 +0100
+++ pulseaudio-9.0/debian/pulse-hook.conf	2016-08-13 04:40:38.0 +0200
@@ -0,0 +1,16 @@
+# PulseAudio alsa plugin configuration file to set the pulseaudio plugin as
+# default output for applications using alsa when pulseaudio is running.
+hook_func.pulse_load_if_running {
+	lib "libasound_module_conf_pulse.so"
+	func "conf_pulse_hook_load_if_running"
+}
+
+@hooks [
+	{
+		func pulse_load_if_running
+		files [
+			"/usr/share/alsa/pulse-alsa.conf"
+		]
+		errors false
+	}
+]
diff -Nru pulseaudio-9.0.orig/debian/rules pulseaudio-9.0/debian/rules
--- pulseaudio-9.0.orig/debian/rules	2016-08-13 04:40:38.0 +0200
+++ pulseaudio-9.0/debian/rules	2016-08-28 19:07:54.0 +0200
@@ -16,7 +16,7 @@
 	mkdir -p $(CURDIR)/debian/tmp/usr/share/alsa/alsa.conf.d
 	cp -a $(CURDIR)/debian/pulse.conf \
 		$(CURDIR)/debian/tmp/usr/share/alsa/alsa.conf.d
-	cp -a $(CURDIR)/debian/pulse-alsa.conf $(CURDIR)/debian/tmp/usr/share/alsa
+	cp -a $(CURDIR)/debian/pulse-alsa.conf $(CURDIR)/debian/pulse-hook.conf $(CURDIR)/debian/tmp/usr/share/alsa
 	install -d $(CURDIR)/debian/tmp/usr/share/apport/package-hooks
 	cp $(CURDIR)/debian/apport-hook.py $(CURDIR)/debian/tmp/usr/share/apport/package-hooks/source_pulseaudio.py
 


smime.p7s
Description: S/MIME cryptographic signature

Bug#835589: libjack-jackd2-0: libjack-0.116 is not equivalent to libjack-jackd2-0

[Javier Serrano Polo]

Package: libjack-jackd2-0
Version: 1.9.10+20150825git1ed50c92~dfsg-2
Severity: wishlist
Control: clone -1 -2
Control: reassign -2 libsoundio1
Control: retitle -2 libsoundio1: Missing hard dependency on libjack-jackd2-0
Control: found -2 1.0.2-1

libsoundio1 depends on jack_set_port_rename_callback, which is provided
by libjack-jackd2-0 only. libjack-jackd2-0 should provide a symbols file
to know if libjack0 (libjack-0.116) is a valid alternative. libsoundio1
could add a manual dependency on libjack-jackd2-0 while waiting for this
symbols file.


smime.p7s
Description: S/MIME cryptographic signature

Bug#834083: libc-bin: essential tag

[Javier Serrano Polo]

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

El dj 11 de 08 de 2016 a les 22:42 +0200, Aurelien Jarno va escriure:
> | dpkg: warning: 'ldconfig' not found in PATH or not executable.
> | dpkg: 1 expected program not found in PATH or not executable.
> | NB: root's PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin.
> | E: Sub-process /usr/bin/dpkg returned an error code (2)
> 
> So it is clearly not correct to say that a squeeze or a sid system can
> work without them.

Sorry, by "system based on Squeeze" I meant a Debian derivative; it
works "with a dpkg that does not require ldconfig". The matter is
whether this ability to run without libc-bin could be merged back into
Debian. Since libc-bin is intended to be essential and the POSIX
requirement looks like a good reason, it is better not to push these
changes.


smime.p7s
Description: S/MIME cryptographic signature

Bug#834083: libc-bin: essential tag

[Javier Serrano Polo]

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

El dj 11 de 08 de 2016 a les 21:55 +0200, Aurelien Jarno va escriure:
> On 2016-08-11 21:32, Javier Serrano Polo wrote:
> > libc-bin is tagged essential since 2.13-10. Old systems based on Squeeze
> > can work without libc-bin, with a dpkg that does not require ldconfig.
> 
> No they can't. In squeeze, the binaries from libc-bin were included in
> libc6. The package has been split as part of the switch to multiarch.

This is not correct:
https://archive.debian.net/squeeze/libc-bin

> > Could anyone explain why libc-bin is essential?
> 
> Because it provides binaries and configuration files essential for the
> system: ldconfig, getent, ld.so.conf, nsswitch.conf, C.UTF-8 locale, etc.

These elements are very useful, but a system based on Squeeze can work
without them. Is there any other reason in a Sid system?


smime.p7s
Description: S/MIME cryptographic signature

Bug#834083: libc-bin: essential tag

[Javier Serrano Polo]

Package: libc-bin
Version: 2.23-4
Severity: wishlist
X-Debbugs-CC: cl...@debian.org, aure...@debian.org, adcon...@0c3.net, 
sthiba...@debian.org

libc-bin is tagged essential since 2.13-10. Old systems based on Squeeze
can work without libc-bin, with a dpkg that does not require ldconfig.
Could anyone explain why libc-bin is essential?


smime.p7s
Description: S/MIME cryptographic signature

Bug#833964: dpkg-dev: Allow dpkg-scanpackages to scan single files

[Javier Serrano Polo]

Package: dpkg-dev
Version: 1.18.10
Severity: wishlist
Tags: patch

It would be nice if dpkg-scanpackages could scan a single file without
scanning all files in the containing directory.
diff -Nru dpkg-1.18.10.orig/man/dpkg-scanpackages.1 dpkg-1.18.10/man/dpkg-scanpackages.1
--- dpkg-1.18.10.orig/man/dpkg-scanpackages.1	2016-07-05 03:55:13.0 +0200
+++ dpkg-1.18.10/man/dpkg-scanpackages.1	2016-08-11 00:04:27.0 +0200
@@ -24,7 +24,7 @@
 .
 .SH SYNOPSIS
 .B dpkg\-scanpackages
-.RI [ option "...] " binary-dir
+.RI [ option "...] " binary-path
 .RI [ override-file
 .RI [ path-prefix ]]
 .B >
@@ -57,7 +57,7 @@
 .B file://
 sources).
 .PP
-.I binary-dir
+.I binary-path
 is the name of the tree of the binary packages to process (for example,
 .BR contrib/binary\-i386 ).
 It is best to make this relative to the root of the Debian archive,
diff -Nru dpkg-1.18.10.orig/scripts/dpkg-scanpackages.pl dpkg-1.18.10/scripts/dpkg-scanpackages.pl
--- dpkg-1.18.10.orig/scripts/dpkg-scanpackages.pl	2016-07-05 03:55:14.0 +0200
+++ dpkg-1.18.10/scripts/dpkg-scanpackages.pl	2016-08-11 00:04:48.0 +0200
@@ -231,10 +231,10 @@
 }
 }
 
-my ($binarydir, $override, $pathprefix) = @ARGV;
+my ($binarypath, $override, $pathprefix) = @ARGV;
 
-if (not -d $binarydir) {
-error(g_('binary directory %s not found'), $binarydir);
+if (not -e $binarypath) {
+error(g_('binary path %s not found'), $binarypath);
 }
 if (defined $override and not -e $override) {
 error(g_('override file %s not found'), $override);
@@ -253,7 +253,7 @@
 push @archives, $File::Find::name if m/$find_filter/;
 };
 
-find({ follow => 1, follow_skip => 2, wanted => $scan_archives}, $binarydir);
+find({ follow => 1, follow_skip => 2, wanted => $scan_archives}, $binarypath);
 foreach my $fn (@archives) {
 process_deb($pathprefix, $fn);
 }


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

Control: tags -1 patch

This patch fixes the issue.
--- a/Debian/Debhelper/Dh_Lib.pm	2016-07-09 09:53:02.0 +
+++ b/Debian/Debhelper/Dh_Lib.pm	2016-07-27 00:48:29.0 +
@@ -39,6 +39,8 @@
 	_gz
 );
 
+use List::Util qw(any);
+
 # The Makefile changes this if debhelper is installed in a PREFIX.
 my $prefix="/usr";
 
@@ -968,6 +970,9 @@
 		}
 		if (/^(?:X[BC]*-)?Package-Type:\s*(.*)/i) {
 			$package_type=$1;
+			if ($package_type eq 'udeb' and any { $_ eq 'noudeb' } @profiles) {
+$included_in_build_profile=0;
+			}
 		}
 		if (/^Multi-Arch: \s*(.*)\s*/i) {
 			$multiarch = $1;
@@ -977,15 +982,17 @@
 		# high enough version of dpkg-dev is needed anyways
 		if (/^Build-Profiles:\s*(.*)/i) {
 		my $build_profiles=$1;
-			eval {
-require Dpkg::BuildProfiles;
-my @restrictions=Dpkg::BuildProfiles::parse_build_profiles($build_profiles);
-if (@restrictions) {
-	$included_in_build_profile=Dpkg::BuildProfiles::evaluate_restriction_formula(\@restrictions, \@profiles);
+			if ($included_in_build_profile) {
+eval {
+	require Dpkg::BuildProfiles;
+	my @restrictions=Dpkg::BuildProfiles::parse_build_profiles($build_profiles);
+	if (@restrictions) {
+		$included_in_build_profile=Dpkg::BuildProfiles::evaluate_restriction_formula(\@restrictions, \@profiles);
+	}
+};
+if ($@) {
+	error("The control file has a Build-Profiles field. Requires libdpkg-perl >= 1.17.14");
 }
-			};
-			if ($@) {
-error("The control file has a Build-Profiles field. Requires libdpkg-perl >= 1.17.14");
 			}
 		}
 


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

Package: debhelper
Version: 9.20160709
Severity: wishlist

udeb packages are being processed when the noudeb build profile is
active. It should not be necessary to include:
Build-Profiles: 
in debian/control. 


smime.p7s
Description: S/MIME cryptographic signature

Bug#831524: dpkg: Add a way to drop the Built-For-Profiles field

[Javier Serrano Polo]

Control: tags -1 patch

El dg 17 de 07 de 2016 a les 00:23 +0200, Javier Serrano Polo va
escriure:
> a third way is at
> build time with a build profile named "clean" (or "dirty") in
> DEB_BUILD_PROFILES.

The solution with "clean" is the simplest to implement, keeping the
behavior of setting Built-For-Profiles by default.
--- a/scripts/dpkg-gencontrol.pl	2016-07-04 11:00:33.0 +
+++ b/scripts/dpkg-gencontrol.pl	2016-07-22 20:38:47.0 +
@@ -298,7 +298,9 @@
 }
 }
 
-$fields->{'Built-For-Profiles'} = join ' ', get_build_profiles();
+my @build_profiles = get_build_profiles();
+$fields->{'Built-For-Profiles'} = join ' ', @build_profiles
+unless any { $_ eq 'clean' } @build_profiles;
 
 for my $f (qw(Package Version Architecture)) {
 error(g_('missing information for output field %s'), $f)


smime.p7s
Description: S/MIME cryptographic signature

Bug#832041: wine32-tools: Missing dependency on g++-multilib

[Javier Serrano Polo]

Package: wine32-tools
Version: 1.8.3-2
Severity: wishlist

Because of wineg++, wine32-tools should depend on g++ or g++-multilib,
like the gcc dependency. Otherwise, indirect dependency
lib32stdc++-5-dev will not be installed and development files will be
missing.


smime.p7s
Description: S/MIME cryptographic signature

Bug#831524: dpkg: Add a way to drop the Built-For-Profiles field

[Javier Serrano Polo]

Package: dpkg
Version: 1.18.9
Severity: wishlist

As discussed in
https://lists.debian.org/debian-dpkg/2016/07/threads.html#00021 , there
should be a way to include the Built-For-Profiles field only when dirty
build profiles are active. Clean build profiles should yield identical
binary packages to those when no build profiles are active.

This may be useful when building a subset of binary packages for
testing, debugging, derivatives waiting for their changes to be merged
in Debian, and providing faster security updates locally. In Squeeze,
there were 21 packages (including exim4, gcc-4.4, gtk+2.0 and linux-2.6)
where building only a subset reduced compilation time or disk space
significantly.

Building a subset of packages can be achieved with build profiles. This
can also be solved with an independent environment variable, such as
DEB_BUILD_FLAVOURS or DEB_BUILD_PACKAGES, which would avoid
Built-For-Profiles.

The solution for the Built-For-Profiles field is to either drop it and
rely on .buildinfo files, or mark some build profiles as dirty or clean.
One way to mark is in binary stanzas with
"Build-Profiles-Content-Changes"; another way is in source stanzas with
"Clean-Build-Profiles" (or "Dirty-Build-Profiles"); a third way is at
build time with a build profile named "clean" (or "dirty") in
DEB_BUILD_PROFILES.


smime.p7s
Description: S/MIME cryptographic signature

Bug#757760: debian-policy: please document build profiles

[Javier Serrano Polo]

On Wed, 13 Jul 2016 07:10:16 +0200 Johannes Schauer  wrote:
> because of technical reasons?

Administrative reasons (https://bugs.debian.org/831059). I will have to
open a bug against dpkg for this issue.

(I have worked around the error in my mail server.)


smime.p7s
Description: S/MIME cryptographic signature

Bug#831059: lists.debian.org: Permanently banned users cannot send positive contributions to lists.debian.org

[Javier Serrano Polo]

El dj 14 de 07 de 2016 a les 07:40 +0100, Adam D. Barratt va escriure:
> For avoidance of doubt, "this user" appears to be you. I'm not sure
> why you didn't just say that.

"This user" is me, Javier Serrano Polo. I was abstracting the problem
from the specific user (me).

El dj 14 de 07 de 2016 a les 10:08 +0200, Alexander Wirt va escriure:
> I don't think that it is acceptable to write a mail in that way and to make
> the impression that you are asking for someone else.

Sorry for the confusion. Although my question was about generic "banned
users", the example user is me. I hope you believe that I was not asking
for someone else when the first link says "jav...@jasp.net", which is my
address.

> That, together with the reason for what you have been banned for (mails like
> [1]) don't make me think that lifting the ban is a good idea.

I would like to contextualize the message [1]. It was sent on the feast
of the holy innocents [2] (it is in Spanish, I cannot find a good
English resource).

I sent that message. I was just trying to help and I thought I was doing
the right thing. I am trying to move forward and continue helping. I can
explain myself again and answer all your questions about what I did. But
I did not open this bug report to talk about the past or to question the
listmaster (Alex) that banned me; I understand that listmasters do their
role as best as they can. I am here to talk about my future behavior.

I made jokes that some people did not like. It is easy for me to not
make any more jokes. I believe that banned users should have a way to
redeem themselves and make positive contributions. IMHO, I think I
deserve an opportunity; is there something I can do?

> That is my personal oppinion as listmaster. Lets see what other listmaster
> have to say.

Alex, your opinion is important to me. I would like to know if I have
convinced you that you can give me a chance.

[2] 
https://es.wikipedia.org/wiki/D%C3%ADa_de_los_Santos_Inocentes#Conmemoraci.C3.B3n.2C_bromas_e_inocentadas


smime.p7s
Description: S/MIME cryptographic signature

Bug#831059: lists.debian.org: Permanently banned users cannot send positive contributions to lists.debian.org

[Javier Serrano Polo]

Package: lists.debian.org
Severity: wishlist

Some users want to contribute to Debian, but they exceptionally make
disruptive contributions to lists.debian.org and are permanently banned.

For instance, this banned user is helping with packages:
https://qa.debian.org/developer.php?login=jav...@jasp.net
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824715

He has trouble interacting with maintainers that are lists.debian.org
accounts:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746498#34
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757760#36

He would like to contribute to threads where he is involved:
https://lists.debian.org/debian-dpkg/2016/07/msg00025.html
https://lists.debian.org/debian-dpkg/2016/07/msg00030.html

The user has been banned just once. According to the user, he intends to
not incur further disruption.

Is there something a banned user can to do to remove or relax the ban?


smime.p7s
Description: S/MIME cryptographic signature

Bug#757760: debian-policy: please document build profiles

[Javier Serrano Polo]

Sorry, I missed your message.

> I'm removing #757760 from the recipients because that bug should
> contain a discussion about the implementation of the current build
> profile spec and should not be a discussion platform for further
> additions or changes to the spec. Lets use debian-dpkg@ to discuss
> this issue.

The BTS is my only way to keep an open discussion. I really cannot post
to lists.debian.org (I can to Alioth lists); should I try to fix that?
We can discuss in #830524.


smime.p7s
Description: S/MIME cryptographic signature

Bug#757760: debian-policy: please document build profiles

[Javier Serrano Polo]

El dg 10 de 07 de 2016 a les 19:25 +0200, Javier Serrano Polo va
escriure:
> For instance, the linux source
> package should have a way to build only linux-image-4.6.0-1-686 (profile
> pkg.linux.686)

Current linux package already uses build profiles. It looks like the
specification works better in negative form. For instance, the field for
linux-image-4.6.0-1-686 should be:
Build-Profiles: 

Perhaps, the "<>" token is not needed.


smime.p7s
Description: S/MIME cryptographic signature

Bug#830913: debian-policy: Allow amd64 systems without /lib64

[Javier Serrano Polo]

Package: debian-policy
Version: 3.9.8.0
Severity: wishlist

Some amd64 systems do not have /lib64, although they can run programs
with the interpreter set to /lib64/ld-linux-x86-64.so.2 . It would be
nice if Debian could allow such systems. In section 9.1.1, where it
says:

The execution time linker/loader, ld*, must still be made
available in the existing location under /lib or /lib64

"must" should be "should".


smime.p7s
Description: S/MIME cryptographic signature

Bug#757760: debian-policy: please document build profiles

[Javier Serrano Polo]

On Sat, 09 Jul 2016 23:56:03 +0200 Johannes Schauer 
wrote:
> I'm CC-ing debian-dpkg@.

I cannot CC lists.debian.org. You will not see my messages in
https://lists.debian.org/debian-policy/2016/07/threads.html .

> I suspect you want to express "this package has to be built when no
> profiles are active as well as when the pkg.linux.zlib profile is
> active"?

Yes.

> If so, then why do you need the Build-Profiles field at all?

Because the package should not be built if other pkg.linux.* profiles
are active.

> What is your use case?

There is an introduction at https://bugs.debian.org/830524 . The goal is
to build a subset of binary packages. For instance, the linux source
package should have a way to build only linux-image-4.6.0-1-686 (profile
pkg.linux.686), only linux-image-4.6.0-1-rt-686-pae (profile
pkg.linux.rt-686-pae), etc. The nodebug profile would be useful to not
build *-dbg packages.

> > I gather that the Built-For-Profiles field is written to
> > DEBIAN/control

> Why do you want to avoid this field? Why would this be useful?

Binary packages should be exactly the same as if built without active
profiles. This helps making and checking a subset of reproducible
packages.


smime.p7s
Description: S/MIME cryptographic signature

Bug#757760: debian-policy: please document build profiles

[Javier Serrano Polo]

Where is this feature discussed?

Could the token "<>" indicate "no build profiles"? That would allow:
Build-Profiles:  <>

I gather that the Built-For-Profiles field is written to DEBIAN/control
when DEB_BUILD_PROFILES is not empty. Could a profile "subset" avoid
this field? Example:
DEB_BUILD_PROFILES="subset pkg.linux.zlib"


smime.p7s
Description: S/MIME cryptographic signature

Bug#830524: debian-policy: Allow building only selected flavors

[Javier Serrano Polo]

Control: merge -1 757760

It looks like build profiles can do the same.


smime.p7s
Description: S/MIME cryptographic signature

Bug#830524: debian-policy: Allow building only selected flavors

[Javier Serrano Polo]

Package: debian-policy
Version: 3.9.8.0
Severity: wishlist

Some source packages build more than one version of binaries using
different configuration options; these versions are called flavors. In
some cases, only a subset of flavors or components is needed, which is
translated into a subset of binary packages. Building only selected
flavors is useful for developers that try to fix bugs, and derivatives
whose patches are not merged in Debian.

A standard to express this flavor selection is desirable, like
DEB_BUILD_OPTIONS. For instance, I use DEB_BUILD_FLAVOURS="flavor1
flavor2". The following example packages use flavors; they are from
Squeeze, but I hope you get the idea:

Package: eglibc
Flavors: libc i686 xen amd64

Package: gcc-4.4
Flavors: base fixincl fortran libmudflap objc objcxx proto

Package: libsdl1.2
Flavors: all arts esd oss nas pulseaudio alsa udeb

Package: linux-2.6
Flavors: none_amd64 none_amd64-dbg openvz_amd64 openvz_amd64-dbg
vserver_amd64 vserver_amd64-dbg xen_amd64 xen_amd64-dbg headers
indep-doc indep-linux-base

Package: mesa
Flavors: dri glw glx other dri-i915 dri-i965 dri-mach64 dri-mga dri-r128
dri-r200 dri-r300 dri-r600 dri-radeon dri-savage dri-sis
dri-swrast dri-tdfx dri-unichrome


smime.p7s
Description: S/MIME cryptographic signature

Bug#826524: opensc-pkcs11: Fix interaction with DNIe UI

[Javier Serrano Polo]

Package: opensc-pkcs11
Version: 0.16.0~rc2-1
Severity: minor
Tags: patch

The interaction with the DNIe UI does not work on Firefox because an
alarm interrupts the read operations, aborting the confirmation.
Description: Fix interaction with DNIe UI
 The interaction with the DNIe UI does not work on Firefox because an alarm
 interrupts the read operations, aborting the confirmation. This is fixed by
 using nointr_fgets(). There are side issues:
 * Forked process should abort on failure instead of continuing with OpenSC.
 * Useless initializations with memset().
 * Size adjustments in read and write operations.
Author: Javier Serrano Polo <jav...@jasp.net>
Forwarded: https://github.com/OpenSC/OpenSC/pull/789

Index: opensc-0.16.0~rc2/src/libopensc/card-dnie.c
===
--- opensc-0.16.0~rc2.orig/src/libopensc/card-dnie.c	2016-06-05 20:48:32.0 +0200
+++ opensc-0.16.0~rc2/src/libopensc/card-dnie.c	2016-06-06 01:42:11.0 +0200
@@ -162,6 +162,25 @@
 char *user_consent_msgs[] = { "SETTITLE", "SETDESC", "CONFIRM", "BYE" };
 
 /**
+ * Do fgets() without interruptions.
+ *
+ * Retry the operation if it is interrupted, such as with receiving an alarm.
+ *
+ * @param s Buffer receiving the data
+ * @param size Size of the buffer
+ * @param stream Stream to read
+ * @return s on success, NULL on error
+ */
+static char *nointr_fgets(char *s, int size, FILE *stream)
+{
+	while (fgets(s, size, stream) == NULL) {
+		if (feof(stream) || errno != EINTR)
+			return NULL;
+	}
+	return s;
+}
+
+/**
  * Ask for user consent.
  *
  * Check for user consent configuration,
@@ -283,9 +302,8 @@
 		/* call exec() with proper user_consent_app from configuration */
 		/* if ok should never return */
 		execlp(GET_DNIE_UI_CTX(card).user_consent_app, GET_DNIE_UI_CTX(card).user_consent_app, (char *)NULL);
-		res = SC_ERROR_INTERNAL;
-		msg = "execlp() error";	/* exec() failed */
-		goto do_error;
+		sc_log(card->ctx, "execlp() error");
+		abort();
 	default:		/* parent */
 		/* Close the pipe ends that the child uses to read from / write to
 		 * so when we close the others, an EOF will be transmitted properly.
@@ -304,22 +322,24 @@
 			goto do_error;
 		}
 		/* read and ignore first line */
-		fflush(stdin);
+		if (nointr_fgets(buf, sizeof(buf), fin) == NULL) {
+			res = SC_ERROR_INTERNAL;
+			msg = "nointr_fgets() Unexpected IOError/EOF";
+			goto do_error;
+		}
 		for (n = 0; n<4; n++) {
 			char *pt;
-			memset(outbuf, 0, sizeof(outbuf));
-			if (n==0) snprintf(outbuf,1023,"%s %s\n",user_consent_msgs[0],title);
-			else if (n==1) snprintf(outbuf,1023,"%s %s\n",user_consent_msgs[1],message);
-			else snprintf(outbuf,1023,"%s\n",user_consent_msgs[n]);
+			if (n==0) snprintf(outbuf, sizeof outbuf,"%s %s\n",user_consent_msgs[0],title);
+			else if (n==1) snprintf(outbuf, sizeof outbuf,"%s %s\n",user_consent_msgs[1],message);
+			else snprintf(outbuf, sizeof outbuf,"%s\n",user_consent_msgs[n]);
 			/* send message */
 			fputs(outbuf, fout);
 			fflush(fout);
 			/* get response */
-			memset(buf, 0, sizeof(buf));
-			pt=fgets(buf, sizeof(buf) - 1, fin);
+			pt=nointr_fgets(buf, sizeof(buf), fin);
 			if (pt==NULL) {
 res = SC_ERROR_INTERNAL;
-msg = "fgets() Unexpected IOError/EOF";
+msg = "nointr_fgets() Unexpected IOError/EOF";
 goto do_error;
 			}
 			if (strstr(buf, "OK") == NULL) {


smime.p7s
Description: S/MIME cryptographic signature

Bug#826110: swh-plugins, vocoder-ladspa: error when trying to install together

[Javier Serrano Polo]

Control: reassing -1 vocoder-ladspa
Control: affects -1 swh-plugins

I will ask to upload a new version of lmms to remove vocoder-ladspa.


smime.p7s
Description: S/MIME cryptographic signature

Bug#824673: Bug#824211: marked as pending

[Javier Serrano Polo]

El dt 31 de 05 de 2016 a les 14:09 +, Jaromír Mikeš va escriure:
> +  * Fix multi-arch path.

Will the plug-ins be installed under /usr/lib/*/ladspa? I would be in
favor, but AFAIK this would be the first Debian package to ship LADSPA
plug-ins under a multiarch folder instead of /usr/lib/ladspa.


smime.p7s
Description: S/MIME cryptographic signature

Bug#824211: marked as pending

[Javier Serrano Polo]

El dt 31 de 05 de 2016 a les 14:09 +, Jaromír Mikeš va escriure:
> +  * Fix multi-arch path.

Will the plug-ins be installed under /usr/lib/*/ladspa? I would be in
favor, but AFAIK this would be the first Debian package to ship LADSPA
plug-ins under a multiarch folder instead of /usr/lib/ladspa.


smime.p7s
Description: S/MIME cryptographic signature