Re: making debian/copyright machine-interpretable
Mike Hommey wrote:
> Surely, any license text, be it DFSG free or not, can be reformatted.
I rather not speculate on that, or on how this license might be interpreted
legally.
This is the beginning of my license.
The License Text is all text from the first "This" in the sentence above
to the last period at the end of "end of my license", below.
If the License Text contains an odd number of period (".") characters,
then software licenced under my license may not be redistributed or
modified. On the other hand, if the text of this license contains an
even number of characters, then software licened under my license may
be modified, used, and redistributed freely.
This is the end of my license.
Seems better not to go there..
--
see shy jo
signature.asc
Description: Digital signature
Lina and BTS News
Hi Here's the latest activity in the BTS: http://asdfasdf.debian.net/~tar/bts/ If someone can think of other interesting, useful ways to do things with a mirrored BTS (about 23 GB of data) please send me software, patches, scripts to run against the data. I'm not sure how useful lina is, but it's basicallly run some random program against all files in Debian (binary as well as source packages): http://asdfasdf.debian.net/~tar/lina/ Any comments? Yours, Guerkan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Trivial file needed by two packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, with the new upload of python-qt4, it seems I have outsmarted myself. Here's an outline of the problem: python-qt4 contains the Python package PyQt4 (in /usr/lib/python*/site-packages/PyQt4) with all kinds of extension modules and some pure Python modules, along, of course, with an __init__.py. python-qt4 uses py-central, and the pure Python modules are shared between Python versions. In the new upload, I have moved the development configuration module (PyQt4.pyqtconfig) into python-qt4-dev, which is only needed as a build dependency (QScintilla2, which is currently ITP, will need this). This package also uses pycentral, but the files are not shared because pyqtconfig.py differs wrt the Python version used. python-qt4-dev does not depend on python-qt4, and the point is of course to make the build-dependencies a bit lighter. Now the problem is that __init__.py is in python-qt4, but also needed if python-qt4-dev is installed with python-qt4 (otherwise PyQt4.pyqtconfig cannot be imported). There are several solutions, among them: 1) roll the change back, move pyqtconfig.py back to python-qt4 or 2) make python-qt4-dev depend in python-qt4 or 3) create a new package python-qt4-common that only contains __init__.py, which can be depended upon by python-qt4 and python-qt4-dev 1) and 2) are quite simple solutions, but fail to make the build-deps lighter (python-qt4 is quite a large package, Installed-Size: 19380). Solution 3 reaches this goal, but introduces a new package that has no added value. Are there any other solutions? If not, which way should I go? best regards & TIA Torsten - -- Torsten Marek <[EMAIL PROTECTED]> ID: A244C858 -- FP: 1902 0002 5DFC 856B F146 894C 7CC5 451E A244 C858 Keyserver: subkeys.pgp.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGtYaKfMVFHqJEyFgRAp5aAJ9/ddYn8kGXOXBgE50UVjqAnty+lgCfavA1 FcKTr1fJ0qJe7oscDXT3VQw= =19QO -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
www.lebspy.com
http://www.lebspy.com/ http://www.lebspy.com/forums -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making debian/copyright machine-interpretable
On Sat, Aug 04, 2007, Joey Hess wrote: > * Others have mentioned the ordering problem that puts the main license > last. Seems that Packaging-Copyright at the top is another case of > this problem (see you've now removed that special case name, but the > debian/* data would still go there). "Most specific matching glob wins"[1] > might be a better approach. Then the licenses could be ordered with the > main one first, or in whatever order that makes sense to humans, and > if someone wanted to write a tool to extract a given file's license, > that could be done too. ACK. I edited the wiki to reflect your and Zack's view which seems to be the preferred way. For the sake of simplicity, I interpreted "most specific" as "matches the fewer files". It has the drawback of possibly changing with the contents of the source tree, but I fear that any other interpretation is going to be ambiguous in some annoying cornercases. > * Having to munge the license text to fit it in the 822 format is one of > the uglier bits of this proposal, especially since we don't require > that license texts be DFSG free.. Any idea on how to fix that? I tend to reformat license texts with leading "|"s quite often so this didn't really strike me as particularly ugly. 822 seemed like a safe way to escape a license text; if the dots are really an issue, one can use U+00A0 NO-BREAK SPACE or U+FEFF ZERO WIDTH NO-BREAK SPACE or anything crazy like that. > * It's a shame that the boilerplate about where to find the full text of > the GPL is still needed at the end of the file. One way to avoid this > might be to use: > > License: /usr/share/common-licenses/GPL-2 > > The info about which versions apply would need to be expressed some > other way though. ACK. How about parentheses?: License: GPLv2+ (/usr/share/common-licenses/GPL-2) | MPL | LGPLv2.1 (/usr/share/common-licenses/LGPL-2.1) The drawback is that the lines can now become very long, and wrapping them means it's no longer possible to say "first line is license list, the rest is freeform text". But we can live with long lines, I guess. > * I don't see much benefit in putting freeform text at the top of the > file. Keeping it all at the bottom would simplify parsing/validating. I tend to agree with you. The first version used to be like this, and I got many suggestions for adding freeform text at the beginning in order to keep the file human-readable so I switched to allowing it everywhere. I'll wait for more comments on why it may be useful, but the paragraph below about tarball origin seems already a valid use case. > * Makes even more clear that debian/copyright is not the best place for > Source URLs. They rather stick out from the other data, and this would > be a great time to go ahead and move them to the control file. > Dropping them entirely in favour of watch files -- not so good: It's > good to know where a package came from even if a tarball can't be > auto-extracted from there by uscan. But we need freeform text to express how we got the source. When a URL is available, it's all right. But you cannot express "tarball done from branch *** of SVN repository ***, stripped from non-free GFDL files *** and from patented algorithm in file ***, then bootstrapped using automake version *** " with a URL. Which doesn't mean we shouldn't have a link to the URL in debian/control if applicable, of course. Just that it can be done in a separate process and doesn't necessarily involve removing it from debian/copyright. -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Trivial file needed by two packages
Le dimanche 05 août 2007 à 10:12 +0200, Torsten Marek a écrit : > python-qt4-dev does not depend on python-qt4, and the point is of course to > make > the build-dependencies a bit lighter. Now the problem is that __init__.py is > in > python-qt4, but also needed if python-qt4-dev is installed with python-qt4 > (otherwise PyQt4.pyqtconfig cannot be imported). > > There are several solutions, among them: > > 1) roll the change back, move pyqtconfig.py back to python-qt4 > or > 2) make python-qt4-dev depend in python-qt4 > or > 3) create a new package python-qt4-common that only contains __init__.py, > which > can be depended upon by python-qt4 and python-qt4-dev > > > 1) and 2) are quite simple solutions, but fail to make the build-deps lighter > (python-qt4 is quite a large package, Installed-Size: 19380). Solution 3 > reaches > this goal, but introduces a new package that has no added value. > > Are there any other solutions? If not, which way should I go? Python-support 0.7 (currently in experimental) introduces support for namespace packages, which should solve your problem by creating an empty __init__.py file if python-qt4-dev is installed and python-qt4 is not. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Lina and BTS News
Hi, On Sun, 2007-08-05 at 09:16:03 +0200, Gürkan Sengün wrote: > I'm not sure how useful lina is, but it's basicallly run > some random program against all files in Debian (binary as > well as source packages): > http://asdfasdf.debian.net/~tar/lina/ > Any comments? Could you poolize the checks subdirectories? It takes quite some time (and memory) to load each page. thanks, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making debian/copyright machine-interpretable
[Sam Hocevar] >And there is more to come. The GPL version 3 is compatible with > the CDDL, but the GPL version 2 isn???t. Which means that in the near > future, GPLv2-only software cannot be distributed as part of a CDDL > operating system such as Nexenta. That's a rather delicate way of saying "GPLv2-only software cannot be distributed as part of a CDDL operating system such as Nexenta - and this has always been true." -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Bug#436106: ITP: cl-ltk -- A Common Lisp binding to the Tk toolkit
Package: wnpp Severity: wishlist Owner: Oleg Belozeorov <[EMAIL PROTECTED]> * Package name: cl-ltk Version : 0.90 Upstream Author : Peter Herth <[EMAIL PROTECTED]> * URL : http://www.peter-herth.de/ltk * License : LLGPL Programming Lang: Common Lisp Description : A Common Lisp binding to the Tk toolkit Ltk is a Common Lisp interface to the well known Tk graphics toolkit. Tk is probably the graphics toolkit that has been ported to the most platforms. Ltk gives a true Lisp interface to Tk. Every widget is a CLOS object on the Lisp side - so using it is very natural. You can even subclass all widgets to create your custom versions of them. Ltk is written in portable Common Lisp, so it runs under almost any operating system/lisp system combination. Your Ltk applications run everywhere! Ltk is stable and actively maintained. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.22-leviathan (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.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: making debian/copyright machine-interpretable
On Sat, 2007-08-04 at 19:17 +0200, Sam Hocevar wrote: > http://wiki.debian.org/Proposals/CopyrightFormat > >I therefore would like your opinions about this proposal, its > shortcomings, and a strategy to implement it quickly and as widely as > possible. This is great! One possible shortcoming might be the lack of information provided for less widely used licenses (anything requiring an 'other' value in the License field). How much Debian should be concerned about such licenses is no doubt up to debate, but especially in non-free there are likely many such cases. One possible solution that I have in mind would be to add information about the terms of the license in a machine-readable way. Perhaps something along the lines of what Creative Commons has done with mod_cc[1], but with several additions that suit Debian's (and Debian's users) requirements. I am imagining another field something like License-Terms: Requires-Attribution, Noncommercial, Choice-of-Venue, SSL-Exception, GPL-Compatible Clearly the exact terms and their meaning would require a bit of discussion, but should ideally include tags which would be as unambiguous as possible and would cover as many of the properties of licenses as we can that are important to Debian end-users, without making the License-Terms field longer than the license itself... Of course, this idea does have several limitations: * It is not particularly useful for well known licenses. Perhaps for any license besides "other", these values could be inferred? * There will be both mistakes and misinterpretations of these terms, regardless of how well defined they can be made in proposals. Mistakes happen. Does this pose a legal problem for Debian if individuals act based on the tags and are later held liable for license violations? * There will no doubt be different interpretations of whether or not a license deserves a particular tag (as there are now about whether or not a license meets the DFSG). Who will be ultimately responsible for the tags, and is that influenced by the previous point about potential liability? * This is not a replacement for people actually reading the licenses of the software they are installing. The tags can not cover every possible facet of a software license and any license-conscious end-user (individual or corporate) will still need to read the licenses of their software to make sure they are in compliance with its terms. That said, I hope that this does provide meaningful benefit. The primary benefit that I envision is to eventually allow users to select which license terms they find acceptable and which they do not and to limit their package installations on that basis. As mentioned above, this is not a complete solution, since the licenses must still be read in full, but it would cut down on the amount of packages which require consideration. For example, corporate users may select a policy which would not consider packages tagged Noncommercial, allowing their license review teams to only look at packages which may be usable by their company. It could also allow users with their own particular definitions of freeness to easily select packages that fit their desires. Thoughts, comments, and criticisms welcome. Cheers, Kevin 1. http://web.resource.org/rss/1.0/modules/cc/ P.S. By making this suggestion, I am volunteering to help with the huge amount of work that it requires. ;) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Symbol-based dependencies on shared libraries: some news
On Sat, 04 Aug 2007, Steve Langasek wrote: > On Sat, Aug 04, 2007 at 10:41:25PM +0200, Raphael Hertzog wrote: > > On Sat, 04 Aug 2007, Loïc Minier wrote: > > > Do you strip the "well known symbols" you've seen on each arch so that > > > one only has to specify the other symbols? > > > No, because they might change with the toolchain and we want to track that > > properly... > > Why does it need tracking? If these symbols were to disappear that would > be no loss, it shouldn't be relevant to the library ABIs at all. I think it > would indeed be better to exclude these symbols from the list. Somehow I always thought that the executables were using those symbols. If that's not the case, and if they are only used by the internal machinery (i.e. none of those symbols actually appear undefined in objdump's output of a program), then I'll happily strip them from the symbols file. That exclude list will still have to be maintained over the years I think since the list will probably evolve. I'm checking for example on a powerpc machine: /bin/ls: file format elf32-powerpc DYNAMIC SYMBOL TABLE: 10025168 DF *UND* 0010 GLIBC_2.0 readlink 10025170 DF *UND* 0154 GLIBC_2.0 getgrnam 1001136c gDF .text 003c Base_restgpr_18 10025178 DF *UND* 003c GLIBC_2.2 __fpending 10011444 gDF .text 0014 Base_restgpr_31_x 1001138c gDF .text 001c Base_restgpr_26 100112f8 gDF .text 0018 Base_savegpr_27 10011384 gDF .text 0024 Base_restgpr_24 10011424 gDF .text 0034 Base_restgpr_23_x So it looks like those symbols are defined in each and every binary. But the programs do not rely on the same symbols from the libraries. Thus it seems fine to exclude them from the symbols files. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd
On Sun, Aug 05, 2007 at 05:39:11PM +0200, SZALAY Attila wrote: > Yes, but you cannot exploit the power of more than one CPU without > multithreading. This is wrong. Note that "multithreading" is a different concept from spawning many processes (ie. the traditional UNIX fork() model). /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#435838: ITP: cpm -- Console Password Manager
Brian May <[EMAIL PROTECTED]> wrote: >> "John" == John Goerzen <[EMAIL PROTECTED]> writes: > John> The software uses CDK (ncurses) to handle the user > John> interface, libxml2 to store the information, the zlib > John> library to compress the data and the library GpgMe to > John> encrypt and decrypt the data securely. > The description seems pretty good. My initial tests seem to suggest it > requires an old version of libcdk that is no longer available in > Debian though: ...was never in Debian, iirc - it requires an older version of the flavor which I maintain. I'm told that the main issue is that it wants to be able to have zero-length lists. I looked into this a few months ago, and found that debugging cpm is going to be work (it doesn't seem to have a mode where I can run it without privileges, trace the result, etc). When I find time to resolve those issues, I'll put out a new version of cdk... -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd
Hi All! On Sat, 2007-08-04 at 22:39 +0200, Steinar H. Gunderson wrote: > > Your system admins sound rather odd. Lots of software is high performance > without ever using threads at all. Yes, but you cannot exploit the power of more than one CPU without multithreading. Of course it's an other question that this power is needed to handle system logging. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd
On Sun, 2007-08-05 at 17:43 +0200, Steinar H. Gunderson wrote: > > This is wrong. Note that "multithreading" is a different concept from > spawning many processes (ie. the traditional UNIX fork() model). You are right, but (I think) it's not harder to write a program which is multithread than which is multiprocess. (And I think that there is no multiprocess logging program too.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#436138: ITP: libtemplate-plugin-xml-perl -- XML plugin for the Template Toolkit
Package: wnpp Severity: wishlist Owner: Dominic Hargreaves <[EMAIL PROTECTED]> * Package name: libtemplate-plugin-xml-perl Version : 2.17 Upstream Author : Andy Wardley <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/Template-XML/ * License : Dual GPL/Artistic Programming Lang: Perl Description : XML plugin for the Template Toolkit This package provides a number of Template Toolkit plugin modules for working with XML. The Template::Plugin::XML module is a front-end to the various other XML plugin modules. Through this you can access XML files and directories of XML files via the Template::Plugin::XML::File and Template::Plugin::XML::Directory modules (which subclass from the Template::Plugin::File and Template::Plugin::Directory modules respectively). You can then create a Document Object Model (DOM) from an XML file (Template::Plugin::XML::DOM), examine it using XPath queries (Template::Plugin::XML::XPath), turn it into a Perl data structure (Template::Plugin::XML::Simple) or parse it as an RSS (RDF Site Summary) file. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
New PAM in experimental needs testing
Hi folks, A new version of PAM (0.99.7.1-1) has been packaged and uploaded to experimental. This is intended to replace 0.79-4. However, because there have been quite a number of upstream changes, and all the Debian-specific patches against the old one were painstakingly re-diffed and updated by hand, and because a broken PAM means a rather broken system, this new version needs some wider testing before it is suitable for unstable. The work for this was done by myself and Jan Christoph Nordholz, who rewrote the @include patch, fixing a memory leak in the current code, as well as doing a lot of testing, building and general reviewing of the PAM packaging. It's thanks to Jan that it's ready for wider review, since I did all the rediffing back in April, but lacked time to squash the last few bugs. If anyone could take the time to install it, test all the services using PAM for authentication/authorisation still work as expected, and report any defects, that would be much appreciated. If you want to avoid breaking your system, it is advisable to install into a chroot. However, we have tested that basic functionality does work (su and passwd in particular), so it should be safe to install for real (but no guarantees are given). Additionally, all of the packages which Build-Depend, Depend or Recommend PAM packages should be tested against the new packages. A complete list is given below, and the maintainer's Bcc'd with this message. If you do hack on the PAM sources, note that the dpatch patch order is important--later patches do rely on earlier patches being present. Also, you need to run "debian/rules patch|unpatch" by hand, due to the need to re-bootstrap the autotools. To do that "debian/rules bootstrap" will do everything consistently, providing the patches are applied. Some bits which need wider review and discussion: Several of the Debian-specific patches should probably be removed. For example, the @include (Debian-specific) syntax should be replaced by the include mechanism added by upstream; we should make this a release goal for Lenny IMO. Maintaining Debian-specific hacks imposes a real burden on the PAM maintainers--it took over 15 man hours to do the main re-diffing, and the same again to get it working, which is ridiculous and error-prone. We could easily be introducing Debian-specific security bugs by doing so. Some checks such as the obscure checks for pam_unix and chroot limits for pam_limits should be dropped (who uses this functionality)? The obsure checks appear to predate PAM, but should cracklib not be the replacement? This non-standard stuff should really be deprecated, obsoleted, then dropped. What do other people think about this? The remaining patches should then really be pushed upstream, which possible now we are synched with their latest stable release. One other note: upstream now default to enabling cracklib in pam_unix (in addition to pam_cracklib), which causes passwd to do all the extra checks cracklib does. This has been disabled for now after discussion with Jan, because it brings in quite a few dependencies into base, and may not be generally wanted. It also breaks passwd if you don't have cracklib-runtime *and* a wordlist *and* run update-cracklib, so this needs some fixing of dependencies and coordination to do properly. It might be worth re-adding, if there was consensus for that. I'm not yet sure how this differs from the pam_cracklib functionality, however. Regards, Roger Laszlo Boszormenyi (GCS) <[EMAIL PROTECTED]> gradm2 Stefan Hornburg (Racke) <[EMAIL PROTECTED]> courier courier-authlib pure-ftpd Richard A Nelson (Rick) <[EMAIL PROTECTED]> libnss-ldap libpam-ldap Marco Presi (Zufus) <[EMAIL PROTECTED]> linesrv Krzysztof Krzyzaniak (eloy) <[EMAIL PROTECTED]> popa3d Russ Allbery <[EMAIL PROTECTED]> libpam-afs-session Sebastien Bacher <[EMAIL PROTECTED]> libgnomesu Carlos Barros <[EMAIL PROTECTED]> tac-plus Dima Barsky <[EMAIL PROTECTED]> python-pam Vincent Bernat <[EMAIL PROTECTED]> xrdp Michael Biebl <[EMAIL PROTECTED]> partimage Laurent Bigonville <[EMAIL PROTECTED]> pam-keyring Blars Blarson <[EMAIL PROTECTED]> nntp Primoz Bratanic <[EMAIL PROTECTED]> pam-pgsql Joachim Breitner <[EMAIL PROTECTED]> poldi Adrian Bridgett <[EMAIL PROTECTED]> dante Chris Butler <[EMAIL PROTECTED]> wu-ftpd Rubén Porras Campo <[EMAIL PROTECTED]> libpam-encfs Pierre Chifflier <[EMAIL PROTECTED]> nufw wzdftpd Adam Conrad <[EMAIL PROTECTED]> poppassd Christopher Cramer <[EMAIL PROTECTED]> usermode Debian CUPS Maintainers <[EMAIL PROTECTED]> cupsys Debian Cyrus SASL Team <[EMAIL PROTECTED]> cyrus-sasl2 cyrus-sasl2-heimdal Debian Cyrus Team <[EMAIL PROTECTED]> cyrus-imapd-2.2 Debian Edu Developers <[EMAIL PROTECTED]> debian-edu Debian GNOME Maintainers <[EMAIL PROTECTED]> gdm Debian Kolab Maintainers <[EMAIL PROTECTED]> kolab-cyrus-imapd Debi
Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd
On Sun, Aug 05, 2007 at 06:02:11PM +0200, SZALAY Attila wrote: >> This is wrong. Note that "multithreading" is a different concept from >> spawning many processes (ie. the traditional UNIX fork() model). > You are right, but (I think) it's not harder to write a program which is > multithread than which is multiprocess. This is also wrong. All threads in a program share address space, which means that all variables are shared by default, which means that every single non-local variable access has the potential of a race condition. Multiprocess is the complete opposite -- the address spaces are separated unless you explicitly use shared memory. (You'll still have to lock files and such, but that's comparatively easy.) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/05/07 10:39, SZALAY Attila wrote: > Hi All! > > On Sat, 2007-08-04 at 22:39 +0200, Steinar H. Gunderson wrote: >> Your system admins sound rather odd. Lots of software is high performance >> without ever using threads at all. > > Yes, but you cannot exploit the power of more than one CPU without > multithreading. Of course it's an other question that this power is > needed to handle system logging. Are you saying that Apache 1.x only ever used 1 CPU? - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGthIfS9HxQb37XmcRAimtAJ9q/icb0kOqfSnLNAdMioaETLftUACfc/n+ pcYPKVame/87ZgGY6SVbQuk= =uO1/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making debian/copyright machine-interpretable
Sam Hocevar wrote:
>ACK. I edited the wiki to reflect your and Zack's view which seems to
> be the preferred way.
>
>For the sake of simplicity, I interpreted "most specific" as "matches
> the fewer files". It has the drawback of possibly changing with the
> contents of the source tree, but I fear that any other interpretation is
> going to be ambiguous in some annoying cornercases.
I belive that it's possible to implement specificity comparison without
looking at the source tree.
Consider a glob parser that counts how many characters of the filename
are matched using literals in the glob ("[a-zA-Z]"), how many are
matched using ? and how many using *. The comparison is then using the
perl <=> operator:
literalsA <=> literalsB ||
questionsA <=> questionsB||
starsA <=> starsB||
disambiguateA <=> disambiguateB
The disambiguation function needs to handle cases where two globs
somehow still matched equally. For example, for file "foo", "f??" and "?o?"
both match equal numbers of liternals and questions. Seems that something
arbitrary has to be done here, but it can be as simple as saying that the
glob with the most specific leftmost side is most specific. (Leaving
definition of "leftmost" to the implementor, because I have to run.)
>Any idea on how to fix that? I tend to reformat license texts with
> leading "|"s quite often so this didn't really strike me as particularly
> ugly. 822 seemed like a safe way to escape a license text; if the dots
> are really an issue, one can use U+00A0 NO-BREAK SPACE or U+FEFF ZERO
> WIDTH NO-BREAK SPACE or anything crazy like that.
License: BSD-ish
Licensed under a 2-clause version of the BSD license, included below.
License: GPL-2+
Some portions are licensed under the GPL version 2, or above. The full
text of the GPL can be found in /usr/share/common-licenses/GPL-2 on
Debian systems.
...
[debconf license here]
?
> > * It's a shame that the boilerplate about where to find the full text of
> > the GPL is still needed at the end of the file. One way to avoid this
> > might be to use:
> >
> > License: /usr/share/common-licenses/GPL-2
> >
> > The info about which versions apply would need to be expressed some
> > other way though.
>
>ACK. How about parentheses?:
>
> License: GPLv2+ (/usr/share/common-licenses/GPL-2) | MPL | LGPLv2.1
> (/usr/share/common-licenses/LGPL-2.1)
>
>The drawback is that the lines can now become very long, and wrapping
> them means it's no longer possible to say "first line is license list,
> the rest is freeform text". But we can live with long lines, I guess.
Yeah, on second thought I sorta prefer the example above, of sticking
the boilerplate in the extended description. This assumes that licenses
with an extended description can still be standard licenses.
--
see shy jo
signature.asc
Description: Digital signature
Re: making debian/copyright machine-interpretable
* Sam Hocevar: > On Sat, Aug 04, 2007, Florian Weimer wrote: > >> It's probably better to use a separate file. If there's a syntax >> error, you can't be sure if the file is in the old format, or if its a >> genuine error. > >But the information must be in debian/copyright. Why? I don't think this has to be the case for the machine-readable part. > Duplicating it is not an option. Your proposal is all about duplicating data. >> Copyright statements with year numbers need to be updated once per >> year, complicating merging from upstream. Is this really worth the >> effort? Copyright holder information is probably not very valuable >> without unique identifiers per copyright holder anyway. > >This information is required for debian/copyright, too. Policy doesn't say so, it seems. > The proposal just puts it in a header. It's impractical to list all copyright holders. For instance, the FSF is sometimes sloppy with its paperwork and accepts patches without copyright assignments. If there was a rule "all copyright holders must be listed", we'd need access to the FSF's secret records to compile the list. And if I submit a patch, there's no way to tell easily if it's copyright by me or by Enyo A/S. > Citing copyright years is not useful, but it's probably required by > law. Over here, law requires that you name authors, not copyright holders (or refrain from naming them, if that's what they demand). We should better ignore that law. 8-/ >> In order to automatically detect licensing violations, the files in >> the binary package would need annotations. Annotating the source >> files is not sufficient. > >That's right, we don't know the licensing terms of binary files. > But if we stop at the "it's not sufficient" argument, we'll never get > anywhere, because it is impossible for a source package to determine the > exact licensing terms of its binary packages. Something involving ELF sections and magic headers (for scripts) could do the job. My concern is that we actually need the binary package thing, and once we have that, we've got the data in about five places: - source file headers - upstream README/license file - debian/copyright, free-form text - debian/copyright (or wherever else), machine-readable format (your proposal) - metadata for generating the binary package data This is a bit excessive. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
rpath and library
Hi ! lintian and linda are issuing a warning when a library contains an rpath statement. However, lintian accepts rpath being /usr/lib/package while lindian does not do this test. Here is the lintian warning: 8<--- Info: The binary or shared library sets RPATH. This overrides the normal library search path, possibly interfering with local policy and causing problems for multilib, among other issues. . The only time a binary or shared library in a Debian package should set RPATH is if it is linked to private shared libraries in the same package. In that case, place those private shared libraries in /usr/lib/package. Libraries used by binaries in other packages should be placed in /lib or /usr/lib as appropriate, with a proper SONAME, in which case RPATH is unncessary. . To fix this problem, look for link lines like: gcc test.o -o test -Wl,--rpath,/usr/local/lib or gcc test.o -o test -R/usr/local/lib and remove the -Wl,--rpath or -R argument. You can also use the chrpath utility to remove the RPATH. 8<--- Whos is right here ? lintian or linda ? -- BOFH excuse #177: sticktion -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd
Hi All! On Sun, 2007-08-05 at 19:55 +0200, Steinar H. Gunderson wrote: > > This is also wrong. All threads in a program share address space, which means > that all variables are shared by default, which means that every single > non-local variable access has the potential of a race condition. Multiprocess > is the complete opposite -- the address spaces are separated unless you > explicitly use shared memory. (You'll still have to lock files and such, but > that's comparatively easy.) I'm on a direct opposite opinion. Yes, there are some rules what you have to keep but in other way it's easy to program. (I know I'm a developer :) First the stack differ in every thread so it's safe to use it. And all local variable allocated in stack. And yes, I know that the choosen method is depend on the function. But I think that this function is better to implement with multithread than multiprocess, because: 1. Reading a log message and write it to a file is highly paralellable. 2. There may be a lot of paralell reading. (the config) 3. We have to ballance the load about message, not connection because sometimes a small number of programs (maybe one) generate a big part of messages. 4. IIRC one of the most important reason to choose multiprocess programing is not that multiprocessing is easier to implement than multithreading but the memory leaks. So if I had to choose I surely choose multithreading. And I think that the real question is that there is place in Debian for a multithread/process system logging daemon (against the singlethread ones) or not. And I think that this dispute is onlt theoretical. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd
Hi All! On Sun, 2007-08-05 at 13:08 -0500, Ron Johnson wrote: > > Are you saying that Apache 1.x only ever used 1 CPU? I protest for multithread/process applications agains singlethread ones. I doesn't care which paralellization is used i just want to say that it's not too bad to write a multiXXX system logging daemon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd
On Sun, Aug 05, 2007 at 10:34:03PM +0200, SZALAY Attila wrote: > Hi All! > > On Sun, 2007-08-05 at 13:08 -0500, Ron Johnson wrote: > > > > Are you saying that Apache 1.x only ever used 1 CPU? > > I protest for multithread/process applications agains singlethread ones. > > I doesn't care which paralellization is used i just want to say that > it's not too bad to write a multiXXX system logging daemon. Why ? Do you need 4 CPU to soak your hard drive ? There is usually one partition for every logs on the machine, so you don't get a lot writing many log files at a time. And if you're that concerned with performance, then it's not multi-foo that you need, but aio's, and a big nice epoll loop to dispatch /dev/log clients. And absolutely no multiple processes that you will else have to deal with locking, especially locking of output files, which would be a huge mistake. The syslog daemon shall not eat anymore than 0.01% of your CPU. Why would you need to bloat it for god's sake ? It reminds me of so called network monitors that are so huge, that they mostly measure their own fat. A multi-foo syslog daemon is just plain silly. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpRqyWDB7d37.pgp Description: PGP signature
Re: Symbol-based dependencies on shared libraries: some news
On Sun, Aug 05, 2007 at 05:11:53PM +0200, Raphael Hertzog wrote: > On Sat, 04 Aug 2007, Steve Langasek wrote: > > On Sat, Aug 04, 2007 at 10:41:25PM +0200, Raphael Hertzog wrote: > > > On Sat, 04 Aug 2007, Loïc Minier wrote: > > > > Do you strip the "well known symbols" you've seen on each arch so that > > > > one only has to specify the other symbols? > > > No, because they might change with the toolchain and we want to track that > > > properly... > > Why does it need tracking? If these symbols were to disappear that would > > be no loss, it shouldn't be relevant to the library ABIs at all. I think it > > would indeed be better to exclude these symbols from the list. > Somehow I always thought that the executables were using those symbols. > If that's not the case, and if they are only used by the internal > machinery (i.e. none of those symbols actually appear undefined in objdump's > output of a program), then I'll happily strip them from the symbols file. Yes, they are symbols that are not referenced by other objects. In fact, I believe you'll find in the case of each of these symbols that *every* binary on the given architecture includes their own copy of these symbols, including executables as well as libraries. > That exclude list will still have to be maintained over the years I think > since the list will probably evolve. Hopefully it will evolve with negative magnitude, so we get fewer such symbols over the years rather than more of them. :) I've seen other people opine before, and I agree, that these extra exported symbols ought to be considered bugs in the toolchain, and ought to eventually be removed from the export list. > I'm checking for example on a powerpc machine: [...] > So it looks like those symbols are defined in each and every binary. > But the programs do not rely on the same symbols from the libraries. > Thus it seems fine to exclude them from the symbols files. Yep. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd
Hi All! On Sun, 2007-08-05 at 23:07 +0200, Pierre Habouzit wrote: > > Why ? Do you need 4 CPU to soak your hard drive ? There is usually one > partition for every logs on the machine, so you don't get a lot writing > many log files at a time. And if you're that concerned with performance, > then it's not multi-foo that you need, but aio's, and a big nice epoll > loop to dispatch /dev/log clients. And absolutely no multiple processes > that you will else have to deal with locking, especially locking of > output files, which would be a huge mistake. You are wrong because (and this is what I have said) aio and epoll couldn't gain anything from the second processor. You can prove this if you try. (I have tried.) > The syslog daemon shall not eat anymore than 0.01% of your CPU. Why > would you need to bloat it for god's sake ? It reminds me of so called > network monitors that are so huge, that they mostly measure their own > fat. A multi-foo syslog daemon is just plain silly. Yes, you are right in a Desktop. You are right in a server too. But if you want to collect log messages from some hundred machine is an other question. And it's more easy to put another CPU into the machine than double the clock rate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd
On Sun, Aug 05, 2007 at 10:25:34PM +0200, SZALAY Attila wrote: > And yes, I know that the choosen method is depend on the function. But I > think that this function is better to implement with multithread than > multiprocess, because: > > 1. Reading a log message and write it to a file is highly paralellable. > > 2. There may be a lot of paralell reading. (the config) > > 3. We have to ballance the load about message, not connection because > sometimes a small number of programs (maybe one) generate a big part of > messages. Since messages arrive on a single socket (usually connection-less) ultimately the messages enter through one process/thread. And they get written to a file or database which is ultimately not parallelable either. Is there a huge amount of processing in between which justifies multithreading? Also does rsyslog guarantee that messages are logged in the order they are sent? If messages may take different paths due to multi-threading I guess this would need extra care. > And I think that the real question is that there is place in Debian for > a multithread/process system logging daemon (against the singlethread > ones) or not. And I think that this dispute is onlt theoretical. :) My original question was why you would mention multi-threaded in the short description of rsyslog? Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd
On Sun, Aug 05, 2007 at 11:49:12PM +0200, SZALAY Attila wrote: > Hi All! please don't CC me, I read the list, and my M-F-T specifically ask you not to do so[0]. > On Sun, 2007-08-05 at 23:07 +0200, Pierre Habouzit wrote: > > Why ? Do you need 4 CPU to soak your hard drive ? There is usually one > > partition for every logs on the machine, so you don't get a lot writing > > many log files at a time. And if you're that concerned with performance, > > then it's not multi-foo that you need, but aio's, and a big nice epoll > > loop to dispatch /dev/log clients. And absolutely no multiple processes > > that you will else have to deal with locking, especially locking of > > output files, which would be a huge mistake. > > You are wrong because (and this is what I have said) aio and epoll > couldn't gain anything from the second processor. You didn't answered, why is there any kind of gain to use another CPU where 1/100 of one is enough ? > You can prove this if you try. (I have tried.) I code daemons using epoll and such techniques (without threads or even multiple processes of course) for a living. > > The syslog daemon shall not eat anymore than 0.01% of your CPU. Why > > would you need to bloat it for god's sake ? It reminds me of so called > > network monitors that are so huge, that they mostly measure their own > > fat. A multi-foo syslog daemon is just plain silly. > > Yes, you are right in a Desktop. You are right in a server too. But if > you want to collect log messages from some hundred machine is an other > question. And it's more easy to put another CPU into the machine than > double the clock rate. That's very blunt assertions, backed up with nothing. The bottleneck in any application that has big flows of data to write somwhere, is the hard drive (or you're a very crappy programmer). So please explain to me how using more CPU will make you able to write faster to your hard drive. I'm sure that would be enlightening. Hint: For a hundred machines, even very busy ones, you don't need multiple processes to collect the logs. And for a thoudand, you'll merely need a setrlimit to overcome the 1024-file-descriptor-limit. [0] thanks Mister Ray not to start a new MFT flame. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgprzgwlnKQVp.pgp Description: PGP signature
Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd
On Mon, Aug 06, 2007 at 08:15:58AM +1000, Hamish Moffatt wrote: > On Sun, Aug 05, 2007 at 10:25:34PM +0200, SZALAY Attila wrote: > > And I think that the real question is that there is place in Debian for > > a multithread/process system logging daemon (against the singlethread > > ones) or not. And I think that this dispute is onlt theoretical. :) > > My original question was why you would mention multi-threaded in the > short description of rsyslog? To scare people away. But maybe the ability to log into mysql was enough. No kidding, that's a great feature of the Description, it says to every clever sysadmin: don't use me. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpNVZ8IFVgYf.pgp Description: PGP signature
Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd
Pierre Habouzit wrote: > To scare people away. But maybe the ability to log into mysql was > enough. No kidding, that's a great feature of the Description, it says > to every clever sysadmin: don't use me. Well, I don't know if you or me or Debian will use it but Fedora is going to switch to it as the default syslog server for F8. It may be a mistake from their part of course but it certainly deserves at least another look because of that. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making debian/copyright machine-interpretable
On 11102 March 1977, Sam Hocevar wrote: > License: GPLv2+ (/usr/share/common-licenses/GPL-2) | MPL | LGPLv2.1 > (/usr/share/common-licenses/LGPL-2.1) >The drawback is that the lines can now become very long, and wrapping > them means it's no longer possible to say "first line is license list, > the rest is freeform text". But we can live with long lines, I guess. Veto, i dont want to scroll miles of horizontal text in a line, just to see if every needed license is mentioned. (A task that this proposal doesnt get away with from NEW, as its simply impossible to do fully automagical) -- bye Joerg Joey was bist du eigentlich offiziell im debian projekt genau? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rpath and library
On Aug 05, Vincent Bernat <[EMAIL PROTECTED]> wrote: > lintian and linda are issuing a warning when a library contains an rpath > statement. However, lintian accepts rpath being /usr/lib/package while > lindian does not do this test. > Whos is right here ? lintian or linda ? lintian. -- ciao, Marco signature.asc Description: Digital signature
ITA: anthy
At Sat, 04 Aug 2007 00:11:51 +0900, Masahito Omote wrote: > I intend to orphan the anthy package. Because I cannot take enough time > to catching up anthy's release and because no one take over or become a > co-maintainer of this package in [EMAIL PROTECTED] and > [EMAIL PROTECTED] I'll take it, but I have no time in a few days. -- NOKUBI Takatsugu E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] / [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
