Bug#966373: Please stop reopening bugs that maintainers have closed
On Wed, 17 Mar 2021 16:12:37 -0700 Don Armstrong wrote: > Please stop reopening bugs which have been closed by Debian Maintainers. Please, Don, could you guide me on this matter? The bug focus has changed, thus I retitled the bug and I thought wontfix was not valid now. Should I open a new report instead? What should I do when maintainers are unresponsive or do not explain their actions? Should I never reopen a report? Thank you. smime.p7s Description: S/MIME cryptographic signature
Bug#966373: general: Version for derivatives between binNMU and stable update
On Thu, 15 Oct 2020 21:25:51 +0200 Javier Serrano Polo wrote: > Thus, there are three choices: > >1. Before binNMU (case 1.0-1deriv1). >2. After stable update (case 1.0-1+deriv1). >3. Between binNMU and stable update. This is what I am asking for. > > Would you agree to preserve this third choice if it is currently > feasible? Dear Paul Wise, Package linux parses the Debian version. Could we settle on a version pattern for derivatives that lies between binNMU and stable update? smime.p7s Description: S/MIME cryptographic signature
Bug#954794: Permit packages to declare dependencies on Essential packages
On Mon, 16 Nov 2020 16:11:53 -0800 Jonathan Nieder wrote: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=nonessentiale2fsprogs;users=helm...@debian.org > shows that people are already adding explicit dependencies on it, > which means that > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954794;msg=111 is > the de facto policy / what people believe policy to say. So, should policy change? Currently, it says that packages "should not" declare essential dependencies, which is more permissive than "must not". Is the workflow with e2fsprogs the path to follow? smime.p7s Description: S/MIME cryptographic signature
Bug#890834: gtk+2.0: Add build profiles to skip flavors and packages
Control: tags -1 - moreinfo More information was provided. smime.p7s Description: S/MIME cryptographic signature
Bug#890556: aptitude: Add build profile to skip documentation packages
Control: tags -1 - moreinfo More information was provided. smime.p7s Description: S/MIME cryptographic signature
Bug#837723: Removing/Disabling the general psuedo package; refering to debian-u...@lists.debian.org
On Mon, 26 Oct 2020 22:10:56 +0100 Javier Serrano Polo wrote: > I am trying to solve a bug, Perhaps this should be a permanent bug without the wontfix tag. I do not know why wontfix would not be correct, but I will leave the tagging to other users. I have provided a patch; without feedback, I think I have helped as much as possible with this issue. -- "We saw how there is peace even in the storm." Famous painter smime.p7s Description: S/MIME cryptographic signature
Bug#966373: general: Higher version for uploads to stable and oldstable distributions
On Mon, 19 Oct 2020 12:33:09 +0200 Julien Cristau wrote: > tags 966373 + wontfix > close 966373 Another closure, this time without excuse. It is obviously a mistake, because Debian derivatives are welcome, right? I will correct this. Adam D. Barratt did not answer my previous questions, thus she needs more time. smime.p7s Description: S/MIME cryptographic signature
Bug#854973: lists.debian.org: Create debian-banned
Control: reopen -1 El dg 18 de 10 de 2020 a les 22:40 +0200, Javier Serrano Polo va escriure: > Otherwise, I will reopen this report. Reopening. smime.p7s Description: S/MIME cryptographic signature
Bug#837723: Removing/Disabling the general psuedo package; refering to debian-u...@lists.debian.org
On Sat, 24 Oct 2020 11:53:44 +0800 Paul Wise wrote: > # It is not up to people who are not submitters or BTS admins to determine the outcome for this bug What do you mean? Are you the submitter? No, you refused to be. Are you a BTS admin? No, you are not listed as a member. You determine the outcome, thus you do not follow your own guideline. I am trying to solve a bug, you are sabotaging this effort. So, either give a solution to this bug or let the submitter or BTS admins reply. Otherwise, I will tag this report as wontfix again and, if you undo this action, I may submit a complaint. smime.p7s Description: S/MIME cryptographic signature
Bug#854973: lists.debian.org: Create debian-banned
Control: submitter -1 ! On Sun, 18 Oct 2020 22:10:47 +0200 Geert Stappers wrote: > Closing this "new list request" > because in three years no one second the request. Closing this report does not make these Debian users disappear. Please clarify if you are officially recognizing your hate against such users. Otherwise, I will reopen this report. smime.p7s Description: S/MIME cryptographic signature
Bug#966373: general: Higher version for uploads to stable and oldstable distributions
On Sat, 10 Oct 2020 09:00:48 +0100 "Adam D. Barratt" wrote: > This has nothing specifically to do with updates to stable, and > changing the versioning used for source updates to stable will not > change it. If stable released with version 1.0-1 of package foo, then > it is entirely feasible that a binNMU will be required at some point, > and that will be versioned as 1.0-1+b1. Please make up your mind. If you are not interested in knowing the problem with 1-1+b1foo1 and 1-1+b1foo1+b1, then stop with the "ugliness" stuff. > It also conflicts with your original claims that you were trying to > avoid having a stable update - which would be a source change When did I say such a thing? > There are two choices for the derivative when making source changes. There are two patterns: 1. binNMU 2. stable update Thus, there are three choices: 1. Before binNMU (case 1.0-1deriv1). 2. After stable update (case 1.0-1+deriv1). 3. Between binNMU and stable update. This is what I am asking for. Would you agree to preserve this third choice if it is currently feasible? smime.p7s Description: S/MIME cryptographic signature
Bug#954794: New packages must not declare themselves Essential
On Wed, 07 Oct 2020 18:43:22 -0400 Sam Hartman wrote: > C) I'd support non-normative documentation that we don't expect to > approve new essential packages in the future in policy. Worthless documentation, I think. > A) I do support reducing the essential set over time Fine, then you should choose one essential package and remove it from the set for bullseye or bookworm. smime.p7s Description: S/MIME cryptographic signature
Bug#954794: New packages must not declare themselves Essential
On Wed, 30 Sep 2020 18:34:06 -0700 Jonathan Nieder wrote: > Even so, some *rough* consensus on the plan is very useful for > helping people evaluate that first step. Here is a rough plan: 1. Policy: Packages should declare all their dependencies, even essential ones. 2. Make easier this task: document dependencies, add Lintian checks, etc. 3. Policy: Packages must declare all their dependencies. 4. Wait until previous Debian releases become unsupported. 5. Drop support for Essential. smime.p7s Description: S/MIME cryptographic signature
Bug#966373: general: Higher version for uploads to stable and oldstable distributions
El dl 21 de 09 de 2020 a les 16:50 +0200, Javier Serrano Polo va escriure: > I will elaborate on the problem with 1-1+b1foo1 and 1-1+b1foo1+b1 if > you are willing to help. First, a binNMU in Debian may be unnecessary in the derivative. Following Debian binNMUs means unnecessary builds in architectures supported by the derivative and a burden for users in unsupported architectures. Moreover, the derivative would need to track all binary changes instead of source changes only. smime.p7s Description: S/MIME cryptographic signature
Bug#837723: Removing/Disabling the general psuedo package; refering to debian-u...@lists.debian.org
Control: tags -1 wontfix El dt 29 de 09 de 2020 a les 17:10 +0200, Javier Serrano Polo va escriure: > Thus, I will tag this report as wontfix. Tagging. smime.p7s Description: S/MIME cryptographic signature
Bug#954794: New packages must not declare themselves Essential
El dt 29 de 09 de 2020 a les 15:08 -0700, Josh Triplett va escriure: > I want to avoid letting the problem get any worse. So Essential packages are a problem. Do you want to remove Essential in the long-term? If this goal is not clear, there is little point in changing policy. New Essential packages will exist if there is a good- enough reason. smime.p7s Description: S/MIME cryptographic signature
Bug#971379: libnss3: Make CERT_AddCertToListTailWithData available
Package: libnss3 Version: 2:3.56-1 Severity: wishlist Function CERT_AddCertToListTailWithData is available in headers. Please make this function available in the library too. smime.p7s Description: S/MIME cryptographic signature
Bug#954794: New packages must not declare themselves Essential
El dl 21 de 09 de 2020 a les 17:15 +0200, Javier Serrano Polo va escriure: > Do you want to remove Essential? Since it looks like you do not try to eliminate Essential, I will close this report. smime.p7s Description: S/MIME cryptographic signature
Bug#966373: general: Higher version for uploads to stable and oldstable distributions
Control: reopen -1 El dl 21 de 09 de 2020 a les 16:50 +0200, Javier Serrano Polo va escriure: > Would you show your good intention by letting this discussion > happen in an opened report? Let us test your good intention. smime.p7s Description: S/MIME cryptographic signature
Bug#837723: Removing/Disabling the general psuedo package; refering to debian-u...@lists.debian.org
On Sat, 26 Sep 2020 10:47:52 +0800 Paul Wise wrote: > submitter 837723 Don Armstrong Paul Wise is not helping, since he undoes my work without any explanation. Let us continue. This bug is four years old, a patch has been submitted, and maintainers show no will to fix the bug. Thus, I will tag this report as wontfix. smime.p7s Description: S/MIME cryptographic signature
Bug#954794: New packages must not declare themselves Essential
On Mon, 23 Mar 2020 08:00:04 -0700 Josh Triplett wrote: > This change does not propose eliminating the concept of Essential, What is the point of Essential? To omit declaring dependencies on the false assumption that some packages are always required by all systems; the concept is essentially ill. Thus, if you are not pursuing the elimination of Essential, your effort is virtually useless. Do you want to remove Essential? smime.p7s Description: S/MIME cryptographic signature
Bug#966373: general: Higher version for uploads to stable and oldstable distributions
El dl 21 de 09 de 2020 a les 15:29 +0100, Adam D. Barratt va escriure: > You said disruptive. You are not addressing the reason I have given. I will elaborate on the problem with 1-1+b1foo1 and 1-1+b1foo1+b1 if you are willing to help. Closing bugs immediately and repeatedly seem the opposite to a desire to help. Would you show your good intention by letting this discussion happen in an opened report? smime.p7s Description: S/MIME cryptographic signature
Bug#966373: general: Higher version for uploads to stable and oldstable distributions
On Mon, 21 Sep 2020 14:53:33 +0100 "Adam D. Barratt" wrote: > ("These version numbers are ugly" Who did say that? Please reopen the bug and answer to the reason I have given, unless you admit that Debian derivatives are not welcome. smime.p7s Description: S/MIME cryptographic signature
Bug#970682: debian-policy: 5.6.12, temporarily forbid versions ending with zero
Package: debian-policy Version: 4.5.0.3 Severity: wishlist For those who care about Debian derivatives: Until #966373[1] is fixed, I propose adding this text to section 5.6.12: As a temporary measure to support Debian derivatives, versions must not explicitly end with zero (i.e., -0 or .0). -- [1] https://bugs.debian.org/966373 smime.p7s Description: S/MIME cryptographic signature
Bug#837723: Removing/Disabling the general psuedo package; refering to debian-u...@lists.debian.org
Control: submitter -1 p...@debian.org Control: tags -1 patch El dl 14 de 09 de 2020 a les 08:40 +0200, Javier Serrano Polo va escriure: > you should become the new submitter. Changing then. > Could you explain your reason for reopening this bug? I assume you are not satisfied with current situation, so I will provide a procedure for fixing this bug: 1. "general" should be disabled. 2. "multiple-packages" should handle bugs about multiple packages. Maintainer should be debian-de...@lists.debian.org. 3. "dont-know" should handle bugs where the submitter does not know the right package. Maintainer should be debian-u...@lists.debian.org. "general" could be kept instead of "multiple-packages" if you accept the risk of confusion with "dont-know". smime.p7s Description: S/MIME cryptographic signature
Bug#966373: general: Higher version for uploads to stable and oldstable distributions
Control: reopen -1 El dg 06 de 09 de 2020 a les 22:50 +0200, Javier Serrano Polo va escriure: > Otherwise, I will reopen this report. Reopening then. smime.p7s Description: S/MIME cryptographic signature
Bug#837723: Removing/Disabling the general psuedo package; refering to debian-u...@lists.debian.org
On Mon, 14 Sep 2020 13:40:48 +0800 Paul Wise wrote: > reopen 837723 Since the original submitter does not care anymore, you should become the new submitter. Could you explain your reason for reopening this bug? What is your request to the Debian bug tracking team? smime.p7s Description: S/MIME cryptographic signature
Bug#966373: general: Higher version for uploads to stable and oldstable distributions
El dg 06 de 09 de 2020 a les 11:59 +0200, Ansgar va escriure: > I didn't say that, Yes, Ansgar literally did:[1] If I were anyone else, "I would recommend to discuss on debian-devel@." Filing a bug against general was the right way; submitter's identity is irrelevant. > This > includes filing bugs that end up forwarded to said mailing lists. My reports to the BTS do not end up forwarded to mailing lists, which is known by their administrators. Ansgar's "recommendation" comes from intolerance and her closing of this report is out of place. > Please don't send me further mails. I will send messages to Ansgar if it is required to solve a Debian issue like this one. BTS managers: Please clarify whether I am banned from the BTS. Otherwise, I will reopen this report. -- [1] https://bugs.debian.org/966371#10 smime.p7s Description: S/MIME cryptographic signature
Bug#966373: general: Higher version for uploads to stable and oldstable distributions
On Sun, 30 Aug 2020 11:53:59 +0200 Chris Hofstaedtler wrote: > Filing this against the `general` package does nothing > useful for this discussion, On Mon, 27 Jul 2020 16:28:25 +0200 Ansgar wrote: > I would recommend to > discuss on debian-devel@. smime.p7s Description: S/MIME cryptographic signature
Bug#837723: Removing/Disabling the general psuedo package; refering to debian-u...@lists.debian.org
On Mon, 19 Sep 2016 13:18:39 +0100 Ian Jackson wrote: > If that doesn't work, might it be possible to make it impossible to > _report_ a bug against general, but still retain the ability to > _reassign_ a bug to general ? This would only complicate the handling of general bugs. As said, we need a place in the BTS for bugs which affect lots of packages. Perhaps you should rename "general" to "multiple-packages". Anyway, you are living with general four years later. May I close this report? smime.p7s Description: S/MIME cryptographic signature
Bug#883133: general: Add new package header Upstream-Version:
On Sat, 2 Dec 2017 11:08:32 + Simon McVittie wrote: > If you want to avoid packaging-system-specific code, you'll need to > query version numbers in a way that only relies on the upstream > software, The issue has been answered correctly. May I close this report? smime.p7s Description: S/MIME cryptographic signature
Bug#966357: security.debian.org: Higher version for security updates
See https://bugs.debian.org/966373. smime.p7s Description: S/MIME cryptographic signature
Bug#966371: project: Higher version for uploads to stable and oldstable distributions
See https://bugs.debian.org/966373. smime.p7s Description: S/MIME cryptographic signature
Bug#966373: general: Higher version for uploads to stable and oldstable distributions
Package: general Severity: wishlist For those who care about Debian derivatives: A derivative may be deployed as an overlay rather than a full archive. Modifications from the derivative live together with originals from Debian, but modifications must have a higher version. Full archives use this approach to increase the version: 1-1 → 1-1foo1 This does not work with overlays because of binNMUs: 1-1+b1 > 1-1foo1 1-1+b1 > 1-1foo1+b1 A binNMU may be unnecessary in the derivative. Also, these versions are disruptive: 1-1+b1foo1 1-1+b1foo1+b1 Thus, overlays should use this approach: 1-1 → 1-1.0foo1 However, regular uploads to stable and oldstable distributions may use the same signalization ("+") as binNMUs, so: 1-1+deb1u1 < 1-1.0foo1 Therefore, please use a higher version for these uploads, such as: 1-1 → 1-1.0+deb1u1 smime.p7s Description: S/MIME cryptographic signature
Bug#966371: project: Higher version for uploads to stable and oldstable distributions
Package: project Severity: wishlist For those who care about Debian derivatives: A derivative may be deployed as an overlay rather than a full archive. Modifications from the derivative live together with originals from Debian, but modifications must have a higher version. Full archives use this approach to increase the version: 1-1 → 1-1foo1 This does not work with overlays because of binNMUs: 1-1+b1 > 1-1foo1 1-1+b1 > 1-1foo1+b1 A binNMU may be unnecessary in the derivative. Also, these versions are disruptive: 1-1+b1foo1 1-1+b1foo1+b1 Thus, overlays should use this approach: 1-1 → 1-1.0foo1 However, regular uploads to stable and oldstable distributions may use the same signalization ("+") as binNMUs, so: 1-1+deb1u1 < 1-1.0foo1 Therefore, please use a higher version for these uploads, such as: 1-1 → 1-1.0+deb1u1 smime.p7s Description: S/MIME cryptographic signature
Bug#966357: security.debian.org: Higher version for security updates
Package: security.debian.org Severity: wishlist For those who care about Debian derivatives: A derivative may be deployed as an overlay rather than a full archive. Modifications from the derivative live together with originals from Debian, but modifications must have a higher version. Full archives use this approach to increase the version: 1-1 → 1-1foo1 This does not work with overlays because of binNMUs: 1-1+b1 > 1-1foo1 1-1+b1 > 1-1foo1+b1 A binNMU may be unnecessary in the derivative. Also, these versions are disruptive: 1-1+b1foo1 1-1+b1foo1+b1 Thus, overlays should use this approach: 1-1 → 1-1.0foo1 However, security updates may use the same signalization ("+") as binNMUs, so: 1-1+deb1u1 < 1-1.0foo1 Therefore, please use a higher version for security updates, such as: 1-1 → 1-1.0+deb1u1 smime.p7s Description: S/MIME cryptographic signature
Bug#947672: lists.debian.org: Javier Serrano Polo is banned
Empty words from a politician. smime.p7s Description: S/MIME cryptographic signature
Bug#947672: lists.debian.org: Javier Serrano Polo is banned
Package: lists.debian.org Severity: wishlist This user is permanently banned from all lists. Facts start at: https://lists.debian.org/debian-user-catalan/2013/12/msg00034.html To those less gifted in computer science: I am Javier Serrano Polo. To those third-person speech impaired: I am this user. smime.p7s Description: S/MIME cryptographic signature
Bug#946576: Mention the word "QR" in the one-line descriptions
El dc 11 de 12 de 2019 a les 14:25 +0800, 積丹尼 Dan Jacobson va escriure: > Now that QR codes are becoming more and more important, ZBar is not only about QR codes. > Else the user might not even know he has a QR code reader already > installed, or downloadable. There are better ways to achieve this. smime.p7s Description: S/MIME cryptographic signature
Bug#900451: fenix: please upload pending changes from git, or remove from Debian
On Wed, 30 May 2018 23:31:40 +0100 Simon McVittie wrote: > src:fenix has had pending changes in git since 2015 which have > not been uploaded. On 2019-02-13, fenix 0.92a.dfsg1-12 was accepted into unstable. Please close the report if you feel all significant issues have been solved. > I can't help questioning whether a project that still isn't 64-bit > clean is suitable for a stable release in 2018. Debian's structural policies may be the fault. smime.p7s Description: S/MIME cryptographic signature
Bug#888073: glibc: Support amd64 systems without /lib64
El dl 16 de 09 de 2019 a les 22:53 +0200, Samuel Thibault va escriure: > How can it start without its interpreter in /lib64? This is explained in the report. It uses an "ugly solution" that happens to be the only way for a regular user to override interpreters, as far as I know. > What does > ldd ./true print? linux-vdso.so.1 (0x7ffddd5a2000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f8c935f4000) /lib64/ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 (0x7f8c93b9a000) smime.p7s Description: S/MIME cryptographic signature
Bug#888073: glibc: Support amd64 systems without /lib64
El dv 26 de 01 de 2018 a les 19:18 +0100, Samuel Thibault va escriure: > Can you run the attached program? Yes, I can. It looks like the program is true from GNU coreutils 8.28. smime.p7s Description: S/MIME cryptographic signature
Bug#925771: lmms: ftbfs with GCC-9
On Wed, 27 Mar 2019 19:46:58 + Matthias Klose wrote: > /<>/plugins/LadspaEffect/calf/src/calf/giface.h:458:15: error: > 'memset' used with length equal to number of elements without multiplication > by element size [-Werror=memset-elt-size] > 458 | memset(ins, 0, sizeof(ins)); > | ~~^ Compiler is wrong. smime.p7s Description: S/MIME cryptographic signature
Bug#762209: /usr/bin/zbarcam: zbarcam crashes immediately
I have tested zbarcam from future version 0.21.1. It works. Uploading the new release should close this report. smime.p7s Description: S/MIME cryptographic signature
Bug#762114: monkeysign: monkeyscan fails to start with IndexError: list index out of range
I have tested zbarcam from future version 0.21.1. It works without warnings. Uploading the new release should close this report. smime.p7s Description: S/MIME cryptographic signature
Bug#920393: lmms: Find Wine 4 headers
Source: lmms Version: 1.1.3-8 Severity: wishlist Tags: patch Wine headers' location has changed in version 4. This patch fixes the build for i386.Description: Find Wine 4 headers Wine headers' location has changed in version 4. . Fixed upstream in 1.2.0. Author: Javier Serrano Polo Index: lmms-1.1.3/cmake/modules/FindWine.cmake === --- lmms-1.1.3.orig/cmake/modules/FindWine.cmake +++ lmms-1.1.3/cmake/modules/FindWine.cmake @@ -7,7 +7,7 @@ # WINE_DEFINITIONS - Compiler switches required for using wine # -FIND_PATH(WINE_INCLUDE_DIR windows/windows.h PATH_SUFFIXES wine) +FIND_PATH(WINE_INCLUDE_DIR windows/windows.h PATH_SUFFIXES wine wine/wine) FIND_LIBRARY(WINE_LIBRARY NAMES wine PATH_SUFFIXES wine) FIND_PROGRAM(WINE_CXX NAMES wineg++) smime.p7s Description: S/MIME cryptographic signature
Bug#918242: Take over lmms maintanenace
El dg 20 de 01 de 2019 a les 13:20 +0100, Ross Gammon va escriure: > Would you like me to remove you from the uploaders list? Do as you wish, I do not have upload permission. smime.p7s Description: S/MIME cryptographic signature
Bug#918242: Lmms Review
You seem to know what you want. Do you want to take over maintenance? Go ahead. smime.p7s Description: S/MIME cryptographic signature
Bug#918242: ITS: lmms
El dv 04 de 01 de 2019 a les 17:57 +0100, Ross Gammon va escriure: > And he has been recently adding information to some of the bugs, > including > asking for help to upload something. Indeed, I am still waiting. Boyuan Yang offered to sponsor too. I am fine if you do the upload. Next upstream version, namely 1.2.0, is not ready. > I am wondering if it would be a good idea to move lmms into the > Debian > Multimedia team where I could help with the maintenance. This is for Debian Edu developers to decide. smime.p7s Description: S/MIME cryptographic signature
Bug#897806: lmms: ftbfs with GCC-8
El dl 24 de 12 de 2018 a les 11:42 +0800, Boyuan Yang va escriure: > Could you provide a reference to it, especially an URL for the source > package? Request is at https://alioth-lists.debian.net/pipermail/debian-edu-pkg-team/Week-of-Mon-20181203/002400.html smime.p7s Description: S/MIME cryptographic signature
Bug#897806: lmms: ftbfs with GCC-8
I asked for an upload two weeks ago. smime.p7s Description: S/MIME cryptographic signature
Bug#910899: zbar: SQ code support
El dv 19 de 10 de 2018 a les 00:57 +0200, Bernd Zeimetz va escriure: > That is NOT an upstream project, that is just the packaging of zbar. Nevertheless, further discussion should be in GitHub.[2] We should be in coordination if you accept this new upstream source. -- [2] https://github.com/jasp00/zbar smime.p7s Description: S/MIME cryptographic signature
Bug#910899: zbar: SQ code support
El ds 13 de 10 de 2018 a les 02:40 +0200, Javier Serrano Polo va escriure: > Is it fine if I upload the project to GitHub? Bernd did already.[1] Further discussion should be in GitHub. -- [1] https://github.com/bzed/pkg-zbar smime.p7s Description: S/MIME cryptographic signature
Bug#893852: lmms: Please package new version and migrate to Qt5
This report is premature. smime.p7s Description: S/MIME cryptographic signature
Bug#870473: calf-ladspa: Conflicts with calf-plugins in ardour
I fail to see how this is a bug from LMMS and not from Ardour. smime.p7s Description: S/MIME cryptographic signature
Bug#875038: [lmms] Future Qt4 removal from Buster
On Fri, 23 Mar 2018 18:23:51 +0800 Boyuan Yang <073p...@gmail.com> wrote: > lmms 1.2.0 is on its way. I will not package a candidate version unless this bug becomes serious. Efforts should be directed in helping upstream to release a stable version. smime.p7s Description: S/MIME cryptographic signature
Bug#889042: lintian: Do not use dot as a separator in build profile names
El ds 13 de 10 de 2018 a les 08:52 +0100, Chris Lamb va escriure: > I still do not understand your unnecessary antagonism towards me (or > anyone) here, I will not explain side issues here because this report is meant for lintian. smime.p7s Description: S/MIME cryptographic signature
Bug#897806: lmms: ftbfs with GCC-8
El ds 13 de 10 de 2018 a les 11:14 +, Holger Levsen va escriure: > why don't you attach your fix to this bug? Because I am the lazy maintainer. smime.p7s Description: S/MIME cryptographic signature
Bug#910899: zbar: SQ code support
El ds 13 de 10 de 2018 a les 02:16 +0200, Bernd Zeimetz va escriure: > Debian is not the place where upstream > development happens. My offer to SourceForge did not get through. > Best would be if somebody would fork it and start to work on it > again, Is it fine if I upload the project to GitHub? I cannot become an active upstream, but I can watch over future efforts. smime.p7s Description: S/MIME cryptographic signature
Bug#889042: lintian: Do not use dot as a separator in build profile names
El dv 13 de 07 de 2018 a les 10:18 +0100, Chris Lamb va escriure: > > I do my job. Your position regarding humankind is > > established already. > > Sorry, I don't understand your response - can you elaborate? Why? No one wants to hear it. So, let me go back to work. smime.p7s Description: S/MIME cryptographic signature
Bug#910899: zbar: SQ code support
Source: zbar Version: 0.10+doc-10.1 Severity: wishlist I would like to offer the integration of SQ code support. This technology is somewhat usable now. smime.p7s Description: S/MIME cryptographic signature
Bug#897806: lmms: ftbfs with GCC-8
Someone should give me access to the repository, user jasp-guest. smime.p7s Description: S/MIME cryptographic signature
Bug#888073: glibc: Support amd64 systems without /lib64
El dc 24 de 01 de 2018 a les 23:18 +0100, Aurelien Jarno va escriure: > Just right a new ABI document for > the x86-64 CPU and create a new architecture from it. Then this > architecture can be supported by Debian. Someone thinks that was a serious reply, so... I would like to write an ABI document for the x86-64 CPU and create a new architecture from it. Obviously, this is not as simple as writing a document in my computer or starting a repository on GitHub. Could you explain what this creation process actually means? Thank you. smime.p7s Description: S/MIME cryptographic signature
Bug#897965: drascula: Clarify license and authors' intention
On Sat, 4 Aug 2018 03:27:02 +0800 Markus Koschany wrote: > Closing as not a bug. Whatever you say. However, there has been plenty of time for authors to respond. We can conclude that authors agree with section 3 of the license being ineffective. You may want to close #897965 too. smime.p7s Description: S/MIME cryptographic signature
Bug#904725: firefox: Add-ons that open windows can get an empty window
Package: firefox Version: 61.0-1 Severity: wishlist Tags: patch Control: forwarded -1 https://bugzilla.mozilla.org/1408446 This patch works with Firefox 61. It is essentially the same as the one for Firefox 60 in upstream report.Index: firefox-61.0/browser/components/extensions/parent/ext-windows.js === --- firefox-61.0.orig/browser/components/extensions/parent/ext-windows.js +++ firefox-61.0/browser/components/extensions/parent/ext-windows.js @@ -225,6 +225,10 @@ this.windows = class extends ExtensionAP if (createData.titlePreface !== null) { win.setTitlePreface(createData.titlePreface); } +// Do a dummy resize (bug 1408446) +window.addEventListener("DOMContentLoaded", () => { + window.resizeTo(window.outerWidth, window.outerHeight); +}); return win.convert({populate: true}); }); }, Index: firefox-61.0/widget/gtk/nsWindow.cpp === --- firefox-61.0.orig/widget/gtk/nsWindow.cpp +++ firefox-61.0/widget/gtk/nsWindow.cpp @@ -1112,6 +1112,22 @@ nsWindow::Show(bool aState) NativeShow(aState); } +// Add-ons may open windows that do not display their contents (bug 1408446), so +// invalidate the related layer when doing a repaint +static void +InvalidateFirstChildLayer(LayerManager* manager) +{ +Layer* root = manager->GetRoot(); +if (root) { +Layer* layer = root->GetFirstChild(); +if (layer) { +PaintedLayer *pLayer = layer->AsPaintedLayer(); +if (pLayer) +pLayer->InvalidateWholeLayer(); +} +} +} + void nsWindow::Resize(double aWidth, double aHeight, bool aRepaint) { @@ -1131,6 +1147,9 @@ nsWindow::Resize(double aWidth, double a NativeResize(); +if (aRepaint) +InvalidateFirstChildLayer(GetLayerManager()); + NotifyRollupGeometryChange(); // send a resize notification if this is a toplevel @@ -1159,6 +1178,9 @@ nsWindow::Resize(double aX, double aY, d NativeMoveResize(); +if (aRepaint) +InvalidateFirstChildLayer(GetLayerManager()); + NotifyRollupGeometryChange(); if (mIsTopLevel || mListenForResizes) { smime.p7s Description: S/MIME cryptographic signature
Bug#831104: xevil: FTBFS with GCC 6: stl_algobase.h:243:56: error: macro "min" passed 3 arguments, but takes just 2
Control: tags -1 patch Game works on stretch.Index: xevil-2.02r2/cmn/game.cpp === --- xevil-2.02r2.orig/cmn/game.cpp +++ xevil-2.02r2/cmn/game.cpp @@ -577,7 +577,7 @@ void GameObjects::level_reset(const Dim assert(maximums[weapons[n]->classId] == 0); // Don't allow objectWorldPercent values that are too small. - float objWPercent = (float)max(weapons[n]->objectWorldPercent, + float objWPercent = (float)MAX(weapons[n]->objectWorldPercent, OBJECT_WORLD_PERCENT_MIN); maximums[weapons[n]->classId] = (int)ceil(areaFactor * objWPercent); @@ -590,7 +590,7 @@ void GameObjects::level_reset(const Dim for (n = 0; n < oItemsNum; n++) { // Check not already set. assert(maximums[oItems[n]->classId] == 0); - float objWPercent = (float)max(oItems[n]->objectWorldPercent, + float objWPercent = (float)MAX(oItems[n]->objectWorldPercent, OBJECT_WORLD_PERCENT_MIN); maximums[oItems[n]->classId] = (int)ceil(areaFactor * objWPercent); Index: xevil-2.02r2/cmn/utils.h === --- xevil-2.02r2.orig/cmn/utils.h +++ xevil-2.02r2/cmn/utils.h @@ -98,11 +98,11 @@ extern "C" { #define MSEC_PER_CLOCK (1.0e3 / CLOCKS_PER_SEC) #endif -#ifndef max -#define max(a,b) (ab ? b : a) +#ifndef MIN +#define MIN(a,b) (a>b ? b : a) #endif #if X11 smime.p7s Description: S/MIME cryptographic signature
Bug#889042: lintian: Do not use dot as a separator in build profile names
I can see through your polite answer. I do my job. Your position regarding humankind is established already. smime.p7s Description: S/MIME cryptographic signature
Bug#889042: lintian: Do not use dot as a separator in build profile names
Control: tags -1 patch Fix works on 2.5.50.4. This patch is for 2.5.92.Bug-Debian: https://bugs.debian.org/889042 Index: lintian-2.5.92/checks/control-file.desc === --- lintian-2.5.92.orig/checks/control-file.desc +++ lintian-2.5.92/checks/control-file.desc @@ -285,7 +285,7 @@ Info: The restriction formula in Build-P "noudeb", "stage1", "stage2" - and "pkg.srcpkg.anything". + and "pkg/srcpkg/anything". Ref: https://wiki.debian.org/BuildProfileSpec#Registered_profile_names Tag: multiline-architecture-field Index: lintian-2.5.92/checks/control-file.pm === --- lintian-2.5.92.orig/checks/control-file.pm +++ lintian-2.5.92/checks/control-file.pm @@ -364,7 +364,7 @@ sub run { tag 'invalid-profile-name-in-build-profiles-field', $profile, $bin unless $KNOWN_BUILD_PROFILES->known($profile) - or $profile =~ /^pkg\.[a-z0-9][a-z0-9+.-]+\../; + or $profile =~ /^pkg\/[a-z0-9][a-z0-9+.-]+\/./; } } } Index: lintian-2.5.92/checks/fields.desc === --- lintian-2.5.92.orig/checks/fields.desc +++ lintian-2.5.92/checks/fields.desc @@ -669,7 +669,7 @@ Info: The restriction formula in the sou "noudeb", "stage1", "stage2" - and "pkg.srcpkg.anything". + and "pkg/srcpkg/anything". Ref: https://wiki.debian.org/BuildProfileSpec#Registered_profile_names Tag: build-depends-on-build-essential-package-without-using-version Index: lintian-2.5.92/checks/fields.pm === --- lintian-2.5.92.orig/checks/fields.pm +++ lintian-2.5.92/checks/fields.pm @@ -1097,7 +1097,7 @@ sub run { tag 'invalid-profile-name-in-source-relation', "$prof [$field: $part_d_orig]" unless $KNOWN_BUILD_PROFILES->known($prof) - or $prof =~ /^pkg\.[a-z0-9][a-z0-9+.-]+\../; + or $prof =~ /^pkg\/[a-z0-9][a-z0-9+.-]+\/./; } } Index: lintian-2.5.92/t/tests/fields-build-profiles-general/debian/debian/control.in === --- lintian-2.5.92.orig/t/tests/fields-build-profiles-general/debian/debian/control.in +++ lintian-2.5.92/t/tests/fields-build-profiles-general/debian/debian/control.in @@ -5,7 +5,7 @@ Maintainer: {$author} Standards-Version: {$standards_version} Build-Depends: {$build_depends}, big , bpfail1 , - bpcomplicated + bpcomplicated Rules-Requires-Root: no Package: {$source}-wrong-syntax @@ -23,7 +23,7 @@ Description: {$description} (wrong synta Package: {$source}-unknown-profile Architecture: {$architecture} Depends: $\{shlibs:Depends\}, $\{misc:Depends\} -Build-Profiles: +Build-Profiles: Description: {$description} (unknown profile) Check for unknown profile names . smime.p7s Description: S/MIME cryptographic signature
Bug#852494: wine: Add libwine.so and libwine.so.1 alternatives
El ds 19 de 05 de 2018 a les 23:39 +0200, Jens Reyer va escriure: > I definitely want the well-established system command > "update-alternatives" to be used. What are the requirements? "update-alternatives --config wine" must work if wine or wine- development are installed. Only this one? smime.p7s Description: S/MIME cryptographic signature
Bug#897961: drascula: Clarify license and authors' intention
Dear Alcachofa Soft staff, About the license for Drascula, section 3 states: You may not charge a fee for the game itself. But section 2 says: and may distribute it in aggregate as part of a larger & possibly commercial software distribution Could you confirm that, when this license was suggested to you, you did know this is a poor wording license that effectively allows to charge a fee for the game itself? Thank you. smime.p7s Description: S/MIME cryptographic signature
Bug#897965: flight-of-the-amazon-queen: Clarify license and authors' intention
Dear John Passfield and Steven Stamatiadis, About the license for Flight of the Amazon Queen, section 3 states: You may not charge a fee for the game itself. But section 2 says: and may distribute it in aggregate as part of a larger & possibly commercial software distribution Could you confirm that, when this license was suggested to you, you did know this is a poor wording license that effectively allows to charge a fee for the game itself? Thank you. smime.p7s Description: S/MIME cryptographic signature
Bug#897965: flight-of-the-amazon-queen: Clarify license and authors' intention
Source: flight-of-the-amazon-queen Version: 1.0.0-8 Severity: wishlist Like in https://bugs.debian.org/854679, this report determines whether authors agree with section 3 of the license being ineffective. In the absence of contradictory evidence, they do. smime.p7s Description: S/MIME cryptographic signature
Bug#897961: drascula: Clarify license and authors' intention
Source: drascula Version: 1.0+ds2-3 Severity: wishlist Like in https://bugs.debian.org/854679, this report determines whether authors agree with section 3 of the license being ineffective. In the absence of contradictory evidence, they do. smime.p7s Description: S/MIME cryptographic signature
Bug#890556: aptitude: Add build profile to skip documentation packages
El dv 16 de 03 de 2018 a les 14:42 +0100, Manuel A. Fernandez Montecelo va escriure: > Precisely in the latest versions I moved stuff to Build-Depends-Indep, > so you can just build the arch part, without the doc. aptitude Depends: aptitude-common (= ${source:Version}) aptitude-common is Architecture: all. If you build aptitude-common, you will build documentation packages too. > What you're trying to achive? Use modified software and reuse as many Debian packages as possible. smime.p7s Description: S/MIME cryptographic signature
Bug#854679: Clarify license for Beneath a Steel Sky
X-Debbugs-CC: en...@scummvm.org El dg 11 de 03 de 2018 a les 04:13 +0800, James 'Ender' Brown va escriure: > this issue has been discussed in detail now. Yet you do not address the problem. Let me write it in another way. Were the copyright holders of Flight of the Amazon Queen, Lure of the Temptress, and Drascula aware that "It was pretty obvious [...] that the license was weak, and there are certainly ways to break the spirit legally"? > I deny the license is 'deceptive'. So there are no known ways to break the spirit legally? > *You* (the user) have the freedom to act immorally, find a loophole > and cheat, to intentionally ignore > the express intent of the license. Certainly, and the user may have their reasons, but the license allows that and the designers knew it. > All parties who actually have any invested stake in the license were > and are still currently > satisfied. As long as authors know that "there are certainly ways to break the spirit legally", it is fine. Did they agree to release their games under this license knowing that individual resale is possible? If they were not aware, would they still accept this license now? Debian can sell the games, is it that terrible that users sell the games individually? smime.p7s Description: S/MIME cryptographic signature
Bug#854679: Clarify license for Beneath a Steel Sky
X-Debbugs-CC: en...@scummvm.org El ds 10 de 03 de 2018 a les 19:54 +0100, Fabian Greffrath va escriure: > Please don't do that for other people's addresses. X-Debbugs-CC is meant for this purpose. If James says he is receiving the messages through other paths, I will stop including his address. > Since when do we need an extra confirmation from copyright holders that > they meant the license exactly as it was written? In this case, authors were presented a license that promises "You may not charge a fee for the game itself", but fails to enforce it by design. Revolution knew that, so they should not be surprised if the game is being sold separately. However, it is not clear that other authors were aware. Is this a problem for Debian? Is Debian involved in any way in this possible deception? Who assisted in the license design? Who was the beneficiary for this license acceptance? smime.p7s Description: S/MIME cryptographic signature
Bug#854679: Clarify license for Beneath a Steel Sky
X-Debbugs-CC: en...@scummvm.org El ds 10 de 03 de 2018 a les 18:07 +, Simon McVittie va escriure: > which is something that the copyright holders specifically didn't want! > Also, intent matters in interpreting licensing, and if this ever > went to court, it seems fairly plausible that a court would decide that > this trick is stupid and the redistribution was copyright infringement. As you can see, James, my points have been repeated. Please confirm that game authors were not deceived by section 3 of the license. smime.p7s Description: S/MIME cryptographic signature
Bug#854679: Clarify license for Beneath a Steel Sky
Control: tags -1 - wontfix X-Debbugs-CC: en...@scummvm.org El dg 11 de 03 de 2018 a les 00:19 +0800, James 'Ender' Brown va escriure: > Reading the other BTS bug you linked, my understanding of the DFSG (and the > commonly accepted interpretation) > is the same as Ansgar supplied there: I understand your interpretation now. When you say "it must be permitted for Commercial Use" and DFSG #6 says "it may not restrict the program from being used in a business", I understand a sale is commercial use and use in a business, whereas you consider a sale is only conveyance. From that point of view, your license is DFSG-compliant. However, it is compliant because DFSG #1 renders section 3 ineffective. If you knew it, why does section 3 exist? Please confirm that copyright holders of Flight of the Amazon Queen, Lure of the Temptress, and Drascula were not deceived by section 3. smime.p7s Description: S/MIME cryptographic signature
Bug#854679: Clarify license for Beneath a Steel Sky
El ds 10 de 03 de 2018 a les 05:38 +0800, James 'Ender' Brown va escriure: > I'm not really sure what outcome you are looking for here... DFSG #6 warrants use in any field of endeavor. The outcome is either software can be sold, both modified and unmodified, or it is non-free. > Yes. It was pretty obvious to all parties that the license was "weak, > and there are certainly ways to break the spirit legally. By design. I take your word that Revolution was aware. It would help if you could state the same for Flight of the Amazon Queen, Lure of the Temptress, and Drascula. > Without allowing that freedom, we couldn't honor the spirit of the > DFSG. DFSG allows to sell individual software, but the spirit of DFSG does not encourage to break the spirit of licenses. > * "We've decided to trust you and permit re-distribute it > as freeware" > * ".. oh, but we don't want people to sell the game > individually for $$$" This is my concern. You were entrusted with finding a way to effectively forbid the sale of the game. > (very very paraphrased) "Looks good, ship it!" Then you seemed to have found the solution. Section 3 is clear: you may not charge a fee for the game itself. > To be perfectly honest - Debian-legal provided more input on the > wording than Revolution. Let me make this clear: you did nothing wrong by writing a custom license; you asked for help, which is sensible. I do not find related discussions in debian-legal, so I cannot judge what they told you. > This is the same sort of exception already implemented in other > DFSG-approved licenses, They suffer from the same problem; Artistic License 1.0 is not DFSG-compliant.[1] Propagating the error was not the right way. Again, you asked for help, so I do not blame you. > * Honor Revolutions request to limit individual resale > * Satisfy the "fields of endeavor" clause of the DFSG to encourage > Linux Distros able to ship These are incompatible, limiting individual resale breaks the "fields of endeavor" clause. Anyway, Debian can ship games under the non-free component. Debian accepts your license because section 3 is ineffective by using tricks. If you know it, then you deceive by writing a non-binding preamble describing author's intent and a binding section that you present as enforceable. Conflict arises when a Debian user believes section 3 does not really apply, but author believes it does. I thank engine developers and game creators for all your efforts. You provide culture and some freedoms. Now I ask for the right to use for any commercial purpose. Although this report is to clarify a license, I would like to convince authors that individual resale is not a problem. I defend "scammy" behavior because of these reasons: 1. Selling unmodified games encourages conveyance to users unaware of these games. 2. Selling free games, modified or not, propagates free software to users that otherwise are presented with non-free software. 3. Selling modified versions allows to reach more users. E.g., "Bajo un cielo de acero" could be easier to sell in South America. 4. It demonstrates that anyone can make a living out of free software. This reason may not appeal to authors, but it does to free software defenders. Furthermore, while discouraging "scammy" behavior, you also discourage other possibilities which are more likely to happen if the effort can be paid. Examples are full internationalization, source restoration, and game editor. In short, either copyright holders effectively allow to charge a fee for the game itself or they do not. According to your answer, they do. -- [1] https://bugs.debian.org/854825 smime.p7s Description: S/MIME cryptographic signature
Bug#835211: beneath-a-steel-sky: Enable subtitles by default
On Tue, 23 Aug 2016 16:35:00 +0200 Nils Dagsson Moskopp wrote: > scummvm has a “-n” option to enable subtitles. > I think those should be enabled by default. This should be tackled from accessibility preferences. Please discuss the matter in the proper list. smime.p7s Description: S/MIME cryptographic signature
Bug#854679: Clarify license for Beneath a Steel Sky
Dear Revolution staff, About the license for Beneath a Steel Sky, section 3 states: You may not charge a fee for the game itself. But section 2 says: and may distribute it in aggregate as part of a larger & possibly commercial software distribution Could you confirm that, when this license was suggested to you, you did know this is a poor wording license that effectively allows to charge a fee for the game itself? Thank you. smime.p7s Description: S/MIME cryptographic signature
Bug#853527: lmms: ftbfs with GCC-7
X-Debbugs-CC: 073p...@gmail.com El dv 09 de 03 de 2018 a les 19:10 +0800, Boyuan Yang va escriure: > Are > you going to fix the problem soon? I cannot promise anything. > If not, is it okay if someone prepares an NMU and upload the fix? If master version still works, do not wait for me either. smime.p7s Description: S/MIME cryptographic signature
Bug#814156: Extra-Source-Only field in Sources index
X-Debbugs-CC: a...@debian.org, ballo...@debian.org, r...@debian.org On Mon, 08 Feb 2016 20:49:18 +0100 Ansgar Burchardt wrote: > the source is only > there to fulfill the "provide the complete source" requirement. apt-get downloads these new versions by default. These sources are part of the stable release index. Are these sources officially supported? smime.p7s Description: S/MIME cryptographic signature
Bug#832564: debhelper: udeb packages should not be processed with noudeb
On Wed, 27 Jul 2016 17:38:05 +0200 Helmut Grohne wrote: > Just > adding those headers is more explicit and much harder to get wrong. It is more explicit and redundant. If you do not add those headers, you do not get wrong at all. > It simply isn't worth the maintenance cost. You described development cost, not maintenance one. Adding Build-Profiles fields is not an option because maintainers are reluctant to support build profiles; e.g., https://bugs.debian.org/890834 . I know it is not worth your effort since you do not use noudeb and similar build profiles; it is worth mine. It is far easier for me to maintain this code than to add Build-Profiles fields to all packages. smime.p7s Description: S/MIME cryptographic signature
Bug#890834: gtk+2.0: Add build profiles to skip flavors and packages
El dl 19 de 02 de 2018 a les 17:41 +, Simon McVittie va escriure: > What goal(s) are you aiming to achieve by requesting this? This is a mainstreaming request. Disk usage and build time decrease when I apply this build profiles. > The namespace for source-package-defined build profiles is > pkg.some-source.foo, not pkg/some-source/foo. See https://bugs.debian.org/889042 . > > * pkg/gtk+2.0/nostatic: Skip static flavor and packages, the > > latter being libgtk$(APIVER)-static-dev and libgail-static-dev. > > Those packages don't exist. If you are asking the GTK maintainers to > split them out, that's an intrusive change. Nevertheless, it is a wishlist request. I have done that change, you may want to do it too. Users that need static libraries build-depend on the new packages. smime.p7s Description: S/MIME cryptographic signature
Bug#890834: gtk+2.0: Add build profiles to skip flavors and packages
Source: gtk+2.0 Version: 2.24.32-1 Severity: wishlist Please consider adding the following build profiles: * noudeb: Skip udeb flavor and packages. * pkg/gtk+2.0/noexamples: Skip @EXAMPLES_PKG@. * pkg/gtk+2.0/nogir: Skip gir1.2-gtk-2.0. * pkg/gtk+2.0/nopixbuf: Skip @PIXBUF_PKG@. * pkg/gtk+2.0/nostatic: Skip static flavor and packages, the latter being libgtk$(APIVER)-static-dev and libgail-static-dev. smime.p7s Description: S/MIME cryptographic signature
Bug#890556: aptitude: Add build profile to skip documentation packages
Source: aptitude Version: 0.8.10-6 Severity: wishlist Please consider adding a build profile, such as pkg/aptitude/nodoc, to skip building documentation packages. smime.p7s Description: S/MIME cryptographic signature
Bug#890555: aptitude: add apt-get -c functionality (2)
Source: aptitude Version: 0.8.10-6 Severity: wishlist This was requested at https://bugs.debian.org/499204 . The patch in that report works with version 0.8.7-1. Please consider adding the feature and tell me if you want me to write related documentation. smime.p7s Description: S/MIME cryptographic signature
Bug#890132: glibc: Use built iconvconfig
El dg 11 de 02 de 2018 a les 13:55 +0100, Aurelien Jarno va escriure: > There is no need to X-Debbugs-CC everybody. Please stop doing that. My messages do not reach debian-gl...@lists.debian.org . How do I know that maintainers receive them? It would not be the first time a maintainer misses my message because I do not use X-Debbugs-CC. smime.p7s Description: S/MIME cryptographic signature
Bug#890138: glibc: Allow to not build Xen packages
Source: glibc Version: 2.26-6 Severity: wishlist X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net, aurel...@aurel32.net, sthiba...@debian.org Please consider adding a pkg/glibc/noxen build profile to skip building Xen files. smime.p7s Description: S/MIME cryptographic signature
Bug#890129: glibc: Support simpler multiarch systems
X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net, sthiba...@debian.org El dg 11 de 02 de 2018 a les 13:52 +0100, Aurelien Jarno va escriure: > Those are not officially supported and might be removed at any moment. Debian officially supports the main component of stable releases. Are you going to remove multiarch interpreters from stretch? Of course you may drop multiarch interpreters. Debian has dropped support for some ports and machines. If you remove multiarch interpreters just for the sake of incompatibility, I will provide them. > As said many times, the program interpreter are part of the ABI. And there are compatibility measures available. > It's a > pitty that there are some conflicts, but such is life. Such is your choice. I can change and remain compatible, you do not want to fix the issue because you want it that way. > please stop opening new bugs or bothering upstreams > about that. New proposal, new report. It seems logical to me. smime.p7s Description: S/MIME cryptographic signature
Bug#890132: glibc: Use built iconvconfig
Source: glibc Version: 2.26-6 Severity: wishlist X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net, aurel...@aurel32.net, sthiba...@debian.org Please use $(CURDIR)/debian/tmp-libc/usr/sbin/iconvconfig instead of /usr/sbin/iconvconfig in debian/rules.d/build.mk, since new iconvconfig may behave differently. smime.p7s Description: S/MIME cryptographic signature
Bug#890131: glibc: Do not build-depend on multilib with nobiarch profile
Source: glibc Version: 2.26-6 Severity: wishlist X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net Please do not build-depend on g++-7-multilib when the nobiarch build profile is active. smime.p7s Description: S/MIME cryptographic signature
Bug#890129: glibc: Support simpler multiarch systems
Source: glibc Version: 2.26-6 Severity: wishlist X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net One goal of a multiarch system is to make possible to run programs from any other architecture. ELF executables depend on an interpreter that should have a unique name; otherwise, loading the executable is complicated. Simpler multiarch systems use multiarch interpreter names. These multiarch interpreters are officially supported in Debian,[1] despite recent statements from Debian glibc maintainers. Compatibility with third-party programs relies on the absence of traditional interpreters because then there is no ambiguity about which interpreter to invoke. Thus, I propose to support these simpler systems by putting the traditional interpreters in the package elf-compat-links. This way, file conflicts are solved; e.g., libc6 conflicts on /lib/ld.so.1 on mips <-> mipsel. Of course, this may be enabled through a build profile. -- [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173#c14 smime.p7s Description: S/MIME cryptographic signature
Bug#889106: Multiarch interpreter names for traditional architectures
El dv 09 de 02 de 2018 a les 16:03 +0100, Aurelien Jarno va escriure: > I love the way you use "official" here. Me too. It is precisely your policy not to include any unnecessary file because "experience shows that users are very imaginative when you provide a feature". You have taken steps to insure the existence of multiarch interpreters and they have landed on stable releases. > I don't care about compatibility within Debian and derivatives. I do. Strange statement from a Debian developer. > I care > about the compatibility within the whole GNU/Linux ecosystem. I do too. I even care about compatibility with non-Linux systems. Give a solution like I do instead of complaining about the past. smime.p7s Description: S/MIME cryptographic signature
Bug#853527: lmms: ftbfs with GCC-7
El dv 09 de 02 de 2018 a les 17:22 +0300, Dmitry Eremin-Solenikov va escriure: > Any progress on uploading > 1.1.3-8 or packaging 1.1.90? Pending upload. smime.p7s Description: S/MIME cryptographic signature
Bug#888073: Multiarch interpreter names for traditional architectures
El dv 09 de 02 de 2018 a les 15:02 +0100, Aurelien Jarno va escriure: > The notion of "multiarch interpreter" doesn't exist. It does exist, but you do not accept it. You are now denying the official support that exists in Debian. Use /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 as the program interpreter and the program will work perfectly in Debian and derivatives. smime.p7s Description: S/MIME cryptographic signature
Bug#889820: debian-policy: 12.5, relaxed requirement for copyright location
//X-Debbugs-CC: -doc suffix cannot be used, e.g. acl2-doc. I am going with -doc-minimal and Outdates, which is softer than Breaks. I will return when support is ready. smime.p7s Description: S/MIME cryptographic signature
Bug#889820: debian-policy: 12.5, relaxed requirement for copyright location
//X-Debbugs-CC: El dc 07 de 02 de 2018 a les 22:45 +0100, Javier Serrano Polo va escriure: > What about a > new Outdates field? Forget Outdates. If there are two possible versions of a documentation package, it should be possible to install both. That can be done with different package names. So, the proposal is: Every package must be accompanied by a verbatim copy of its copyright information and distribution license in the file /usr/share/doc/package/copyright or /usr/share/doc/docpackage/copyright; docpackage is a package providing source-doc and may not be installed. [...] [...] and the first package Depends on the second. Alternatively, /usr/share/doc/package may not exist if the package Recommends docpackage, which comes from the same source. [...] smime.p7s Description: S/MIME cryptographic signature
Bug#889820: debian-policy: 12.5, relaxed requirement for copyright location
X-Debbugs-CC: a...@debian.org, ballo...@debian.org, spwhit...@spwhitton.name, r...@debian.org El dc 07 de 02 de 2018 a les 20:01 +0100, Bill Allombert va escriure: > > Versioned Recommends actually, but does a versioned Recommends make any > > difference? > > That is why a versioned Depends: is needed. A hard dependency on non-functional data makes no sense. What about a new Outdates field? It would help to warn the user about outdated documentation. El dc 07 de 02 de 2018 a les 11:13 -0800, Russ Allbery va escriure: > Then we can close this bug as unnecessary? Since the *-doc mechanism is > already specified. I cannot make libc6 depend on glibc-doc. > > I do not think so. Metadata is usually smaller than those files: > > copyright, changelog, manpages, etc. > > None of which you're addressing here except copyright. True. What suffix would you use for copyright plus changelog? -doc-minimal? > I'm fairly sure about this, but feel free to do an experiment if you > really want to check the numbers. What metadata are you thinking of? What is the test you are suggesting? El dc 07 de 02 de 2018 a les 12:25 -0700, Sean Whitton va escriure: > Either way, please X-debbugs-CC the list rather than all four of us > individually. It would not work. https://bugs.debian.org/831059 smime.p7s Description: S/MIME cryptographic signature