Bug#910548: base-files - please consider adding /usr/share/common-licenses/Unicode-Data
Josh, I understand your intention, but it's not that straightforward. The data that I saw in Debian packages I looked through used various pieces of property data from various files from the Unicode Consortium within pre-built arrays also containing other data, though I didn't look through all packages that used Unicode data by any means. In my case, I used Unicode code point descriptions in the comment fields of lex patterns (flex on Debian) in my beta2uni program (part of my unibetacode package), which converts Beta Code to Unicode. Here are a few such lines of code: \*\/[Aa] print_pattern (yytext, 0x0386); /* GREEK CAPITAL LETTER ALPHA WITH TONOS*/ \*\/[Ee] print_pattern (yytext, 0x0388); /* GREEK CAPITAL LETTER EPSILON WITH TONOS */ \*\/[Hh] print_pattern (yytext, 0x0389); /* GREEK CAPITAL LETTER ETA WITH TONOS */ \*\/[Ii] print_pattern (yytext, 0x038A); /* GREEK CAPITAL LETTER IOTA WITH TONOS */ \*\/[Oo] print_pattern (yytext, 0x038C); /* GREEK CAPITAL LETTER OMICRON WITH TONOS */ \*\/[Uu] print_pattern (yytext, 0x038E); /* GREEK CAPITAL LETTER UPSILON WITH TONOS */ \*\/[Ww] print_pattern (yytext, 0x038F); /* GREEK CAPITAL LETTER OMEGA WITH TONOS*/ etc. I used the utf8gen program (another package that I wrote and then debianized) to create those lines of code, typing in the regular expressions myself by hand after utf8gen did the monotonous work of printing everything to the right of those patterns on each line for me from data that I had pre-extracted from a Unicode data file. I had to have the Unicode names in front of me to type the correct regular expression for each code point. The way I did that also will help me or anyone else debug the program in the future. Were I to attempt to pull such comment strings from another package on the fly, I would have to write a program that knew which lines in my source code needed those comment strings, fetch them from said external package, and create a new source code file for lex/flex before building the final program. Apart from the most obvious immediate inconveniences of doing that, two others come to mind: 1) I could not then produce the source file in final form without running on a distro such as Debian that implemented a packaging scheme, or providing complicated build instructions for an end user (most likely a student of ancient Greek who would not have deep knowledge of building software packages). As implemented, my unibetacode package builds and installs on many distros just the way it is, including on non-GNU/Linux systems thanks to the modern miracle of GNU Autotools. 2) I would have to perform such a partial build just to read the comments that I intended for debugging (and I would have had to resort to an external table while typing in the generating regular expressions rather than having them conveniently on the same line of code). There would also be the impracticality of telling such groups as the Linux kernel developers and other upstream teams that they must switch to using the Unicode package that Debian provides for their future builds. OTOH, packaging the Unicode data files could be useful for other, unrelated purposes. Of course, such a package would be one more instance of the need for the Unicode Consortium's license and (lengthy) copyright information in yet one more package's debian/copyright file. :-) Yet that still doesn't answer the question of whether or not Debian would find such a common file of Unicode license & copyright terms useful...but the text is there if Debian makes that decision. If not, at least I took the time to make it available. Thanks, Paul Hardy
Bug#911165: debian-policy: drop requirement to ship sysvinit init script with same name
On Wed, Oct 17, 2018 at 10:07:44AM +0200, Ansgar Burchardt wrote:
> Russ Allbery writes:
> > Until such time as we make a project-wide
> > decision to drop support for sysvinit, providing an init script for
> > straightforward daemons is part of packaging a daemon. If people are
> > unwilling to do this work, I don't believe we should accept the package in
> > Debian. In other words, I personally believe not providing an init script
> > should be an RC bug (as Policy currently indicates) given the current
> > project stance on init systems, except for the standard exception case of
> > packages that are specifically designed to only be meaningful with systemd
> > for which making them work with any other init system would require
> > significant porting (not just writing a simple equivalent init
> > script).
> That exception does not exist in Policy; there is only an exception for
> packages provided by the init implementation itself. Policy currently
> requires the "Loose coupling of init systems" option of
> https://www.debian.org/vote/2014/vote_003 as far as I can tell as
> services must be able to run under sysvinit.
> We already have several packages only shipping systemd units, including
> with socket activation (I did not check if any services cannot be
> configured to not listen on their own, but I wouldn't be surprised).
> Those with socket activation include: chasquid, cockpit-ws, erlang-base,
> hddemux, ibacm, rkt, snapd, sssd-kcm, tang, tinysshd.
I actually don't agree with this policy proposal - I think that if we are
going to support non-systemd init at all in Debian, it needs to be more than
lip service, and that means policy needs to spell out that maintainers have
a responsibility to help hold the line - but there's one package in your
list above that I have specific knowledge of. The snapd package uses socket
activation, yes, but this is an optimization and the package could equally
be started using /lib/systemd/system/snapd.service.
However, the package does not ship an init script. There would be no point.
The snapd service as implemented upstream generates and manages systemd
units, including both .service and .mount units. Making snapd work with
non-systemd init would be a non-negligible upstream porting effort.
Snapd is also not straightforwardly portable to non-Linux kernels, which
IMHO is the principle reason that Debian should continue to care about
non-systemd init at all.
Should Debian refuse to allow a package into a stable release ("RC-buggy")
whose upstream has made technology decisions that tie it to a particular
sysvinit-incompatible init system?
Again, I think the current policy language is broadly correct and don't
think it should be dropped outright. I think now that we have more
experience with systemd as default, and more examples we can point to in the
archive, it is time to think about how we should add more nuance to the
policy.
> I wouldn't be surprised to see more services require systemd's socket
> activation in the future.
> (Also, see DBus-activated services, inetd-style socket activation,
> .timer units with their associated .service; there is no need for a
> sysvinit script in these cases, but Policy requires it.)
In my mind, the intent of the current policy language is to require an init
script matching any .service units, not for .socket or .timer units.
Perhaps the text should be refined to be systemd-specific instead of
continuing to treat "alternate init systems" generically, and then call this
out?
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
Processed: Re: Bug#905930: www.debian.org: Duplication of text in webpage https://www.debian.org/doc/manuals/developers-reference/ch04.en.html 4.6.5 "Debian 10, will be called buster and Debian 10 wil
Processing control commands: > tags -1 + pending Bug #905930 [developers-reference] www.debian.org: Duplication of text in webpage https://www.debian.org/doc/manuals/developers-reference/ch04.en.html 4.6.5 "Debian 10, will be called buster and Debian 10 will be called buster." Added tag(s) pending. -- 905930: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905930 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#905930: www.debian.org: Duplication of text in webpage https://www.debian.org/doc/manuals/developers-reference/ch04.en.html 4.6.5 "Debian 10, will be called buster and Debian 10 will be called bus
Control: reassign -1 developers-reference Lucy Wayland wrote: > Package: www.debian.org > Severity: minor "text in webpage https://www.debian.org/doc/manuals/developers-reference/ch04.en.html 4.6.5 "Debian 10, will be called buster and Debian 10 will be called buster." " Re-assigning to the correct package Holger -- Created with Sylpheed 3.5.1 under D E B I A N L I N U X 9 " S T R E T C H " . Registered Linux User #311290 - https://linuxcounter.net/
Bug#905930: www.debian.org: Duplication of text in webpage https://www.debian.org/doc/manuals/developers-reference/ch04.en.html 4.6.5 "Debian 10, will be called buster and Debian 10 will be called bus
Control: tags -1 + pending Holger Wansing wrote: > Control: reassign -1 developers-reference > > Lucy Wayland wrote: > > Package: www.debian.org > > Severity: minor > > "text in webpage > https://www.debian.org/doc/manuals/developers-reference/ch04.en.html > 4.6.5 "Debian 10, will be called buster and Debian 10 will be called buster." > " > > > Re-assigning to the correct package I have fixed this in GIT. Tagging this bug as pending -- Created with Sylpheed 3.5.1 under D E B I A N L I N U X 9 " S T R E T C H " . Registered Linux User #311290 - https://linuxcounter.net/
Processed: Re: Bug#905930: www.debian.org: Duplication of text in webpage https://www.debian.org/doc/manuals/developers-reference/ch04.en.html 4.6.5 "Debian 10, will be called buster and Debian 10 wil
Processing control commands: > reassign -1 developers-reference Bug #905930 [developers-reference] www.debian.org: Duplication of text in webpage https://www.debian.org/doc/manuals/developers-reference/ch04.en.html 4.6.5 "Debian 10, will be called buster and Debian 10 will be called buster." Ignoring request to reassign bug #905930 to the same package -- 905930: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905930 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#910548: base-files - please consider adding /usr/share/common-licenses/Unicode-Data
On Sun, 7 Oct 2018 16:25:39 -0700 Paul Hardy wrote: > Package: base-files > Severity: wishlist > Tags: patch > > Hello, > > I recently formatted the Unicode Data license for the d/copyright file > of a Debian package that I created. I thought I would offer it to > Debian if you are interested. You probably do not want the Copyright > stanza, and you might not want the Comment stanza, but I erred on the > side of too much rather than too little. > > Unicode data files are used in a number of free software packages, > such as linux-libc-dev and the Linux kernel itself. Use of Unicode > data in software is likely to continue growing over time. Thus you > might find this useful. Duplication of such data among multiple packages does not seem like a feature, and certainly not enough duplication to justify a common-licenses entry. I would hope that most such uses could pull in these data files from a common package.
Re: base-files - please consider adding /usr/share/common-licenses/Unicode-Data
reassign 910548 debian-policy thanks On Sun, 7 Oct 2018, Paul Hardy wrote: > Package: base-files > Severity: wishlist > Tags: patch > > Hello, > > I recently formatted the Unicode Data license for the d/copyright file > of a Debian package that I created. I thought I would offer it to > Debian if you are interested. [...] Hello. According to /usr/share/doc/base-files/README, the decision to include a license or not is delegated to the Debian Policy Group, so I'm reassigning this bug. Thanks.
Processed: Re: base-files - please consider adding /usr/share/common-licenses/Unicode-Data
Processing commands for cont...@bugs.debian.org: > reassign 910548 debian-policy Bug #910548 [base-files] base-files - please consider adding /usr/share/common-licenses/Unicode-Data Bug reassigned from package 'base-files' to 'debian-policy'. Ignoring request to alter found versions of bug #910548 to the same values previously set Ignoring request to alter fixed versions of bug #910548 to the same values previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 910548: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910548 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#911165: debian-policy: drop requirement to ship sysvinit init script with same name
Russ Allbery writes: > Ansgar Burchardt writes: >> So shipping a daemon without init scripts is better than shipping one >> with only a systemd unit? > > I don't believe such a daemon package (with no init script) should be > included in Debian at *all*, as a matter of not meeting the quality > bar. Policy says the opposite though... >> Shipping a sysvinit script is only a "should" in Policy, unless you ship >> something for any other init system. > > I think that's just that it's very difficult to write a Policy rule > explaining when something should have an init script and when something > should not. Yes, that's why I suggest the one rule that tries to state that sometimes a init script *must* exist is a bad rule. Even without the "must" in 9.11, there is still the recommendation that init scripts "should" be provided (9.3.2). According to policy that is enough for a bug. Unless one assumes bad faith that seems to be good enough to me. Otherwise one gets to enumerate exceptions or has to forbid packaging applications that only work under systemd. As far as I know snapd delegates some work to systemd and wouldn't work under sysvinit even if you start it from an init script... We could of course also say that this decides the "snap" vs "flatpak" decision ;-) >> We already have several packages only shipping systemd units, including >> with socket activation (I did not check if any services cannot be >> configured to not listen on their own, but I wouldn't be surprised). >> Those with socket activation include: chasquid, cockpit-ws, erlang-base, >> hddemux, ibacm, rkt, snapd, sssd-kcm, tang, tinysshd. > > I'm not surprised, but (and I have not investigated in detail) I suspect > at least some of these are bugs. I think they should be RC bugs in cases > where there's no significant porting required, just no init script, but > I'm not on the release team and don't get to make that call. I do think > they violate a Policy must. If one of them requires socket activation, would it be a RC bug in the package or a RC bug in alternative init systems such as sysvinit to provide no means to start such services? If one of them requires other systemd features and doesn't work under sysvinit anyway, why should an init script be required? I also note that Policy currently has no "where there's no significant porting required" exception and as I said earlier I don't believe in enumerating exceptions if one can just use "should". >> (Also, see DBus-activated services, inetd-style socket activation, >> .timer units with their associated .service; there is no need for a >> sysvinit script in these cases, but Policy requires it.) > > I think you're reading Policy far too literally here; the intent is only > to cover unit files that are equivalent to init scripts, and none of those > things are. I certainly support fixing that to make it clearer. I think the "should" from the earlier section on init scripts is enough. Then one doesn't need to write more complex rules here. Ansgar
