Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
Guillem Jover [EMAIL PROTECTED] writes: On Fri, 2006-06-16 at 23:10:36 +0200, Goswin Brederlow wrote: Package: debian-policy Severity: normal [Side note: Buildds/dpkg-buildpackage has no robust way of telling if the optional build-arch field exists and must call build. This is wastefull for both build dependencies and build time.] I've a counter-proposal. ;) Make dpkg source v2.0 (Wig And Pen) format require build-arch and build-indep. And when will that ever happen? - Build-Depends/Conflicts-Indep becomes usefull, build-indep becomes usefull Ditto. It won't have a usefull meaning for building just architecture all packages since that requires both Build-Depends/Conflicts and Build-Depends/Conflicts-Indep. There currently is no dpkg-buildpackage option for this but there are plans for it. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Including more licenses in 12.5
On 18 Jun 2006, Joerg Jaspert told this:
How about including more licenses in the list in 12.5 (and at the
same time adding them to base-files).
How many packages are there under this license? Seems to me
that in order for a license to be termed ``common'', it should indeed
be common -- and some sizeable fraction of Debian packages be
available under the terms of that license (the sizeable fraction to
be decided upon, of course, but shouldn't it at least 5-10%?)
Good candidates, IMO, are: The python license, the ZPL, the ruby
license.
Looking at my own machine, I can't assert that the license yet
meets that criteria.
Also, note the footnote in policy:
--
Why common-licenses and not licenses? Because if I
put just licenses I'm sure I will receive a bug report
saying license foo is not included in the licenses
directory. They are not all the licenses, just a few
common ones. I could use /usr/share/doc/common-licenses
but I think this is too long, and, after all, the GPL
does not document anything, it is merely a license.
--
What does common mean anyway?
--
2. Belonging to or shared by, affecting or serving, all the
members of a class, considered together; general; public;
as, properties common to all plants; the common schools;
the Book of Common Prayer.
common
adj 1: belonging to or participated in by a community as a whole;
public; for the common good; common lands are set
aside for use by all members of a community [ant: {individual}]
--
There is a tradeoff involved in not having the copyright file
included in a package; and the savings are not having multiple copies
of the same file over and over again. The informal rule of thumb
applied to such licenses is whether we have significant savings -- to
offset the fact the .deb does not carry the license in itself
(removing the copyright files raises the issue that the .deb is no
longer distributable by itself).
The reason that all possible licenses are not in the common
license directory is that not including the license directly in
/usr/share/doc/package requires anyone looking for a license to
take an extra step to find it; and only a substantial saving in disk
space justifies that extra step.
So, if there are at least 5% of the source packages (or
whatever number emrges from the debate that is sure to follow), we
can include the license into common license. A nice, objective
criteria for admission ;-)
manoj
Here are some quick and dirty results, for just one system
with a fraction of the total packages installed, good for ball park
estimates (some packages are dual licensed, for example). 5% of the
packages on my system turn out to be 181 packages, after
rounding. This seems like bad news for the BSD and the LGPL :)
__ grep-status -s Source '.' | sort -u | wc -l
1149
__ find /usr/share/doc -type f -name copyright | wc -l
3615
__ find /usr/share/doc -type f -name copyright | \
xargs egrep -l 'GNU.+General' |
2154
__ find /usr/share/doc -type f -name copyright | \
xargs egrep -l Artistic | wc -l
504
__ find /usr/share/doc -type f -name copyright | \
xargs egrep -l 'GNU.+Lesser' | wc -l
252
__ find /usr/share/doc -type f -name copyright | \
xargs egrep -l 'GNU.+Library' | wc -l
174
__ find /usr/share/doc -type f -name copyright | \
xargs egrep -l 'Berkeley' | wc -l
82
__ find /usr/share/doc -type f -name copyright | \
xargs egrep -l 'Python.+Software' | wc -l
19
__ find /usr/share/doc -type f -name copyright | \
xargs egrep -l 'Zope' | wc -l
15
--
I take Him shopping with me. I say, 'OK, Jesus, help me find a
bargain' --Tammy Faye Bakker
Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
On 18 Jun 2006, Goswin von Brederlow outgrape: Peter Eisentraut [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: On the other hand the savings can be huge. Think about how many packages install latex and fonts and generate the documentation needlessly during build. Installing and purging latex as well as all the initex runs and font generation takes up a awfull lot of time I think most packages build their documentation or other architecture-independent parts as part of a general make/make install process, so it's not possible to create useful separate build-arch and build-indep targets. A lot of software has a doc dir and it is relatively simple to seperate recursing into doc from the rest. Unless the build-* targets become actually usefull nobody will put any work into splitting the build process into arch and indep parts though. Umm. Most of my packages I can simply call make or ake build and let upstream Makefiles build stuff -- which means that if the arch indep part is split of changed (./scripts dir, for example), I do not have to change my rules file to follow suit. In this case, splitting the buiild process into arch and indep parts is not trivial. Looking at the archive right now, there are only 129 source packages (in testing) that are not Architecture: all and declare Build-Depends-Indep (and quite a few of those are obviously wrong). So it seems to be a limited problem. However, if your concern is mostly to reduce installation time of documentation tools, then the current Build-Depends/Build-Depends-Indep setup seems to work quite well. I don't see where Build-Depends-Arch would fit in there. The problem currently is that it isn't even possible to seperate them even if the makefile suports it because the build target must be called. The proposal is as much a clarification and extension of the Build-Depends* fields as a mechanism to detect and use build-* targets. Only then can one split arch and indep building and have a meaningfull Build-Depends-Indep. I think the way to do this is to make the build target depend on build-arch and build-indep, so calling build builds everything, but allows for a future improvement in efficiency. Assuming, of course, that upstream build process also allows for this split up. manoj -- Eat drink and be merry, for tomorrow we diet. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Including more licenses in 12.5
* Manoj Srivastava [Mon, 19 Jun 2006 08:59:23 -0500]: I'll give the numbers on my system so as to affirm that the proportions are quite similar: __ grep-status -s Source '.' | sort -u | wc -l 1149 442 __ find /usr/share/doc -type f -name copyright | wc -l 3615 1448 __ find /usr/share/doc -type f -name copyright | \ xargs egrep -l 'GNU.+General' | 915 2154 __ find /usr/share/doc -type f -name copyright | \ xargs egrep -l Artistic | wc -l 504 177 __ find /usr/share/doc -type f -name copyright | \ xargs egrep -l 'GNU.+Lesser' | wc -l 252 181 __ find /usr/share/doc -type f -name copyright | \ xargs egrep -l 'GNU.+Library' | wc -l 174 117 __ find /usr/share/doc -type f -name copyright | \ xargs egrep -l 'Berkeley' | wc -l 82 46 __ find /usr/share/doc -type f -name copyright | \ xargs egrep -l 'Python.+Software' | wc -l 17 19 __ find /usr/share/doc -type f -name copyright | \ xargs egrep -l 'Zope' | wc -l 15 13 And now, I will give an extra command: % find /usr/share/doc -type f -name copyright | \ xargs egrep -l 'GNU.+Documentation' | wc -l 168 (On my laptop this number is 268.) This is because one and each of the binary packages coming from kde.org (of which there are around 500) ships a copy of the GFDL. I would certainly like to see this license shipped as a common license. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Los Planetas - San Juan de la Cruz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374498: debian-policy: please suggest #! / for 4 byte magic
Package: debian-policy Version: 3.7.2.0 Severity: wishlist policy presently uses #!/ without a space, but some systems apparently require the space (#! /) and sense the script type using a 4-byte magic number. info autoconf / portable shell mentions this. It would be nice to at least error on the side of portability and suggest this instead of the current one (without a space). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374498: debian-policy: please suggest #! / for 4 byte magic
ma, 2006-06-19 kello 13:30 -0400, Justin Pryzby kirjoitti: Package: debian-policy Version: 3.7.2.0 Severity: wishlist policy presently uses #!/ without a space, but some systems apparently require the space (#! /) and sense the script type using a 4-byte magic number. info autoconf / portable shell mentions this. It would be nice to at least error on the side of portability and suggest this instead of the current one (without a space). Which systems? Have any of them been manufactured since the 1980s? -- Päivät on kuin piikkilankaa, ne murjoo mua.
Bug#374498: debian-policy: please suggest #! / for 4 byte magic
On Mon, Jun 19, 2006 at 08:55:40PM +0300, Lars Wirzenius wrote: ma, 2006-06-19 kello 13:30 -0400, Justin Pryzby kirjoitti: Package: debian-policy Version: 3.7.2.0 Severity: wishlist policy presently uses #!/ without a space, but some systems apparently require the space (#! /) and sense the script type using a 4-byte magic number. info autoconf / portable shell mentions this. It would be nice to at least error on the side of portability and suggest this instead of the current one (without a space). Which systems? Have any of them been manufactured since the 1980s? Copying from the cited page: 4.2BSD based systems (such as DYNIX). As noted in #374472, my interest here is in the low cost of changing the policy document in 3 places; but I don't how significant the gain is. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373212: marked as done (policy: postinst doesn't document typical abort-remove case)
Your message dated Mon, 19 Jun 2006 14:43:04 -0500 with message-id [EMAIL PROTECTED] and subject line policy: postinst abort-remove without in-favour not allowed by maintscript templates has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: dpkg Version: 1.13.19 Severity: minor Tags: patch The postinstall script includes comments, which might reasonably be used as documentation for the maintainer script interface. However, the postinstall script has only # If prerm fails during replacement due to conflict: # postinst abort-remove in-favour new-package version But not the typical abort-remove case. --- /var/lib/dpkg/info/dpkg.postinst2006-05-04 07:09:34.0 -0400 +++ /tmp/dpkg.postinst 2006-06-06 17:05:08.0 -0400 @@ -8,6 +8,9 @@ # If prerm fails during upgrade or fails on failed upgrade: # old-postinst abort-upgrade new-version # +# If prerm fails during removal: +# old-postinst abort-remove +# # If prerm fails during deconfiguration of a package: # postinst abort-deconfigure in-favour new-package version # removing old-package version ---End Message--- ---BeginMessage--- Hi, On 13 Jun 2006, Justin Pryzby told this: I've been reading more thorougly about the dpkg maintainer script interface. I noticed that the neither the dpkg maintscript comments nor your maintscript templates allow for the postinst abort-remove case which is called with only a single parameter (instead of $2 = in-favour). I've filed #372145 against dpkg to fix the comments. The template files used should be updated too, especially for the policy package, since they are a good reference; I'd like to patch dh_make shortly to use some combination of your code and dpkg comments. Err, I am not sure this belongs to policy, which does not have any maintscript templates. Policy does document the call correctly, so I am closing this report. manoj -- Different all twisty a of in maze are you, passages little. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C ---End Message---
Re: Bug#374498: debian-policy: please suggest #! / for 4 byte magic
On Mon, Jun 19, 2006 at 03:02:12PM -0400, Justin Pryzby wrote: On Mon, Jun 19, 2006 at 08:55:40PM +0300, Lars Wirzenius wrote: ma, 2006-06-19 kello 13:30 -0400, Justin Pryzby kirjoitti: Package: debian-policy Version: 3.7.2.0 Severity: wishlist policy presently uses #!/ without a space, but some systems apparently require the space (#! /) and sense the script type using a 4-byte magic number. info autoconf / portable shell mentions this. It would be nice to at least error on the side of portability and suggest this instead of the current one (without a space). Which systems? Have any of them been manufactured since the 1980s? Copying from the cited page: 4.2BSD based systems (such as DYNIX). As noted in #374472, my interest here is in the low cost of changing the policy document in 3 places; but I don't how significant the gain is. Non-existent. People who are trying to make their scripts portable to miscellaneous ancient oddball systems are going to need a quite different reference than Debian policy. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#368055: marked as done (debian-policy: Add a section about 'transitional packages')
Your message dated Mon, 19 Jun 2006 15:11:45 -0500 with message-id [EMAIL PROTECTED] and subject line This is a best practices recommendation has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: debian-policy Severity: wishlist Since I just accidentally created a grave bug due to errors in a transitional package I would like to propose the policy mentions them. Section 7.5.2 of the policy deals with virtual packages already. Somewhere near that section I would like to learn about transitional packages. Quick proposal: Sometimes a package A unites functionality from a second package B making B obsolete. In this situation the package B becomes a 'transitional package' that is just needed to move users to the package A. This is done by removing all files from the package B and setting the dependencies as follows: A: Replaces: B Conflicts: B B: Depends: A Description: Transitional package for A This is a transitional package which ensures users of B will use A in the future. It can safely be removed. Is it important that B is not just removed. Even the Replaces: B in package A is not sufficient for an automatic migration. [Even though 'aptitude' already seems to support that.] B can be safely removed after the next stable release. (Note: I'm not sure whether the Provides: B is actually necessary. It works without it. And I understand it that Provides: is mainly/only there for virtual packages.) Kindly Christoph -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.10 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) ---End Message--- ---BeginMessage--- Hi, How to create a transitional package that works and is not uninstallable is is nice, and perhaps does belong in the developers reference, but is not appropriate for policy. manoj -- Bershere's Formula for Failure: There are only two kinds of people who fail: those who listen to nobody... and those who listen to everybody. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C ---End Message---
Bug#366889: marked as done (GNU office not on Temple Place anymore)
Your message dated Mon, 19 Jun 2006 15:07:23 -0500 with message-id [EMAIL PROTECTED] and subject line This does not belong in policy has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: debian-policy Version: 3.6.2.2 Severity: wishlist Tags: patch $ dlocate /copy|sed s/.*://|xargs grep -l Temple|wc -l shows at least 216 packages still say Temple Place in their copyright snippet, no matter how short. Even though GNU now lives on Franklin St. I Didn't check /COPY... nor packages not installed on my system, nor did I check for other old addresses. Cure: *** policyOLD.txt 2006-05-12 03:42:15.489929291 +0800 --- policy.txt 2006-05-12 03:41:26.302934636 +0800 *** *** 5681,5683 `/usr/share/common-licenses/LGPL' respectively, rather than quoting ! them in the copyright file. --- 5681,5685 `/usr/share/common-licenses/LGPL' respectively, rather than quoting ! them in the copyright file. /usr/share/common-licenses/* will ! contain current office addresses, so don't quote them in the ! copyright file. But wait, even policy.txt says Temple Place!! $ zgrep Temple /usr/share/doc/debian-policy/policy.txt.gz ---End Message--- ---BeginMessage--- Hi, Specifying incorrect office addresses is a bug; and the solution is to fix the bugs, nit to say that the address should be elided. Additionally, with the correct office address a user may still get hold of the license from a canonical location even if they do not have access to a running Debian system, which is a good thing. manoj -- Your project will be late. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C ---End Message---
Bug#368130: marked as done (grep 59 Temple St /usr/bin/*)
Your message dated Mon, 19 Jun 2006 15:09:45 -0500 with message-id [EMAIL PROTECTED] and subject line This is not appropriate for policy has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: debian-policy Severity: wishlist Many programs in /usr/bin have GNU's _old_ address hardwired in: $ cd /usr/bin $ fgrep --files-with-matches '59 Temple Place' *|wc -l 179 $ fgrep --files-with-matches Temple *|wc -l 187 And that's just on my machine. $ fgrep --files-with-matches Mass *|wc -l 40 #An even older address, Mass Ave. It must be because policy doesn't say anything about sticking copyright notices in the /usr/[s]bin/file, only about /usr/share/doc/package/copyright . Therefore policy should say not to put copyright notices in /usr/[s]bin/* or at least not office addresses that will get stale. Instead when one does $ some_program --view-copyright the output should say to see /usr/share/common-licenses/... ---End Message--- ---BeginMessage--- Hi, An old, or wrong, address in the script is a bug, or at least a wishlist for updating. The bugs should be fixed, and should not need policy to say do not have bugs in your packages. manoj -- I think we're all Bozos on this bus. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C ---End Message---
Processed: Setting severities
Processing commands for [EMAIL PROTECTED]: severity 328951 minor Bug#328951: Clarification for difference between Build-Depends and Build-Depends-Indep (Section 7.6) Severity set to `minor' from `normal' severity 367984 wishlist Bug#367984: Policy 8.2 has unclear last sentence Severity set to `wishlist' from `normal' severity 374029 minor Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition Severity set to `minor' from `normal' -- Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374498: marked as done (debian-policy: please suggest #! / for 4 byte magic)
Your message dated Mon, 19 Jun 2006 15:29:53 -0500 with message-id [EMAIL PROTECTED] and subject line This is not a bug. has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: debian-policy Version: 3.7.2.0 Severity: wishlist policy presently uses #!/ without a space, but some systems apparently require the space (#! /) and sense the script type using a 4-byte magic number. info autoconf / portable shell mentions this. It would be nice to at least error on the side of portability and suggest this instead of the current one (without a space). ---End Message--- ---BeginMessage--- Hi, Actually, POSIX: The Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Edition Copyright © 2001-2004 The IEEE and The Open Group, All Rights reserved., states: == Another way that some historical implementations handle shell scripts is by recognizing the first two bytes of the file as the character string #! and using the remainder of the first line of the file as the name of the command interpreter to execute. == So it is only a two byte magic, which is what I recall. It gets even better: == 2.1 Shell Introduction The shell is a command language interpreter. This chapter describes the syntax of that command language as it is used by the sh utility and the system() and popen() functions defined in the System Interfaces volume of IEEE Std 1003.1-2001. The shell operates according to the following general overview of operations. The specific details are included in the cited sections of this chapter. 1. The shell reads its input from a file (see sh), from the -c option or from the system() and popen() functions defined in the System Interfaces volume of IEEE Std 1003.1-2001. If the first line of a file of shell commands starts with the characters #!, the results are unspecified. == manoj -- Men freely believe that what they wish to desire. Julius Caesar Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C ---End Message---
Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
On Mon, Jun 19, 2006 at 01:02:42PM -0500, Manoj Srivastava wrote: On 16 Jun 2006, Goswin Brederlow stated: The existance of either of the two makes build-arch mandatory. The old fields change their meaning: Build-Depends, Build-Conflicts The Build-Depends and Build-Conflicts fields must be satisfied when any target is invoked. Does the converse hold as well? Is Build-Depends a superset of all dependencies until further notice? If not, if I am using an older dpkg-checkbuildeps or an older sbuild, my package may fail to build. Sbuild explicitely, by design, only looks at build-depends. So in order for build-depends to be useful at this time if you want a package to build, you need to list mostly everything in build-depends right now anyway. It is in fact not against policy to list build dependencies that could technically be put in build-depends-indep in build-depends only, and I believe (though I'm not sure, and can't remember offhand where) that I have already seen some packages do so in the past. So, yes, for all practical matters build-depends right now is a superset of build-depends-indep. Build-Depends-Indep, Build-Conflicts-Indep The Build-Depends-Indep and Build-Conflicts-Indep fields must be satisfied when any of the following targets is invoked: build-indep, binary-indep. The existance of either of the two makes build-indep mandatory. The use of Build-Depends/Conflicts-Arch/Indep is optional but should be used in architecture all/any mixed packages. If any of them is omitted the respective Build-Depends/Conflicts field must be suffient already. ### End of Proposal ### - Simple to implement. + Trivial change in dpkg for the new field. + dpkg-checkbuilddeps has to parse 3 fields (2 with -B option) instead of 2 (1). + sbuild, same change + Simple change for 'apt-get build-dep' Does this mean a package which conforms to the new proposal would fail if the an old sbuild/dpkg-checkbuilddeps is used? In other words, can someone running Sarge build a package from Etch? old sbuild should not be an issue. Official buildd hosts never run sbuild from stable, they run sbuild from a separate repository at db.debian.org. If policy is updated to do something new which will benefit the buildd hosts, then sbuild will follow suit (provided there is code to do that) Of course, if a package does not build with old dpkg-buildpackage, that might be a problem; not sure about that. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366889: marked as done (GNU office not on Temple Place anymore)
reopen 366889 thanks Dan Jacobson said: [...] But wait, even policy.txt says Temple Place!! $ zgrep Temple /usr/share/doc/debian-policy/policy.txt.gz Manoj Srivastava said: Specifying incorrect office addresses is a bug; and the solution is to fix the bugs, nit to say that the address should be elided. ... I agree that Policy should not say that the address should be elided. But given that Policy still lists the FSF's Temple Place address in its own copyright notice, instead of their current address, I think that this is still a bug in Policy until the copyright notice is fixed. (I was going to open a bug against Policy a few weeks ago about changing the address, until I saw this bug.) -- Hubert Chan - email Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#366889: marked as done (GNU office not on Temple Place anymore)
Processing commands for [EMAIL PROTECTED]: reopen 366889 Bug#366889: GNU office not on Temple Place anymore Bug reopened, originator not changed. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366889: marked as done (GNU office not on Temple Place anymore)
On 19 Jun 2006, Hubert Chan told this: reopen 366889 thanks In the future, do not hijack bugs to report an unrelated issue. Open a new report. Doing otherwise only causes confusion. manoj -- To err is human, to moo bovine. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354504: marked as done (debian-policy: Please include the python policy in the package)
Your message dated Mon, 19 Jun 2006 21:24:10 -0500 with message-id [EMAIL PROTECTED] and subject line Bug#354504: debian-policy: Please include the python policy in the package has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: debian-policy Version: 3.6.2.2 Severity: wishlist Please include the Python policy, as done with the Perl policy. http://www.debian.org/doc/packaging-manuals/python-policy/ Thanks. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-2-686-smp Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- no debconf information ---End Message--- ---BeginMessage--- On 26 Feb 2006, Joe Wreschnig uttered the following: On Mon, 2006-02-27 at 00:16 +0200, Lior Kaplan wrote: Please include the Python policy, as done with the Perl policy. http://www.debian.org/doc/packaging-manuals/python-policy/ Please do not, because the Python policy does not document current practice but rather ideal practice that we are a long way from. As far as that goes, it's not very ideal, and in need of a huge overhaul (which it is getting). (In the future, issues of Python policy should probably be brought up on debian-python before anywhere else.) Please open a fresh bug report when the python policy is ready for inclusion. thanks, manoj -- finlandia:~ apropos win win: nothing appropriate. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C ---End Message---
Changes to archive debian-policy--devel--3.7--patch-6
Revision: debian-policy--devel--3.7--patch-6 Archive: [EMAIL PROTECTED] Creator: Manoj Srivastava [EMAIL PROTECTED] Date: Tue Jun 20 00:23:54 CDT 2006 Standard-date: 2006-06-20 05:23:54 GMT New-files: debian/.arch-ids/ChangeLog.id debian/ChangeLog Modified-files: ChangeLog debian/changelog debian/control menu-policy.sgml mime-policy.sgml perl-policy.sgml policy.sgml upgrading-checklist.html New-patches: [EMAIL PROTECTED]/debian-policy--devel--3.7--patch-6 [EMAIL PROTECTED]/debian-policy--devel--3.7--patch-20 [EMAIL PROTECTED]/debian-policy--devel--3.7--patch-21 [EMAIL PROTECTED]/debian-policy--devel--3.7--patch-22 [EMAIL PROTECTED]/debian-policy--devel--3.7--patch-23 [EMAIL PROTECTED]/debian-policy--devel--3.7--patch-24 [EMAIL PROTECTED]/debian-policy--devel--3.7--patch-25 Summary: Synchronize from Manoj's branch. Mostly typograpical corrections and bug fixes, upgrading checklist has not changed, and is this only 3.7.2.1. Keywords: Synchronize from Manoj's branch. Mostly typograpical corrections and bug fixes, upgrading checklist has not changed, and is this only 3.7.2.1. Patches applied: * [EMAIL PROTECTED]/debian-policy--devel--3.7--patch-20 revert the cgi-lib change * [EMAIL PROTECTED]/debian-policy--devel--3.7--patch-21 Minor typographical fixes * [EMAIL PROTECTED]/debian-policy--devel--3.7--patch-22 Fixed description of the behaviour of dpkg. * [EMAIL PROTECTED]/debian-policy--devel--3.7--patch-23 multi-line values for control file fields clarified * [EMAIL PROTECTED]/debian-policy--devel--3.7--patch-24 mention the need to have a copyright file in the source package section * [EMAIL PROTECTED]/debian-policy--devel--3.7--patch-25 Fix FSF Email address -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
