Re: samba crashing in debian etch
Quoting Frederico Rodrigues Abraham ([EMAIL PROTECTED]): > yeah, i can report the bug, but there will be no stack trace, although > samba-dbg is supported to supply these? Well, the mail you received gives you the details about what to do: -check whether you can reproduce the bug consistently -install samba-dbg -send the contents of the samba logs as a bug report While we (samba package maintainers) agree that the first crash is a bug, the available information makes it completely impossible to investigate for both us and our upstream. This is why we now ask bug reporters to first try reproducing such bugs, then install samba-dbg and then only report the bug. signature.asc Description: Digital signature
Re: Use bz2 not gz for orig.tar ?
Le jeudi 12 avril 2007 à 21:15 +0200, Robert Millan a écrit : > I think compression ratio is better than speed in most cases. With better > compressed packages we save archive space, users save a lot of bandwidth, and > the first CD/DVD can hold more stuff. That's important too. You wouldn't say that if you had a Via C3 with 10 Mbit bandwith. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: The number of etch installations is rocketing...
Hi! * Roberto C. Sánchez <[EMAIL PROTECTED]> [070413 00:27]: > > The only caveat I can think of (but there might be others) is that it would > > not be possible to properly count installations that are using > > corporate (or ISP's) caching proxies (in somecases those are transparent to > > the end users) > I think that is the principal problem. I use apt-proxy and have about a > dozen machines (counting virtual machines) that all hit that one > apt-proxy. Yes, and some (like me) use a private mirror for internal use. But at least we could estimate a lower count, which would be better, than the "don't know" we currently have. Yours sincerely, Alexander
Re: The number of etch installations is rocketing...
Roberto C. Sánchez wrote: > On Fri, Apr 13, 2007 at 12:21:09AM +0200, Javier Fernández-Sanguino Peña > wrote: >> The only caveat I can think of (but there might be others) is that it would >> not be possible to properly count installations that are using >> corporate (or ISP's) caching proxies (in somecases those are transparent to >> the end users) >> > I think that is the principal problem. I use apt-proxy and have about a > dozen machines (counting virtual machines) that all hit that one > apt-proxy. > > I am not sure how best to solve that problem. It's probably impossible to get perfectly reliable figures for installations. I'm sure that even the companies that sell their OS don't have exact numbers for installed systems. Presently the number of installations reported to popcon is about the same as the number of subscriptions to debian-security-announce, but I am sure there are many users of debian who don't read d-s-a and many users, who have several -maybe hundreds- of installations and subscribe only once! :-) A combination of voluntary popcon as is, addition of some voluntary hardware information and correlating this information with that from logfiles at security.debian.org would improve the reliability of the present data of popcon significantly. Also with regard to privacy we shouldn't aim at a perfect counting system, but as far as the estimates can be improved, they should. Johannes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFH] CMake and /usr/lib64/
Am 12.04.2007 09:11 schrieb Michal Čihař: > On Thu, 12 Apr 2007 08:49:47 +0200 > Bastian Venthur <[EMAIL PROTECTED]> wrote: >> Does anybody know how to tell CMake not to use /usr/lib64 but /usr/lib >> when building a package on amd64? > > There are needed some special steps? I recently switched Gammu package > to CMake and it automatically installs to /usr/lib. Maybe I found a bug in CMake. Gtk-qt-engine uses both variables: * GTK_LIB_DIR * KDE3_LIB_DIR the first one returns /usr/lib while the latter returns /usr/lib64. In other words, this bug should only affect KDE apps. I wonder which severity this bug should have. Cheers, Bastian -- Bastian Venthur http://venthur.de Debian Developer venthur at debian org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Use bz2 not gz for orig.tar ?
On Fri, Apr 13, 2007 at 09:12:33AM +0200, Josselin Mouette wrote: > Le jeudi 12 avril 2007 à 21:15 +0200, Robert Millan a écrit : > > I think compression ratio is better than speed in most cases. With better > > compressed packages we save archive space, users save a lot of bandwidth, > > and > > the first CD/DVD can hold more stuff. That's important too. > > You wouldn't say that if you had a Via C3 with 10 Mbit bandwith. > Which is by far a minority situation. You are much more likely to end up with someone on a 384k or 512k DSL (or even slower ISDN link) with an opteron, xeon, athlon64 or the like. I'm not saying that your situation is not possible, simply that trading size for compression/decompression time would benefit far more people than it would "hurt." Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: The number of etch installations is rocketing...
On Fri, Apr 13, 2007 at 09:16:33AM +0200, Alexander Schmehl wrote: > > Yes, and some (like me) use a private mirror for internal use. But at > least we could estimate a lower count, which would be better, than the > "don't know" we currently have. > That makes sense. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#419009: ITP: fcode-utils -- OpenBIOS FCode utilities
Package: wnpp Severity: wishlist Owner: Aurelien Jarno <[EMAIL PROTECTED]> * Package name: fcode-utils Version : 1.0.2 Upstream Author : Stefan Reinauer <[EMAIL PROTECTED]> David L. Paktor <[EMAIL PROTECTED]> * URL : http://www.openbios.org * License : GPL v2 + CPL 1.0 Programming Lang: C, Forth Description : OpenBIOS FCode utilities FCode is a Forth programming language dialect compliant with ANS Forth. It can exist in two forms; source code and a compiled version, known as bytecode. It is of interest mainly for its use in OpenFirmware. . This package provides a set of FCode utilities: - the tokenizer toke - the detokenizer detok - a PCI rom header utility - a portable implementation of Forth local values -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: sparc Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-sparc32 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Shouldn't [EMAIL PROTECTED] be more liberal on accepting mail?
This one time, at band camp, Nikita V. Youshchenko said: > Looks like with current setup, [EMAIL PROTECTED] does not accept > mail from domain that does not exist for the outside world. > > This looks suboptimal for me: why not accept all mail that looks like a > popcon report? > > I know that it is possible to do local setup such as mail will look more > legitimate for outside checkers. But shouldn't popcon be as transparent as > possible? Why don't you use the http post option if your email address isn't routable? -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Use bz2 not gz for orig.tar ?
* Drew Parsons <[EMAIL PROTECTED]> [070412 19:55]: > But the question could be made more general. Why do we explicitly > enforce gz compression at the moment, why couldn't we support *any* > compression scheme that upstream developer or Debian maintainer might > care to use? Because it is a packaging format, and a package format should be well defined. Having more than a specific set of compressions causes problems for all kind of use cases (build systems that might want to unpack the package outside of the build environment and thus in an older one, people looking inside some or all packages, ...) and makes security harder (having compressions supported that are used by everyone gives hopes they are roughly checked for vulnerabilities, having everything that anyone might want to use in it means to have some vulnerability in there for sure. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#419048: ITP: fdm -- fetching, filtering and delivering emails
Package: wnpp Severity: wishlist Owner: Frank Terbeck <[EMAIL PROTECTED]> * Package name: fdm Version : 1.1 Upstream Author : Nicholas Marriott <[EMAIL PROTECTED]> * URL : http://fdm.sf.net * License : ISC Programming Lang: C Description : fetching, filtering and delivering emails fdm is a program to fetch mail and deliver it in various ways depending on as user-supplied ruleset. Mail may be fetched from stdin, IMAP or POP3 servers, or from local maildirs, and filtered based on whether it matches a regexp, its size or age, or the output of a shell command. It can be rewritten by an external process, dropped, left on the server or delivered into maildirs, mboxes, to a file or pipe, or any combination. . fdm is designed to be lightweight but powerful, with a compact but clear configuration syntax. It is primarily designed for single-user uses but may also be configured to deliver mail in a multi-user setup. In this case, it uses privilege separation to minimise the amount of code running as the root user. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.19.2-suspend2+ipw2200 (PREEMPT) Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Development environments.
Sex, 2007-04-13 às 14:47 +0300, costin c escreveu: > May be some informations or tips about how to build a particular > package from maintainers/developers of that package could help new > maintainers who want to learn how to build/debug packages in > generally. for taht you have: - new maintainers guide - debian policy - [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Use bz2 not gz for orig.tar ?
On Fri, Apr 13, 2007 at 06:30:53AM -0400, Roberto C. S?nchez wrote: > Which is by far a minority situation. You are much more likely to end > up with someone on a 384k or 512k DSL (or even slower ISDN link) with an > opteron, xeon, athlon64 or the like. I'm not saying that your situation > is not possible, simply that trading size for compression/decompression > time would benefit far more people than it would "hurt." I run a 486DX2/66 on a 3MBit DSL link. I don't compile stuff on it anymore though. I would hate to have package installs get any slower though. :) Of course it isn't a big deal really, and certainly for some people bandwidth is a bigger issue than cpu power. Does the Packages file still come in both gz and bz2? Does it still come uncompressed for that matter? Does it matter now that we have the diffs as well? -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Use bz2 not gz for orig.tar ?
On Fri, 13 Apr 2007, Roberto C. Sánchez wrote: > On Fri, Apr 13, 2007 at 09:12:33AM +0200, Josselin Mouette wrote: > > Le jeudi 12 avril 2007 à 21:15 +0200, Robert Millan a écrit : > > > I think compression ratio is better than speed in most cases. With better > > > compressed packages we save archive space, users save a lot of bandwidth, > > > and > > > the first CD/DVD can hold more stuff. That's important too. > > > > You wouldn't say that if you had a Via C3 with 10 Mbit bandwith. > > > Which is by far a minority situation. You are much more likely to end > up with someone on a 384k or 512k DSL (or even slower ISDN link) with an > opteron, xeon, athlon64 or the like. I'm not saying that your situation > is not possible, simply that trading size for compression/decompression > time would benefit far more people than it would "hurt." You know, make it intelligent enough, and you can have per-arch settings of what compression to use. gzip for arm, lzma for amd64, and source, etc. The dak suite, and dpkg, certainly won't care. It would just work. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Use bz2 not gz for orig.tar ?
On Fri, Apr 13, 2007 at 01:09:50PM -0300, Henrique de Moraes Holschuh wrote: > On Fri, 13 Apr 2007, Roberto C. Sánchez wrote: > > On Fri, Apr 13, 2007 at 09:12:33AM +0200, Josselin Mouette wrote: > > > Le jeudi 12 avril 2007 à 21:15 +0200, Robert Millan a écrit : > > > > I think compression ratio is better than speed in most cases. With > > > > better > > > > compressed packages we save archive space, users save a lot of > > > > bandwidth, and > > > > the first CD/DVD can hold more stuff. That's important too. > > > > > > You wouldn't say that if you had a Via C3 with 10 Mbit bandwith. > > > > > Which is by far a minority situation. You are much more likely to end > > up with someone on a 384k or 512k DSL (or even slower ISDN link) with an > > opteron, xeon, athlon64 or the like. I'm not saying that your situation > > is not possible, simply that trading size for compression/decompression > > time would benefit far more people than it would "hurt." > > You know, make it intelligent enough, and you can have per-arch settings of > what compression to use. gzip for arm, lzma for amd64, and source, etc. > > The dak suite, and dpkg, certainly won't care. It would just work. > Cool. Out of curiousity, how would source packages be handled? Would you allow multiple source upload formats or mandate the "best"? Also, if the uploader uploads a "wrong" format for a binary upload, would the archive repackage it or would it reject the upload? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Shouldn't [EMAIL PROTECTED] be more liberal on accepting mail?
> This one time, at band camp, Nikita V. Youshchenko said: >> Looks like with current setup, [EMAIL PROTECTED] does not accept >> mail from domain that does not exist for the outside world. >> >> This looks suboptimal for me: why not accept all mail that looks like a >> popcon report? >> >> I know that it is possible to do local setup such as mail will look more >> legitimate for outside checkers. But shouldn't popcon be as transparent >> as possible? > > Why don't you use the http post option if your email address isn't > routable? Does it support web proxy? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Development environments.
Please CC the debian-devel list. Sex, 2007-04-13 às 18:26 +0300, costin c escreveu: > On 4/13/07, Luis Matos <[EMAIL PROTECTED]> wrote: > > Sex, 2007-04-13 às 14:47 +0300, costin c escreveu: > > > May be some informations or tips about how to build a particular > > > package from maintainers/developers of that package could help new > > > maintainers who want to learn how to build/debug packages in > > > generally. > > > > for taht you have: > > - new maintainers guide > > - debian policy > > - [EMAIL PROTECTED] > > > > > > Many details (low and high level) are still missing. If new maintainer > or developer has some linux experiences, will do heavily search about > missing details, but if he/she came from *doze at some point, probably > will abandon his/here work. > > Missing details about working with source packages (and other things) > can be found through various sites/forums like > debian-administration.org, debianhelp.co.uk and many other. > > One problem is that all those informations are not centralized or > structured in some way. do you use gnome? Do you know devhelp? This is a good documentation tool, if used. If is there going to be development tasks, Maintainer docs should go there, so the developper has all documentation in one place, and easilly searchable. Something you learn by the documentation in the files that are created with, for example dhmake. other docs are in /usr/share/doc and are not available in a way that user (developer) can easilly read/study. For example, to attach a patch to a debian package ( to change the source code as needed) is just one more call in the rules file and put the patch in place... Comparing with ubuntu, because it is focused in newbies, they have good wiki documentation and howto's. People just go there, follow the howto's and hope they work. Debian on the other hand, i think, have lot's of unrelated doc's. But they have them. For example, one complain i got from rpm packging system is that even if it was more easilly to packge than debian, it was not provided by good documentation. In the case of debian that documentation exists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#419127: ITP: decorator -- simplify the usage of decorators for the average programmer
Package: wnpp Severity: wishlist Owner: Oleksandr Moskalenko <[EMAIL PROTECTED]> * Package name: decorator Version : 2.0.1 Upstream Author : Michele Simionato <[EMAIL PROTECTED]> * URL : http://www.phyast.pitt.edu/~micheles/python/documentation.html * License : BSD Programming Lang: Python Description : simplify the usage of python decorators for the average programmer (Include the long description here.) -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (950, 'unstable'), (500, 'testing'), (10, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-mrb319 (SMP w/4 CPU cores) Locale: LANG=uk_UA.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Use bz2 not gz for orig.tar ?
On Fri, 13 Apr 2007, Roberto C. Sánchez wrote: > Out of curiousity, how would source packages be handled? Would you In whatever way the maintainer told dpkg-dev to for that package, I suppose. > the uploader uploads a "wrong" format for a binary upload, would the > archive repackage it or would it reject the upload? Reject it, I suppose. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The number of etch installations is rocketing...
On Thu, 12 Apr 2007 14:53:42 +0200 Johannes Wiedersich <[EMAIL PROTECTED]> wrote: > For laptops brand/model would be nice, although it probably will be > difficult or impossible to include that in an automated fashion. No it wouldn't. Most laptops have usable information in their smbios which. See dmidecode(8). grts Tim signature.asc Description: PGP signature
Re: The number of etch installations is rocketing...
* Joey Hess <[EMAIL PROTECTED]> (Thu, 12 Apr 2007 15:45:38 -0400): > > Lars Wirzenius wrote: > > However, changing the popcon debconf question to something like the > > following might be an acceptable compromise: > > Farid not, it might result in slightly more installations being > reported, but it will not let us calculate the approximate total number > of new installations, since most people will still choose the default > "No", and we will still have no good number for what percentage don't. As suggested by Simon Josefsson <[EMAIL PROTECTED]> in <[EMAIL PROTECTED]>, the default could be the report-installation-only answer; here it would be: > > [ ] I want to report once that I have installed Debian. The just-hit-enter users would be counted, then, as well as the deliberate popcon participators. At the same time, full privacy would still be available through the not-at-all option, but deliberately. Regards, Fabian -- Fabian "zzz" Pietsch - http://zzz.arara.de/ signature.asc Description: Digital signature
Re: Building i386 binaries on ia64.
On Thu, 2007-04-12 at 20:29 +0100, Rob Andrews wrote: > Hi all, > > I notice ia64 has ia32-libs and ia32-libs-dev, but I can't seem to find a > compiler to build i386 binaries. Use the -m32 option to gcc. Ben. -- Ben Hutchings Never put off till tomorrow what you can avoid all together. signature.asc Description: This is a digitally signed message part
Re: Building i386 binaries on ia64.
On 14-Apr-2007 00:43.04 (BST), Ben Hutchings wrote: > > I notice ia64 has ia32-libs and ia32-libs-dev, but I can't seem to find a > > compiler to build i386 binaries. > Use the -m32 option to gcc. That works on gcc for amd64, but there's no common runtime in /usr/lib/gcc/ia64-linux-gnu/4.1.2/32/, so I don't think it works on ia64. Are you an ia64 user? Does -m32 definitely generate i386 binaries? Thanks for any information you can provide, rob. -- rob andrews :: pgp 0x01e00563 :: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#419155: ITP: aspell-am -- Amharic wordlist for aspell
Package: wnpp Severity: wishlist Owner: Lior Kaplan <[EMAIL PROTECTED]> * Package name: aspell-am Version : 0.03-1 Upstream Author : Daniel Yacob <[EMAIL PROTECTED]> * URL : ftp://ftp.gnu.org/gnu/aspell/dict/am/ * License : Public Domain Description : Amharic wordlist for aspell (Include the long description here.) -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-k7 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFH] CMake and /usr/lib64/
Bastian Venthur <[EMAIL PROTECTED]> writes: > Hi, > > Does anybody know how to tell CMake not to use /usr/lib64 but /usr/lib > when building a package on amd64? > > My quick and dirty solution to fix #417044 would be a modification in > debian/rules where I move /usr/lib64 to /usr/lib, but it would be > cleaner if CMake could take care of this. > > > Cheers, > > Bastian Don't. CMake is correct. The primary location for libraries on amd64 is (/usr)/lib64 and you should compile your code for that. Only when packaging you must move files into (/usr)/lib because dpkg can't handle links in one package (libc6) being directories in others. If you don't compile for /usr/lib64 then you break compatibility with other linux systems. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Building i386 binaries on ia64.
Rob Andrews <[EMAIL PROTECTED]> writes: > Hi all, > > I notice ia64 has ia32-libs and ia32-libs-dev, but I can't seem to find a > compiler to build i386 binaries. > > The reason being is that I want to add support for the Debian nspluginwrapper > package to run on ia64 machines, since they are biarch and have ia32-libs > and ia32-libs-gtk. > > If there isn't a gcc with target i386 on ia64, why is there an ia32-libs-dev > package? I'm quite curious! > > thanks, > rob Afaik ia64 can't compile 32bit binaries. The ia32-libs package source contains prebuild i386 debs that get unpacked to the right places and repackaged into ia32-libs and ia32-libs-dev. Same for ia32-libs-gtk. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
