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
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?
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
>
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:
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
libc6 does no longer depend on libc-bin. This bug is fixed.
smime.p7s
Description: S/MIME cryptographic signature
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
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
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;
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
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:
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
e: 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
We had some words at #debian-bootstrap. Helmut agrees. I will fix this
someday.
smime.p7s
Description: S/MIME cryptographic signature
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
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
Where should I report issues about the spec in the meantime?
smime.p7s
Description: S/MIME cryptographic signature
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
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
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
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
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
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
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
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
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,
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
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:
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: Javie
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
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
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
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.
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
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
> 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:
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
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
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.
>
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
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
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]
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
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
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
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.
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,
> > 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
>
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
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
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
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
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.
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
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
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
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
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).
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.
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
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
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
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
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
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
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 = '';
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
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
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
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
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.000
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
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 =
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
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
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
(
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
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.
>
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 Squeez
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
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
---
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
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
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 imp
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
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
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
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
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:
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
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 wor
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
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
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:
Control: merge -1 757760
It looks like build profiles can do the same.
smime.p7s
Description: S/MIME cryptographic signature
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
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 2
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
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
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
101 - 200 of 501 matches
Mail list logo