Re: Language code for Brazilian Portuguese
On 10/01/2018 07:36 AM, Fred Maranhão wrote: > Le ven. 28 sept. 2018 à 12:42, Sean Whitton a écrit : >> Would "debian-policy-pt-br" be the right name for a binary package >> containing a translation of Debian Policy into Brazilian Portuguese? > > in my opinion, yes. > > it is the same pattern as in: > aspell-pt-br > firefox-esr-l10n-pt-br > libreoffice-help-pt-br Yes, that would be the preferred name for Brazilian Portuguese, as Fred pointed out, it follows the pattern of other packages and it's also what our users would expect. Kind regards, -- Felipe Augusto van de Wiel (faw) signature.asc Description: OpenPGP digital signature
Re: Keeping master releaseable without posting to d-d-a
On Sat, Oct 27, 2018 at 03:16:55PM -0700, Russ Allbery wrote: > Sean Whitton writes: > > On Sat 27 Oct 2018 at 02:43PM -0700, Russ Allbery wrote: > > >> Yup, completely agreed. I was wondering myself if we should start > >> doing that for exactly this reason (clearing the path for non-normative > >> changes), but didn't get far enough to write a full proposal and then > >> forgot about it. :) > > > Cool, whoever applies a normative change next gets to create a branch > > called 'next', then. > > Yup, sounds great. Agreed, it should work OK. Cheers, -- Bill. Imagine a large red swirl here.
Bug#818850: developers-reference: Join the two chapters about the 'default' field
Control: tags -1 - pending Maintainers, what do you think about https://salsa.debian.org/debian/developers-reference/merge_requests/8/diffs to fix this bug? Any objections against me merging this? BTW: I'm removing the pending tag for now, since this is not yet committed (at least not to master) Holger -- Created with Sylpheed 3.5.1 under D E B I A N L I N U X 9 " S T R E T C H " . Registered Linux User #311290 - https://linuxcounter.net/
Processed: developers-reference: Join the two chapters about the 'default' field
Processing control commands: > tags -1 - pending Bug #818850 [developers-reference] developers-reference: two chapters regarding the 'default' field Removed tag(s) pending. -- 818850: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818850 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#188731: debian-policy: "strip --strip-unneeded" is insufficient
Hello, On Sun 28 Oct 2018 at 04:04PM GMT, Niels Thykier wrote: >> Well, more specifically debhelper. >> > > FTR, I would be happy if the solution was not specific to "debhelper" in > the long term. In particular, there is a world of difference between > "debhelper", "cdbs with debhelper", "dh-style debhelper", and > "dhmk-style debhelper". Indeed, but the shading will get a lot less useful if it merely indicates that there is /some/ common tool that implements the requirement. We probably want to restrict the shading to dh-style debhelper. -- Sean Whitton signature.asc Description: PGP signature
Processed: Re: Bug#188731: debian-policy: "strip --strip-unneeded" is insufficient
Processing control commands: > tag -1 -patch +pending Bug #188731 [debian-policy] Also strip .comment and .note sections Removed tag(s) patch. Bug #188731 [debian-policy] Also strip .comment and .note sections Added tag(s) pending. -- 188731: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=188731 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#188731: debian-policy: "strip --strip-unneeded" is insufficient
control: tag -1 -patch +pending Hello, On Sun 28 Oct 2018 at 03:51PM GMT, Niels Thykier wrote: >> .. [#] >> - You might also want to use the options ``--remove-section=.comment`` >> - and ``--remove-section=.note`` on both shared libraries and >> - executables, and ``--strip-debug`` on static libraries. >> + You might also want to use the option ``--strip-debug`` on static >> + libraries. >> > > For static libraries, you want to use --strip-debug *instead* of > --strip-unneeded (as opposed to "also" as the text implies) AFAICT. At > least, debhelper always used --strip-debug without --strip-unneeded on > static libraries. > > Note that for static libraries, it might be prudent to remind people to > use "-D" / "--enable-deterministic-archives" to ensure a deterministic > result (and thereby comply with the policy's recommendation to support > reproducible builds). I've updated the footnote. Thanks. -- Sean Whitton signature.asc Description: PGP signature
Bug#188731: debian-policy: "strip --strip-unneeded" is insufficient
Sean Whitton: > Hello Niels, > > On Sun 28 Oct 2018 at 02:22PM GMT, Niels Thykier wrote: > >> I think I agree with your suggestion of shading policy requirements that >> are already covered by common tools. > > Well, more specifically debhelper. > FTR, I would be happy if the solution was not specific to "debhelper" in the long term. In particular, there is a world of difference between "debhelper", "cdbs with debhelper", "dh-style debhelper", and "dhmk-style debhelper". >> At the moment, I am hesitant as to whether I should second Sean's text >> as it is or point out that text fails to handle cross-building[1] (note >> the cross building issue is not a regression). >> On one front, it would be technically correct - on the other front, I >> fear most maintainers will be overloaded by irrelevant details that is >> already handled for them. > > At present Policy does not require crossbuilding support. So while it > would be nice to include details of how to properly support > crossbuilding, it's not as though we're contradicting another > requirement in Policy. So it seems like including the crossbuilding > details would be a separate bug. > Indeed - and accordingly, it is not a regression. :) Thanks, ~Niels
Bug#188731: debian-policy: "strip --strip-unneeded" is insufficient
Sean Whitton: > control: tag -1 +patch > > Hello, > > On Fri 28 Sep 2018 at 05:38AM GMT, Niels Thykier wrote: > >> * We now have auto-generated dbgsym packages by dh_strip (which were >>just an idea when Bill wrote that answer). >> >> * Policy mentions "--remove-section=.comment --remove-section=.note" in >>a footnote as a "You might also want to use ...". >> >> * Policy section 10.1 implies that "INSTALL = install -s" is a useful >>way of stripping binaries (both in text and examples). Besides not >>covering the .comment + .note sections it also neuters dh_strip's >>ability to create dbgsym packages. >> >> >> I think we should update the policy to say that you should use >> "--strip-unneeded --remove-section=.comment --remove-section=.note" and >> maybe recommend delegating that task (where possible) to dh_strip as it >> provide dbgsym packages. > > Thank you for following up. > > Here is a minimal patch, for which I am seeking seconds. [...] > Hi, Seconded with one remark. > diff --git a/policy/ch-files.rst b/policy/ch-files.rst > index 21c4c37..7106afe 100644 > --- a/policy/ch-files.rst > +++ b/policy/ch-files.rst > @@ -48,12 +48,20 @@ used: > CC = gcc > CFLAGS = -O2 -g -Wall # sane warning options vary between programs > LDFLAGS = # none > -INSTALL = install -s # (or use strip on the files in debian/tmp) > > -Note that by default all installed binaries should be stripped, either > -by using the ``-s`` flag to ``install``, or by calling ``strip`` on the > -binaries after they have been copied into ``debian/tmp`` but before the > -tree is made into a package. > +By default all installed binaries should be stripped by calling > + > +:: > + > +strip --strip-unneeded --remove-section=.comment --remove-section=.note > binaries > + > +on the binaries after they have been copied into ``debian/tmp`` but > +before the tree is made into a package. > + > +It is not recommended to strip binaries by passing the ``-s`` flag to > +``install``, because this fails to remove .comment and .note sections, > +and also prevents the automatic creation of dbgsym binary packages by > +tools like ``dh_strip``. > > Although binaries in the build tree should be compiled with debugging > information by default, it can often be difficult to debug programs if > @@ -114,7 +122,7 @@ All installed shared libraries should be stripped with > > :: > > -strip --strip-unneeded your-lib > +strip --strip-unneeded --remove-section=.comment --remove-section=.note > your-lib > > (The option ``--strip-unneeded`` makes ``strip`` remove only the symbols > which aren't needed for relocation processing.) Shared libraries can > @@ -123,7 +131,8 @@ linking are in a separate part of the ELF object file. > [#]_ > > Note that under some circumstances it may be useful to install a shared > library unstripped, for example when building a separate package to > -support debugging. > +support debugging. The debhelper `dh_strip`` tool can create such > +packages automatically. > > Shared object files (often ``.so`` files) that are not public > libraries, that is, they are not meant to be linked to by third party > @@ -741,9 +750,8 @@ restricted to ASCII when it is possible to do so. > shared library, like ``mklibs`` does in the Debian installer project. > > .. [#] > - You might also want to use the options ``--remove-section=.comment`` > - and ``--remove-section=.note`` on both shared libraries and > - executables, and ``--strip-debug`` on static libraries. > + You might also want to use the option ``--strip-debug`` on static > + libraries. > For static libraries, you want to use --strip-debug *instead* of --strip-unneeded (as opposed to "also" as the text implies) AFAICT. At least, debhelper always used --strip-debug without --strip-unneeded on static libraries. Note that for static libraries, it might be prudent to remind people to use "-D" / "--enable-deterministic-archives" to ensure a deterministic result (and thereby comply with the policy's recommendation to support reproducible builds). > .. [#] > A common example are the so-called "plug-ins", internal shared > > = > > To obtain a side-by-side diff: > > % git clone salsa.debian.org:dbnpolicy/policy.git debian-policy > % cd debian-policy > % git difftool -y -x icdiff master..origin/bug188731-spwhitton > > Alternatively, visit > > https://salsa.debian.org/dbnpolicy/policy/commit/3cc86484767ac0aead9b7466c074ade5021ef225?view=parallel > Thanks, ~Niels
Bug#188731: debian-policy: "strip --strip-unneeded" is insufficient
Hello Niels, On Sun 28 Oct 2018 at 02:22PM GMT, Niels Thykier wrote: > I think I agree with your suggestion of shading policy requirements that > are already covered by common tools. Well, more specifically debhelper. > At the moment, I am hesitant as to whether I should second Sean's text > as it is or point out that text fails to handle cross-building[1] (note > the cross building issue is not a regression). > On one front, it would be technically correct - on the other front, I > fear most maintainers will be overloaded by irrelevant details that is > already handled for them. At present Policy does not require crossbuilding support. So while it would be nice to include details of how to properly support crossbuilding, it's not as though we're contradicting another requirement in Policy. So it seems like including the crossbuilding details would be a separate bug. -- Sean Whitton signature.asc Description: PGP signature
Bug#188731: debian-policy: "strip --strip-unneeded" is insufficient
Russ Allbery: > Sean Whitton writes: > >> Thank you for following up. > >> Here is a minimal patch, for which I am seeking seconds. I didn't >> include a recommendation to use dh_strip because we generally keep such >> recommendations in footnotes rather than the text of Policy, and we are >> trying to reduce the number of footnotes -- but I don't mind adding it >> if others think it would be a good idea (and it wouldn't need >> seconding). > > Looks good to me. Seconded. > > On an entirely unrelated note (and probably a larger project than anyone > will be able to tackle any time soon), I think it would be very helpful if > we had some way of annotating what parts of Policy are just handled for > you if you use debhelper in the normal way (perhaps with references to the > tools involved). Maybe with background shading or an icon or something? > I think Policy needs to state all of the rules, including the ones > implemented by other tools, but at the same time nearly everyone doing > Debian packaging is using debhelper (either directly or indirectly), so > it's a bit of a disservice to people to ask them to wade through a bunch > of specifications for stuff that normally they don't and shouldn't think > about. > I think I agree with your suggestion of shading policy requirements that are already covered by common tools. At the moment, I am hesitant as to whether I should second Sean's text as it is or point out that text fails to handle cross-building[1] (note the cross building issue is not a regression). On one front, it would be technically correct - on the other front, I fear most maintainers will be overloaded by irrelevant details that is already handled for them. Well, given it is not a regression, the choice is strictly speaking "obvious" in this case but the general issue stands. Thanks, ~Niels [1] For cross build support, you would have to use "$(DEB_HOST_GNU_TYPE)-strip" rather than "strip"... Except if you are doing a "Canadian Cross" build in which case you *might* need "$(DEB_TARGET_GNU_TYPE)-strip" instead in very rare cases. Plus you have to ensure DEB_HOST_GNU_TYPE is defined - either by including a dpkg makefile (recommended) or defining it yourself via dpkg-buildflags which will imply $(shell ...). We would like to avoid the latter due to the high overhead involved in doing that.
