Bug#789810: summit.debconf.org: Registration form: parts of the page are not encrypted
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/24/2015 07:23 PM, Francesco Poli (wintermute) wrote: > I don't feel too safe to enter personal data on a page that is not > fully encrypted. I suppose other people feel the same and I wonder why > this issue has not yet been solved. The problem the favicon.ico. More precisely http://www.debian.org/favicon.ico , so don't worry. I feel that the bug is minor. ciao cate -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJViu/7AAoJEPGwLFkKjsup97wP/3NHVyFaiXCrYbnyAaUnw7vl 6TTh9pnLssNmgnRF+/wamkc2SPy6d3SK1ZKPsT2xLDYwxQlU9c1g3ky4dc/lHDRO Cjeumz+JEQP3opywsbeMSABoFFgBRR+AOlgBWPp0/86l6VcWbojh5I0HvK9SyG5D 0BwoDxn6L8BcvNIsYEbxhPIY5h/Wu/fVhYiNdrHI/opXHjDWejAJ/+E1x4K/3Gpp bJe++tZzulFvfiqkDo2MBDrZQUUAiUQIuIBIXuW7+SpMHRK4aOhdA2YLuT0STR7Y nEYFejhrR6FxfEc8U7lxZypTKdMZX+kGJff852YEojdkSXz+RpTQCOE7ePU3CJdo uNgzvq6LDIO2saAJa9F7SBpwyOcYRlTUMDuo8VrmUYr7G4pmAn9bSiksOY2AHE8o xJQTb3xeHXReJinns2tsmrRiR7tRkFEVs6VHJbAepAW8hkatMaL/dsnd5lrLZwwh Uep9ZeIqkf55JsLUQRTAlO7I2tnbUh3kCNSNm9ijAMsgcCWUXZbSKhbomX/inVuL /sN3JfocoAUv1B/n0KVclTGWOfTcxlfs67RVf36fhKXMAxR+mNp6bpp4K+Fx+hWO qu1BmvNd0Zs8yeZwLpOxGJN4lEdBBcoR7HwwuplE9DVWwptxyu9M5sxi5cO0k3S1 xdpHA5P9f2rBmqjuvkYK =oldP -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#699382: Broken syslinux in sid
On 02/04/2013 08:40 AM, Giacomo A. Catenazzi wrote: > On 02/03/2013 10:53 PM, Daniel Baumann wrote: >> On 02/03/2013 10:44 PM, Cyril Brulebois wrote: >>> Now please explain how exactly syslinux-themes-debian is involved >>> here. >> >> it's a bug in your config, you need more files present on the media, as >> the link to the corresponding commit in live-build shows. > > Could you be more specific, and put an information in README.Debian? > > On the 5.0 version, I had libutil_com.c32 and not the libutil.c32. Could > be that the error? (Note: I copied it also /boot/extlinux). > > Anyway running extlinux -i /boot/extlinux, I would expect that the > program will copy the right files in boot (so possibly my original bug > is a slight different [or deeper] to the installer bug) Version 5.01 works again for me, so for me the initial bug is closed. Because of the further concerns opened by -release and -boot, I left it open, to continue the discussion. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#699382: Broken syslinux in sid
On 02/03/2013 10:53 PM, Daniel Baumann wrote: > On 02/03/2013 10:44 PM, Cyril Brulebois wrote: >> Now please explain how exactly syslinux-themes-debian is involved >> here. > > it's a bug in your config, you need more files present on the media, as > the link to the corresponding commit in live-build shows. Could you be more specific, and put an information in README.Debian? On the 5.0 version, I had libutil_com.c32 and not the libutil.c32. Could be that the error? (Note: I copied it also /boot/extlinux). Anyway running extlinux -i /boot/extlinux, I would expect that the program will copy the right files in boot (so possibly my original bug is a slight different [or deeper] to the installer bug) ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-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
On 03.09.2010 01:46, Russ Allbery wrote: Samuel Thibault writes: Well, it's mostly - some people saying "it's useless", - while other people saying "I need it", and also - "en_US.UTF-8 is just fine" vs. - "en_US.UTF-8 sucks, we really need C.UTF-8 instead" without any convergence. I think the way to get past that is to make a specific proposal. With my Lintian maintainer hat on, I need a UTF-8 locale that's guaranteed to always be available. Right now, we're doing something complicated and annoying (and fragile on Ubuntu) to generate one on the fly (en_US.UTF-8 just because it's probably always there), and we would love to stop doing that. 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. BTW I think we should wait some more time. Last week I was on debian-glibc list a bug: printf fails if it find an invalid UTF-8 character (when the locale uses UTF-8). Note it is allowed in POSIX, which distinguish raw strings and parts which uses locale definitions. So I don't think a C.UTF-8 is safe. But a good release goal for squeeze+1. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#488214: make mailx a registered virtual package name
On 21.08.2010 08:36, Raphael Hertzog wrote: On Fri, 20 Aug 2010, Russ Allbery wrote: diff --git a/virtual-package-names-list.txt b/virtual-package-names-list.txt index 9ba66e5..2308d39 100644 --- a/virtual-package-names-list.txt +++ b/virtual-package-names-list.txt @@ -123,6 +123,8 @@ News and Mail imap-server an IMAP mail server mail-reader a mail user agent (e.g. Pine, Elm, mailx,&c) mail-transport-agenta mail transport agent (e.g. Smail, Sendmail,&c) + mailx a /usr/bin/mailx binary that provides at least + the POSIX mailx interface (*) news-reader a news reader (e.g. trn, tin,&c) news-transport-system a local news system (e.g. INN, C News or B News) pgp a version of PGP (International or US) Seconded. seconded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#488214: make mailx a registered virtual package name
On 19.08.2010 09:45, Russ Allbery wrote: "Giacomo A. Catenazzi" writes: On 18.08.2010 23:38, Russ Allbery wrote: Julien Cristau writes: Is there a spec somewhere about the command line arguments for mailx? I know that bsd-mailx and heirloom-mailx do completely different things for -a, e.g., which is a major pain, and I'm not sure they should be alternatives. mailx is specified by POSIX. POSIX does indeed not specify the -a flag. (Out of curiosity, if one needs the -a flag to mailx, why not just call sendmail directly and pass in exactly the headers one wants?) To Russ: yes, mailx was mean to replace mail and sendmail (which is difficult to standardize, and most of sendmail is outside POSIX scope). Should we say explicitly in the virtual package listing that packages providing mailx are only promising to implement the POSIX flags and you're on your own for anything more than that? Note: I was replying to your "out of curiosity". To answer the original question: I agree to make "mailx" a virtual package. And I agree to specify that the mailx provides the POSIX interfaces of mailx NOTE: LSB 4.0 don't have any extra requirement on mailx. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593533: debian-policy: Proposal to stop requesting to list initial Debian maintainers in debian/copyright
On 19.08.2010 09:37, Russ Allbery wrote: "Giacomo A. Catenazzi" writes: No, I think it is wrong! The debian/copyright also include packaging copyright. I think the part involved in this proposal is for such reasons. So IMHO we must still require the names of packagers (and the specific license). We've never said or required that, though. All we've required is that debian/copyright contain any relevant copyright notices and any licenses. I agree that if there are any for the Debian packaging, they should be in debian/copyright (and I think that's already covered by the other language), but it's common practice (if arguably sloppy) in the archive to not put a specific license on the packaging (in which case I think everyone in the free software community would assume it's under the same license as the rest of the work since that's pretty much standard usage). And it's relatively rare for Debian packagers to put explicit copyright notices on things. Maybe I misunderstand, but dh-make put explicitly at the bottom of debian/copyright: : The Debian packaging is (C) #YEAR#, #USERNAME# <#EMAIL#> and : is licensed under the GPL, see above. See /usr/share/debhelper/dh_make/licenses/* I meant about the specific debian files. I really think that the patches should have the same license as the upstream. Anyway, I agree that the information are already there, so the proposal is useless. IMHO it is good to repeat (what was implicit said in first paragraph) that we need the same information for upstream side and packing side. Copyright notices are strictly optional in countries that are signatories to Berne. If the copyright holder doesn't put one on, we're under no obligation to invent one. I agree, but this is also the problem: by default a work is *full protected* by copyright. Thus we need to explicitly grant at minimun the DFSG basic rights. Also the initial debian packager should ask upstream for authorisation to pack the original software, and such information is important for legal reasons, thus we must know who where the initial debian packager. Surely not... if we have to ask anyone for authorization to package something, it at the very least is non-free, and if we have to know who that person is for legal reasons, I'm skeptical that it's even redistributable in non-free since we often will have no way of contacting that person nor are any sort of legal signatory to any agreements they made. Not really, but this is becoming off-topic. The debian reasons was something like: we are packagers and not developers, so we need a cooperative upstream (and we should not pack a packages that upstream want to obsolete). But IMHO having an authorization give us a better legal base: The author acknowledge that the package is really distributable (errors happens), and it give a light base about using the package name (trademarks). Such things are not legally binding, but we can at minimum demonstrate that we was not in bad faith, and give judge some acknowledgement of intents of both sides. ciao cate PS: probably there is also a "license -> contract", but I don't know if such things is better or not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#488214: make mailx a registered virtual package name
On 18.08.2010 23:38, Russ Allbery wrote: Julien Cristau writes: On Wed, Aug 18, 2010 at 12:31:59 -0700, Russ Allbery wrote: I propose the following addition. Seconds or objections? (As mentioned elsewhere in the file, the * indicates that the providing packages are using alternatives, which appears to be the case.) Is there a spec somewhere about the command line arguments for mailx? I know that bsd-mailx and heirloom-mailx do completely different things for -a, e.g., which is a major pain, and I'm not sure they should be alternatives. mailx is specified by POSIX. POSIX does indeed not specify the -a flag. (Out of curiosity, if one needs the -a flag to mailx, why not just call sendmail directly and pass in exactly the headers one wants?) What -a does? Searching on google: two man page don't describe it, and one as "add attachment" and one as "add header". So I think portable scripts should not use -a To Russ: yes, mailx was mean to replace mail and sendmail (which is difficult to standardize, and most of sendmail is outside POSIX scope). ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593533: debian-policy: Proposal to stop requesting to list initial Debian maintainers in debian/copyright
On 19.08.2010 04:10, Russ Allbery wrote: Charles Plessy writes: Information about the initial Debian maintainers partially overlaps the information in debian/changelog, and the copyright statements for the packaging work. Under normal circumstances, it always duplicates information in debian/changelog (there are some edge cases where it doesn't, but I think they're rare). diff --git a/policy.sgml b/policy.sgml index 9037de8..e924b5a 100644 --- a/policy.sgml +++ b/policy.sgml @@ -9554,9 +9554,8 @@ END-INFO-DIR-ENTRY In addition, the copyright file must say where the upstream - sources (if any) were obtained. It should name the original - authors of the package and the Debian maintainer(s) who were - involved with its creation. + sources (if any) were obtained, and should name the original + authors. Seconded. No, I think it is wrong! The debian/copyright also include packaging copyright. I think the part involved in this proposal is for such reasons. So IMHO we must still require the names of packagers (and the specific license). I think that the debian/changelog don't give enough informations about packagers (e.g. if they are more than one). Also the initial debian packager should ask upstream for authorisation to pack the original software, and such information is important for legal reasons, thus we must know who where the initial debian packager. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#584671: [lxr-cvs] new stable version fix security hole
On 26.07.2010 15:08, Alexander Reichle-Schmehl wrote: Hi! * Giacomo A. Catenazzi [100607 09:29]: Please update lxr-cvs to the new stable version. The new version 0.9.8 of lxrng fix several cross-site scripting vulnerabilities (CVE-2009-4497) reported in bug #575745 The new version was published 2010-01-15 on http://sourceforge.net/projects/lxr/ Yes, I'll push the security fix. Note that the new upstream version is not a releasable version: it was an alpha version with the security fix added, but still it is not really working. Any news on this? There are four security related RC bugs open against lxr and lxr-cvs. And as popcon seems to report only one actively used installation, I wonder if removing these packages wouldn't be an option. "Seb" (I know only the nickname on IRC) told me few days ago, that it was ready to release a fix for the 4 CVEs for lxr-cvs. I was planing than to test and port the fixes to lxr. Probably should not be put anymore on stable releases, but it is IMHO a base for further developements (debian sources, etc.), and considering that CVE are issued, I think the lxr is still used and checked (so possibly it is not in a so bad shape). Note: probably one of the two package should be removed, but I'm still undecided which one ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#477240: Please clarify status of XSI extensions for kill and trap
On 07/15/2010 06:53 PM, Russ Allbery wrote:
"Giacomo A. Catenazzi" writes:
As we have in "test" item, I think we should add ",if implemented as a
shell built-in," also for the kill command.
Good point. Here's a new patch. (This doesn't apply to trap because I
don't think trap can work without having it implemented as a shell
built-in.)
diff --git a/policy.sgml b/policy.sgml
index 6c770fd..d694fd2 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -7460,7 +7460,19 @@ fname () {
must be supported and must set the value ofc to
delta.
-
+
+ The XSI extension tokill allowingkill
+ -signal, wheresignal is either
+ the name of a signal or one of the numeric signals listed in
+ the XSI extension (0, 1, 2, 3, 6, 9, 14, and 15), must be
+ supported ifkill is implemented as a shell
+ built-in.
+
+ The XSI extension totrap allowing numeric
+ signals must be supported. In addition to the signal
+ numbers listed in the extension, which are the same as for
+ kill above, 13 (SIGPIPE) must be allowed.
+
If a shell script requires non-SUSv3 features from the shell
interpreter other than those listed above, the appropriate shell
Thanks,
seconded.
ciao
cate
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#477240: Please clarify status of XSI extensions for kill and trap
On 05.07.2010 01:02, Raphael Geissert wrote:
On Sunday 04 July 2010 00:04:20 Russ Allbery wrote:
Yeah, I was trying too hard to avoid a problem which doesn't really
exist. Here's an updated patch.
diff --git a/policy.sgml b/policy.sgml
index bad28af..8b715d0 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -7427,7 +7427,18 @@ fname () {
must be supported and must set the value ofc to
delta.
-
+
+ The XSI extension tokill allowingkill
+ -signal, wheresignal is either
+ the name of a signal or one of the numeric signals listed in
+ the XSI extension (0, 1, 2, 3, 6, 9, 14, and 15), must be
+ supported.
+
+ The XSI extension totrap allowing numeric
+ signals must be supported. In addition to the signal
+ numbers listed in the extension, which are the same as for
+ kill above, 13 (SIGPIPE) must be allowed.
+
If a shell script requires non-SUSv3 features from the shell
interpreter other than those listed above, the appropriate shell
Looks good now. Seconded.
As we have in "test" item, I think we should add ",if implemented as a
shell built-in," also for the kill command.
ciao
cate
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#475101: obsolete linuxthreads requirement
On 04.07.2010 10:42, Kurt Roeckx wrote: On Sat, Jul 03, 2010 at 12:26:40PM -0700, Russ Allbery wrote: --- a/policy.sgml +++ b/policy.sgml @@ -7225,10 +7225,10 @@ INSTALL = install -s # (or use strip on the files in debian/tmp) for C files) will need to be compiled twice, for the normal case. + - You must specify the gcc option-D_REENTRANT - when building a library (either static or shared) to make - the library compatible with LinuxThreads. + Libraries should be built with threading support and to be + thread-safe if the library supports this. Seconded. Seconded. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#436105: suggestion to add GPL-1 as a common licence
On 11.06.2010 14:25, Andrew McMillan wrote: If the code is v1-or-later then a trivial fork (by the original developer) is able to relicense it as v2-or-later or v3-or-later. If the original developer is unhappy with doing that, then they do have uncommon licensing desires. It would be illegal. You can act as if there is v2-or-later, but you cannot apply additional restriction on original code, so the old code is still v1-or-later. Note in GPLv3 there could be a "proxy" authority to allow increment base license number, but AFAIK few project define such proxy in the code, and it is only from GPLv3. PS: you can fork and add a new GPL-v2-or-later file, which automatically cause the aggregate work and binary to be GPL-v2-or-later, but: (1) debian/copyright is about pure source licenses; (2) the source file license is not changed. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#436105: suggestion to add GPL-1 as a common licence
On 11.06.2010 13:16, Andrew McMillan wrote: On Fri, 2010-06-11 at 11:35 +0200, Santiago Vila wrote: Ok, I agree that it would a good idea to include GPL-1 in common-licenses because of the high number of packages still using it. I'm sorry, but I disagree, for the time being. I do not believe that large numbers of packages are deliberately using GPL v1, and I think that anyone who is needs to confirm that explicitly since (I hope) many of them have moved on to less broken licenses such as GPL3 or GPL2. Yes for new code, but old code cannot be relicensed easily: all authors should agree, but GPLv1 is very old, in periods where contribution did not have an email and "fix" (live-long) email address was not common. and OTOH the unversioned GPL notices means any GPL license. [both for old programs and for "careless" new developement. BTW unilaterally moving "version 1 and any later versio" to "version 2 [or 3] and later later" is against the GPL. So I think that GPLv1 will remain important for the time being, and I would include it in common-license. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#487201: MPL-license
On 10.06.2010 21:45, Russ Allbery wrote: I recently did a survey of both licenses already listed in common-licenses and ones proposed for common-licenses using a Perl script that's now in the debian-policy Git repository. The result was that the MPL version 1.1 was used by 654 binary packages in the archive. This is by far the best claim of any of the proposed new licenses for common-licenses, although it still falls short of the least-used license already in common-licenses (the GFDL, used by 875 binary packages in some variant or version) and certainly well short of the 5% of the archive standard that Manoj proposed (which would be 1473 binary packages). On the other criteria we've used in the past, popcon, the MPL 1.1 fares relatively well, since Iceweasel references it and could replace its copy with a link to common-licenses and is installed by 50% of the systems reporting via popcon. I'm not sure to what extent including something in common-licenses is an approval. We included the GFDL because it was widely used and looked likely to be more widely used, despite the fact that the project definitely isn't very fond of it. So I'm torn on this one, and the discussion also seemed divided. I'm leaning mildly towards rejecting it, but only very mildly. Other opinions? The common-licenses was done (IIRC) to save disk space, so to use such criteria, I would count only packages with priority >= standard, or a proof that most systems have the verbatim license installed many times). OTOH the disk usage is no more a big issue, so we could use common-license as a pool of common and recommended licenses. Personally I don't think policy should discuss so many licenses, so, I would like: - make clear and strong requirements for new licenses (e.g. we should include only few licenses), or - move the choice outside policy procedure (e.g. maintainer of base-files). ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#584671: [lxr-cvs] new stable version fix security hole
On 05.06.2010 15:00, Xavier Brochard wrote: Package: lxr-cvs Version: 0.9.5+cvs20071020-1 Severity: serious Tags: security X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org --- Please enter the report below this line. --- Please update lxr-cvs to the new stable version. The new version 0.9.8 of lxrng fix several cross-site scripting vulnerabilities (CVE-2009-4497) reported in bug #575745 The new version was published 2010-01-15 on http://sourceforge.net/projects/lxr/ Yes, I'll push the security fix. Note that the new upstream version is not a releasable version: it was an alpha version with the security fix added, but still it is not really working. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#569174: [PATCH] Correction of RFC number for date format -- bug #569174.
On 04.06.2010 04:40, Andrew McMillan wrote: On Thu, 2010-06-03 at 18:31 -0700, Russ Allbery wrote: Charles Plessy writes: I also like the idea, so I prepared a patch (attached) Thank you! RFC 822 dates use only two digits for the years, but Debian changelogs described by this paragraph (§4.4 in Policy 3.8.4) use four digits. This patch replaces the reference to the RFC 822 by a specification that is compatible with its successors, RFC 2822 and RFC 5322, but does not use their full range of options. --- policy.sgml | 26 ++ 1 files changed, 22 insertions(+), 4 deletions(-) diff --git a/policy.sgml b/policy.sgml index af00c0e..5ba1980 100644 --- a/policy.sgml +++ b/policy.sgml @@ -1618,11 +1618,29 @@ - Thedate must be in RFC822 format + Thedate has the following format This is generated bydate -R. - ; it must include the time zone specified - numerically, with the time zone name or abbreviation - optionally present as a comment in parentheses. + (compatible and with the same semantics of + RFC 2822 and RFC 5322): + day-of-week, dd month hh:mm:ss + + where: + + day-of week is one of: Mon, Tue, Wed, Thu, Fri, Sat, Sun + dd is a one- or two-digit day of the month (01-31) + month is one of: Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec + is the four-digit year (e.g. 2010) + hh is the two-digit hour (00-23 + mm is the two-digit minutes (00-59) + ss is the two-digit seconds (00-60) + + + or - is the the time zone offset from Coordinated Universal + Time (UTC). "+" indicates that the time is ahead of (i.e., east of) UTC + and "-" indicates that the time is behind (i.e., west of) UTC. The + first two digits indicate the hour difference from UTC and the last + two digits indicate the number of additional minutes difference from + UTC. The last two digits must be in the range 00-59. + + Seconded. Seconded. Seconded. PS: to the editor: missing parenthesis after "hour (00-23" I had preferred to maintain the 00-61 second intervall, just for compatibility of POSIX (now an anal-orthodox-fundamentalist program must check the impossible case before to call POSIX interfaces), but this is bikesheeding/not important/not security relevant (and probably it will confuse less the readers), so I second this. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#569174: [PATCH] Correction of RFC number for date format -- bug #569174.
On 02.06.2010 14:59, Bill Allombert wrote: What is the diffrence between RFC5322 and RFC2822 time format ? RFC 5322 was only released in 2008, so the standard that packages actually follow is clearly RFC2822. I would prefer if we keep a reference to RFC2822 because is is more well known than RFC5322 The 'date' utility denotes this format under 'RFC 2822': The option is named --rfc-2822 and the documentation list RFC 2822. There are some differences (usually backward compatible). The main difference I see is: RFC 5322 doesn't permit comments before and after month name, so really an insignificant change for Debian. OTOH we don'twant to have the full range of options, e.g. the tree RFCs permits the 2 digit year (check obs-year), it permits to leave off the day-of-week, it permits to use the "obsolete" time zones, etc. So I propose to define "date" field explicitly: The date has the following format (compatible and with the same semantic of RFC 2822 and RFC 5322): day-of-week, dd month hh:mm:ss + where: - day-of week is one of: Mon, Tue, Wed, Thu, Fri, Sat, Sun - dd is 2 digist (01-31) - month is one of: Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec - is 4 digits (e.g. 2010) - hh is 2 digits (00-24) - mm is 2 digits (00-59) - ss is 2 digits (00-61) - + (or -) is a sign (+ or 0) followed by 4 digits. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#572746: libm: sinf/cosf performance is awful on amd64
On 17.03.2010 14:36, Vincent Lefevre wrote: On 2010-03-17 13:41:04 +0100, Giacomo A. Catenazzi wrote: On 17.03.2010 11:29, Vincent Lefevre wrote: On 2010-03-07 16:17:08 +0100, Aurelien Jarno wrote: On amd64, only sincos has an optimized version, It may be optimized, but completely buggy. For instance, on 1e22, sincos returns 0.46261304076460174617 for the sine instead of -0.85220084976718879499 (correctly rounded value). Even the sign is incorrect! Sorry, but I don't see the error. Both are the correct values, as any values from -1 to 1. The double "1e22" is outside the *relevant* precision for double, e.g. a whole range of 2*pi is described with the same number (1e22). No, this is wrong. This could be correct with interval arithmetic, but floating-point arithmetic works differently: inputs are regarded as *exact*. Are you sure? From C standard (not really the standard, but the draft n1256: 5.2.4.2.2, point 5): : The accuracy of the floating-point operations (+, -, *, /) and of : the library functions in and that return : floating-point results is implementationdefined, : as is the accuracy of the conversion between floating-point : internal representations and string representations performed by : the library functions in , , and . : The implementation may state that the accuracy is unknown. And also looking in POSIX, I find no further requirement, so are you sure that 1e22 should be taken as exact. So maybe the bug is to define __STDC_IEC_559__ on such case. OTOH, section F9.1 don't require (my interpretation) trigonometric to be IEC 60559 functions. It has such requirement for more elementary functions, e.g. for sqrt (see section F3). OTOH I think you are an expert on such standards, so it is possible/probable that I'm completly wrong. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#572746: libm: sinf/cosf performance is awful on amd64
On 17.03.2010 11:29, Vincent Lefevre wrote: On 2010-03-07 16:17:08 +0100, Aurelien Jarno wrote: On amd64, only sincos has an optimized version, It may be optimized, but completely buggy. For instance, on 1e22, sincos returns 0.46261304076460174617 for the sine instead of -0.85220084976718879499 (correctly rounded value). Even the sign is incorrect! Sorry, but I don't see the error. Both are the correct values, as any values from -1 to 1. The double "1e22" is outside the *relevant* precision for double, e.g. a whole range of 2*pi is described with the same number (1e22). Maybe using long double (and sincosl) you will have the expected results (I did not calculate the minimun precision of long double). ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#567316: bsdmainutils: [ncal] -w week-numbers are off by one since version 8.0
On 29.01.2010 12:57, Wesley Schwengle wrote: Michael Meskes wrote: severity 567316 normal thanks Severity: grave Justification: renders package unusable You're kidding right? I just don't get the joke. A calender which displays incorrect weeks is not usable, not to me at least. "Package unusable" means (in Debian bug terminology) that nothing works. You case is a normal bug: some functions are not usable, which is your case: the other programs works, and only in one locale, one program (cal) has some problem. I've noticed it also with the testing version, upgraded to the unstable version and the same bug is present. ... Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Are you sure the week numbering is incorrect for that locale? If so please point me somewhere to find out what the right week numberiung is for en_US. Yes, this is an international standard (ISO-8601 standard). No! International standard is not equal to en_US. If you check other part of ISO-8601 you will see much more differences. So it must be checked further what are the usual week numbers in US (e.g. from government documents or similar). But breaking a long existing standard is usually not a nice things to do, because probably a lot of users depends on current practice. ciao cate http://en.wikipedia.org/wiki/ISO_week_date http://en.wikipedia.org/wiki/ISO_8601 "The first week of a year is the week that contains the first Thursday of a year." On my stable box I have the same locale. LANG=en_US.utf8 LC_CTYPE="en_US.utf8" LC_NUMERIC="en_US.utf8" LC_TIME="en_US.utf8" LC_COLLATE="en_US.utf8" LC_MONETARY="en_US.utf8" LC_MESSAGES="en_US.utf8" LC_PAPER="en_US.utf8" LC_NAME="en_US.utf8" LC_ADDRESS="en_US.utf8" LC_TELEPHONE="en_US.utf8" LC_MEASUREMENT="en_US.utf8" LC_IDENTIFICATION="en_US.utf8" LC_ALL= Cheers, Wesley -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#563910: microcode.ctl: [PATCH] Consider using logging functions in lsb-base for init script
On 06.01.2010 10:35, Jonathan McDowell wrote: Please consider applying the attached patch to this package. It changes the init script to use the logging functions in lsb-base, which allows for easier customisation of system boot message format. I've also corrected a couple of spelling mistakes in the init script at the same time. Ok, thanks. But I think I should also add lsb-base as pre-dependency, right? giacomo Thanks, J. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (750, 'testing'), (500, 'testing-proposed-updates') Architecture: i386 (i686) Kernel: Linux 2.6.32.2 (PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages microcode.ctl depends on: ii debconf [debconf-2.0] 1.5.28 Debian configuration management sy ii libc6 2.10.2-2 GNU C Library: Shared libraries ii makedev 2.3.1-89 creates device files in /dev ii module-init-tools 3.11-1 tools for managing Linux kernel mo ii udev 149-2 /dev/ and hotplug management daemo Versions of packages microcode.ctl recommends: ii intel-microcode 0.20090330-1 Processor microcode data file for ii wget1.12-1.1 retrieves files from the web microcode.ctl suggests no packages. -- debconf information: * microcode.ctl/check-new: true -- To UNSUBSCRIBE, email to debian-bugs-dist-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
Thorsten Glaser wrote: 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.) Why not? Note that usual functions work on bytes, not on characters, and on POSIX utilities the old/classical options work on bytes by default. POSIX introduced new options for characters. E.g. the -c in 'wc' means really bytes, not characters (which is given by -m). Not so logical, but compatible with the expected old behaviour. POSIX was discussing if is is "legal" to have a UTF-8 POSIX/C locale. IIRC the doubts was about the language in the standard, not about real problems. OTOH they acknowledged that real bugs could appear. OTOH I use by default the UTF-8 locale, because I don't expect that Debian will corrupt my data. And I think system utilities will do the right things with locale. I start to think that moving C to UTF-8 will be the real simpler and faster way to *hide* most of the encoding bugs. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#547809: bauble: manipulates site-packages/ directly, failing with Python 2.6
ACK the patch and the NMU. Thanks! I really had to solve myself the bugs (and a lot earlier). ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#494429: [Pkg-hpijs-devel] Bug#494429: hplip: hp-check won't detect cups version : should be error or warning ?
Hello Mark,
Mark Purcell wrote:
Version: 3.9.8-1
On Sunday 01 November 2009 19:44:47 Giacomo A. Catenazzi wrote:
Hello,
this is a moer general problem:
hp-check check the wrong things (or the package dependencies are
wrong).
hplip now will advise if it is a run time checks or build time checks:
Really I mean only the runtime dependencies, and IMO these are:
or wrong checks (thus misleading) or wrong dependency on debian/control.
Try to install hplip in a new minimal system (without gnome and KDE):
hp-check -r will give a lot of errors in dependencies.
Note: hp-check can be run in three modes:
1. Compile-time check mode (-c or --compile): Use this mode before compiling the HPLIP supplied tarball (.tar.gz or .run) to determine if the proper
dependencies are installed to successfully compile HPLIP.
2. Run-time check mode (-r or --run): Use this mode to determine if a distro supplied package (.deb, .rpm, etc) or an already built HPLIP supplied
tarball has the proper dependencies installed to successfully run.
3. Both compile- and run-time check mode (-b or --both) (Default): This mode will check both of the above cases (both compile- and run-time
dependencies).
In this case:
hp-check execute "cups-config --version", but this command is available
only on cups-dev.
Checking for dependency: CUPS devel- Common Unix Printing System development
files...
error: NOT FOUND! This is a REQUIRED/COMPILE TIME ONLY dependency. Please make sure that this dependency is installed before installing or running HPLIP.
No, I mean line 326 of hp-check:
:log.info(log.bold("Checking for CUPS..."))
:cups_ok = True
:
:status, output = utils.run('lpstat -r')
Note: this command prints also a "scheduler is running", which is IMHO
not so nice and newbies friendly.
:if status == 0:
:log.info("Status: %s" % output.strip())
:else:
:log.error("Status: (Not available. CUPS may not be installed or
not running.)")
:cups_ok = False
:num_errors += 1
:
:if cups_ok:
:status, output = utils.run('cups-config --version')
:if status == 0:
:log.info("Version: %s" % output.strip())
:else:
:log.error("Version: (Not available. CUPS may not be
installed or not running.)")
:cups_ok = False
:num_errors += 1
This part last check is wrong: CUPS is installed, but the program uses
a cups-dev command. IMHO it should get the CUPS version using
an other method.
hp-check is only informative, but IMHO could give trouble to users
(as far I saw googling when solving my printer problem).
ciao
cate
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#494429: hplip: hp-check won't detect cups version : should be error or warning ?
Hello, this is a moer general problem: hp-check check the wrong things (or the package dependencies are wrong). In this case: hp-check execute "cups-config --version", but this command is available only on cups-dev. On some other dependency checks, hp-check doesn't check for the plain subsystem libraries, but already the gnome/gtk library links. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#552757: debian-policy: all caps "must"
Jakub Wilk wrote: * Giacomo A. Catenazzi , 2009-10-29, 10:16: "must" is a quite common word in the Debian Policy: For consistency, I'd do s/MUST/must/. But not automatically. On RFC usage "must" is different from "MUST", so you SHOULD distinguish the normative "MUST" and with the non normative "must". The Debian Policy is not an RFC. A lowercased "must" is normative, see section 1.1. oops. I read your change in the wrong way. So I agree with your change. BTW the sentence about must (in 1.1) starts with "In the normative part", and it is not is not always simple to distinguish the normative with the informative part (but such problems are being slowly solved, removing old non-normative text from main text). ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#552757: debian-policy: all caps "must"
Jakub Wilk wrote: "must" is a quite common word in the Debian Policy: For consistency, I'd do s/MUST/must/. But not automatically. On RFC usage "must" is different from "MUST", so you SHOULD distinguish the normative "MUST" and with the non normative "must". And BTW if we do such change, we SHOULD do also for the other all-caps terms: MUST NOT, SHOULD, SHALL, ...). ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#391836: debian-policy: New virtual package: cron-daemon
Raphael Hertzog wrote: On Wed, 14 Oct 2009, Russ Allbery wrote: Do both of our proposed cron daemons support that same syntax? (Does anyone here use bcron to comment on that?) bcron supports the */n syntax, but not @reboot and the other @*. See http://manpages.debian.net/cgi-bin/man.cgi?query=bcrontab&sektion=5 Hm. I wonder how many packages that ship cron.d files expect the @* stuff to work. If none, then maybe we should document that packages shouldn't rely on it. Everything other than @reboot is trivial to replace. @reboot is a lot trickier, although I suspect most packages use an init script. As a user, I got used to rely on @reboot to start services (like an irc proxy). And I have used it in packages (outside of Debian though) as well because init scripts are a pain nowadays compared to this simple solution (need to write meta-information to order the boot, etc). It would be nice if we could mandate its support. But OTOH @reboot has a "feature" which could confuse users: @reboot (on std cron) is called sometime earlier as expected in the init.d sequence. And I think the new dependency based init it could make it worse. IMO I really think that packages should use the init.d script instead of rely @reboot, allowing @reboot only for sysadmin: better to have a unique method for "init.d"-like scripts, and to use the full features of new booting system. But in this case we doesn't need @reboot in the policy. In the other case, I think we need to specify in policy when @reboot is called, and which services should be available. ciao cate PS: priority of cron: S89 (old style) and "$remote_fs $syslog $time" new style. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#549910: debian-policy: Specify requirement in terms of upgradeability, interface stability
Raphaël Hertzog wrote:
Package: debian-policy
Version: 3.8.3.0
Severity: wishlist
We have some unwritten packaging rules and it would be good to write them
down even if some of them appear to be obvious to most of us. I think in
particular to stuff like:
- a package must at least be upgradable from one stable release to the next:
- transitional packages are required when the software is renamed
- {pre,post}{inst,rm} snippets dealing with upgrade issues must be kept
for at least one release (but it's better to keep them for 2-3
releases)
I agree
- a package must provide some interface stability (names of programs,
ABI/API of libraries, location of data files, etc.) when other packages
depend on it. In that case, any change must be coordinated and
appropriate dependencies must be added. It should give examples of
Breaks:, bumped Depends when an change is made in a non-backwards
compatible way, temporary compatibility symlinks, etc.
I find difficult to implement it in policy in a clear way. We already have
nearly the same requirement for ABI/API in libraries: the package name must
contain the SOVERSION.
If we add such requirement, I would change chapter 8 from
"Shared libraries" into "Shared libraries and common files" and adding
a general stability suggestion.
BTW I find no reference in policy about the NEWS.Debian file. It would
nice to require to document (at last for one stable release) all (also
user visibe API/ABI) incompatibilities in such files.
ciao
cate
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#549834: Bug#549816 and #549...@bugs.debian.org (g15daemon-audacious and g15macro): FTBFS: libtool: link: `/usr/lib/libg15.la' is not a valid libtool archive
Yes, thanks you for remind me to publish the new g15daemon. On removing the *.la files I used a shortcut, but than I forgot to upload the new version of g15daemon without .la file (and references to no more existent libg15 la file. I'll upload the new version of g15daemon in next few days, and I'll check/upload the other g15 packages, to finally remove all .la dependencies from my packages. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#549699: microcode.ctl: update-intel-microcode downloads older microcode than latest
Hajo Möller wrote: Hello, update-intel-microcode gets the last mentioned microcode instead of the lastest one, as the RSS feed currently mentions two firmware files and sed failing to use non-greedy patterns. The attached patch uses perl to parse the wget output, there's no need to add perl-base to microcode.ctl's dependencies, as it depends on debconf which depends on perl. Ok, your patch works (and it fixes also the 201x problem). About perl-base: no. When a program uses an other package e.g. perl, it must declare it as dependency. I see it as documentation, but it is also more robust in case of change on the dependency package (note: there exists a cdebconf (in C), and maybe someone will write it in an other language). Anyway in this case (perl-base) it is not needed because perl-base is "Essential: yes", and your simple script doesn't need a particular version of perl-base. In next days I'll upload your fix, along some other fixes, thanks for the patch. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#532456: Are these licenses DFSG?
Florian Weimer wrote: * MJ Ray: cate wrote: Eugen Dedu wrote: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532456, about licenses I think there is a problem in terminology. AFAIK (but IANAL), the "any use" doesn't include distribution of software. For this reason I think it is safe to classify it as non distributable, It seems that the author intention was to interpret the "any use" in a wider manner, but this is not legally safe for us. I'd agree with that unless someone can tell me why not. Surprise, surprise---it does include distribution: ok, good! So IMHO (IANAL) the license is free according DFSG. Unfortunately this statement was not in the original bug report. The other licenses in bug report seems OK, but also this time I read only the bug report + responses: I've not looked in the sources ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#532456: Are these licenses DFSG?
Eugen Dedu wrote: Hi, We have a bug report, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532456, about licenses of various plugins of opal package, and I do not know if the licenses involved are DFSG-free. Could you please tell me if these plugins are allowed to be in debian main? The main license: - Copyright 1992, 1993, 1994 by Jutta Degener and Carsten Bormann, Technische Universitaet Berlin Any use of this software is permitted provided that this notice is not removed and that neither the authors nor the Technische Universitaet Berlin are deemed to have made any representations as to the suitability of this software for any purpose nor are held responsible for any defects of this software. THERE IS ABSOLUTELY NO WARRANTY FOR THIS SOFTWARE. As a matter of courtesy, the authors request to be informed about uses this software has found, about bugs in this software, and about any improvements that may be of general interest. Berlin, 28.11.1994 Jutta Degener Carsten Bormann - I think there is a problem in terminology. AFAIK (but IANAL), the "any use" doesn't include distribution of software. For this reason I think it is safe to classify it as non distributable, It seems that the author intention was to interpret the "any use" in a wider manner, but this is not legally safe for us. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#518199: debian-policy: virtual package names for doom-related packages
Manoj Srivastava wrote: Hi, The most recent version of this proposal was: --8<---cut here---start->8--- --- virtual-package-names-list.txt~ 2009-03-15 18:19:17.0 + +++ virtual-package-names-list.txt 2009-03-15 18:20:00.0 + @@ -179,6 +179,17 @@ scheme-srfi-55 Scheme interpreter accepting the SRFI 55 language extension +Games and Game-related +-- + + doom-engine An executable Doom engine + boom-engine An executable Doom engine supporting the 'boom' + feature-set + doom-wadThe data component of a Doom game, compatible with + the original Doom engine + boom-wadThe data component of a Doom game, using features + from the "boom" engine family + Old and obsolete virtual package names -- Note, that no other package then the ones listed here should use --8<---cut here---end--->8--- seconded cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards
Russ Allbery wrote: "Giacomo A. Catenazzi" writes: Do we really need to use the triplets? Do you see some possible cases where we must really specify the first part? Isn't someone working on a klibc port? That would require using the triplet. Does the new dpkg support also the triplets? Personally I would move it in a footnote, as "future direction". If dpkg already supports it, it certainly shouldn't be a future direction. ok. fair enough. BUT: the original proposal and this proposal contain only the duet: + A package may specify an architecture wildcard. Architecture + wildcards are in the format os-any and + any-cpu. Internally, the package The triplets are listed only in the footnote (which is IMHO confusing). But if we want to support the klibc (and in general different libc ABI), as it seems nice, this proposal should be more explicit about the use of triplet, allow them in the usual places, and policy should set the default value. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#547186: g15daemon: Random crashes
Could you check in /var/log/syslog, if at the time of the crash there is some additional information? The daemon is terminated with SIGKILL, and this signal should not be caused by the daemon itself (SEGSEGV, SIGILL, SIGBUS, etc. are delivered for internal errors). So I think an external program/setting will send such signals, on passing some limits or with invalid permissions. So I expect ulimits, acct, selinux, etc to send the signal. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards
Manoj Srivastava wrote: + + + A package may specify an architecture wildcard. Architecture + wildcards are in the format os-any and + any-cpu. Internally, the package + system normalizes the GNU triplets and the Debian + arches into Debian arch triplets (which are kind of inverted GNU + triplets). So when matching two Debian arch triplets, whenever an + any is found it matches with anything on the other side, + like in: + + gnu-linux-i386 == gnu-linux-any + gnu-kfreebsd-amd64 == any-any-amd64 + + And for example any is normalized to any-any-any. + + Do we really need to use the triplets? Do you see some possible cases where we must really specify the first part? Does the new dpkg support also the triplets? Personally I would move it in a footnote, as "future direction". Now we miss only the "all [linux-any]" like constructs. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#547272: policy 5.6.16 - Format field: Is it really 1.5?
Package: debian-policy Version: 3.8.3.0 In policy 5.6.16, about Format field I read: : This field specifies a format revision for the file. The most current format : described in the Policy Manual is version 1.5. The syntax of the format : value is the same as that of a package version number except that no epoch : or Debian revision is allowed - see Version, Section 5.6.12. I've some doubts: 1- what is the 1.5 format ? Googling it seems that few packages *had* such version, and some references give it as Wig&Pen format (which it is really 2.0). 2- Policy really specify the format (as 1.0 or 1.5)? It seems that the format is not specified in policy, but only by dpkg-source. So I propose to remove the second sentence. BTW how will be the new version? "Format: 3.0" which is valid according such paragraph "Format: 3.0 (native)" which seems the proposed form in dpkg-source, but invalid in policy In such case we should adapt the policy. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#547186: g15daemon: Random crashes
Could you send also the output of grep g15daemon /var/log/syslog thanks cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#546877: depends on extra package (makedev)
Xavier Bestel wrote: Package: microcode.ctl > Version: 1.17-12 > Severity: serious > Justification: Policy 2.5 your package depends on "makedev" which is an "extra" packages. That's a violation of Debian Policy 2.5: "Packages must not depend on packages with lower priority values (excluding build-time dependencies). In order to ensure this, the priorities of one or more packages may need to be adjusted." Moreover, this makes "makedev" un-uninstallable and so blocks the sysv-rc conversion to dependency based boot. I don't think this is a bug, and I don't think your analysis is correct: microcode.ctl depends on "udev | makedev", thus it depends on makedev ONLY if udev (a package with higher priority) is not installed, and this happen only if user choose not to follow the priorities. Also the second part: if a system have udev installed, the package makedev could be removed. (on the countrary, please fill the bug on dpkg or apt). I'll ask other maintainer if my interpretation is right, before closing or resolving the bug. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#541780: g15daemon spurious restarts due to udev rules.
pancho horrillo wrote:
> When I run mplayer, or openarena, somehow udev reacts as if the device
> (Z-10 USB speakers) was reconnected, and calls
strange. On my system I don't see such things (with vlc and mplayer).
udev rules are still an hack, because I had not yet time to correct
the g15daemon code.
But I'm not so sure that this hack is the originator of your bug.
Could send me the output of:
lsusb | grep -i logitech
("lsusb" is in package "usbutils")
> ACTION=add /etc/init.d/g15daemon udev
> (as per /etc/udev/rules.d/z60_g15daemon.rules)
>
> I see this in dmesg:
> input: G15 Extra Keys as /devices/virtual/input/input8
> input: G15 Extra Keys as /devices/virtual/input/input9
> input: G15 Extra Keys as /devices/virtual/input/input10
> input: G15 Extra Keys as /devices/virtual/input/input11
> ...
>
> (Each line happens after each g15daemon restart.)
Are there some errors in /var/log/user.log ?
Are there some other errors in dmesg /var/log/syslog.log
(regarding g15)? (I hope to find a segfault).
> Hope that it helps.
I don't know ;-) It is a very strange behaviour. Do you have some
special setting for audio or in mplayer?
Do you run some virtual machines with the same keyboard?
I would like to reproduce the bug in my machine.
I'll send you in next days a verbose init.d script for debugging:
I whouls understand because running mplayer will cause a udev
action.
ciao
cate
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531699: ITP: apt-offline -- Offline APT Package Manager
Ritesh Raj Sarraf wrote: Just for the record, apt-offline is being tailored for inclusion into Debian at: http://git.debian.org/?p=users/rrs-guest/apt-offline.git;a=summary Hello, I find interesting your program. I'm one of the maintainers of apt-zip, which do similar tasks, but: - it is not really developed since some years, - it lack the support of an high level language (it is written in shell), thus it is difficult to do real (complex) works - we (maintainers) lack interest to continuing developing apt-zip BTW I also written a much shorter "apt-remote" in python, but it is not complete and I have no intention to continue developing it. So, I can help you sponsoring and mentoring you to upload apt-offline in Debian. I think also that we could remove apt-zip (I think we will provide a wrapper between the old apt-zip interface and the new tools). ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#541306: g15daemon: Fail to install when required hardware is not present
Petter Reinholdtsen wrote: I just tried to install the g15daemon package on a Dell Latitude D505, and there the package failed to install because the init.d script return an error exit code (1). The messages sent to syslog indicate that the daemon failed to start because the supported hardware was not found. I belive it should be possible to install the package even if the supported hardware is missing. Yes, it is a know problem, and it was one of the reason of my recent post in debian-devel. Few hours ago I uploaded a new version, which finally use udev, and I hope I corrected all the possible error, when hardware is not present (but I still need to test it extensively). Also, the LSB header in the init.d script lack a dependency on $syslog, making the daemon start before syslog is available. As the daemon log to syslog, its init.d script should depend on $syslog. Ok. I forgot this. ciao cate PS: next week I'll do more testing about the init.d script of this package (case without hardware, and with less common architectures) and about sysvinit -> insserv timing, but I wait for my null-modem cable -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#381511: Please have spell support aspell as a backend in addition to ispell
It should be easy to include support for aspell. Really using "spell -i /usr/bin/aspell" works as expected, using aspell instead of spell. But this should be done by default: if ispell doesn't exists, the program should try aspell. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#491295: latencytop can run only on i386 and amd64 only, not any
The new kernels support also other architectures. From latest kernel sources: arch/powerpc/Kconfig:config HAVE_LATENCYTOP_SUPPORT arch/sparc/Kconfig:config HAVE_LATENCYTOP_SUPPORT arch/arm/Kconfig:config HAVE_LATENCYTOP_SUPPORT arch/sh/Kconfig:config HAVE_LATENCYTOP_SUPPORT arch/s390/Kconfig:config HAVE_LATENCYTOP_SUPPORT arch/x86/Kconfig:config HAVE_LATENCYTOP_SUPPORT arch/parisc/Kconfig:config HAVE_LATENCYTOP_SUPPORT unlike powertop, latencytop don't requires hardware support, but it collects statistics from scheduler, so i expect newer kernel will support more architectures. So I'll retitle the bug: latencytop can run only on Linux ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539744: chroot to lenny /target in debootstrap segfaults
Frans Pop wrote:
This oneliner change would fix the issue as well:
+++ b/packages/base-installer/debian/bootstrap-base.postinst
@@ -88,7 +88,7 @@ install_base_system () {
# so make a backup to be restored later
copied_fstab=true
cp /target/etc/fstab /target/etc/fstab.orig
thus this should be a "mv"
- echo "# UNCONFIGURED FSTAB FOR BASE SYSTEM" >> /target/etc/fstab
+ echo "# UNCONFIGURED FSTAB FOR BASE SYSTEM" > /target/etc/fstab
fi
if [ "$PROTOCOL" = "http" ]; then
And it even makes more sense than the current code...
ciao
cate
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems
Aníbal Monsalve Salazar wrote: Package: wnpp Severity: wishlist Owner: Anibal Monsalve Salazar * Package name: libposix I still have doubts that this package is undistributable with this name, because of POSIX trademark (but DFSG allow us to change the package name). Note: It is not the case of posix-thread, where posix is used as attribute. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#534408: debian-policy: Installed-Size is defined as "kilobytes" but dpkg-gencontrol fills it in with kibibytes
Ben Pfaff wrote: Russ Allbery writes: Ben Finney writes: If you're going that far, please perform one of the following: s/rounded/fractions rounded up/ s/rounded/fractions rounded down/ s/rounded/fractions rounded to the nearest whole number/ to disambiguate the calculation. Does du guarantee to do one of those? The specification at http://www.opengroup.org/onlinepubs/009695399/utilities/du.html says: By default, file sizes shall be written in 512-byte units, rounded up to the next 512-byte unit. But this is an other case, and pretty historical. du indicate the disk usage in block. A file of one byte uses one entire block (but on few filesystems), thus to calculating the quota of a user, one needs the block count and not the sum of the file sizes. Anyway I agree that rounded up is safer. But I still not sure that it is correct. I would change: "It gives the total amount of disk space required to install the named package." to "It gives an indicative amount of disk space required to install the named package." because the field cannot give the real required disk space: - (we really round up the size of every file?) - On linux kernel the block size could be up to 4096 bytes (and it is filesystem dependent, thus unknown on packing time) - we install also directories (the disk space depends heavily on filesystems). thus I would prefer a *indicative amount* and maybe in a foot note the reason because we cannot put the real disk space. As alternative we indicate only the sum of file sizes, removing the "disk space required". ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533287: debian-policy: please clarify 10.7.4
Don Armstrong wrote: On Wed, 17 Jun 2009, Sune Vuorela wrote: so it seems that the "alternative" interpretation, is that "if there is a interface, then it must be used", but all that is wrapped in a "should", which is not as binding as a "must". While this section of policy could probably be clarified, violating a should directive of policy is almost always a bug. It may be a bug in the package, another package, or in policy itself. Still, somewhere in the train, something is suboptimal and should be fixed. I agree and section 1.1 is clear about this: "Non-conformance with guidelines denoted by should (or recommended) will generally be considered a bug, but will not necessarily render a package unsuitable for distribution." "These classifications are roughly equivalent to the bug severities serious (for must or required directive violations), minor, normal or important (for should or recommended directive violations) and wishlist (for optional items). " Thus violating a "should" could be a bug with important priority. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
Raphael Hertzog wrote: For the second argument: [ using bash ] $ type printf printf is a shell builtin $ dash $ type printf printf is a shell builtin There's no external executable needed. but also "echo -n" is recognized by these tools. I've interpreted the original bug report as a way to allow any conform shell to be used. OTOH it could be seen differently: as a way to educate user to write conform scripts, and to simplify the reading of script by non debian or non linux user. [But I'm pretty sure that we will fail this last point: IMHO it would port to lsb or other utilities similar to debhelper, thus still requiring some insight into Linux specific features] ciao cate PS: Anyway, it would be simple to move printf to /bin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#521918: pbuilder --build --binary-arch invokes 'build' target
Filippo Rusconi wrote: On Mon, May 11, 2009 at 02:11:18PM +0200, Julien Cristau wrote: On Mon, May 11, 2009 at 13:46:30 +0200, Lionel Elie Mamane wrote: No, policy is very clear on that: if you call the "build" target, you _must_ satisfy Build-Depends-Indep and Build-Conflicts-Indep: And policy is clearly not followed by any actual practice on this point. So that's as much a bug in policy as anything else (#374029). Cheers, Julien Well, but then, why have new packagers trained by studying the Policy? Because they should find errors in policy and report such bugs ;-) Really many bug of debian-policy are found by new maintainers, but unfortunately most of new maintainers are too shy to report bugs to debian-policy, just because they are *new* maintainers. Thus debian-policy still have many bugs. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#508644: new release goal default-mta?
martin f krafft wrote: [moving debian-rele...@l.d.o to Bcc, continuing discussion in bug log] also sprach Andreas Metzler [2009.05.04.1856 +0200]: FWIW as previously discussed on debian-devel starting with the lastest upload (4.69-10) exim4-daemon-light provides default-mta. Excellent. If there are no objections, I'll formulate a squeeze release goal and file the bugs. In this case, I'll really prefer that we setup an other virtual package (e.g. lsb-sendmail-cmd) and we start to distinguish where a MTA is required, and where only a sendmail command (with the minimal LSB interface) is required (which is the more frequent case). ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-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
Thorsten Glaser wrote: Giacomo A. Catenazzi dixit: 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. Yes, right. ASCII-7 characters need to be encoded as a single char (octet), with values between 1 and 127, but not necessarily with ASCII values. With a quick look, it seems that all locales implement are ASCII compatible charsets, which is also very nice for filename portability (also between users and system). Recently there was a short discussion in POSIX about locales which code "/" in a non stanrdard place, thus creating a lot of problems (also security related), but this is an other story. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-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
Thorsten Glaser wrote: Giacomo A. Catenazzi dixit: 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. This is good way to do things! 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. This means that we make few automatic regression tests ;-) But so, the UTF-8 requirement are a lot narrow than the rest of discussion. I think that we should provide some package that give pbuilder environment a UTF-8 environment. Or a debhelper (or like) utility that "construct it" for build needs. In this case "us_EN.UTF-8" is a sensible locale (we want to test 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). You had already a solution (but embedding in a standard utility is IMHO better, which hide the complexity, and show direct what you need). BTW the locale could be also a pathname, so no root power needs (i.e. for other tests in user gleba). 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. I agree that we must provide by default also a UTF-8, but I don't like "C.UTF-8". A solution: force all locales to have also the UTF-8 "brother", and force installation of such locale when user choose (at installation time) a non UTF-8 locale. "C" is not offered at installation time (but IIRC KDE offered at first run, some versions ago). For building env I prefer a "us_EN.UTF-8" (we need English to read logs) or build when needed (better because probably we need other locales to test, and probably some packages needs some Asian locale for building/testing) 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. C is not the default locale. "en_US.UTF-8" is the default (d-i of lenny, pressing only ENTERs). 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). But your case is very specific (to building package). And in these case we want a minimal build environment. Additionally it is for testing purpose, so you test UTF-8, other package maybe needs other locales. Anyway I agree that a UTF-8 locale could be installed by default (also on pbuilder), but I we need also a locale utility for debian/rules, and that user has the right UTF-8 locale (so for a generic user, not C.UTF-8, but xz_YW.UTF-8, if is normally using xz_YW) ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-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
Andrew McMillan wrote: On Wed, 2009-04-08 at 10:15 +0200, Giacomo A. Catenazzi wrote: So I've a question: what does UTF-8 mean in this context (C.UTF-8) ? It is not a stupid question, and the answer is not the UTF-8 algorithm to code/decode unicode. I'm still thinking that you are confusing the various meanings. And until I understand the problem, I cannot propose a solution. While it is true that the C locale is (already) a UTF-8 compatible locale, it provides no clues to the system for the encoding of characters outside that locale. We can all be pure about the C locale and believe that all characters have 7 bits, but we all know that reality is not like that. It's not like that even in the northern part of the content pair that 'ASCII' gets it's name from. I believe that Debian should endorse Unicode as the preferred method for mapping between numbers to characters. I do not expect there is any real argument against this, although I do understand that current versions of Unicode may not yet comprehensively/satisfactorily represent all glyphs in some languages. I think there is hope that these problems will eventually be ironed out. There are, of course, a number of systems for encoding unicode characters, but I do not seriously expect that anyone is recommending that Debian should use UTF-16, UTF-32 (or, $DEITY forbid, Punycode :-) as something which should be available everywhere. > So given a character which is outside of the 0x00 <= 0x7f range, in an environment which does not specify an encoding, I would like to one day be able to categorically state that "Debian will by default assume that character is unicode, encoded according to UTF-8". I agreem but the last sentence. "Debian will use as default unicode, encoded according to UTF-8", but not *assume*. It is again portability. Let (old) programs to works also on the future Debian. Note that the problem with ASCII7 arise also to other encoding. We are Europeans or Americans, so UTF-8 seems an easy transition, but for people who use other non-ASCII based encoding, this could be very hard. If we start assuming UTF-8 we cause a lot of troubles in other continents. Files which were readable in Lenny will be readable in future only using a command line utility, what a nightmare for our users! So if your first paragraph are a nice objective, we should not add "assumptions" that causes more troubles. I think the opposite direction will be the best: let assume less about locale, and let user and system to find and choose the right encodings. I.e. let me read file with "less" in many encodings (heuristic, magic strings, or command line argument), instead of building "less" to assume UTF-8. We have the same objective, but two different ways. And because I used and use a lot of different systems, I think my way is the best. In such an environment, with a C.UTF-8 encoding selected, when I start a word processing program and insert an a-umlaut in there, I would expect that my file will be written with a UTF-8 encoded unicode character in it. I would not expect that if I sort the lines in that file, that the lines beginning with a-umlaut would sort before 'z'. I would not expect that if I grep such a file for '^[[:alpha:]]$' that my a-umlaut line would appear. I think nobody should use "C" or "C.UTF-8" as user encoding. And I really hope that Debian will try to convince user to use a proper locale. At present I don't believe that this does happen. At present we continue to perpetuate encodings such as ISO 8859-1 in these situations, making pain for our children and grandchildren to resolve. No, I think Debian is really pushing UTF-8, and fortunately we can distinguish automatically ISO 8859-1 from UTF-8 (but few "degenerate" cases). This could help. But world is not only ASCII based, so mandate UTF-8 will causes more trouble. I think we can do more heuristic to find the right encoding, and encouraging programmers to annotate file with the right encoding (you see more and more file with tell explicitly the editor about the encoding). So as a first step in this process of 'cleaning up our world', this bug is proposing a smaller change than that, and a smaller change than I believe you think it is. It helps you, it helps Europeans and Americans, but it doesn't help writing program that all world could use (also to read older documents). Setting a real locale (not "POSIX" or "C") solve this, and BTW is what Debian is doing. C.UTF-8 will create a new locale, not destroying one, so not going in the right direction. 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. People will naturally continue to be free to uninstall it,
Bug#522776: locale dependend compilation
Ok, maybe I found the problem. Giacomo A. Catenazzi wrote: > No ;-) Ok, it take me some modifications of your program and looking to POSIX to discover the reason. You forget to check error codes. In this case we have "Invalid or incomplete multibyte or wide character" in the non UTF-8 locale. So looking to POSIX: "Wide-character codes for other characters are locale and implementation-defined." so you (and me) compiled the code with UTF-8, so in binary there is different wchar representation. Which is invalid on non-UTF-8 locale. Note that that it is locale dependent, so same charset with different language could give different results (I don't know if there are such cases on glibc). So it means that NO portable programs could use constant (i.e. as fixed value in sources) wchars and wstrings, because a compiled program has now way to distinguish a wstring build at compiler time and a wstring from outside, thus with possible two different locales/charsets. [GCC uses as default UTF-16 or UTF-32 for wchar, according to the space need for chars in current locale] BTW we have a similar problem with "normal" strings. This is very unfortunate, and it is *worse* than the initial problem. Changing locale will not solve this, but probably will reduce the visibility of the error. [no locale specified means UTF-8 for GCC]. So maybe we need to specify the locale to be passed to debian/rule or the parameter to gcc, in order to have a (default) fix source encoding. But this doesn't not solve the problem. An encoded UTF-8 or UTF-32 (for wchar) is not decoded correctly on non UTF-8 terminals. But in this case we have iconv() function (because NOW we know the inizial encoding), to convert constant-string to the right locale. So: programs that use constant wchar or string with chars outside ASCII must be compiled with the right encoding (ev. with right locale), specified in debian/rule (or every developer will see a different output). Such program should convert the string to the right locale, before to print it to terminal. Alternatively, the string must be put outside source code, and read from a file. The iconv() apply also in this case. PS: requiring "us_EN.UTF-8" as default to debian/rule seems also nice, so logs can be read from all developers. Possibly also "C" in UTF-8 could be good. Such "C" should have only charset UTF-8 and not other additional meaning to characters outside ASCII-7. But this should be carefully tested: I really things that there are existing wrong assumption and cases we forgot. So ok: I think I've understood the problem (but part of the bug is in the program / Makefile). ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-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 wrote:
On Tue, Apr 07, 2009 at 10:36:20AM +0200, Giacomo A. Catenazzi wrote:
>> Roger Leigh wrote:
I can't help but feel that your reply completely missed the
purpose of what I want to do, and why. I hope the following
response clears things up.
I know that I missed the original point, but IMHO you was and still
misunderstandings locale, charset and C language behaviour.
So I'm trying to explain you how these things works, and after
this, we can go to the real problem.
[Note: maybe I am on the wrong side. Often standards are not
so consistent on these behaviours, and thus maybe I interpreted them
wrongly]
- input charset is the source charset (used to parse C code)
- exec charset is the charset of the target machine (which run the program).
That's pretty much what I said.
- C99 must support unicode identifier (written with \u or in other
non portable implementation defined way)
OK. But that's really nothing to do with the fact that you can use
UTF-8 sources directly. It's akin to having to support trigraphs,
but we don't use trigraphs because they are bloody annoying and nowadays
competelely unnecessary. But mainly, it doesn't affect the exec charset
whether you use UTF-8 encoded sources or \u.
ok.
- standard libraries can use locales (but only if you initialized the locale),
but not all the functions, not all uses.
- wide charaters are yet an other things (as you note in your example,
the wide string is not in UTF-8, but I think UTF-32)
Same input and exec charset really means: don't translate strings
(e.g. in
if(c = 'a') printf("bcde\n");
'a' and "bcde\n" will have the same values as in the input file, else
it will put in binary the representation of exec charset)
Of course. However, the test program I posted showed what that if the
locale has been appropriately initialised, there is an additional
translation between the exec charset and the output charset specified
by the locale (see the Latin characters correctly preserved and output
as ISO-8859-1 in an ISO-8859-1 locale).
No ;-) Ok, it take me some modifications of your program and
looking to POSIX to discover the reason.
You forget to check error codes. In this case we have
"Invalid or incomplete multibyte or wide character" in the
non UTF-8 locale.
So looking to POSIX:
"Wide-character codes for other characters are locale and
implementation-defined."
so you (and me) compiled the code with UTF-8, so in binary there is
different wchar representation. Which is invalid on non-UTF-8 locale.
Note that that it is locale dependent, so same charset with different
language could give different results (I don't know if there are such
cases on glibc).
Usually the interpretation of bytes is done by terminal, not by compiler.
It's done at several points:
compiler: source->exec
runtime: locale-dependent exec->output (and optional use of gettext)
terminal: output->display
to go to the point: what is the problem in mksh?
At which level it fails?
yes, in a perfect world we need only one charset (and maybe only
one language and one locale). From all the proposals to reach this
target, unicode and UTF-8 seems the best solution.
But... for now take care about locales and don't assume UTF-8,
or you will cause trouble with a lot of non-UTF-8 users.
Converting locale (from non-UTF-8 to UTF-8) is simple for
English and few European languages, but it is a tedious work
for many user: it need a "flag day", in which I should convert
all my files to UTF-8 or annotate every file with the right
encoding (most of editors and tools understands such annotations).
I have never *ever* suggested that we only use one charset. I'm only
suggesting that the *C locale* must be UTF-8 in order to allow for
full UTF-8 support. Normal user locales can use whatever charset
they like.
(see the other mail: what do "full UTF-8" mean)
Non-UTF-8 users won't be disadvantaged because the UTF-8 exec charset
will be recoded to their locale-specific output codeset, either by
libc or gettext.
Not sure to understand. Debian is moving all file to UTF-8
(manual pages, documentation, debian control files, ...).
So I totally agree.
But was not the point of the original proglem?
The C locale is special in that normal users won't use it, but
system programs and code needing locale independence do use it.
Any program wanting to work correctly in a C locale must only use
ASCII or it *breaks*. This means we are /de facto/ restricted to
ASCII unless we take special effort to work around the fact (and
this was the point of my l10n/i18n comments above).
Most programs do need to work correctly in a C locale, and so can't
use UTF-8 either as a source or exec charset. This is a severe
limitation.
No. "locale" is not really charset. A program
Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
Roger Leigh wrote: On Tue, Apr 07, 2009 at 09:24:38PM +0200, Adeodato Simó wrote: + 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? I’m genuinely interested if that would behave any different to what you said (unsetting all, setting LC_CTYPE). % sudo localedef -c -i POSIX -f UTF-8 C.UTF-8 % LANG=C.UTF8 locale charmap UTF-8 % LANG=C locale charmap ANSI_X3.4-1968 This appears to work correctly at first glance. 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). POSIX doesn't mandate "C" to be ASCII7. BTW ASCII7 is a subset of UTF-8, so what would be different with normal "C"? I don't expect any differences on any program (which are POSIX compatible). The output characters will still be only on the c<128 range. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-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
Andrew McMillan wrote: On Tue, 2009-04-07 at 22:32 +0200, Adeodato Simó wrote: It is my impression that more packages than mksh could use an UTF-8 locale at build time (I’m afraid I don’t have pointers, but I’m sure I’ve come across at least a couple). Wouldn’t it be just better to change Debian’s default to make an UTF-8 locale available by default, rather than to force all those packages to play tricks with LOCPATH? I too would really like to see a UTF-8 locale available by default, and would prefer to see this be the C.UTF-8 locale, which doesn't screw with the collation / character type settings like any other UTF-8 locale would. It seems to me that the consensus here is that having a UTF-8 locale available is a good idea and I don't hear any very strong argument against such a change. Consequently I think we should move on from the discussion and start working out a patch to resolve this in policy. So I've a question: what does UTF-8 mean in this context (C.UTF-8) ? It is not a stupid question, and the answer is not the UTF-8 algorithm to code/decode unicode. I'm still thinking that you are confusing the various meanings. And until I understand the problem, I cannot propose a solution. - terminals should be sensible to charsets, on choosing how to display things - programs should be sensible to locales (topic of this discussion): the locales provides some charsets dependent strings, and interpretation of the various characters, but (usually) they MUST NOT translate characters. Anyway: The locale C is already a UTF-8 compatible locale. No? so what it misses? - other alphabetic, numeric, currency, whitespace characters? But not UTF-8 local provides all characters: they define only the needed range for the language [see wikipedia, which should code UTF-8 as binary for this reason]. The "C" "spoken" language require only ASCII-7 (or maybe only a subrange of it). So why we need further characters? Note: whitespace are restricted in "C" locale by POSIX, in only two values We could use charset UTF-8 for C locale, declaring unused/illegal all c > 127. Whould this solve the problems with mksh? I don't think so, so what you need in this C.UTF-8? I still think that "en_US.UTF-8" is the right default (note: I'm not a US citizen, nor I speak English). The installation will install the correct locale, so the en_US period is very short (we'll dominate them ;-) ). On debootstrap/pbuild/... things are different. But if it this the problem, let check a solution for building environment (and I still think that in this env "en_US.UTF-8" could be nice. But I'll prefer a simple basic ASCII-7 "C" for basic/plain build, and only after packager thinks if it is a bug or a feature to have a specific build with UTF-8, it should manually set it. Why build need to depend to a locale? UNIX way is to allow to compile things for remote (maybe other OS, other arch) system. For testing? So why not test various locales (UTF-8, but also other non ascii based encodings) ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-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 wrote: > I wasn't aware that this level of checking was performed, though it does make sense. But, does it not reject non 7-bit input in the C locale for completeness? Should tools doing "raw" I/O not be using lower level interfaces such as fread() and fwrite() rather than the "formatted" print functions which are specified to behave in a locale-dependent manner? printf is not locale dependent, but on numeric display (and eventually on some extensions). ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-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 wrote:
On Mon, Apr 06, 2009 at 11:09:17AM -0700, Steve Langasek wrote:
On Mon, Apr 06, 2009 at 05:33:35PM +, Thorsten Glaser wrote:
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.
You can build-depend on the locales package and generate the locales you
want locally, using LOCPATH to reference them. There's no need for Debian
to guarantee the presence of a particular locale ahead of time -
particularly one that isn't actually useful to end users, as C.UTF-8 would
be.
I think that it would be very useful, I'll detail why below.
The GCC toolchain has, for some time now, been using UTF-8 as the
internal representation for narrow strings (-fexec-charset). It has
also been using UTF-8 as the default input encoding for C source code
(-finput-charset). This means that unless you take any special
measures, your program will be outputting UTF-8 strings for all file
and terminal I/O. Of course, this is backward compatible with ASCII,
and is also transcoded automatically when in a non-UTF-8 locale. I've
attached a trivial example. Just to be clear: this handling is
completely built into GCC and libc, and is completely transparent.
Hmm. Warning, you confuse some terms.
- input charset is the source charset (used to parse C code)
- exec charset is the charset of the target machine (which run the program).
- C99 must support unicode identifier (written with \u or in other
non portable implementation defined way)
- standard libraries can use locales (but only if you initialized the locale),
but not all the functions, not all uses.
- wide charaters are yet an other things (as you note in your example,
the wide string is not in UTF-8, but I think UTF-32)
Same input and exec charset really means: don't translate strings
(e.g. in
if(c = 'a') printf("bcde\n");
'a' and "bcde\n" will have the same values as in the input file, else
it will put in binary the representation of exec charset)
I expect that your program will run fine (i.e. really no changes: the
same binary output), if you use tell GCC that you use any other ASCII-7
derived 8-bit encoding (both for input and exec charset).
printf/wprintf uses locale only for numeric representation.
Usually the interpretation of bytes is done by terminal, not by compiler.
Now, this will work fine in all locales *except for C/POSIX*.
Obviously the charsets of some locales can't represent all the
characters used in this example, but the C library will actually
transcode (iconv) to the locale codeset as best it can. Except for
C/POSIX.
Now, why is this needed?
If I write a program, I might want to use non-ASCII UTF-8 characters
in the sources. We have been doing this for years without realising
since GCC switched to UTF-8 as the default internal encoding, but
simply for portability when using the C locale we are restricted to
using ASCII only in the sources,
Really minimal C charset is smaller than ASCII (a portable program
must not have "$" and no "@", plus C supports also smaller charset,
with trigraps [preprocessor] and/or new bigraphs [compiler])
and then a translation library such
as libintl/gettext to get translated strings with the extended
characters in them. This is workable, but it imposes a big burden on
translators because I might want to use symbols and other characters
which are not part of a /language/ translation, but need adding by
each and every translator through explicit translator comments in the
sources. This is tedious and error-prone. If the sources were UTF-8
encoded, this would work perfectly since I could just use the
necessary UTF-8 characters directly in the source rather than abusing
the translation machinery to avoid non-ASCII codes. A UTF-8 C locale
thus cuts out a big pile of cruft and complexity in sources which only
exists to cater for people who want to run your code in a C locale!
And the translators can completely ignore the now no longer needed
job of translating special characters as well doing as the actual
translation work, so the symbol usage is identical in all
translations, and their job is much easier.
yes, in a perfect world we need only one charset (and maybe only
one language and one locale). From all the proposals to reach this
target, unicode and UTF-8 seems the best solution.
But... for now take care about locales and don't assume UTF-8,
or you will cause trouble with a lot of non-UTF-8 users.
Converting locale (from non-UTF-8 to UTF-8) is simple for
English and few European languages, but it is a tedious work
for many user: it need a "flag day", in which I should convert
all my files to UTF-8 or annotate every file with the right
encoding (most of editors and tools understands such annotations).
So for now we support UTF-8, we try to set UTF-8 default to
new users, and UTF-8 is the encoding for debia
Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
Thorsten Glaser wrote: 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.) I don't understand the problem. In POSIX the choice of locale and charset is done by user (in the list of system supported locales/charset). The default is the locale "C" (alias "POSIX"). 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. Why does mksh need UTF-8? What is wrong with other charsets or with simple ASCII7? Debian target is that all program should support (and possibly display) UTF8 inputs and outputs. Mandate UTF-8 as default (instead of C/POSIX) would probably be worse (and non POSIX conformant). About "C.UTF-8". I really think it is an error. If a user need a locale, it should set it with the right language (maybe "en_US.UTF-8"). "C" doesn't mean "default" or "English", but it specify a specific output, usually for automatic processing. (Check POSIX standard, and output requirement on "C" locale). en_US could be more user friendly, but "C" means "old sysadmin gergo". So, if I interpret right your problem, the right solution is: - mksh should allow all locales and charsets 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. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#521810: debian-policy: Document user defined fields starting with X-
Raphael Hertzog wrote: After having accepted the patch, I wondered where it should be documented and Nils pointed me to the policy section. So I asked him to submit a bug here. I fail to see any problem with telling people outside of Debian that they can freely use "X-" fields for their private use. You might want to say to DD that are inventing new fields, that they should not make them start with X- if they ever expect it to be standardized. You should document it in dpkg-deb, but I don't think policy is the right place (but ev. in a footnote). A package that uses: X-foo: bar is policy compliant? Could/should be installed on official Debian archives? IMHO the answers are no. Realted problems: - so which policy item would violate a such package? - having an x- field and a Standards-Version field is wrong? So I think such text in policy would confuse the developer, and I don't like having something like that in policy: "user defined field are prefixed by x-, but MUST NOT be used on official packages". ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#521810: debian-policy: Document user defined fields starting with X-
Nils Rennebarth wrote: Package: debian-policy Version: 3.8.0.1 Severity: wishlist Please add something along the following lines to the section 5.7 "User defined fields" to the debian policy manual: Usually, unknown fields are iggnored by the debian packaging system. To avoid conflicts of user defined fields with field that may be used by debian in the future, we suggest to use field names starting with X- (so you need to put X[BCS]-X-foo into the control file) which are guaranteed to never conflict with future official fields. That has the added bonus that dpkg-deb will not issue warnings about user defined fields at package build time. I consider both as features. On email, the x- fields is grown too much, and it is no more a test before requiring a non x- header. So now you could have conflicting x-* headers, and not advantage for standardization. I think we don't want such behaviour on packages, and user should avoid conflict (e.g. searching in archives, googling,...). Eventually I could accept "non-registered" fields for tracking and additional informations, but every field which could modify behaviour of package manager, should be taken with great care. Personally I would remove the "User-defined fields" title, adding short commentary about support of X*- for forward compatibility, or eventually removing the entire section: it is a documentation of dpkg-deb (e.g. for special user needs), not for official packages, which is the target of policy. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#519910: [PKG-IRC-Maintainers] Bug#519910: inspircd: weird and undocumented syntax required for links, accessign clsoed fd's
Marc Lehmann wrote:
> when having two servers with the following link lines (without passwords
etc.):
I assume you intend to use 10.0.0.x. The address space 1.x.x.x is yet
unallocated,
but not for local use.
then despite trying to connect,t he other server will instantly close the
conenction, without logging a message:
accept(11, {sa_family=AF_INET6, sin6_port=htons(41545), inet_pton(AF_INET6,
":::1.0.0.1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 23
close(23) = 0
fcntl(23, F_GETFL) = -1 EBADF (Bad file descriptor)
fcntl(23, F_SETFL,
O_ACCMODE|O_CREAT|O_EXCL|O_NOCTTY|O_TRUNC|O_APPEND|O_NONBLOCK|O_SYNC|O_ASYNC|O_DIRECT|O_LARGEFILE|O_DIRECTORY|O_NOFOLLOW|O_NOATIME|O_CLOEXEC|0xfff0003c)
= -1 EBADF (Bad file descriptor)
setsockopt(23, SOL_SOCKET, SO_SNDBUF, [32768], 4) = -1 EBADF (Bad file
descriptor)
The first problem here is that the socket gets close()ed first, and then
inspircd tries to access it - when any multithreadeds modules are in use,
this will poentially damage unrelated file descriptions under the same
file descriptor.
Yes. Could you provide the log of inspircd? It would be interesting to
understand why inspircd closed the connection.
Anyway I agree: it should not access a closes connection.
The second problem is that ipv4 addresses are not matched correctly -
inspircd will try to connect to the correct address, but the receiving
server requires specification of :::1.0.0.1 instead of just 1.0.0.1
for the ip address to match.
Note: One bug report per problem, so that it is easier to track.
Anyway, I think it is correct to have ":::1.0.0.1": it use the
IPv6 notation. The libc and the kernel will handle such address correctly.
The advantage: we can use one API for both protocols (IPv6 and IPv4).
ciao
cate
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#519835: debian-policy: Please add new sections to policy
As Joerg has just said on d-d-a, some new sections have been added to the archive. I've attached a patch for policy to bring it up-to-date. The list become complex, considering also the priorities of sections. Could we ask ftp-master to give us a fixed-URL to the list of sections, the meaning and priorities? We definitely need to add that link (informative, in a footnote). ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#518199: debian-policy: virtual package names for doom-related packages
Wouter Verhelst wrote:
On Thu, Mar 05, 2009 at 11:03:57AM +0100, Giacomo A. Catenazzi wrote:
Jon Dowland wrote:
A brief explanation as to their meaning. Doom games are
divided into engine and world-resource components. The
former is captured by 'doom-engine'.
I don't understand why we need a 'doom-engine' virtual package.
[i.e.: avoid circular dependencies].
IMHO, a user will select an engine, not data.
I do not think so. The game data defines what game you play; the engine
defines _how_ you play it. Personally, I couldn't care less how exactly
a game is run on my system, as long as it is a game I like. IOW, the
data is what the user will choose, not the engine.
The latter is covered
by two different names, 'boom-wad' and 'doom-wad'.
I'm confused. A single virtual package ('doom-engine')
should handle two incompatibles engines?
No, boom-wad and doom-wad are the data packages.
Yes, I mean:
a 'boom-wad' should depend on the virtual engine: 'doom-engine',
a 'doom-wad' should depend on the virtual engine: 'doom-engine'.
but not all doom-engines support boom data. This was my confusion:
two virtual package on data side, but only one engine virtual package.
So an usage example would help me ;-)
Doom is the original
game from id Software; boom is a fully-free set of data to implement a
different game (with the same engine).
I know. I think some very old kernel release announces has references to
the big final monsters.
ciao
cate
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#518199: debian-policy: virtual package names for doom-related packages
Jon Dowland wrote:
A brief explanation as to their meaning. Doom games are
divided into engine and world-resource components. The
former is captured by 'doom-engine'.
I don't understand why we need a 'doom-engine' virtual package.
[i.e.: avoid circular dependencies].
IMHO, a user will select an engine, not data.
The latter is covered
by two different names, 'boom-wad' and 'doom-wad'.
I'm confused. A single virtual package ('doom-engine')
should handle two incompatibles engines?
I've also some problem understanding the utility of
such ('boom-wad' and 'doom-wad') virtual package,
because of the way of common package manager interfaces.
People tend to use the default value on dependencies.
(to much use of 'apt-get')
Virtual package are not normally used to allow multiple
selections.
I see the problem, but I'm not sure that virtual package
are the right solution, but also I don't see an alternative.
Could you provide an example of use of these new virtual
package, and the common use (what user select and should
expect)?
BTW 'boom-wad' and 'doom-wad' are visually very confusing:
could you use 'boom-extended-wad', 'doom-classic-wad',
or something less confusing?
ciao
cate
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#434489: http://debian.physik.hu-berlin.de/
Gürkan Sengün wrote: Hello Burkhard since I'm maintaining these packages anyway, it wouldn't mind doing that within the official distribution. However, I'm not a DD, so I need someone to sponsor me, right? Are you proposing to do so? And if so, what is the first step to get me startet? I'm sorry I am not DD myself, but you're right. My sponsor is in the CC: of this E-Mail. Giacomo: I know the packages are new, but would you mind having a look at it? It's scientific software, and our Physics people also need the software. Any package available from Debian helps us a lot. I don't have much time, anyway I could act as "semi-sponsor": you will check that the package has Debian quality (and follow debian policies). I'll do only the last check and upload to debian. Anyway there is also a debian-science group (I will join soon this group). ciao cate I see that you maintain "lie", together with Kasper Peeters. Did you contact him about cadabra/modglue? Yes I talked with him about it, but I had troubles packaging modglue. There is an ITP bug about cadabra. To get it into Debian the changelog should be empty aside this entry: * Initial release. (Closes: #434489) Best regards, Guerkan Senguen Best regards, Burkhard Bunk. -- b...@physik.hu-berlin.de Physics Institute, Humboldt University fax:++49-30 2093 7628 Newtonstr. 15 phone: ++49-30 2093 7980 12489 Berlin, Germany -- On Tue, 3 Mar 2009, Gürkan Sengün wrote: Hello I just found about your Debian packages at the url in the subject. Wouldn't you like to maintain cadabra/modglue officially for Debian? Yours, Guerkan -- Gürkan Sengün support: +41 44 633 26 68 IT Services Group, HPT D 17voice: +41 44 633 66 04 Departement Physik, ETH Zurichmobile: +41 76 436 72 00 CH-8093 Zurich, Switzerland http://nic.phys.ethz.ch/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta
Steve Langasek wrote: On Sat, Feb 28, 2009 at 06:32:45PM +0100, Giacomo Catenazzi wrote: Hmmm. I partially agree, but then we have an unnecessary exception: such virtual packages must have only one "provider", or else there will be problems (IIRC) on dpkg, apt or ddbuild, if such dependency is declared as first dependency [1]. >From the definition of the virtual package in question, it should have only one provider at a time. And this is an exception, No, it isn't. why not? Section 3.6: : Sometimes, there are several packages which offer more-or-less the same functionality. : In this case, it's useful to define a virtual package whose name describes that common : functionality. This is the rationale and the explanation of virtual package, which explicitly tell us about "several package". And MTA is not a special case: we have the same problem with syslog, possibly also with inetd. In past we had IIRC mass bug reports on transition with modutils. I would prefer to create a real empty package: default-mta (maybe in a source package debian-defaults), which depends on exim. This unavoidably couples Debian's choice of a default MTA for users who install the new release, to the behavior for users who are upgrading from a previous release, because users who have such a 'default-mta' package installed will find their MTA changed on dist-upgrade. What about an other level of indirection: package debian-mta: Depends: exim | mta-mail-transfer-agent I think this case will solve upgrades, and changing easily the mta (without causing a failed dependency). I believe that would also work, but it seems unnecessarily complex compared to the use of a virtual package. IMO it the contrary: virtual package seems more complex to me. Advantages: - the default is set by an independent maintainer (release, policy, ...) - easier (IMO) for custom distributions But ok, it you think it is simpler with virtual packages, I'm ok also with it. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta
Giacomo A. Catenazzi wrote: Steve Langasek wrote: On Thu, Feb 26, 2009 at 03:42:39PM +0100, Holger Levsen wrote: But as this would hardcode exim4 as the default MTA for Debian in a number of packages, some better solutions have been proposed in http://lists.debian.org/debian-devel/2008/05/msg00381.html with the best choice appearantly being <87ve1faria@frosties.localdomain> which proposes that exim4 should provide default-mta, packages needing an MTA should depend on default-mta | mail-transfer-agent and the other MTAs should provide mail-transfer-agent. Then, if we want to change the default, we just need to touch two packages. I agree that this is the best solution. As per policy I'd like to gather consensus on this before mass filing bugs. Given that m-t-a is mentioned explicitly in policy, and that "default-mta" will be a virtual package, I think this should be recorded in policy as well - though if a clear consensus emerges on debian-devel, there's no need to go through the policy process before filing bugs. Also, I haven't seen the exim4 maintainers comment on this proposal until now. Obviously we would want to get that package to Provide: default-mta before filing bugs on other packages. Hmmm. I partially agree, but then we have an unnecessary exception: such virtual packages must have only one "provider", or else there will be problems (IIRC) on dpkg, apt or ddbuild, if such dependency is declared as first dependency [1]. I would prefer to create a real empty package: default-mta (maybe in a source package debian-defaults), which depends on exim. BTW "mta" is IMHO wrong. In most of the cases (IIRC) programs needs only a "sendmail" program. Should we split the dependencies on real-mta and only on a sendmail provider. BTW we should also rule a minimal set of sendmail interface (which option should be implemented). Actually every "MTA" has different sets of sendmail options, but I don't yet know about problems. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta
Steve Langasek wrote: On Thu, Feb 26, 2009 at 03:42:39PM +0100, Holger Levsen wrote: But as this would hardcode exim4 as the default MTA for Debian in a number of packages, some better solutions have been proposed in http://lists.debian.org/debian-devel/2008/05/msg00381.html with the best choice appearantly being <87ve1faria@frosties.localdomain> which proposes that exim4 should provide default-mta, packages needing an MTA should depend on default-mta | mail-transfer-agent and the other MTAs should provide mail-transfer-agent. Then, if we want to change the default, we just need to touch two packages. I agree that this is the best solution. As per policy I'd like to gather consensus on this before mass filing bugs. Given that m-t-a is mentioned explicitly in policy, and that "default-mta" will be a virtual package, I think this should be recorded in policy as well - though if a clear consensus emerges on debian-devel, there's no need to go through the policy process before filing bugs. Also, I haven't seen the exim4 maintainers comment on this proposal until now. Obviously we would want to get that package to Provide: default-mta before filing bugs on other packages. Hmmm. I partially agree, but then we have an unnecessary exception: such virtual packages must have only one "provider", or else there will be problems (IIRC) on dpkg, apt or ddbuild, if such dependency is declared as first dependency [1]. I would prefer to create a real empty package: default-mta (maybe in a source package debian-defaults), which depends on exim. ciao cate [1] policy 7.5 has only a note: : If you want to specify which of a set of real packages should be the default to satisfy : a particular dependency on a virtual package, you should list the real package as an : alternative before the virtual one. Probably we should be stricter. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#449497: Post-Lenny discussion on packages with external (potentially non-free) dependencies
Michael S. Gilbert wrote: Dear All, First of all, congratulations on getting the Lenny release out the door! I understand that it was a lot of work, and you're probably looking forward to at least somewhat of a break. So I don't want to treat this problem with too much urgency (yet), but I would like to get a dialog going as people find the time to weigh in with their opinions. (...) [removing the long mail: too long to quote, too interesting to extract the best parts. my case (microcode.ctl): - the package is in contrib and not in main - I download only ascii file, converted to binary and feed to the kernel device only at loading time, so difficult to exploit - intel microcode is crypted, thus it is difficult to modify - user had the possibility to download the microcode manually and to put in the right position - no microcode no worrying: the computer work normally (but on new processors on a new family, with usually needs a lot of updates, but usually these are developer machine, not production machines.) - but with problem on distribution format. Intel (I think wrongly) changed the format (instead of a compressed file, it did a compressed tar of the file) thus breaking debian and ubuntu. - but with last versions, Intel changed (again) the microcode license (I think because of us [or better because of Ubuntu :'( ] ), so now microcode is distributed by a non-free package. The script to download microcode from intel side is only a convenience script. I could live (and I think also our user) fine, if I remove the script from postinst (BTW it was called after asking confirmation via debconf) - the microcode now could be installed also by the kernel firmware infrastructure, so I still had to decide a proper procedure with Intel and RedHat, and to debian firmware. After this the package will be a legacy only package. BTW: I still have the non-free.* domains, if Debian need it. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#513955: debian-policy: do not require /etc/init.d/*.sh scripts to be sourced
Russ Allbery wrote: Kel Modderman writes: It is the opinion of myself and Petter Reinholdtsen, maintainers of the sysvinit package, that the last sentence of §9.3.1 of policy is no longer relevant and should be removed: """Also, if the script name ends in .sh, the script will be sourced in runlevel S rather than being run in a forked subprocess, but will be explicitly run by sh in all other runlevels.""" I went to write the patch for this, but I paused when I saw that the other part of this sentence (explicitly running such scripts with sh at other run levels) is implemented. The current /etc/init.d/rc runs the script directly if it doesn't end in .sh but runs it with sh if it does. As alternative, I propose not to use the suffix .sh: - now we change /will be sourced/could be sourced/ , with a footnote that deprecated such feature - we bugs package, to remove the suffix .sh - after most of the most important packages removed the .sh suffix, the policy remove the exception, maybe introducing a footnote which shortly explain the past rules (this will simplify the writing of rationale in the new doc) Rationale: users could be confused by the .sh suffix. > At least on my system, all of the scripts ending in .sh have a proper #! > line and are executable, so this wouldn't make any difference there, but I > wanted to double-check first before also removing that since it appears to > be implemented. hmm. All init.d script should be executable, with proper #! header. Sysadmin are used to manually /etc/init.d/foo >stop|start|restart|reload> So I don't understand your commentart. ciao cate ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
Russ Allbery wrote: "Adam D. Barratt" writes: The Policy section detailing the "Distribution" field in .changes files specifies that the field may contain a space-separated list of distributions. Whilst this is technically accurate, the feature has been deprecated since the "testing" distribution became an official part of the archive and is, imho, obsolete; the use case of uploading the same package to unstable and the frozen-stable-to-be as a single upload no longer applies. I discussed this with a couple of members of the ftpteam on IRC earlier today, and they were both in favour of removing support for the feature from dak. One of them had a dig through the archives and discovered that there have been no multiple-distribution uploads since 2004; even then there was only the one upload in that year, with the grand total of three in 2003. I would do a more radical change. (BTW I think ftp-team/DSA should update the footnote 38, and we should remove "all"). I think we should move distribution field from upload target to a "final target" distribution, i.e. a sort of quality assessment. I really don't like that maintainers fill a RC bug only to stop migrating a package from stable to testing. To distinguish different queues, I would use different upload URLs (like we had for non-us). But such proposal should eventually come from ftp-team. Nobody use it? Maybe we should ask people to use it, i.e. for the case of important fixes that should go *also* to backport. In conclusion: if this proposal will simplify dak tools I'll agree, in other case I'm undecided. This looks good to me in general. The only concern that I have is that there are other archive maintenance packages besides dak and some of them explicitly list multiple- distribution upload support as a feature (reprepro, for instance). Policy is specifically intended to describe the requirements for packages that are part of Debian, where dak matters the most, but this is specifically a description of the *.changes *syntax*. I'm a little unsure as to whether we should make multiple distributions a syntax error, when other tools support it, or instead just say that it's allowed in the syntax but the Debian archive doesn't support it. I think this is a general problem we the policy (that IMO should be fixed in the new policy): it is not clear (and it use the same restrictions) to both users, but IMHO packagers should have stricter rules, and dak/dpkg/... could have more relaxed rules (like the main internet rule). ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#473439: pick consistent terminology for category/component/area
Russ Allbery wrote: Russ Allbery writes: I did a bit more research based on Osamu Aoki's excellent work. Currently, these things are referred to using three different terms: * dak calls them components. * The current Debian Policy document calls them categories. * The Social Contract calls them areas: (...) The above was written in July of last year. The only reaction that I got to this proposal is a comment from Giacomo that didn't object but suggested standardizing more of the terminology while we're at it. But I don't think there's been much progress on that front. As mentioned, I'm not sure we need to match the terminology in dak as long as we're not confusing about it. dak is referring to technical capabilities which are used to implement certain features. I still think distribution area is a good name for this, better than categories. However, there doesn't appear to be any consensus on this right now. So this is a ping to see if we do have consensus and people just haven't said, or if we don't. If we don't have consensus, my inclination is to close this bug and continue using categories, since I don't think anything else uses category in a confusing way. I don't want to just leave the bug open; it doesn't seem likely that anything fundamental is going to change about this bug report in the future. During last DebConf, I've done some further research, but unfortunately I paused it (and I forgot about it). I think that dak is inconsistent with the meaning of "component". I see component and distribution area as two different entities: component is build from distribution area and eventually prepended with some name (source, distributuion), e.g. the security "sub-distribution" have as components (e.g. in http://security.debian.org/dists/etch/updates/Release ) : : Components: updates/main updates/contrib updates/non-free OTOH, sometime we uses (sources.list(5)): : deb uri distribution [component1] [component2] [...] but in this case "updates" is attached to "distribution", thus here "componentN" should be really "areaN". So I agree we your patch, with only one remark: Here's the proposed patch: diff --git a/policy.sgml b/policy.sgml index 24c9072..16919b2 100644 --- a/policy.sgml +++ b/policy.sgml @@ -293,7 +293,13 @@ free in our sense (see the Debian Free Software Guidelines, below), or may be imported/exported without restrictions. Thus, the archive is split into the distribution - areas or categories based on their licenses and other restrictions. + areas or components + The Debian archive software uses the term "component" internally + and in the Release file format to refer to the division of an + archive. The Debian Social Contract refers to distribution + areas. This document uses the same terminology as the Social + Contract. +based on their licenses and other restrictions. I would replace with: + areas + The Debian archive software uses the term "component" internally + and in the Release file format to refer to the division of an + archive, which is usually the same as the distribution area. +based on their licenses and other restrictions. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#509935: decide whether Uploaders is parsed per RFC 5322
Russ Allbery wrote: > Alternatively, we could document the permitted character set for the name portion of the Maintainer field and exclude commas. It's annoying to do this since commas have been supported in the past (in Maintainer, they're unambiguous) and have only become a problem in Uploaders. We could only restrict them in Uploaders, but the lack of symmetry strikes me as a bad idea. I think it is not polite to force changes in maintainer names. We could also standardize a simple escaping mechanism of our own (allow double quotes, for example, but require that, if used, they surround the entire name and are stripped off by the parsing). However we resolve this, we should probably also update the referece in Policy to RFC 822 to refer to RFC 5322 instead, since I doubt we really want to support source-routed e-mail addresses or similar bizarreness in Debian control files. Hmm, RFC5322 is not yet a standard (BTW it is not yet cited in STD1), and anyway it still use the old semantic for compatibility (see the "obs-" references, e.g. the section 4.4). IMHO we should specify a subset of RFC 822, because a full 5322 parse is IMO too complex (and BTW not so useful) to implement in all the tools. Ev. require to use only a subset in the control file, and to recommend a full 5322 parsing in the tools. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#509933: versioning SONAMEs of shared libraries is not clearly recommended
Russ Allbery wrote: Package: debian-policy Version: 3.8.0.1 Severity: minor I read through the shared library sections of Policy a few times last night and can't find anywhere where Policy unambiguously recommends always including a version in SONAME for public libraries. If you don't have a version, you can't represent the library in the shlibs format, so there's an implicit recommendation, but I think it would be better to make it explicit. I think the first sentence of 8.1 with the footnote 47 give an answer, but: a footnote (IMO) is not normative, and a "a good idea" is too weak. [8.1] The run-time shared library needs to be placed in a package whose name changes whenever the shared object version changes.[47] [47] Since it is common place to install several versions of a package that just provides shared libraries, it is a good idea that the library package should not contain any extraneous non-versioned files, unless they happen to be in versioned directories. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#449497: foo2zjs dispute
Note: I'm not a CTTE member. Steffen Joeris wrote: Maintainer: -- The problem is as follows. The submitter sees the inclusion of the getweb script as a violation of the DFSG. The script is provided by upstream to download non-free firmware from his upstream webpage. The package includes documentation in README.Debian and a GUI interface (hannah-foo2zjs) around the getweb script for the user's convenience. Some printers need this non-free firmware to run, others don't. More information can be found in the bugreport. Could we please ask you to settle this dispute? Submitter: -- The submitter sees the getweb script's dependencies on external data/files as potentially dangerous. Once the package enters stable, upstream changes (moving/modifying files, etc.) can break functionality -- leading to a package that can no longer be considered "stable." External dependencies also potentially leave users vulnerable to security risks (the upstream site could be spoofed or hijacked and malicious files hosted instead of the legitimate firmware files). Also, the submitter views external dependencies as a possible violation of the spirit of the debian policy, which currently is not explicitly clear on the issue. Section 2.2.1 says "... the packages in main must not require a package outside of main for compilation or execution (thus, the package must not declare a 'Depends', 'Recommends', or 'Build-Depends' relationship on a non-main package)." This makes the policy clear about "packages," but it does not address dependencies on other external non-packaged non-free files. It is the submitter's belief that Debian's policy should be reworded for clarity on situations such as this. It is not a DFSG violation, because the file are not distributed by Debian, but I think it violated the policy. I think Debian should not assume a machine on the net, so I would interpret "main" in the stricter way. I don't find an overkill to make a separate package for the download script. As you will see, maintaining such script will be complexer and in case of layout change, it don't requires a updates from most of the package user. The changing of remote layout is an important problem: the package could become unusable thus potentially a RC bug, which should not happens on other bugs in main. The "contrib" section includes (historically) also the reduced quality package, so the uninstability of a contrib package could be temporary accepted. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#496655: State of pci.ids
Martin Mares wrote: I think that changing the format of the file (with other suffix) would also be helpful, i.e. instead of using tab-indent I would explicitly writing vendor id (ev. other implicit ids) in every line. In this manner it is easier to grep for hardware, and also to merge files from different sources (cat | sort -u), without requiring external libraries or complex scripts. It was a "side proposal", and probably offtopic, but anyway. First, I do not believe it would help anything -- the file would be less readable, larger and harder to edit. This is not a fair price for simplifying a couple of scripts. I agree that the file would be a lot bigger (so no ideal for installations, but I think it is optimal to compress, and maybe a better tradeoff between code and data sizes. Readable: I don't find that actual version is readable, in particular with biggest vendor (i.e. I need a lot of scroll to see if I'm in the right section). Harder to edit: see usb.ids: it is difficult to distinguish tab from space (but the library could accept 8 spaces as tab). Second, merging of pci.ids does not help with the updating problem I have described. Do you see any way how it could? It was a side note: if you need to change it (because of split, etc.) I propose to change also the format. Merging different sources is not so simple (but also not so complex). I would move the logic from code (and runtime) to data. Third, while grepping for ID's is appealing, it is nowhere as simple as it looks -- for example, the subsystems can be present either as sub-items of the devices, or as stand-alone entries. Could you elaborate this? grep '^ ' grep '^ ' would give the subsystem in two simple lines. But I don't find any of such kind of detection in kernel (e.g. no checking of subsystem ids without a fix vendor/device ids). [Note: other files *try* to use the same format, e.g. usb.ids, zorro.ids and eisa.ids (in kernel sourcers). But usb.ids has frequently spaces instead of tabs.] I hope this will get much better soon as a common administration system for all the ID files is almost finished. ok. This would be nice! So maybe we could have a common tools that handle, grep, merge different ids files. This would remove most of my concerns. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#496655: State of pci.ids
Martin Mares wrote: Dropping this information in the udeb is if course a good way of saving space, but the full package should contain everything. In the future (after Lenny), I would like to solve one more problem: with the current rate of development of new hardware, the pci.ids file is getting out of date very quickly and there is no way how to update it nicely. The problem is somewhat mitigated by the network lookup feature present since pciutils 3.0.0, but not all users are connected to the network all the time (and not all programs linked with libpci know how to enable the lookups), so it still makes sense to update the pci.ids file. Of course, we have the update-pciids script, but does its job in a dirty way as it rewrites the pci.ids file coming from the pciutils package, so the file system is no longer consistent with the packages (and debsums fail and so on). We might make libpci look for the file at several places and keep the updated copy somewhere in /var/, but it would make updates of the package painful: which version is the more up-to-date? The one in /usr/share, or the one in /var? So it does not help either. I suggest that we should split off the pci.ids file to a separate arch-independent package with a date-based version number, so that the users can mix pci.ids from several sources and still get consistent upgrades: o the base version present in the distribution; o potential updates from debian-volatile (once in a month?); o daily snapshots from the PCI ID database (I can easily make the snapshot machinery produce Debian packages as well). What do you think of this approach? I think that changing the format of the file (with other suffix) would also be helpful, i.e. instead of using tab-indent I would explicitly writing vendor id (ev. other implicit ids) in every line. In this manner it is easier to grep for hardware, and also to merge files from different sources (cat | sort -u), without requiring external libraries or complex scripts. See for example pci.list in http://cateee.net/sources/lkddb [Note: other files *try* to use the same format, e.g. usb.ids, zorro.ids and eisa.ids (in kernel sourcers). But usb.ids has frequently spaces instead of tabs.] ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311772: Fwd: Password leaks are security holes
Mark Brown wrote: On Thu, Aug 28, 2008 at 01:05:19PM +0200, Johan Walles wrote: 2008/8/28 Giacomo A. Catenazzi <[EMAIL PROTECTED]>: auth.log was invented for this reason, and separated to standard log: it should be readable only by root, because users do errors. It's readable by anybody with physical access to the hardware. Hard disks get stolen all the time [1], and on publicly accessible machines it's often possible to boot in runlevel 1 or from something other than the hard disk and access any files you like. That's why the passwords in /etc/shadow are all hashed, rather than just being chmodded. As alternative, you could redirect "auth" syslogd to /dev/null (or to a pipe that filter results). Note that the important data are still available in 'last' (wtmp, btmp). But I don't think that on normal cases (which sould be the Debian default) the security is decreased having misstyped password on auth.log ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311772: Fwd: Password leaks are security holes
Johan Walles wrote: Hi Nico! Let's keep debian-security in the discussion to see what others have to say about this. Technically I agree with you when you say that people shouldn't enter anything but their usernames at the login prompt, but the fact is that people (like me and the bug submitter for example) *do* enter their passwords there from time to time. People make mistakes, and this is not an uncommon one. Security shouldn't be based on nobody ever doing more or less common mistakes. auth.log was invented for this reason, and separated to standard log: it should be readable only by root, because users do errors. Anyway root already has the capability to view passwords (i.e. by installing alternate login programs, sniffing tty, ...) So auth.log should log usernames, so that users don't do wrong assumption that password are not accessible by root! ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#471287: [PKG-IRC-Maintainers] Bug#471287: Thanks for the help but
Matt Arnold wrote: > #471287 is _NOT_ an upstream issue! Furthermore if you had been paying > attention to the bug report logs you would have noticed I think the user wrongly interpreted "upstream". We are "upstream" from Ubuntu, but we are not the real/initial upstream. >> No, the patch is wrong! >> BTW "-n" is not a bashism, but a long time convention starting >> from the *BSD, IIRC, and cited also on POSIX. > > I thank you for trying to help however i think we have this well under > control and i don't wish to spam upstream with bugs that are purely > packaging related. Thanks again for trying to help :) This comment was to the people that added tag upstream, or to my comment? Anyway: The patch is wrong. echo "\c" is less portable than echo -n. echo -n is the right thing to have. Eventually, simple portable shell could wrap "echo", at level of init.d handler. BTW POSIX discourages to use "echo -n" to print "-n" (and it say that it is not portable), and I think no sensible person will do that, so eventually a wrapper will have no problems. BTW the -e option should be removed (not it is reported on initial report, but missed the patch). - echo -en "\nAlready running!" + echo + echo -n "Already running!" but I'm not so sure that this need to be written in a new line. Eventually the lsb helper function could be used, so that eventually we can have colored boot. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
Russ Allbery wrote: Raphael Hertzog <[EMAIL PROTECTED]> writes: On Sat, 12 Jul 2008, Raphael Geissert wrote: As demonstrated by the following trivia[1], and also mentioned by SUSv3, the echo built-in varies from implementation to implementation and thus should be discouraged. Well, you just proved that you can't rely on correct interpretation of special escaped characters and that's true. It's not a reason to discourage echo or echo -n in general though. That would be ridiculous given how frequently it's used. But it would be nice to remember that printf "" must be used if you want to reliably use escaped characters. But here you must take care to use "%s" for each variable expansion: echo "a $var\n b" is printf "a %s\n b\n" "$var" I realize that Policy already provides a little bit of generic advice about writing shell scripts, so it's not like we have a particularly pure distinction on which to stand, but unless we're going to require particular practices via filing bugs I think putting best practices in the devref may be better. Policy does say by reference that echo varies. It referes to SUS, which says: If the first operand is -n, or if any of the operands contain a backslash ( '\' ) character, the results are implementation-defined. and: It is not possible to use echo portably across all POSIX systems unless both -n (as the first argument) and escape sequences are omitted. The printf utility can be used portably to emulate any of the traditional behaviors of the echo utility as follows (assuming that IFS has its standard value or is unset): [...] We of course override the part about -n and require that it behave in a particular way, but the part about backslashes remains. It's unfortunate that SUS requires free registration; it makes it harder to link directly to specific sections of interest. The POSIX pages are available online, in http://kerneltrap.org/man/linux unfortunately they are not very well formatted (some extra groff are written on html) For echo: http://kerneltrap.org/man/linux/man1p/echo.1p I don't think this bug need to be address, for the following reasons: - I don't find debian scripts which uses escapes (but one of mine package in stable, on the non-debian support part) Eventually policy could state that escapes should not be used in echo. - "-n" is so wide used, that other solution will create more bugs! Anyway, no user should use "echo -n" to print "-n" (POSIX discurages it), so again, it is a non-problem. note: it can is very easy corrected by wrapper (or shell alias) - I think the debian script are is outside POSIX scope: - the system is not completely up, so POSIX commands and support is incomplete. Anyway the init.d scripts use usually other non-portable command (i.e. mount), so - the installation of program is also outside POSIX scope: it modify system in a manner not allowed by portable scripts. So, IMHO, there is noway to have debian script compatible 100% to posix. So I would reject the bug, until we don't see real problems. OTOH moving to LSB command could help in this case, help logging and give some colors to users. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489978: g15daemon: fails to reacquire keyboard when disconnected and reconnected
My G11 keyboard seems to be flaking somewhat. This results in unpredictable USB disconnects, followed by near-immediate reconnects on the same port. I've also noticed it: I connected Logitech headphone to keyboard usb, which caused power problem and thus disconnecting usb. but I've not yet a real solution, which could handle also multiple g15 keyboards. cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#473439: debian-policy: Debian Policy inconsistent with Developer's Reference
Giacomo A. Catenazzi wrote: At the end of the process, I would like to have a glossary (maybe included into the policy) To simplify the discussion, I created: http://wiki.debian.org/PolicyGlossary It contain important term and links to policy. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#473439: debian-policy: Debian Policy inconsistent with Developer's Reference
Russ Allbery wrote: "Giacomo A. Catenazzi" <[EMAIL PROTECTED]> writes: OTOH, the 'Release' file uses the dak terminology, and the name is encoded on some tools. The most visible is apt: apt_preferences(5) for pining use the term "Component". Because is not a urgent topic, and (IMO) there are some other terminology problems about archive terminology, I thinks we should wait and find a good terminology for all terms, and having some agreement on transition plan (dak, apt, debian reference,) BTW, I think a good starting point is to "standardize" the terms in the Release file, after this, the solution of term problem should be trivial. I tried to cover this in my initial message, but I think it's reasonable for us to use different terminology than dak uses. dak is talking about a capability of the archive software, whereas we're talking about a split of the archive that has more project significance (such as for licensing). If it helps, I think of it this way: distribution areas are a Debian Policy requirement, which are implemented using dak's component capability. Component doesn't really feel like the right term in Policy given that we use a different term in the Social Contract. But it's possible that I'm being too picky. I'm not sure. I've no problem also with "area" terms, but my points was: - there are more terms which should clearly defined, and they are "stacked"/hierarchical. So I think it is better to make a complete proposal and using term which cannot be confused with other parts. Probably we need also a precise definition. dak: "Components: updates/main updates/contrib updates/non-free". in policy "area" should be only "main" (or "updates/main"??) - identify who use other terms, and discuss with others: maybe there is a good reason to have name "component". On the other hand, they could/should change terms, so they should know the problem, and set ev. a transition plan. - Because it is a term problem and not a hard policy rule, I think we could wait more, to have a good proposal and more feedback from apt/dpkg/dak people. At the end of the process, I would like to have a glossary (maybe included into the policy) ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#473439: debian-policy: Debian Policy inconsistent with Developer's Reference
Russ Allbery wrote: Ian Jackson <[EMAIL PROTECTED]> writes: Russ Allbery writes: So as a purist, I would prefer `category'. `Area' works too since it refers to an `area' in the FTP site. I did a bit more research based on Osamu Aoki's excellent work. Currently, these things are referred to using three different terms: * dak calls them components. * The current Debian Policy document calls them categories. * The Social Contract calls them areas: (...) I think Policy should not attempt to make up its own terminology here, so I'd like to change it to match either dak or the Social Contract. After thinking about it for a bit, I favor going to the terminology of the Social Contract with a minor modification (distribution areas instead of just areas) in part because of Ian's point and in part because I think it's meaningful to suppose that component refers to a technical capability of dak whereas distribution area refers to a concept within Debian as a project. Here is a proposed patch to consistently use distribution area in Policy. What do people think? OTOH, the 'Release' file uses the dak terminology, and the name is encoded on some tools. The most visible is apt: apt_preferences(5) for pining use the term "Component". Because is not a urgent topic, and (IMO) there are some other terminology problems about archive terminology, I thinks we should wait and find a good terminology for all terms, and having some agreement on transition plan (dak, apt, debian reference,) BTW, I think a good starting point is to "standardize" the terms in the Release file, after this, the solution of term problem should be trivial. ftp://ftp2.de.debian.org/debian-security/dists/stable/updates/Release Origin: Debian Label: Debian-Security Suite: stable Version: 4.0 Codename: etch Date: Sat, 05 Jul 2008 16:13:30 UTC Architectures: amd64 alpha arm hppa i386 ia64 mips mipsel powerpc s390 sparc Components: updates/main updates/contrib updates/non-free Description: Debian 4.0 Security Updates (...) http://ch.archive.ubuntu.com/ubuntu/dists/intrepid/Release Origin: Ubuntu Label: Ubuntu Suite: intrepid Version: 8.10 Codename: intrepid Date: Mon, 07 Jul 2008 7:43:57 UTC Architectures: amd64 hppa i386 ia64 lpia powerpc sparc Components: main restricted universe multiverse Description: Ubuntu Intrepid 8.10 (...) Note: also apt is not consistent. About "suites" (i.e. stable, testing, unstable) apt-get(8): (...)the version of the distribution or the *Archive name* (stable, testing, unstable). (...) -t, --target-release: (...) using the specified *release string* ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485553: ITP: charybdis -- fast, scalable irc server
William Pitcock wrote: - epic4 (impossible to get an exception, dead contributors) You are wrong to the "impossible to get an exception, dead contributors", in this sentence and in other sentences: The copyright go to the heirs, so you could contact the heirs. Anyway, we should follow the copyright law. If we do exception to GPL, other people will think they could also make esceptions to GPL, losing the value of the GPL, and all people will lose. Don't think only on these project, where it would be very convenient to make exceptions, but if you broke in one place the GPL, why our users should not make additional exceptions and not disclose sources? So this annoyance will allow us to sue people violating the GPL. Think: it is a great advantage! ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#169600: Rejected: Bug#169600: Policy should mandate a place for init.d script to log errors to
Russ Allbery wrote: This proposal asks that Policy mandate a location to which init scripts must log verbose errors. The original proposal was made in 2002 and there was little subsequent discussion in 2003. This Policy proposal is also not currently widely implemented in the archive and hence would be a change ahead of current practice. I'm rejecting this proposal due to lack of consensus and lack of support by current practices in the archive. This is a soft rejection, meaning that if someone feels strongly about this proposal and wants to step forward to champion it again, I'd be willing to reopen the bug. However, I would encourage anyone looking to champion this proposal to introduce a simple facility for packages with init scripts to do something along these lines (which can be done today without a Policy change) and then see how much adoption across the archive can be achieved prior to a formal Policy change. I think /etc/init.d/bootlogd (in initscripts package) is good enough to solve definitely this bug. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479080: debian-policy: Policy '3.8 Essential packages' does not explain when/why essential is neccessary
Manoj Srivastava wrote: Hi, On Fri, 02 May 2008 17:45:30 +0200, Carl Fürstenberg <[EMAIL PROTECTED]> said: Policy section 3.8, about essential packages, doesn't explain when/why essential is neccessary, only that it should not be essential if it's not necessary. My understanding is that a package is Essential if without it is impossible to install any more packages to the system -- that is, the package is required for proper functioning of dpkg. If my understanding is correct, it should be easy to add in a line about when packages can be made Essential. In addition "Essential" is also used not full dependencies with "obvious" packages. (Policy 3.5) Ah... the rationale is in footnote 7 http://www.us.debian.org/doc/debian-policy/footnotes.html#f7, which is linked in 3.5. I think we should split the rationale and put the first part in 3.8. And 3.5 should linke to the section 3.8 ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#172436: Updated BROWSER proposal
Russ Allbery wrote: "Giacomo A. Catenazzi" <[EMAIL PROTECTED]> writes: "web browser to display an URL." I don't like the sentence, but anyway I don't worry much, because the program should be sensible, and open browser only with correct protocols. I've changed it to: Some programs have the ability to launch a web browser to display a resource identified by a URL. Since there are lots of different web browsers available in the Debian distribution, the system administrator and each user should have the possibility to choose a preferred web browser. FYI: "xdg-open" could enter in new LSB, as a generic URL opener (not only for browser): http://portland.freedesktop.org/xdg-utils-1.0/xdg-open.html This was previously discussed in this bug. I think xdg-open is orthogonal to what we're trying to accomplish here. Yes, I was thinking it was more general, but it handle only file:// and web browser. I think we need a generic URL method, which simulated the browser behaviours (i.e. mailto: open mail client, ...). But this is not (yet) a topic for policy. + Since there are lots of different web browsers + available in the Debian distribution, the system administrator + and each user should have the possibility to choose a preferred + web browser. + Is "lots of different" correct? Yes. It's not the most ideal wording, but it's correct. Anyway it is a rationale, so I would remove the first part. No, rationale belongs in Policy. It will eventually become more clearly marked as informative rather than normative, but not having rationale has caused us problems in the past. Ok, right. POSIX rationale are very informative. But I think that this rationale is incorrect. Probably because of "lots of different". Substitute "web browser" to MTA, and you see it is not so correct. I think the "lots of different" means "lots of web browser installed at the same time". Anyway is a minor point, and I will not slow down resolution of this old bug for such things. These 4 paragraphs enter to much in details of a program. I'll really remove these paragraphs, and let the programs use only "/usr/bin/sensible-browser" (next paragraph), so it is easier to update the policy (evolution of FreeDesktop, ...). No, Policy needs to explain what sensible-browser is supposed to do, and needs to explain what's required for interoperability; programs are not required to use any specific wrapper if they want to implement (or if upstream has already implemented) the same logic. Hmm. ok. I think that next paragraph is good, and IMO we should not describe rules in details. I think it's very important that Policy describe rules in detail. If it's important enough to put in Policy, it's important enough to describe in detail. Hmm. It is related to the previous answer, so ok to include the full list of requirements. But I don't agree on your argument. I see it like /usr/sbin/sendmail. For example: a program that send mail, should use /usr/sbin/sendmail. I don't think we should specify the behaviour of common options (for MTA and for the caller). I would be very disappointed if a MTA or a caller use it in a totally wrong way, but I don't want that a full description should be written in policy. Let write in policy only important or controversy points, to have more people read the policy! But reading the bug history, I think that the full description should be included. So I'm ok with the proposal (but I'm not in the policy team) ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#172436: Updated BROWSER proposal
Russ Allbery wrote: --- a/policy.sgml +++ b/policy.sgml @@ -8675,6 +8675,68 @@ name ["syshostname"]: for games (X and non-X games) should be installed in /usr/share/man/man6. + + + Web browsers + + + Some programs have the ability to launch a web browser to + display an URL. "web browser to display an URL." I don't like the sentence, but anyway I don't worry much, because the program should be sensible, and open browser only with correct protocols. FYI: "xdg-open" could enter in new LSB, as a generic URL opener (not only for browser): http://portland.freedesktop.org/xdg-utils-1.0/xdg-open.html > + Since there are lots of different web browsers > + available in the Debian distribution, the system administrator > + and each user should have the possibility to choose a preferred > + web browser. > + Is "lots of different" correct? Anyway it is a rationale, so I would remove the first part. + + + In addition, programs should choose a good default web browser + if none is selected by the user or system administrator. + + + + The recommended way to satisfy these goals is for every program + that launches a web browser with a URL to use the BROWSER + environment variable to determine what browser the user wishes + to use. + + + + The value of BROWSER may consist of a colon-separated series of + browser command parts. These should be tried in order until one + succeeds. A command part consists of the command to executed + followed by 0 or more arguments separated by one or more spaces. + The command and arguments should be separated at the spaces, the + URL added as a final argument, and the resulting command + executed directly (not via the shell). + This protects against bugs and security problems caused by + shell metacharacters in the browser arguments or URL. This + specification is compatible with the + http://www.dwheeler.com/browse/"; + name="Alternative Secure BROWSER Definition">. + + + + + If the BROWSER environment variable is not set, the program can + use /usr/bin/x-www-browser if DISPLAY is set, and + /usr/bin/www-browser if not. These two files are + managed through the dpkg alternatives mechanism. Thus every + package providing a general-purpose web browser should call the + update-alternatives program to register the + appopriate one of these alternatives. + These 4 paragraphs enter to much in details of a program. I'll really remove these paragraphs, and let the programs use only "/usr/bin/sensible-browser" (next paragraph), so it is easier to update the policy (evolution of FreeDesktop, ...). I think that next paragraph is good, and IMO we should not describe rules in details. + + + Instead of implementing the above in every program that runs a + web browser, programs in Debian may be configured to use + /usr/bin/sensible-browser. This is a program + provided by the Debian base system that checks the BROWSER + environment variable, falls back to the configured browser in + the user's desktop environment, and then falls back to + /usr/bin/x-www-browser or + /usr/bin/www-browser if BROWSER is not set and no + recognized desktop environment is in use. + + ok. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#471287: [PKG-IRC-Maintainers] Bug#471287: FIX: atheme-services: bashism in /bin/sh script
Here is one patch to solve the bashism in this package. No, the patch is wrong! BTW "-n" is not a bashism, but a long time convention starting from the *BSD, IIRC, and cited also on POSIX. From POSIX: : A string to be written to standard output. If the first : operand is -n, or if any of the operands contain a : backslash ( '\' ) character, the results are implementation-defined. so also your methods is not portable on all POSIX systems, as cited: : It is not possible to use echo portably across all : POSIX systems unless both -n (as the first argument) : and escape sequences are omitted. You should use printf instead of '-n' and '\c', to be mroe portable. Your patch works well on XSI-conformant systems, but Debian, nor Linux are so far. (I think that POSIX would conform to Linux and not the contrary on thi field, but not yet checked the future posix). Anyway, your Debian policy manual allows (ad uses) the "echo -n" convention. ( http://www.debian.org/doc/debian-policy/ch-opersys.html } ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#462184: RFP: latencytop -- tool to visualize system latencies
What is the status of this bug? I see that you changes few time the bug title, so now is it really RFP? Do you have a preliminary version? If I don't see a reply in next few days, I'll pack a new version. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#438385: NMU awardeco #438385: fails on 64-bit platforms
diff -u awardeco-0.2/debian/changelog awardeco-0.2/debian/changelog --- awardeco-0.2/debian/changelog +++ awardeco-0.2/debian/changelog @@ -1,3 +1,11 @@ +awardeco (0.2-2.1) unstable; urgency=low + + * Non-Maintainer Upload at BSP in Zurich: fix rc bug + * Use the C99 bit length integer, to be safe on various archs Please add "(Closes: #438385)" here. Also, please end all changelog lines with a full stop and start sentences with capital letters for consistency. oops. Ok. the first was a cut-copy error trying cdbs-edit-patch (nice tools!). Never realized about cosmetic consistency, I'll fix also that. --- awardeco-0.2.orig/debian/patches/30_fixeduint.patch +++ awardeco-0.2/debian/patches/30_fixeduint.patch @@ -0,0 +1,17 @@ +diff -Nur awardeco-0.2/src/awardeco.h awardeco-0.2.new/src/awardeco.h +--- awardeco-0.2/src/awardeco.h2006-08-05 11:38:03.0 +0200 awardeco-0.2.new/src/awardeco.h2008-01-16 08:12:10.0 +0100 +@@ -10,10 +10,11 @@ + #define AWARDECO_H 1 + + #include ++#include + + typedef unsigned char byte; Maybe make this uint8_t then, too, for consistency? Yes, it's more cosmetical, but still. yes. This change doesn't harm: in C, char is a byte and in POSIX, char is 8 bit. So I take a smaller NMU. But reading the code it seems ok to do this conversion. I've some other minor stylistic C correction, i.e. "0x;" is wrong, it should have a "u" postfix. (and "ul" if we care about real C, but anyway POSIX int is 32-bit or more.), but for this I think I (or you) should contact upstream author. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#460302: NMU #460302 in tdb: usr/include/tdb.h uses sig_atomic_t without including signal.h
Jelmer Vernooij wrote: Am Montag, den 14.01.2008, 08:43 +0100 schrieb Giacomo Catenazzi: and the diff PS: This bug will close also a rc-bug in an other package. Please don't upload this. I'm not sure what upstream package you're looking at but tdb_setalarm_sigptr() still exists in upstream gits tdb.h. ok. I'll check how to remove from the delayed queue. Or you can include and upload a new package (so that my package will never be installed). [see POSIX: http://www.opengroup.org/onlinepubs/009695399/basedefs/signal.h.html ] I was locking in: http://viewcvs.samba.org/cgi-bin/viewcvs.cgi/tags/TDB_1_1_0/include/tdb.h?rev=22638&view=auto which seemed me the right source, extrapoled and interpreted from debian/copyright. But I lack of deep knowledge of the project, so I had taken a wrong branch (you were the last commiter). Sorry for my error! ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
