Bug#992414: debian-policy: upgrading-checklist is not upgraded
Package: debian-policy Version: 4.6.0.0 Severity: normal The upgrading-checklist at /usr/share/doc/debian-policy/upgrading-checklist.txt.gz was not upgraded correctly for 4.6.0.0. It references Version 4.5.2 instead.
Bug#940144: developers-reference: document self-service givebacks in wanna-build section
Has the self-service wannabuild giveback script been disabled? It's now rejecting connections, e.g. https://buildd.debian.org/auth/giveback.cgi?pkg=ga&suite=sid&arch=armel generates Forbidden You don't have permission to access this resource.Reason: Cannot perform Post-Handshake Authentication. Apache Server at buildd.debian.org Port 443 My SSO is otherwise working fine, e.g. triggering debci tests at https://ci.debian.net/user
Bug#365510: 11.8.7: X11R7 puts headers in /usr/include/X11
On Sun, 2006-04-30 at 15:12 -0700, Steve Langasek wrote: > Yes, policy definitely needs to be amended to reflect these changes in > X11R7. I don't have time to propose a formal policy amendment right now; > Drew, perhaps you would be willing to synthesize the above information into > one? Yeah, if no one else gets to it sooner, I can drum up a draft patch. Feel free to beat me to it, anyone :) Drew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#365510: 11.8.7: X11R7 puts headers in /usr/include/X11
Package: debian-policy Version: 3.7.0.0 Severity: normal Latest policy still says in 11.8.7 "Packages must not provide or install files into the directories /usr/bin/X11/, /usr/include/X11/ or /usr/lib/X11/." But the new X11R7 dev packages now generally put their headers into /usr/include/X11/. So the sentence in 11.8.7 must be changed to either remove the mention of /usr/include/X11/ or to specify that only X11R7 headers may be placed there. Thanks, Drew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.16 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#122817: example of profile.d's usefulness
The Xprint printing system provides an example of how an /etc/profile.d type of mechanism could be useful. The Xprint specs (see http://www.x.org/X11_Xprint.htm#environment) indicate that client programs such as mozilla should use Xprint when environment variable XPSERVERLIST is set (this variable identifies the available Xprint servers). If the variable is not set, then mozilla only provides it's default, buggy, Postscript driver. The Xprint server itself does not require or use XPSERVERLIST, only client programs do, if they are to use Xprint rather than the standard printing drivers. If /etc/profile.d existed, then it would be simple for the Xprint packages (xprt-common) to provide a scriplet to define the variable, make Xprint available to all programs that can make use of it. Since the XPSERVERLIST mechanism for identifying Xprint servers is part of the Xprint design, it doesn't seem possible to "fix" the client programs such as mozilla to be able to use Xprint when the variable is not defined. Such a "fix" would necessarily be Debian-specific, or would require the Xprint specifications themselves to be changed (to have client programs check /var/run/Xprint_servers, perhaps?). Allowing xprt-common to add a file to /etc/profile.d would solve the problem simply, without having to ignore the Xprint spec or continually monitoring any future clients of Xprint to add Debian's "fix" to let them use Xprint without XPSERVERLIST. Admittedly, this particular example is not necessarily the most effective for justifying /etc/profile.d, since /etc/profile only applies to shells (logging on at the console), and is not invoked when logging on via xdm (or [gk]dm). Hence in the case of Xprint I need to use /etc/X11/Xsession.d instead to achieve the desired result for all X clients. Just a little more food for though :) Drew Parsons -- PGP public key available at http://people.debian.org/~dparsons/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A pgpbAMQu60v5p.pgp Description: PGP signature
Re: the math section should really be science
On Tue, Mar 13, 2001 at 08:32:23PM +0100, Josip Rodin wrote: > On Tue, Mar 13, 2001 at 10:54:45PM +1100, Drew Parsons wrote: > > Seems to me there's still a gaping hole in policy though. Is > > packages.debian.org really supposed to be the definitive arbiter of policy > > with regards to sections? The grep-available trick is obscure enough to not > > count. Shouldn't these sections rather be in Policy proper? > > Well, none of these are the canonical source, they just read data from it -- > the override file, see the /indices/override.* files on every mirror. > Too arbitrary, too inaccessible, too unaccountable. How is any developer supposed to know to put a package in the science section, for instance? Is he expected to scan through every single override file looking at every single package listed therein until he just happens to discover one indicating that a science section does in fact exist? Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: the math section should really be science
On Sun, Mar 11, 2001 at 07:03:51PM +0100, Josip Rodin wrote: > > > > I'm packaging viewmol, a program for visualising molecules, used in > > > computational chemistry. > > > > > > The question arises, what subsection should it be put into? > > > A comparable program, rasmol, is already in debian, in the math subsection. > > > But computational chemistry is not, strictly speaking, mathematics (it > > > can be considered a sub-branch of mathematics, but you don't usually talk > > > about the weight or electron affinity of a number). > > > > So, put it in "science" section. > > > > % grep-available -F Section -s Package science > > Package: hodie > > % > > > > This has been discussed already, and the new section was created/allowed. > > It's not very useful if http://packages.debian.org/unstable/science > does not exist. I'll start moving packages of mine when I see > > the section actually listed anywhere. >That was a bug on the web pages, I fixed it now. Thanks for fixing it. Seems to me there's still a gaping hole in policy though. Is packages.debian.org really supposed to be the definitive arbiter of policy with regards to sections? The grep-available trick is obscure enough to not count. Shouldn't these sections rather be in Policy proper? Besides, there are other related issues: menu has its own section policy, and it's not in sync with the package sections (again, there is a math section but no science section). Shouldn't all these things be listed together in official Policy? menu sections do not "have" to be the same as package sections, but does it make sense for them to be different? On a side note, I noticed gnumeric was also in section "math". Given the general intentions we have of making Linux useful on the desktop and therefore to businesses, is it a good idea to create a "business" section for containing gnumeric, gnucash, cbb, xacc etc. ? Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
the math section should really be science
I'm packaging viewmol, a program for visualising molecules, used in computational chemistry. The question arises, what subsection should it be put into? A comparable program, rasmol, is already in debian, in the math subsection. But computational chemistry is not, strictly speaking, mathematics (it can be considered a sub-branch of mathematics, but you don't usually talk about the weight or electron affinity of a number). Looking through the math section, there are other packages which aren't strictly maths: some biomaths programs (genesis, busx, hmmr), some plotting programs (sciplot, grace, geg), some astronomical tools (seesat5, ssystem). I therefore wonder if it would not be more appropriate to call this subsection "science" rather than "math" ? Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
