Bug#850289: debian-policy: Patch so that there is an Example section in manual pages
Hi, please break the lines, as is customary, do not use overlong lines. I also believe you are confusing packages with executables. Packages do not have manual pages, executables do. Packages oftentimes *do* have instructions in /usr/share/doc/. This also means that the second sentence (missing a full stop) is probably unnecessary. Also (no affront intended), please run this through the English l10n team before applying the patch… bye, //mirabilos -- >> Why don't you use JavaScript? I also don't like enabling JavaScript in > Because I use lynx as browser. +1 -- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel
Bug#883233: First footnote to section 7.1 should say which of Debian's autobuilders ignore alternative dependencies
On Thu, 30 Nov 2017, Sean Whitton wrote: > wanna-build team / Release Team / Backports Team: exactly which buildds > ignore alternative dependencies? We want to include this in an > (existing) Policy footnote. Good idea. For porter uploads, some people (including me) use cowbuilder, which uses aptitude, a “classic” hand-grown algorithm, or (in very recent distributions) apt for dependency resolution, and thus does consider alternative dependencies. Others use sbuild, which may or may not, as the buildds also use sbuild. Not exactly a buildd, but for completeness sake… bye, //mirabilos -- «MyISAM tables -will- get corrupted eventually. This is a fact of life. » “mysql is about as much database as ms access” – “MSSQL at least descends from a database” “it's a rebranded SyBase” “MySQL however was born from a flatfile and went downhill from there” – “at least jetDB doesn’t claim to be a database” ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!
Bug#864615: apt-listchanges: changelogs for tglase-nb.lan.tarent.de
On Sat, 7 Jul 2018, root wrote:
> * Policy: Update version of POSIX standard for shell scripts
I wonder why the maintainers of the shell packages providing
a suitable /bin/sh were not contacted regarding this. We could
have provided input.
(tl;dr: Debian’s sh-suitable shells follow POSIX more closely,
so if POSIX past the last release changes something, chances are
the shells will implement the behaviour of the to-be-released-in-
the-future standard rather than the past one. GNU bash, dash and
mksh all have sh modes suitable enough, but they all are not 100%
compliant due to bugs and the moving of the platform; they are all
pretty close though. POSIX also leaves a lot open to implementors.
Shell *scripts* though are often not compliant, e.g. they (such as
debconf…) use "${foo#*(}" which works in bash and dash by accident
but is not permitted by POSIX… so I’m content enough with a “good
enough.)
bye,
//mirabilos
--
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database” (#nosec)‣‣‣ Please let MySQL and MariaDB finally die!
Bug#905251: apt-listchanges: changelogs for tglase.lan.tarent.de
On Wed, 29 Aug 2018, root wrote: > debian-policy (4.2.1.0) unstable; urgency=medium > * Fix inconsistent wording in 4.9 by dropping the word 'maximally' > (Closes: #905251). > Thanks to several people who pointed out this issue, both in the BTS > and in person. > -- Sean Whitton Sat, 25 Aug 2018 13:05:54 -0700 You have a stray colon left there: | The package build should be as verbose as reasonably possible, except | where the terse tag is included in DEB_BUILD_OPTIONS (see | debian/rules and DEB_BUILD_ | +OPTIONS:). This means that debian/rules ↑ here | + bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * **Besuchen Sie uns auf der dmexco 2018!** 12**. **& 13. September 2018, Koelnmesse / **Halle 7,** **Stand A-031** Digital Business, Marketing und Innovation [www.tarent.de/dmexco](http://www.tarent.de/dmexco) * **Visit us at dmexco 2018!** 12th & 13th September, 2018, Koelnmesse / **Hall 7,** **Booth A-031** Digital business, marketing and innovation [www.tarent.de/dmexco](http://www.tarent.de/dmexco) *
Bug#908155: Coordination with upstream developers not universally applied
On Thu, 6 Sep 2018, Moritz Muehlenhoff wrote: > "You have to forward these bug reports to the upstream developers so that they > can be fixed in a future upstream release." > > That's not the current/best practice for a number of packages, either because > of the sheer volume of bug reports/size of the package or because some of the > bugs are very specific to the reporters setup and having the Debian maintainer > as a middle person forwarding information back and forth would be useless > (e.g. for the Linux kernel where a lot of bug reports are hardware-specific). I respectfully disagree. In just as many cases, the middle person is necessary, because it’s a burden to the end user (and often enough virtually impossible) to • register an account on 10'000 upstream bugtrackers, with 30 different kinds of bug tracking systems (if any), themselves (one for each pak‐ kage they use) ‣ finding the tracker in the first place ‣ reporting it in the correct tracker, against the correct component, in the correct format, etc. • keep track of the state of these bugs (we have debbugs with a sub‐ scription interface as a single consistent interface for a reason) • respond to back-questions from upstream (which version, compile options, why did you patch X, etc) ‣ deal with upstreams not interested in bugreports for anything stable • tell upstream convincingly enough that no, you can’t just build and use their git master ‣ (the real package maintainers could pick the proposed fix and put it in experimental, though, or prepare, if necessary, a special build for the reporter to test back) • well, build the proposed fix for testing • reproduce the bug with older (think oldstable-security) or newer (think sid, for a stable user) versions • keep track of whatever upstream versions and whatever Debian versions carry the fix (those can differ quite a lot) • be able to judge whether it’s a security-relevant problem • speak upstream’s language (both programming and human) well enough for both sides to understand stuff • etc. Furthermore, it’s considered nice to upstream to filter out Debian-specific bugs instead. One could even argue with Social Contract §4 here, but I’m not going quite as far. Yes, I’ve also been guilty of asking users to report things upstream as they aren’t packaging-specific. (I’d still move or copy them upstream if the reporter is unable or unwilling.) However, I *still* think the language of DevRef should be *strongly* urging DDs (and other package maintainers) towards being a bidirectional bug report gateway, at least for real problems (I can understand being annoyed with upstream feature requests). Yes, that doesn’t scale when you maintain “a lot of” packages. However, it *is* something you have signed up for when you started maintaining your first package. Perhaps you should look for help (bug triage and forwarding could even be done, in part, by less involved people). I also think that upstreams, conversely, should have an eye on packaging bugtrackers, but that can explode quickly… I’m trying for mine (Debian, CentOS/RedHat, Gentoo, Arch seems to be a manageable subset, and I pick up weird ones like Void on the occasion). So, perhaps upstream can help those “a lot of” maintainers, too. This also means that there should be a good relationship between the package maintainers and upstreams. In those, it’s easier to deal with bugreports than when someone totally unknown goes to upstream and reports a bug (“uh, a clueless end user… meh, let’s ignore it”). It’s basically the *definition* of a distribution and its maintainers to coordinate between upstreams, other packages and distro-wide policies, and users and other downstreams. It’s your *job*! I’m trying to be constructive here, but in the end, I still think that this was something package maintainers (at least DDs) have read beforehand and signed up for, so there’s no room to complain now, and I strongly believe that the current wording should either not be changed at all, or changed in a way that still strongly supports users unable (by lack of knowledge, skills, or just time) to report directly upstream. Thanks for having read till the end, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#908155: Coordination with upstream developers not universally applied
Hello Moritz, > On Thu, Sep 06, 2018 at 11:29:52PM +0200, Thorsten Glaser wrote: > > I’m trying to be constructive here, but in the end, I still > > think that this was something package maintainers (at least > > DDs) have read beforehand and signed up for, so there’s no > > room to complain now, > > Good. Please subscribe to the PTS, I take that as an offer > by you to take care of forwarding Debian kernel bugs to upstream. you seem to be deliberately misunderstanding me. I’m not a maintainer of the Debian Linux kernel. I exhibit a few of the things I mentioned, such as, not being know‐ ledgeable enough about the stuff. In this instance, I’m the user / bug reporter. Not “all DDs must forward bugs about *all* packages to *all* upstreams”, but “package maintainers must forward bugs about *their* packages (and perhaps others, if interested and capable) to those upstreams”. I try to do so for my packages and a couple others (I’d even be more involved in klibc if upstream and maks weren’t such a wall of silence). bye, //mirabilos -- >> Why don't you use JavaScript? I also don't like enabling JavaScript in > Because I use lynx as browser. +1 -- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel
Re: Bug#908155: Coordination with upstream developers not universally applied
Hi Wouter, > I agree that it's perfectly fine for a maintainer to say "this is an > upstream bug, please report it upstream", which the current text > doesn't allow for. In theory, I could agree to that, were it not for a number of points I outlined earlier: • the variety of upstream bug trackers and having to register an account with each of them • the problems dealing with upstream reactions (questions, patches, etc.) especially for less technical users (or merely these not knowledgeable about that particular package’s internals) • the lack of familiarity between upstream and distro end user Now that I write it again, there’s another point: • the package maintainers not being involved in the discussion (dangerous if e.g. upstream suggests a fix that won’t work in the distro for some reason, and the end user not knowing about that, and them agreeing to that fix) I’m still convinced that package maintainers should at least forward patches from end users and keep an eye on them, and that, if/when it’s okay to ask the end user to report upstream themselves, they help whenever needed and perhaps also keep an eye on the upstream bugs. bye, //mirabilos -- [16:04:33] bkix: "veni vidi violini" [16:04:45] bkix: "ich kam, sah und vergeigte"...
Re: Bug#908155: Coordination with upstream developers not universally applied
On Fri, 7 Sep 2018, Ian Jackson wrote: > I think it is usually better if the Debian maintainer can do this. > I would like to encourage maintainers do do it. But I really don't > think we can make this mandatory. Uhm… it’s been mandatory the last couple of years. > It's all very well to say that package maintainers "should" do > something. Package maintainers "should" fix all bugs in their > packages. > > But we have limited effort. It is better to have a package in Debian, > but where users have to do some more of the work, than no package. Good point. As I wrote in I don’t think it’s sensible to _forbid_ maintainers to ask users to report upstream. My concerns is more about cases in which that is a big burden on the users. Tons of bug trackers come to mind, or being unskilled in the interna of a particular package. As long as it’s a “should” in the same sense as “should fix bugs in their packages”, and package maintainers keep an eye on users’ bug reports and, when necessary, help them (providing infos to upstream, packages to test to users who can’t (easily) build themselves, and, yes, definitely *also* forward bugs upstream, occasionally. Does this sound like an option? bye, //mirabilos -- [17:15:07] Lukas Degener: Kleines Asterix-Latinum für Softwaretechniker: veni, vidi, fixi(t) ;-)
Re: Bug#908155: Coordination with upstream developers not universally applied
Short answer (slightly drunk and short on time), more later: On Fri, 7 Sep 2018, Ian Jackson wrote: > In some packages this will not be possible at least for some bug > reports. You've seen the poor quality and hard-to-follow-up bug […] Yes, but that does not mean we should make it permitted by the rules to slack in that “duty”. A “should” may be violated within reason, so keep it that. > […] Not commenting on the text in between for now. > What did you think of the text I proposed just over <- there, that > Moritz was happy with ? Just answering because of this: I think it way too lax still. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * **Besuchen Sie uns auf der dmexco 2018!** 12**. **& 13. September 2018, Koelnmesse / **Halle 7,** **Stand A-031** Digital Business, Marketing und Innovation [www.tarent.de/dmexco](http://www.tarent.de/dmexco) * **Visit us at dmexco 2018!** 12th & 13th September, 2018, Koelnmesse / **Hall 7,** **Booth A-031** Digital business, marketing and innovation [www.tarent.de/dmexco](http://www.tarent.de/dmexco) *
including complete corresponding licence information should stay a requirement (was Re: Debian Policy 4.3.0.0 released)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA384 Sean Whitton dixit: >2.3 & 4.5 >In cases where a package's distribution license explicitly permits >its copyright information to be excluded from distributions of >binaries built from the source, a verbatim copy of the package's >copyright information should normally still be included in the >copyright file, but it need not be if creating and maintaining a >copy of that information involves significant time and effort. I quite disagree. Downstreams will require the licence information, and if it’s included in the source package, it’s easy enough to add it to the binary package, and if not, the above does not apply either. I recently did the work to audit swagger-ui-dist, which is built using “modern web 2.0” tools from over 80 NPM packages, and it took me some hours, but we now have a licence file for the binary, and upstream was actually thankful about these efforts. I would expect that, even if it’s hard, this to be mandatory part of packaging anything for Debian. I will be very unamused about packages without correct corresponding licence information EVEN IF the upstream licence allows such, because ONLY the presence of such correct licence information in the Debian package shows that an actual audit of the legal situation has been done (and only after that, this decision to not include the information could be done, and by then, the information will already be there, so it must (in my opinion) still be included). I hereby ask that this change be reverted. bye, //mirabilos - -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (MirBSD) Comment: ☃ ЦΤℱ—８ ☕☂☄ iQIcBAEBCQAGBQJcH/Y9AAoJEHa1NLLpkAfgp+MP/3CrdFlXpa3eSwxmUAMTyBfu DuZnl6/LhTFEeqCHyw4Gmvcg4TmkBZPSQoBeVXlCfFzw8nFV1POJZh+KEv5pln4+ lHzmg8luWEoBdnsr0cN7yuQT18sNRcXg0sitPHBEaF5G+igNONOY/ibf55OxwoMu XpCcNp8dANH7/zNeM7Yy+kiXNAHMOe8ugkE0zxydTcBCRPuZwFx261PHM5rr2Gs6 Q4XsjtWbYO02MsynwAQHoNJDLW78mfHKYeQWUyHIpKn9fvqIdFWVO2fq9RbEfo53 9gwOpe9mdSdXjcyzoKo6nprIgPfej/YeX2dJyPfUhRbpWKgFD3obAF8GbuN6n/8t hVMyK4xAk0oiHNrCWBC+vszzmHi+O7aXc/OpIN97KaV6DaiQWt54JBkEoPQ55gnG h31+zu+4ebQSFAoTo28Hm78c9sltaD/cIzkkqsKz5fPaS0p24U1PfWaXvyQLxMAV 8pD17weKXDFBVjabSkeLf+wMcWRpWG6SHKSbRaFPiplPl1Fd4kV1SEFDW8QIslal dwInjL+skexlh6mOtQunEVLCuLANQVW+X7aDBSK6gTXxBy/P1fI2NrrEtOCC7OkJ r6+EnttF5u5C69QK8JTnJoBgO/Z0Wi1j4OeeCyTm7K7bqbGIOsBiEoNFC6uNtpq/ MGfQgF4cjJw24+LPmMFh =es6/ -END PGP SIGNATURE-
Bug#926168: debian-policy: §9.3.2 difference to LSB (force-reload action of init scripts)
Package: debian-policy Version: 4.3.0.3 Severity: normal Hi, Policy 4.3.0.3 §9.3.2 reads: force-reload cause the configuration to be reloaded if the service supports this, otherwise restart the service. LSB 5 (but this is also present in LSB 3) reads¹: force-reload cause the configuration to be reloaded if the service supports this, otherwise restart the service if it is running ① http://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html Please clarify whether the omission of “if it is running” after “otherwise restart the service” is a deliberate deviation from LSB (whether initially deliberate or caused by compatibility) or adjust the text to include this. This has relevance because, for a service that does not support reloading (or where the init script maintainer does not know how to achieve that in a meaningful way), force-reload would be equivalent to “restart” per Policy but “try-restart” per LSB, the difference being that “try-restart” does not start the service if it is not currently running, whereas “restart” does. -- System Information: Debian Release: buster/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable') Architecture: x32 (x86_64) Foreign Architectures: i386, amd64 Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) debian-policy depends on no packages. Versions of packages debian-policy recommends: ii libjs-sphinxdoc 1.8.4-1 Versions of packages debian-policy suggests: pn doc-base -- no debconf information
Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages
Ian Jackson dixit: >The problem is that `3.0 (quilt)' has both advantages (eg that >`nativeness' is declared explicitly) and disadvantages (patches stored Not necessarily: | $ cat rs/debian/source/local-options |single-debian-patch | $ cat rs/debian/source/local-patch-header |Please review changes against upstream code using SCM, |see the Vcs-* tags in debian/control for its location. | (empty line at the end) This allows working with 3.0 (quilt) packages precisely the same way (well plus a “git clean -dfx” after building) than with 1.0 packages. So, while it can be a bit annoying to have to first cut an origtgz from your repo excluding debian/ (or from a separate upstream branch) it works very well without tearing down the native package boundary. bye, //mirabilos -- > Hi, does anyone sell openbsd stickers by themselves and not packaged > with other products? No, the only way I've seen them sold is for $40 with a free OpenBSD CD. -- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc
Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages
Russ Allbery dixit: >local-options means that the maintainer sees a very different view of the >package than any other consumer on the package via the archive. Not only Right, but the packaging workflow is the same (and since there is only one quilt patch, the view other developers have pretty much matches). It even has a benefit: NMUs can be added as extra quilt patches, and the maintainer can just commit them. >is this philosophically a bit weird, it also breaks tools that try to keep >the repository and maintainer view consistent (such as dgit). I suspect >it is therefore not the solution Ian is looking for. Ah right, there’s that. OK. Hope the method I’ve suggested helps someone reading the archives anyway, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)
Bug#522776: C.UTF-8 in squeeze
Aurelien Jarno dixit: >Doing so means that the locales or locales-all package will be installed Hm, localedef is in libc-bin – can C.UTF-8 not be generated by its postinst (with some logic in locales-all to restore C.UTF-8 in its postrm)? bye, //mirabilos -- “Having a smoking section in a restaurant is like having a peeing section in a swimming pool.” -- Edward Burr -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1101101307410.11...@herc.mirbsd.org
Bug#196367: priority dependencies and alternatives
Hi, with the latest developer news I saw mksh was listed. However, mksh needs to have dependencies on "debconf ($foo) | cdebconf ($bar)" in two flavours – one is added so lintian doesn’t complain due to mi- nimum version requirements for certain features, the other is added via misc:Depends from debhelper. Now, cdebconf has priority extra. Do I need to do something to my package, and if so, what? Downgrading all packages with an alternative dependency on cdebconf doesn’t seem sensible to me, so the language might need to change. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-) -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.00.1102011607130.23...@tglase.bonn.tarent.de
Bug#196367: priority dependencies and alternatives
Russ Allbery dixit: >that clearly, but I'm quite confident that's the intention. Yes, thought so. However I was surprised to see it pop up in the list, and perhaps other packages are similarly affected, maybe not even this visible. So what now? Does ftpteam read here or do I contact them, and point out a likely mistake in their script? Or does the wording need a change first? bye, //mirabilos -- "Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL." -- Henry Nelson, March 1999 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1102012159370.20...@herc.mirbsd.org
Bug#620566: dpkg: "version number does not start with digit" is in contrast to policy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA384 Guillem Jover dixit… > : ~ (full stop, plus, hyphen, colon, > - tilde) and should start with a digit. If there is no > + tilde) and must start with a digit. If there is no > debian_revision then hyphens are not allowed; +1 (especially considering how version n̲u̲m̲b̲e̲r̲ comparision works) bye, //mirabilos - -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in "Notes on Programming in C" -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MirBSD) iQIVAwUBTZiTxna1NLLpkAfgAQkmCxAAkpSxV8K+E+jYAqxk7F2Ow0K2bQ/ajryr H3shjfygxSowSHEXzuC6edkQiZfIJsFLwuMkFYDgq+HTrXgMRhWUHdVkq70Q68KW qQkk3M6tgauRMjH/De/SIhnCSo4xUH0umNaMdaK5qaobDpssG8R/Wg68ETyr/lZy 3DfW0kMwJpaYH6MW2hiLUNiJcP0FttMqRjOd9s4kjWU6/7/rADYHr/o0yjz+lk0Q tRebUjBuMPi/kZQHjep1jACKQjuIDU0QM/PMBuf6EerJnhJUu3GcVBCthyZAnhUW YyEN7By2s2o+/ZBIjSSu7bvYP/hgwV4SrMx5HAqMxYzWCUvYBFfIFvmg9K3DViCB d+YQFMP1L/bHdR0LtSmklvINCBDfDdrceF62LG6ltWEApsDWjFKSOUJgf9y7P/vv /j9J/JYodc8pNYPuG2/KIJWH6vdlDy59TeMzFzAd2vebBdOyZ2SZ0+UBUh9nUm1u kRf6gNy2nzmdXGmlcdAbNDvJslCOL7e++WgcyGwa7PjXspJUW83c188sDvP1GikU oQz+1tRZbwiE+nIIuu8muukfzNibKFEMkbeoGemSn+O5Z24eSHMvMWIX/ZorixtH +CWSF9wl3IJMflf/jxk941rx7MRCTKjQ3yAJVrLw0SoP5qb07E0maxYLv19ZBnrQ eIu/T5T+phU= =Ck2S -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1104031532400.24...@herc.mirbsd.org
Bug#620566: dpkg: "version number does not start with digit" is in contrast to policy
On Mon, 4 Apr 2011, Carsten Hey wrote: > upstream_version git1234 could be prefixed with epoch 0 and thus lead to > the version number 0:git1234-debian_revision. Maybe this could be Nah. Just drop the leading 'git'. On Mon, 4 Apr 2011, Raphael Hertzog wrote: > We have no upstream with such versions currently in Debian. I don't really We have, mksh version numbers are mangled (see its watch file) in a defined way. It uses a repacked source as .orig.tar.gz, but since dpkg’s extraction mechanism doesn’t really care, for a package with a normal tar.gz upstream this wouldn’t even matter. bye, //mirabilos -- «MyISAM tables -will- get corrupted eventually. This is a fact of life. » “mysql is about as much database as ms access” – “MSSQL at least descends from a database” “it's a rebranded SyBase” “MySQL however was born from a flatfile and went downhill from there” – “at least jetDB doesn’t claim to be a database” (#nosec)‣‣‣ Please let MySQL and MariaDB finally die! -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.00.1104081424520.7...@tglase.bonn.tarent.de
Bug#694384: Bug#694404: More info on cloned bug
Hi all, I think pbuilder’s strict interpretation is correct, especially as the wording of Policy (and RFC822) don’t provide for an empty line before the “first” paragraph, and think we should re-enforce that (literal) reading of Policy and have the packages be fixed and a check added to lintian instead of changing pbuilder. Note that the permit to add comments to debian/control is pretty recent; traditionally, you could not even do that. bye, //mirabilos -- Darwinism never[…]applied to wizardkind. There's a more than fair amount of[…] stupidity in its gene-pool[…]never eradicated[…]magic evens the odds that way. It's[…]harder to die for us than[…]muggles[…]wonder if, as technology[…]better […]same will[…]happen there too. Dursleys' continued existence indicates so. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1211261002140.27...@herc.mirbsd.org
Bug#663762: Bug#694282: openssh: uses too much system ressources to build
Jakub Wilk dixit: > * Colin Watson , 2012-11-25, 15:53: Nothing in policy forbids using -j if parallel *isn't* set; it only specifies behaviour when parallel is set. >>> Hmm. Not in the wording, but that’s why I said that’s my reading. >> To clarify, I think this would be a reasonable thing to suggest as a policy >> amendment; I might well even support it ... > > See bug #663762. Ah, thanks. Cc’ing that bug, with my +1 for defaulting to one job (see #694282 for a slightly longer reasoning; basically, I might want to run more than one build, or do other things in parallel, or have a RAM-constrained machine). bye, //mirabilos -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1211261732490.23...@herc.mirbsd.org
Re: Bug#709382: mksh: broken Built-Using handling
Sune Vuorela dixit: >The handling of built-using is wrong. It is not meant to encode the >compiler used, nor binutils or kernel headers should be recorded there Policy 3.9.4 §7.8 says: Some binary packages incorporate parts of other packages when built but do not have to depend on those packages. Examples include linking with static libraries or incorporating source code from another >It is specifically for building against -source packages and for hacks >like ia32libs where binaries are copied into a source package. Not for >'everything'. In this specific case, there are one to two statically linked programs there. In some cases, they link statically against a GPL licenced library. So my current interpretation of the text from Policy above says that Built-Using is indeed required there. >What you effectively are doing is asking for a mksh rebuild on each No, just that dak keeps the source versions around for longer. A final rebuild near the end of the freeze should be enough, if it is indeed needed at all. (If dak just keeps the relevant source packages at hand, and they end up on the source CDs, I believe all requirements are met, and IIRC reading that this, not rebuilding, is how things are handled on Debian side; the only requirement is that, upon a binary *entering* the archive, the source packages in that precise version must be known to dak, i.e. not already superseded (by newer version, NBFAS or removal); once a package B-Us them they will not be removed. I’m closing this as not a bug. Please feel free to file a bug against the Policy wording in the meantime; as things are now, the wording specifically includes statically linked binaries. The composition of B-U in mksh is as follows: • mksh-static is always built statically; either against klibc (plus linux-libc-dev and libgcc), or against dietlibc (plus libgcc), or against eglibc (plus libgcc) • lksh is built statically if klibc or dietlibc are available, with the same “plus” as above • the build script records what was actually put into the binaries, gets the appropriate source package relationships from that and puts it into Built-Using In the dietlibc case at the very least (since it’s GPL; would have to look closer at others), the resulting binary is fully covered by the requirement of the GPL that its precise and complete sources be available. I don’t mind changing this *at all*, but I can only do that (justifiedly) if it’s not against what I believe to interpret Policy correctly (especially since it specifically lists static linkage), or if there’s a CTTE resolution asking me to change it. I’ve had more troubles with this B-U ever since using it in experi‐ mental, so… really, no argument from me, just following Policy (with some background in licencing and toolchains). bye, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.130518500.12...@herc.mirbsd.org
Re: Bug#709382: mksh: broken Built-Using handling
Russ Allbery dixit: >In the meantime, please don't add Built-Using for libgcc. The libgcc >license does not require it, due to the runtime exception, and essentially The dietlibc licence does require for libgcc to be added there (GPL without exception clause). bye, //mirabilos -- > Hi, does anyone sell openbsd stickers by themselves and not packaged > with other products? No, the only way I've seen them sold is for $40 with a free OpenBSD CD. -- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1305230751140.18...@herc.mirbsd.org
Re: Bug#709382: mksh: broken Built-Using handling
Russ Allbery dixit: >> The dietlibc licence does require for libgcc to be added there >> (GPL without exception clause). > >I think you mean that dietlibc requires that *dietlibc* be added, right? No, I meant it like that. >If not, I'm confused. I don't see any reason why dietlibc's license would >change something about libgcc's license. dietlibc is GPL, so a derivate is also GPL. The mksh-static and lksh binaries, when linked against dietlibc, consist of dietlibc, libgcc and mksh derived source code, but the final binary is the work whose exact sources must be available. bye, //mirabilos -- «MyISAM tables -will- get corrupted eventually. This is a fact of life. » “mysql is about as much database as ms access” – “MSSQL at least descends from a database” “it's a rebranded SyBase” “MySQL however was born from a flatfile and went downhill from there” – “at least jetDB doesn’t claim to be a database” -- Tonnerre, psychoschlumpf and myself in #nosec -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1305231604380.2...@herc.mirbsd.org
Re: Bug#709382: mksh: broken Built-Using handling
Russ Allbery dixit: >If this license analysis is correct, then we have to do this for every >binary on the system that's covered by the GPL v2, since I believe some Hmm. >stub code from libgcc is *always* included statically in every binary, >even if the binary is built dynamically. (Or at least there's a good The csu are included, and TTBOMK some of it comes from GCC and some from the libc in question, so, probably yes. Ouch. >I've never heard the FSF, who are responsible for all the licenses in >question, interpret the licenses this way. So I'm quite dubious that this >analysis is correct. I’m not dubious it’s correct, but it’s likely nobody would care… but I’d rather not be the one making this decision. Whom to involve, d-legal? bye, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1305231812000.2...@herc.mirbsd.org
Re: Bug#709382: mksh: broken Built-Using handling
tl;dr: last paragraph. Dixi quod… >Russ Allbery dixit: > >>If this license analysis is correct, then we have to do this for every >>binary on the system that's covered by the GPL v2, since I believe some […] >The csu are included, and TTBOMK some of it comes from GCC >and some from the libc in question, so, probably yes. Ah. Got it. GPLv2 §3 says: | control compilation and installation of the executable. However, as a | special exception, the source code distributed need not include | anything that is normally distributed (in either source or binary | form) with the major components (compiler, kernel, and so on) of the | operating system on which the executable runs, unless that component | itself accompanies the executable. This clause is generally interpreted like this: If you link against something normally on the system (kernel, libc, compiler), but don’t put that (as upstream distributing precompiled binaries) into the same distribution as you program linked against it, it need not be GPL. But this interpretation is generally restricted to dynamically linked binaries… So that’s relatively vague. I have no idea whether it may help in general or in the specific case. I’d suggest to ask the FSF (as licence author), Felix von Leitner (as dietlibc author – note I have not analysed eglibc and klibc on whether they also force the mksh-static binary to be GPL), and maybe d-legal whether the distribution of a binary statically linked against dietlibc (GPL), the toolchain (kernel headers and GCC startup files, normally with an exception clause) and the binary’s regular source code (GPL compatible) causes the other parts to become subject to GPLv2 §3 as “complete source code”. Might also be worthwhile to look at Cygwin, whose licence statement interprets (current wording; it seems to change over time, and they switched to GPLv3 in the meantime, but the idea has been there for longer): | The Cygwin™ API library found in the winsup subdirectory of the | source code is also covered by the GNU GPL (with exceptions; see | below). By default, all executables link against this library (and in | the process include GPL'd Cygwin™ glue code). This means that unless | you modify the tools so that compiled executables do not make use of | the Cygwin™ library, your compiled programs will also have to be free | software distributed under the GPL with source code available to all. They basically say: by linking against the import library (eglibc has a rough equivalent in libc_nonshared.a) you always include parts of the library, so it’s GPL. (They have a special exception for open source software, but make actual money from selling commercial licences for people to link their applications against the Cygwin libc.) Now dietlibc contains no such exception, *and* it’s linked statically here, which makes this relatively hard to excuse. (Again, klibc and eglibc would need looking at; currently, I’m treating them the same, except only klibc pulls in linux-libc-dev AFAICT, so the others do not cause it to be added to Built-Using.) As for dynamically (against eglibc and possibly klibc; dietlibc does not currently support it) linked binaries… as far as I can tell, it is like this: The binary itself may be GPL, but for it, the exception causes “anything that is normally distributed” to not be subject to it, so it doesn’t matter. (Binaries linked against GPL libraries will be the same; the GPL library causes the main program, but not the system components, to be GPL – if you follow the FSF interpretation, which Debian does, and not the Python/Usenet one.) The system component itself will have an exception clause, so it doesn’t cause this either. I just looked at klibc: for shared binaries, only interp.o from usr/klibc/interp.S is added, which is so trivial it’s not even copyrightable. (klibc’s “dynamic” link mechanism is……… “different” and tricky. It’s not ELF shared objects.) For eglibc, the situation is well understood AFAIK, and it contains exception clauses for things like crt1.o IIRC. So, current Policy wording may indeed be correct in that it requires the B-U for static executables (even the startup objects part), but not for dynamically linked ones, since those libcs in Debian that do support that either do not infer the GPL on the executable or have exception clauses for that case, and since neither the executable nor any other (non-system, but Debian even considers OpenSSL non- system much to my chagrin, so basically all) libraries it links against cause the GPL to be applied to the system library part. bye, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact
Re: Bug#709382: mksh: broken Built-Using handling
Russ Allbery dixit: >debian-legal isn't really the correct venue. It's just a discussion list Ah, okay. >going to start with leader and see if Lucas has an opinion about where to >start with making decisions here. One option available to leader is to >ask for an opinion from external legal counsel. That sounds like a good idea. (Were legal reasons the driving force behind adding Built-Using in the first place?) bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in "Notes on Programming in C" -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1305232039440.2...@herc.mirbsd.org
Re: Bug#709382: mksh: broken Built-Using handling
Russ Allbery dixit: >At the time, though, the assumption was that Built-Using would be a fairly >rare thing that would only be used for those few score packages that were >Build-Depending on *-source packages. And statically linked executables, since that made it into the Policy wording; or possibly, dynamically linked ones that incorporate static libraries from other packages… or Haskell… I think there may be a can of worms or two. I’ve read about the toolchain/-source issues, indeed, but I’m wondering a bit whether a hypothetical statically linked executable from only BSD-licenced sources would need Built-Using (as per current Policy: yes, even though the licences don’t mandate “complete” source availability like the GPL does). Anyway, this probably won’t help us, so I won’t go on with that direction of thought any more. Thanks, //mirabilos -- 08:05⎜ mika: Does grml have an tool to read Apple ⎜System Log (asl) files? :) 08:08⎜ yeah. /bin/rm. ;) 08:09⎜ hexdump -C 08:31⎜ ft, mrud: *g* -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1305232109200.2...@herc.mirbsd.org
Re: Bug#709382: Built-Using, libgcc, and libc_nonshared
Russ Allbery dixit: >If we do need to preserve source for the libcc and libc components >incorporated into binary builds, that's going to mean Built-Using for >nearly the whole archive, and a lot of complexity on the DAK side. That's >obviously not very desirable. We would rather decide that we don't need I’ve tried to draw up an argumentation why this is probably only necessary if the package contains statically linked files, see the discussion in the mentioned bugreport, but IANAL, just have some history in dealing with (mostly OSS) licencing as a hacker, BSD project lead and employee, so TINLA. Interestingly enough, even then, differences from the libcs used can ensue; for dietlibc (GPLv2) it’s pretty clear, but statically linking against klibc *may* and dynamically linking against it *will not* invoke the GPL on the result. (The “may” is because most parts of klibc aren’t GPL, and a quick git grep shows that the C library itself is probably free of GPL code, but I did no throughout analysis except for dietlibc and – for mksh – linking with which libc involves files from which packages.) >Also, if we're going to decide that we're not going to track source code >for that sort of inclusion, we need to know what the boundaries of that >exception or decision are That’s probably the difficult point and why escalating this looked like the best option at that moment. Sorry for raising not just one but two legal issues in one day (but the Creative Commons thing is handled on the upstream side right now, I just asked them to keep us in the loop). bye, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1305232102250.2...@herc.mirbsd.org
Re: Bug#709382: Built-Using, libgcc, and libc_nonshared
Russ Allbery dixit: >of the GPLv2, the GPLv2 itself requires that all of the *source* for the >binary be distributed under the GPLv2. And the libgcc *source* is only >available under the GPLv3, and the runtime exception doesn't allow one to >distribute the *source* under different terms, only the resulting binary. Ouch! >Clearly no one else in the world is worrying about this; there's lots of >GPLv2-only software out there and all the distributions are happily The same thing happens with software labelled as “Public Domain”. There are several cases (the authors aggressively sell licences for those who don’t trust their say-so it’s PD (sqlite) and which are to be avoided at any cost; these where the authors say it’s PD (and subsequently don’t care nor sue) but it isn’t (e.g. if you’re in a country where you can’t dedicate something into PD by yourself, or if some conditions are met, even for USA), or legitimate PD in *one* country (often stuff done by government)), but there is no such thing as global PD as it’s by its definition absence of copyright protection, and the Berne Convention only harmonises copyright protection, so something PD in one country is proprietary in all others in virtually all cases… but this issue only has popped up on the OSI mailing list, and so far, almost nobody cares (I try to get “fallback” clauses from authors myself, succeeded for some, failed for most). >I'm not sure to what extent we can use that as an excuse, though. I guess until you come in front of a court. But there’s the other thing: if a distro/OS promises to use only code with (known) good licences, so that their users can rely on it, like http://www.openbsd.org/goals.html (second list item), one probably does not _want_ to have “grey zone” in their distri‐ bution, so it may be good to be proactive. There’s something else about Built-Using: Are those source packages (that would not otherwise be kept in the archive) released along with “stable”, despite having no binary packages? If not… well, since snapshot.d.o is an official service now, I’d say, point there for the “legal” side, and only require Built-Using to be used for the cases where it’s desireable to have this information present more explicitly, that is, the original toolchain and embedding stuff, possibly static linking and Haskell. Pragmatic but probably doable, and since quite some time, sbuild records (in the build log) the versions of the toolchain packages installed already anyway, so we just need to put build logs into the snapshots archive as well; I believe they’re deleted when an architecture moves off the main archive (to d-ports, or because it’s no longer even in oldstable) normally. bye, //mirabilos -- "Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL." -- Henry Nelson, March 1999 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1305232120160.2...@herc.mirbsd.org
Re: Bug#709382: Built-Using, libgcc, and libc_nonshared
Russ Allbery dixit: >Thorsten Glaser writes: >> If not… well, since snapshot.d.o is an official service now, I’d say, […] >Hm, that's an interesting point, indeed. >> Are those source packages (that would not otherwise be kept in the >> archive) released along with “stable”, despite having no binary >> packages? > >Yes, I believe that's how the implementation works. In that case, require B-U only for those where we want or need to have them in the release. (And schedule binNMUs on “unproblematic” packages shortly before the release, to keep even that number down. Of course, this *may* introduce new bugs, but in that case the package was (hiddenly) RC-buggy in the first place. And we’d probably want the binNMU to happen in testing/frozen not in unstable, at that point… well, jessie’s a long way, so some part of this may, as crazy as it sounds, even look acceptable. Or not. Just random ideas.) bye, //mirabilos -- Yay for having to rewrite other people's Bash scripts because bash suddenly stopped supporting the bash extensions they make use of -- Tonnerre Lombard in #nosec -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1305232143000.2...@herc.mirbsd.org
Bug#780725: PATH used for building is not specified
On Wed, 18 Mar 2015, Bill Allombert wrote: > On Wed, Mar 18, 2015 at 12:48:13PM +0100, Holger Levsen wrote: > > buildd.debian.org uses > > > > PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games Urgh! /usr/local in package builds? It’s unquestionable it should be set like this, and possibly in this order, in login shells (though Debian misses the sbin ones for regular users), but for system tasks? No. > > while pbuilder uses > > > > PATH="/usr/sbin:/usr/bin:/sbin:/bin" That *is* a sane one… > In any case, policy currently has: > > 10.10. File names > - > > The name of the files installed by binary packages in the system PATH > (namely `/bin', `/sbin', `/usr/bin', `/usr/sbin' and `/usr/games') > must be encoded in ASCII. > > though it is a strange place to define the system path. … but, yes, there is this. So, both the buildds and pbuilder should be changed to use… PATH=/usr/sbin:/usr/bin:/sbin:/bin:/usr/games … for builds, right? Where does one assigne the buildd part to, the buildd package? (AIUI, the Debian buildds, in contrast to many debian-ports buildds, do not use the buildd package from Debian.) bye, //mirabilos -- [16:04:33] bkix: "veni vidi violini" [16:04:45] bkix: "ich kam, sah und vergeigte"... -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1503260930280.12...@tglase.lan.tarent.de
Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
Package: debian-policy Version: 3.8.1.0 Severity: wishlist For the mksh regression tests, I need a UTF-8 locale working; most systems either provide “en_US.UTF-8” or “en_US.utf8” with the former being recommended. Build-depending on locales-all has worked for me so far, except it won’t do in Kubuntu where said package does not exist (workaround is to run 「locale-gen en_US.UTF-8」 in a pbuilder hook, but that’s almost certainly not allowed in debian/rules *and* requires root), and fails on hurd-i386 recently (locales-all fails to install). The promise of the etch release to bring UTF-8 support was not met because a standard installation of etch does not supply any locale which can be used for LC_CTYPE with UTF-8 support; only installing locales-all, or installing locales and debconfing one will do so. I do not know about lenny, though, I have to admit. The most light-weight solution would be to • introduce a “C.UTF-8” locale, as some other OSes did, which is equivalent to the “C” (POSIX) locale in all respects *except* for LC_CTYPE, where it uses UTF-8 instead of a 7/8-bit charac- ter set or encoding • deliver the “C.UTF-8” locale with the base system • allow Debian packages to depend on its existence, both at build and run time A more controversial solution would be to do the second and third point of the above with the “en_US.UTF-8” locale, but that would be favouring US americanism. (On the other hand, it’s *the* one most widely spread UTF-8 capable locale available, and as such, the mksh regression tests use it upstream already.) Thanks in advance. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-xen-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/mksh debian-policy depends on no packages. debian-policy recommends no packages. Versions of packages debian-policy suggests: pn doc-base (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
Giacomo A. Catenazzi dixit: > If you need a specific locale (as seems from "mksh", not > sure if it is a bug in that program), you need to set it. You can only set a locale on a glibc-based system if it’s installed beforehand, which root needs to do. > Why does mksh need UTF-8? The regression tests check if the Unicode mode of mksh is properly enabled in a UTF-8 locale, and properly disabled outside of them. > Mandate > UTF-8 as default (instead of C/POSIX) would probably > be worse (and non POSIX conformant). This is not what I proposed. I proposed that an additional C.UTF-8 locale shall be available on all Debian systems, to complement the default 7/8-bit C locale. > but "C" means "old sysadmin gergo". Yes, but some programmes basically need that plus UTF-8. For example, the traditional sorting order, gcc output warnings, date format, etc. Note that mksh *is* fine with any locale, UTF-8 or not, it just makes a distinguishing on the nl_langinfo(CODESET). However, the *regression test suite* for mksh, run at build time, needs one UTF-8 locale, and it needs to know which one. On most systems, this is “en_US.UTF-8”. But Debian, despite its release goals of UTF-8 support, does not guarantee its existence. This is what I’d like to have changed. > So, if I interpret right your problem, the right solution is: > - mksh should allow all locales and charsets This part I think you don’t interpret correctly. > and one of: > - Debian should mandate (ev. recommend en_US.UTF-8) > [ I think it is right on standard installation, but IMHO > it could be to strong for a minimal essential base (chroot)] > - or a "en_US.UTF-8" package dependency should be required. Right, one of them. Or at least, have the locales pregenerated, maybe so that I can depend on a "locale_en_US_UTF_8" package. bye, //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
Bill Allombert dixit: >What about LC_COLLATE (which is a major problem with sort(1)) ? 1:1, just like the C locale does. >What about packages that run before /usr is mounted ? They do not have /usr/*/locale/ anyway. This is a glibc problem. >What about embedded systems with tight space requirement ? They have different rules anyway… they need to see themselves if the C.UTF-8 locale (estimated ~200K) is worth it. //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
Adeodato Simó dixit: >+ Thorsten Glaser (Tue, 07 Apr 2009 18:54:59 +): > >> Except the ton which sets LC_ALL=C to get sane (parsable, >> dependable, historically compatible) output. > >> These would then unset all other LC_* and LANG and LANGUAGE, >> and only set LC_CTYPE to C.UTF-8 to get "old" behaviour but >> with UTF-8 (and mbrtowc and iswctype and and and) available. > >Isn’t setting LC_ALL=C.UTF-8 going to be about the same and less work? Indeed. >I’m genuinely interested if that would behave any different to what you >said (unsetting all, setting LC_CTYPE). For my proposed C.UTF-8 "locale" it would be exactly zero, nada, difference. (For en_US.UTF-8 it is a lot of difference, for example sorting order.) Unfortunately, GNU libc needs a locale to even enable UTF-8 support. bye, //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
Bill Allombert dixit: >Fortunately, since Sarge, debian-installer set LANG in >/etc/environment so programs almost never run under C locale anymore. Except the ton which sets LC_ALL=C to get sane (parsable, dependable, historically compatible) output. These would then unset all other LC_* and LANG and LANGUAGE, and only set LC_CTYPE to C.UTF-8 to get "old" behaviour but with UTF-8 (and mbrtowc and iswctype and and and) available. For what it's worth: vorlon gave me the means to change the mksh regression test (LOCPATH), so that this will no longer block it on the HURD. However, I'm still in favour of a de- fault UTF-8 locale (be it C.UTF-8 or en_US.UTF-8) installed plus, maybe, one binary package per locale? Aurelien - if I remember correctly - said something along these lines too. bye, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
Roger Leigh dixit: >However, I would ideally like the C/POSIX locales to be UTF-8 >by default as on other systems (with a C.ASCII variant if required). No, this has the potential to break, for example, tr(1). I lived through that on MirBSD. //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
Adeodato Simó dixit: >I would go as far as suggesting that some package like libc6 itself FWIW: -rw-r--r-- 1 tg tg 238336 Apr 7 22:59 en_US.UTF-8/LC_CTYPE It's not *that* much... >Finally, this stuff that Roger proposes about making “C” be UTF-8, and >create some C.ASCII for people needing that, sounds shocking at the same >time as appealing. It won't work, because in a UTF-8 locale, for example stdio functions must reject "invalid" (not valid UTF-8) input, so it would not be 8-bit clean/transparent any more. //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
Roger Leigh dixit: >But, does it not reject non 7-bit input in the C >locale for completeness? No, it doesn't - "we" (before my time though, I think) fought hard for eight-bit transparence and eight-bit cleanliness. >Should tools doing "raw" I/O not be using lower level interfaces >such as fread() and fwrite() These too are affected. //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
Roger Leigh dixit: >Are you sure? Not entirely, but I recall fgetc (or was it fgetwc?) being affected. //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
Giacomo A. Catenazzi dixit: > The locale C is already a UTF-8 compatible locale. It is UTF-8 transparent but that's its pro and con. It does not tell the system that UTF-8 encoding is to be used. It basically says the encoding is none/unknown. > Why build need to depend to a locale? [...] > For testing? So why not test various locales (UTF-8, but also other non > ascii based encodings) > to go to the point: what is the problem in mksh? > At which level it fails? [...] > But if mksh don't work on "C", I'm very worried. > The problems are on inputs or on outputs? I think you misunderstand the mksh part of the problem. mksh has two modi: a legacy mode, in which it does not make any assumptions about charsets or encodings and is 8-bit clean and mostly 8-bit transparent, safe a few mostly past bugs and imple- mentation shortcomings, and a unicode mode, in which it assumes its input is UTF-8 (although, with ^V, you can still enter non- UTF-8 sequences, and tabcomplete filenames in legacy encodings as well). The unicode mode is enabled with "mksh -U" or "set -U". However, mksh has a feature which automatically enables the uni- code mode if - the current CODESET is UTF-8 (or the locale ends in .utf8 or .UTF-8 or something similar, in some cases), or - the input begins with a UTF-8 BOM. The regression test suite merely checks for this feature. To do so, it needs a way to set the checked mksh process' CODESET to UTF-8, which is only possible by setting a non-C/POSIX locale. Andrew McMillan dixit: >The proposal, at this stage is only that the C.UTF-8 locale is >*installed* and *available* by default. Not that it *be* the default, >but that it *be there* as a default. This is about what I was to propose, indeed. Andrew McMillan dixit: >Once this minimum step is made, and we've all calmed down, we can think >further on radical and dramatic changes over coming years where more >significant shifts are made, like: > >* The default locale at installation is C.UTF-8 rather than C. That would be nice. >* If a locale is set which doesn't specify an encoding, the system >defaults to assuming UTF-8. Andrew McMillan dixit: >[...] and indeed Steve >Langasek has already suggested a seemingly reasonable workaround for the >immediate problem which was, funnily enough, that mksh wants to have a >UTF-8 locale *available* in order for it to *test the build*... Yes, his suggestion and searching for someone to actually use it (Daniel Jacobowitz does) helped that part of the problem. However, the mksh regression test suite is only one of the manifestations. Even as a mere user, I'd like to have, see above, a UTF-8 locale available and, if possible, default. Well, maybe not a UTF-8 locale, just UTF-8 encoding (especially when I ssh from a MirBSD system to a Debian system, since on MirBSD there is *only* UTF-8¹), but glibc defines encodings exclusively via locales, which is why I'm in fa- vour of C.UTF-8 for myself, but setting LC_CTYPE only has the same effect (and I often set LC_MESSAGES to en_GB.UTF-8 for gcc's bene- fit). Giacomo A. Catenazzi dixit: > "Debian will use as default unicode, encoded according to UTF-8", but > not *assume*. It is again portability. I agree too. You cannot simply assume things. > Let (old) programs to works > also on the future Debian. These need to export LC_ALL=C already, since you've been able to choose a locale in d-i for a while, so no change there. bye, //mirabilos -- 23:22⎜«mikap:#grml» mirabilos: und dein bootloader ist geil :) 23:29⎜«mikap:#grml» und ich finds saugeil dass ich ein bsd zum booten mit ⎜ grml hab, das muss ich dann gleich mal auf usb-stick installieren -- Michael Prokop von grml.org über MirGRML und MirOS bsd4grml -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
Giacomo A. Catenazzi dixit: > This is good way to do things! Thanks. > Or a debhelper (or like) utility > that "construct it" for build needs. That’s already done, as I said – vorlon gave me an idea, I implemented it, it works, I uploaded a new mksh package… and then I saw someone’s added it to the D-D-R since I last looked into it… > In this case "us_EN.UTF-8" is a sensible locale (we want to test It’s “en_US.UTF-8” by the way. > a real locale), but in this case I would also test some UTF-16 > or Asian locale (mksh should not assume UTF-8 in these cases). It doesn’t. This test is already run for the C locale. Besides, there are no UTF-16 or somesuch locales on UNIX® or compatible systems. //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#490605: Bug#532324: udev init script bash+dashism: assumes printf is a builtin
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Debian Policy 10.4 states that shell scripts using a /bin/sh shebang line must conform to POSIX Shell, with a few (listed) exceptions. http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html specifies, under “Command Search and Execution” 1.c, a list of required shell builtins. I cannot find printf(1) there, or in any other place of current SUSv3 (online edition), for that matter, except as stand-alone utility. udev uses /bin:/sbin as $PATH whereas printf(1) lies in /usr/bin. udev uses printf nevertheless, assuming it right because GNU bash sup- ports it and dash, unlike posh (I think) and other Debian Policy 10.4 compliant /bin/sh-capable shells, implements it as a speed hack (lower boot times combined with portable use of printf, since echo isn’t). I call for the CTTE to decide that no maintainer is above Policy 10.4 and that udev shall be fixed to not use printf as builtin, or require a different shebang. My proposals: ① udev in sid will be changed to use "#!/bin/dash" as shebang; udev in lenny will be changed to use "#!/bin/bash" as shebang. The change in lenny is necessary, as it is affected as well. ② udev in both sid and lenny will be changed to not use printf any more. Both ① and ② need to override the maintainer’s decision. I would be most pleased if one of the above were to be decided upon. ③ coreutils will be changed to move /usr/bin/printf to /bin/printf and have a /usr/bin/printf@ → ../../bin/printf symbolic link. I do not like this. It is non-standard, an evil workaround, and will(!) lead to the creation of more unportable scripts. ④ dash will be changed to have the printf builtin removed, so that maintainers will be forced to change their scripts. I do not like this. Debian uses dash to provide a rather minimal /bin/sh for quick system startup. While the presence of a printf builtin is a speed hack, it serves this purpose well. Other shells, including bash, ksh93, mksh and posh, but not pdksh, can be used to validate scripts instead. ⑤ Debian changes policy to allow the use of bash+dash as /bin/sh. I do not like this, for similar reasons as in ③, as well as for the fact that I fought to have mksh an allowed /bin/sh in Debian, which has led to improvements upstream. These may be personal, but I expect this proposal to be rejected due to the unportabi- lity argument. I think using printf is okay *as long* as it it possible for the script to pick it up in /usr/bin/ and *not* rely on an unportable builtin. The whole point of Policy 10.4 is portability, and maybe even portability beyond Debian. It _is_ well-known, after all, that shell and utility "echo" are both unportable. (This serves as comment to #490605.) The motion to have maintainer scripts, whether in udev or other places, fixed so that /bin/sh can be a shell other than GNU bash or dash, is supported (as in, they don't like the current situa- tion) by the DDs Alexander Wirt, Gerfried Fuchs, and possibly others. Thank you very much for your consideration. //mirabilos – mksh Debian Maintainer – Project Leader, The MirOS Project - -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MirBSD) iQIVAwUBSnBN2Ha1NLLpkAfgAQNmxQ//RCMN/DovvBuFp2nGqhm55lccA6iGLUCX EDUGcwPVX0OdWlESa6UjSswNv75kXyuAY1vX5PW09o9M/6NLQU46L+TOP6ZbGDsz dunimBEoEhw/YzZU1KkOplX7uCyOB39+cvQ4CmwP9U4N5hIGqlttDkWFO+1fwEWR yEUQ1W8h0zH9M8APGCwgGf6BbdTE2Cmx4uV+tppZ4xwEhxgH6UvjjGm6KmOsKpfl OzFIb37hhZbxpyywNzWs7Fw4Ze4PC8UqK/dbzn40LLfbQSob3bDj/dfODX0dpwoL DmelAZzrdDC5CLJASpXC05Jw3Wo2IgMkaCRWJx6/40SMdA9TKVejSD9LbnCAkamj M1M3aNdFxOW35GEXaJ4EByXGxCY9wTm93xD/f1j49zIBe/IIrfacpa9AU1YUhwaF W317xSHDJjXJGwLl5QPWGwxwV9lHvMG7K8rTiR/j/F6lMXwNf3nAQE9JvmRgnhVF D48LBygx7yXVD97Gtv4N9zv7namCDrBd5BrH4lQu2eAwWrtu5fmhODVxBEuBRt/L Sqv9ApBZaQmoE2P2ULyaEhpN4qCOi63GBzzEVuB7i2pUCfEdGTqqxP16EhK9bzzN s1L7mPagKcE2jfx1QsBGFeVafLNFs9WxyKhnjCU8V4Rj4xuCLyNCKLxO1DQw/Jx+ LTP8EfDi1xA= =1ufg -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#490605: oops
Oops… The bug I tried to handle was already archived. The new one is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539158 Sorry for the noise, //mirabilos -- 23:22⎜«mikap:#grml» mirabilos: und dein bootloader ist geil :) 23:29⎜«mikap:#grml» und ich finds saugeil dass ich ein bsd zum booten mit ⎜ grml hab, das muss ich dann gleich mal auf usb-stick installieren -- Michael Prokop von grml.org über MirGRML und MirOS bsd4grml -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#490605: […] assumes printf is a builtin
Steve Langasek dixit: >You're aware that [ (test) is also not listed as a mandatory shell built-in, >according to the POSIX reference you've cited? Interesting. >So from that perspective, there are lots of POSIX failures. Do you think we >should treat [ specially, but not printf, because mksh happens to implement >the one as a built-in but not the other? I see that this weakens my argumentation, but I could still mention that [ lies in /bin/ on BSD (and possibly a lot more OSes), and that (almost?) all POSIX compatible shells available on Debian implement it, whereas having printf as builtin is a feature in GNU bash, a mere speed hack in dash, and not available in many other shells. >No, portability beyond Debian is not relevant to Policy 10.4. We've never >been able to usefully rely on /bin/sh complying with POSIX on arbitrary >other Unices. I didn’t mean that; it was more in the sense of writing somewhat portable POSIX (not Bourne) shell scripts. >Does the mksh package somehow support switching /bin/sh automatically on >installation? Yes. >who want to use mksh instead of dash/bash that /usr must be on the same >partition as /. udev EXPLICITLY sets $PATH to /bin:/sbin in its init script, so that is not an option, unfortunately. >>From a Policy perspective, it would be ideal to document the set of >built-ins that we expect from a shell as /bin/sh, that scripts may rely on >prior to the mounting of /usr. Indeed. (Note that the printf in NetBSD® ash speed hack is rather recent.) >Have you looked at this set yet, by chance, >to see if there are others besides printf that mksh doesn't share with dash >and bash? Not yet, but I will and report. I also have looked at adding a printf builtin to mksh, but I don’t quite like it because it pulls in a *lot* of external symbols, including strtod, and introduces floating point into the binary. This is undesirable (also seeing that I have a project of an mksh linked against klibc, which I’d like to offer for initramfs, replacing the one from klibc-utils *and* busybox (if replacing both, at an actual size gain), for very little (in terms of disc space) cost but some benefit). bye, //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#490605: [...] assumes printf is a builtin
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Steve Langasek dixit: >Have you looked at this set yet, by chance, >to see if there are others besides printf that mksh doesn't share with dash Here they are: Builtins in mksh (-current from CVS), but not in dash (source from sid): * bind (interactive) * builtin * fc (interactive) * let (fancy for (( ... )) ) * mknod (another speed hack, OpenBSD's responsible for this one) * print (Korn shell command) * realpath (same as "readlink -f" from base) * rename (similar to mv but doesn't copy; sometimes a life-saver) * typeset (Korn shell command) * whence (Korn shell command; whence -p approximately equals which) Builtins in dash, but not in mksh: * chdir (use cd instead) * printf dash builtins implemented as built-in macros in mksh: * hash (alias -t) * local (typeset) * type (whence -v, but it's the same as command -V in dash+mksh) The macro versions do not pose a threat because the macros are "always" defined. (We had versions that didn't define them, ex- cept local, for a /bin/sh, but these are long gone.) So, the only mismatches are chdir (which could arguably be added as a Debian-local patch, unless shows me the benefit of having it upstream as well - if desired at all, that is; what does bash do?) and printf (the topic of this discussion). >and bash? Having looked at dash, I think I don't need to, since the team which converted /bin/sh to dash should already have done so ;-) bye, //mirabilos - -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MirBSD) iQIVAwUBSnCN1Xa1NLLpkAfgAQOEPg//Wuj9yQbbDkiooDAObflE6hJzG/bpGvQF ZNdCUX6p9wlvmpyIzXzOPf3+Q2XGyq8PaQ4O4ByX8J/oMrYG77M5NxzMh3L4DR/t +a9DB90KS4YRRt1heQviJgHR+lxeYZLf9X/wlRSVaQ2x3cKeuO7KBCk3Hjkwir2e Girza5gvtn+Za7ffvjGSHRYWQEcT28g1E/iyi9kwMLgw3A4REIRFouwF8ME1+wdT jpF2nSqye1Y6G/5pZBrUjGsUNuOIfvoBK04s22K3y6vjwP8X2oM+OOte7H5/z3h9 xvvEJZx/BsCS9BmnOJd6OM2tK4eaA+2+NXdg45aMDNLuGZ5sq/XVoK36DgjF0PlM 0+Q81rZD7ulV6Gg72/Flty5bsv1ZrG+JpsUTv7dcOKmeyO7oJM0wFwkePqNkBNka DmSgV4tIjscHxzZMUzldbkEDCUQBIH91ePf0q/SiWPLcPGnX83K1O5sarfIy5c52 UIckccUgIq2nYbVkxMTHV2YwNj8/oFTadoDTB8Z3E3/sLHFindBjcQuDOv+/YlNt VISDa622whq6VQhs2CPU2K0+JLFjbpXd/16gTgBYTPCAPKXQA9vOFlPuVDF6Zmj7 aSzmTa0RwCOCsPXzOiVmZRNllJIri5tDvq1hqtvOPlH8acMQfgi3a49GVdAvx1ek V1XmcXcQZ6k= =2s5t -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#522776: Subject: Re: Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
Albert Cahalan dixit: >Any imperfection in a locale results in "C", as ASCII as can be. Yes, and "C" shall not imply latin1 but 7-bit ASCII but 8-bit transparent. //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in "Notes on Programming in C" -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
Albert Cahalan dixit: >Unless plain "C" goes UTF-8 Not going to happen, it’s not binary-safe. (I fought that in MirBSD with the OPTU-8/16 encoding scheme.) >The stupid broken en_US.UTF-8 fucks up the sort order. So true… (and paper size!) >We really need a do-nothing locale that follows the Unicode spec >using the UTF-8 encoding. Yes, my proposal exactly. >We could also use a do-nothing locale >that follows the Unicode spec using the Latin-1 encoding. No, for two reasons: ① legacy encodings must die ② then you need one for EVERY legacy encoding (why special-case one?) bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in "Notes on Programming in C" -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#522776: Subject: Re: Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
Albert Cahalan dixit: >Giacomo A. Catenazzi writes: >> I think nobody should use "C" or "C.UTF-8" as user encoding. I’d use it. >Debian doesn't ship a proper locale. I want sorting according >to the raw Unicode values. Also called ASCIIbetically ☺ But C exists, C.UTF-8 doesn’t. >>> * All ISO8859 locales are moved to a new locales-legacy-encodings >>> package. >> >> This encoding is used also on CD/, floppy, remote filesystems, >> USB pens, on a lot of internet pages, etc. > >Nope. > >It's actually UTF-16 in VFAT, Joliet, CIFS, and so on. And cp437 (or, worse, cp850) in FAT SFNs. >> So scripts should use LANG=C on most cases. > >That leaves iswprint() and towupper() broken. (not that it must) No, LANG is *also* wrong. Scripts relying on certain behaviour use LC_ALL=C (and, on GNU OSes, also must “unset LANGUAGE”), but some things just require UTF-8, so the current approach is to unset everything beginning with LC_*, setting LANG=C (or unsetting it) and LC_ALL=en_US.UTF-8 or en_GB.UTF-8 or whatever and hoping that that locale is installed… not acceptable! bye, //mirabilos -- 16:47⎜«mika:#grml» .oO(mira ist einfach gut) 23:22⎜«mikap:#grml» mirabilos: und dein bootloader ist geil :)23:29⎜«mikap:#grml» und ich finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann gleich mal auf usb-stick installieren -- Michael Prokop über MirOS bsd4grml -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
Giacomo A. Catenazzi dixit: >> Not going to happen, it’s not binary-safe. (I fought that in >> MirBSD with the OPTU-8/16 encoding scheme.) > > Why not? Note that usual functions work on bytes Not really. The difference between 'tr u x' on binary files can, depending on the implementation of tr (if it does 'tr ¥ €' correctly in an UTF-8 locale), trash it because it must use mbsrtowcs then, which is, by POSIX, required to fail for non-representable strings. In MirBSD, we have solved that by clever use of the PUA. //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in "Notes on Programming in C" -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
Russ Allbery dixit: >I agree with others in this thread that having a UTF-8 locale without the >collation changes implied by en_US is very useful for various software >packages such as automated test suites that want reproducible results and >were originally written for the C locale. Same for testsuites that are written for UTF-8 but don’t care about anything other than LC_CTYPE. And for people to whom en_US.UTF-8 is too fat or “politically incorrect” (though the latter is usually be fixed by en_GB.UTF-8 which has metric and ISO A4 paper) and others, like apparently Hurd. To me, strictly spoken, it doesn’t matter which one as long as there is one, for the mksh testsuite, but as user, being able to run a command with 'env LC_ALL=C.UTF-8 foo' on a “hostile” system (e.g. my cow-orkers insist on installing systems in German *shudder*) simply rocks. If nobody beats me, I’ll digest-and-write-a-proposal as suggested. bye, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1009031259050.1...@herc.mirbsd.org
Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
Samuel Thibault dixit: >LC_CTYPE has differences between locales, transliterations notably. For Oh, okay – good to know… >I'd say go on :) OK. >(of course we'll need to wait for libc to provide the locale >(post-squeeze I guess) before changing the policy). Sure. Maybe think of something to help backporters, make a source package able to detect if it already can use this locale or has to use the localedef way. bye, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1009031618560.1...@herc.mirbsd.org
Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
Samuel Thibault dixit: >believe that's something that shouldn't break Squeeze at all. I also believe it cannot possibly do that. bye, //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1009031621090.1...@herc.mirbsd.org
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
On Mon, 5 Jun 2023, Simon McVittie wrote: >No init system at all, (C.), can only happen when starting with a >minbase debootstrap or equivalent (because a default debootstrap >includes the init metapackage due to its Priority: required). In >this scenario it *usually* doesn't really matter whether we >install systemd or systemd-tmpfiles-standalone. systemd is somewhat This is not quite true; there is one really important use case: chroots. I have multiple chroots (sid, stretch, buster) on one of my bullseye systems which I use with schroot, but that could just as well be any other chroot, to run individual software in it. They are, as is proper, configured to not run any services (via policy-rc.d). >I also think that Policy shouldn't be recommending this interface without Therefore I belive that Policy ought to *not* recommend any solution that depends on starting dæmons or init scripts to create temporary files/directories that are necessary for programs to work. >- if we get a useful non-Linux port (admittedly this looks increasingly > unlikely) which cannot compile src:systemd, then their reimplementation hurd-amd64 is just shy of being uploaded; work on Debian GNU/Hurd is active and things seem to look good on that front. (The pools for hurd-amd64 have just been created a week or two ago.) bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ╳ HTML eMail! Also, https://www.tarent.de/newsletter ╱ ╲ header encryption!
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
On Tue, 13 Jun 2023, Bill Allombert wrote: >I agree, chroots are important to consider, and the system should not >make assumptions how and why there are used. Thanks! >Conversely, sometimes I need to use chroots to test init scripts. >start-stop-daemon should not refuse to run in a chroot if policy-rc.d >allows it. TTBOMK this works-ish. It certainly starts and stops things, but if you have the same thing running outside of the chroot, interference may happen. You’ll probably want a separate pid namespace (I think) at least, and make sure that, when leaving the chroot, everything started in it is in fact terminated; sometimes, things like to keep hanging around. This is easier to manage with VMs or (probably; I don’t like to use them myself) container-ish thingies. In my schroot setup I used to start a vncserver in a persistent chroot back when my main system was x32 and vncserver didn’t like that nor was coïnstallable (hence the i386 chroot). My “enter a Debian chroot” script, to use e.g. with a Grml live ISO to fix the bootloader (or to work under qemu-user with an RPi µSD image before moving it into the embedded machine), certainly tries hard to create a policy-rc.d to disable dæmon starting should the user need to install packages, so it generally will work. https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=shellsnippets/shellsnippets.git;a=blob;f=posix/sysadmin/debchroot.sh;hb=HEAD in case someone’s interested, it’s more complete than grml-chroot. bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ╳ HTML eMail! Also, https://www.tarent.de/newsletter ╱ ╲ header encryption!
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
On Tue, 13 Jun 2023, Russ Allbery wrote: >Thorsten Glaser writes: > >> Therefore I belive that Policy ought to *not* recommend any solution >> that depends on starting dæmons or init scripts to create temporary >> files/directories that are necessary for programs to work. > >This is handled by this proposal, no? That's the point of requiring >integration with maintainer scripts (via triggers or direct invocation). >My understanding is that this is exactly what dh_installtmpfiles already >does, via generating an explicit call to systemd-tmpfiles --create. Hmm, that sounds okay-ish, except… >Or am I missing something? what you described of course does not work for /tmp and /run. It is viable for /var/tmp etc. bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ╳ HTML eMail! Also, https://www.tarent.de/newsletter ╱ ╲ header encryption!
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
On Tue, 13 Jun 2023, Russ Allbery wrote: >namely if you're running anything >in a chroot that needs directories created in /tmp and /run, the chroot >either needs to have a persistent /tmp and /run or you have to arrange for >it to run at least some init scripts during boot. I very much disagree here. Both /tmp and /run are volatile, and for /tmp there usually even are cronjobs that delete old files, so programs that need anything in there must create it themselves at startup (via wrapper scripts if needed) if absent. bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ╳ HTML eMail! Also, https://www.tarent.de/newsletter ╱ ╲ header encryption!
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
On Tue, 13 Jun 2023, Russ Allbery wrote:
>Ah, I think I understand what you're getting at. You're talking about
>using the init script of a daemon as this sort of wrapper script for
Not really. I was talking about normal programs, not dæmons.
I have the expectation that these, when invoked, create their
necessary temporary files/directories when they are placed on
volatile storage, i.e. /tmp and /run and possibly /var/tmp.
>nothing we're talking about here changes that behavior, because nothing
>needs to be pre-created.
Ah, good then.
For dæmons, running them in chroots is usually more tricky
anyway. Ideally, just /etc/init.d/foo {stop|start} would
work, but there’s situations where that doesn’t suffice.
If maintainers can get the former working, fine.
bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:
╳ HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!
Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA384 Helmut Grohne dixit: >I would like to take the opportunity make you aware of a Debian policy >change #1074014 about merged-/usr. I mentioned your approach in mksh and >pax and the consensus among discussion participants was that policy >should not allow for such interpretation. We have six seconds on the >following diff now: > >- To support merged-/usr systems, packages must not install files in both >- /path and /usr/path. For example, a package must not install both >- /bin/example and /usr/bin/example. >+ Since base-files implements mandatory merged-/usr by installing the >+ aliasing symbolic links, other packages must not install files into >+ aliased paths such as /bin, /lib, /lib* or /sbin. The package manager is >+ not prepared to deal with such aliasing and in prohibiting the >+ installation into aliased locations, we avoid triggering undefined >+ behaviour. Conversely, packages may assume that /bin, /lib and /sbin are >+ symlinks at all times and that their files below /usr/bin, /usr/lib and >+ /usr/sbin are also accessible via their aliased locations. This is dangerous, and I’d like to officially veto this policy change. You got your merged /usr already, and to force packages to move their files WILL break users’ systems. In particular, mksh as /bin/sh is a supported configuration. bye, //mirabilos -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (MirBSD) Comment: ☃ ЦΤℱ—８ ☕☂☄ iQIcBAEBCQAGBQJmspuTAAoJEHa1NLLpkAfg4cUP/1yEiYQSl+TQBe0WdF4JR0CQ YLx2v/vAO4WWmUOgvZ4eFhsxQOucaTnWSBA+wq+NsUi7xVP7soOCEVG1CqgEo92W rIBpqxYUegFGTZUdbSf/Eut5fPCug8JoEuTGUVSVFnij6AoQ8GZtkJldGbOfe3oO 4J7ArKTJ3+8k7VvYYgohxebp7RPpC+KRKk0oNe2iec3csW71eQriiDINV2kRC9ZK S9cV16Uda8pw6P/u0ioyjYnRiKYBXCJg+HPFuioI4zefsRVfqoLFN0O7WmE99zKJ sb8JBnvVoA3eUcSPBBfqHIFbhdUO6F8KxXtUyqxZNgKigbHCAzAyUu9qH95pwltZ 7vMVeCM15kfhdWRT5vRYgSYHwryawi2gc22W1gpuAba68FgNnz1O0qaNTY/Lcfdi zKRDAUDFRWUmpDuPEHFyNZgiRpv6kAEad378FRUv4ESOqEbGKLeJmLIRjdsgPrBl 7L3Yp/eKOC/5O2XPQcBI48cMc9zrREFgDKZXOcer2nUX+xR39/8qRNV5u0DPUUk5 /xseGZhYVah1q8Y2j6sUP1lEm3w62tGq1+fBEFdLKVo6WZtHnpO5ZWIIXMPHs9Sb j9//r8gdeb7W10qwxZKoTnMPSeQyt8Rn7fzwpPRnA54hXMtjzBcB9dulxrQLyg6l IAOF5fwerKsRufeCPy8h =PRWD -END PGP SIGNATURE-
Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:
Russ Allbery dixit: >Thorsten Glaser writes: > >> You got your merged /usr already, and to force packages to move their >> files WILL break users’ systems. In particular, mksh as /bin/sh is a >> supported configuration. > >Could you explain how this would break a user's system? From your second >sentence I'm guessing that you're anticipating some problem related to >diversions, but I can't put the pieces together without some more details. If I have a link from /bin/sh to a binary from the mksh package, then on normal upgrades dpkg updates it atomically. Diverting the binary in /bin/ away will leave the symlink from /bin/sh (which is managed by the local admin because the dash package ignored two(!) rc bugs regarding its changed /bin/sh management behaviour, when they broke it, for more than two releases so the bug got eventually closed so mksh couldn’t offer package-controlled /bin/sh management that was coordinated with bash post-lenny) dangling. Despite all this, running with mksh (the /bin/lksh binary) as /bin/sh is a supported configuration (Policy 10.4), and I’ve read of many users who are doing this. This means that, hypothetically, should someone upload mksh with the suggested move, which would divert the /bin/ files away in preinst, users would need to be told to manually change their /bin/sh back to bash for a bit, upgrade then, and then switch it back, or have their system break on upgrade. This is fragile, and the “benefits” are nowhere even near worth it: /usr-merge per top-level symlinks per CTTE was forced on all systems, so we got that now, and it is absolutely unnecessary for packages that are not part of the pseudo-Essential set to move their files because their implicit Pre-Depends on the Essential set will ensure that the /bin symlink is already in place so this is a total nōn-issue. bye, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
Bug#1074014: Bug#1073608: Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:
Helmut Grohne dixit: >that the way people tend to use mksh is by adding a local diversion for Unfortunately not. The way we have to do it since squeeze, when dash unilaterally broke cross-package coordination, is: dpkg-reconfigure dash ⇒ remove its owning of /bin/sh (so it reverts to bash) ln -sf lksh /bin/sh This cleanly persists across upgrades, bash was never problematic wrt this. >I don't think the CTTE has actually issued a ruling on DEP17 or >/usr-move short of repealing the moratorium in order to enable moving >forward. That, and that UsrMove via symlinks /bin etc. is to be instated. There is absolutely no reason to force files to move, given they are now aliased already *anyway*. bye, //mirabilos -- Yes, I hate users and I want them to suffer. -- Marco d'Itri on gmane.linux.debian.devel.general
Bug#1074014: Bug#1073608: Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:
(Another data point is that there’s versions of mksh with version numbers larger than what’s in sid around in my own repo, for those wanting to follow CVS snapshots more closely, backported to all versions up to sarge, so bookworm users can very well have mksh packages with a version number that is greater than what will be in trixie so anything that relies on version numbers for transitioning will also not work.)
Bug#1074014: Bug#1073608: Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:
Helmut Grohne dixit: >> Maybe the protective diversions also protect against this problem as well >> as the problem of moved files? I unfortunately failed to spot where the >> protective diversions were added in dh_movetouser (if that even is the >> right place to be looking), so I'm fairly sure I'm missing something. > >dh_movetousr has nothing to do with protective diversions. It does not >add nor remove diversions nor does it change any. All it changes is >locations of files in the data.tar of a .deb. All of the protective >diversions that we ever installed for DEP17 are managed in maintainer >scripts and dh_movetousr does not touch maintainer scripts at all. Huh? So the lots of diversions to /sbin/something.moved-to-usr I’ve been seeing come from maintainer scripts? But at what point does dpkg remove /bin/mksh vs. rename /usr/bin/mksh.dpkg-new to /usr/bin/mksh? I thought the diversions were needed so the latter doesn’t then get renamed? Agh, this is all so complex and fragile. Are you really surprised that maintainers are very much against this? >In the first bug, Andrew stated that selecting the shell via debconf >wasn't supported. Still salty about this, as it worked in lenny and before, and the Canonical agents who made dash the default shell unilaterally broke this, refused cross-shell communication, ignored suggested patches and sat out the rc bugs for 2 releases until we just gave up. bye, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)
Re: Bug#1095791: dpkg: incompatible and Policy-violating R³ default change breaks packages’ builds
On Fri, 14 Feb 2025, Sean Whitton wrote: >Policy has to go through binary-NEW in order to be released. So there Technicalities. >isn't a quick fix here. Not looking for one. dpkg should revert this until then. >This bug does not count as RC just because Debian upload bureaucracy >hasn't been performed yet. If packagers cannot rely on Policy to give correct information, what *can* they rely on? >There is a clear agreement that the default value has changed. I’m still in a place where I question this, and diziet apparently also is. This is going to cause untold amounts of headaches in both downstream distro and third-party packages (including organisation- internel ones). dpkg introduced this build api thing. Use that. Or, if you absolutely must cause more useless churn on package maintainers, at least forbid not setting R³. But don’t silently change the default to an incompatible value. bye, //mirabilos -- Yes, I hate users and I want them to suffer. -- Marco d'Itri on gmane.linux.debian.devel.general
Re: Bug#1095791: dpkg: incompatible and Policy-violating R³ default change breaks packages’ builds
severity 1095791 serious thanks On Thu, 13 Feb 2025, Guillem Jover wrote: >> >From what I can tell from other mails, I believe the package in >> question is openjdk-8 (unstable only); see bug #1095746. > >Ah, thanks for the context. In that case, going by that bug report, it >looks like openjdk-8 was most probably already buggy, and this seems >like another instance of what was reported in: Yes, it’s one of doko’s originally, and it’s mostly on life support due to many active users. I was unaware of the change due to not having been included in the MBF I only learnt about after reporting the bug on the Fediverse; who knows what other packages are excluded? This also cost me *quite* some debugging, which could have been avoided. It’s still an RC bug in dpkg because Policy specifically says that the default value isn’t “no”, though. Furthermore, this WILL break numerous third-party and downstream distro packages. I consider this a bad change, not only deliberately backwards‐ incompatible, but also SILENTLY changing. If you wanted to have gotten rid of packages not declaring R³ and force package maintainers into even more (usual culprit is lintian) useless churn, go make that an error, but do NOT *ever* change the default value in a backwards-incompatible way leading to silent failures. Plus, you have invented this whole dpkg-build-api thing. Go make that change THERE instead. So, due to the Policy violation, raising severity again. If you want to not have this treated as RC bug, ensure a changed Policy is released first. But I ask you to move the default change to the dpkg-build-api thingy instead. bye, //mirabilos -- Yes, I hate users and I want them to suffer. -- Marco d'Itri on gmane.linux.debian.devel.general
Re: Bug#1095791: dpkg: incompatible and Policy-violating R³ default change breaks packages’ builds
On Fri, 14 Feb 2025, Guillem Jover wrote: >> >This bug does not count as RC just because Debian upload bureaucracy >> >hasn't been performed yet. >> >> If packagers cannot rely on Policy to give correct information, what >> *can* they rely on? > >This is not how Debian Policy has ever worked. By that measure >packages could not rely on multiarch or triggers to name a coupled >of examples. And Policy changes in general tend to be done after the >changes have been implemented and deployed in the archive. That’s for things which Policy didn’t describe yet because they were new. But if Policy states a definite value, I *expect* the tooling to adhere to that value. >> Or, if you absolutely must cause more useless churn on package >> maintainers, at least forbid not setting R³. But don’t silently >> change the default to an incompatible value. > >The problem that triggered this report was only surfaced by the R³ >change, but it is not really directly affected by it. The real problem >is that the R³ change made it possible to skip calling the >«debian/rules build» targets, where the affected package was already Yes, I know. I’m sorry for having a life in which I needed a quick workaround for this dpkg RC bug in the package first, since that affects actual users, and that it takes time fully analysing what the packaging I only inherited in the first place does wrong, where, and how to best fix it, plus openjdk-8 takes a full day to build on my hardware. (Less with nocheck, sure.) >Policy buggy, but the breakage was not visible. If the R³ default >would get reverted, but the change to call >«fakeroot debian/rules binary-arch» kept, the openjdk-8 package would >still misbuild. I know. Doesn’t change the fact that dpkg’s change breaks packages. Would you *please* at least read and consider the alternative solutions I pointed out above? Thanks. bye, //mirabilos -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too… may I quote you on that? sure, tho i doubt anyone will listen ;)
