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

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

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

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?

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

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 >

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

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:

Bug#889106: Multiarch interpreter names for traditional architectures

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

Bug#614708: libc6 could just Recommends libc-bin

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

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

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

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

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

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;

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

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

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

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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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:

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

> 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:

Bug#884640: firefox: Internationalized extensions are broken

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

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

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. >

Bug#859793: fluidsynth: Package has infringed GPL

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

Bug#859793: fluidsynth: Package has infringed GPL

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

Bug#859793: fluidsynth: Package has infringed GPL

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]

Bug#859793: fluidsynth: Package has infringed GPL

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

Bug#859793: fluidsynth: Package has infringed GPL

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

Bug#859793: fluidsynth: Package has infringed GPL

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

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

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.

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

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,

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

> > 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 >

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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).

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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 = '';

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

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

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

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

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

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

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

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

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

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

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

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

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

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 =

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

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

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

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

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 (

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

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

Bug#834083: libc-bin: essential tag

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. >

Bug#834083: libc-bin: essential tag

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

Bug#834083: libc-bin: essential tag

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

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

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 ---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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

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

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

Bug#824211: marked as pending

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

<    1   2   3   4   5   6   >