Re: Very BIG Problem with debian packages versioning...
On Fri, Oct 29, 2004 at 11:51:44AM +0200, Vincenzo Belloli wrote: > Package: clamav-daemon > Version: 0.80-2 > The problem is related to clamav debian packages maintained by ... and > hosted here: > deb http://people.debian.org/~sgran/debian woody main > I've 2 identical machines. These are versions installed in the 2 machines: > server1# dpkg -l | grep clam > ii clamav 0.80-2 Antivirus scanner for Unix > ii clamav-base0.80-2 Base package for clamav, an anti-virus > utili > ii clamav-daemon 0.80-2 Powerful Antivirus scanner daemon > ii clamav-freshcl 0.80-2 Downloads clamav virus databases from > the In Note this package here.^^ > ii clamav-testfil 0.80-2 Use these files to test that your > Antivirus > ii libclamav1 0.80-2 Virus scanner library > ii libclamav1-dev 0.80-2 Clam Antivirus library development files > server2# dpkg -l | grep clam > ii clamav 0.80-2 Antivirus scanner for Unix > ii clamav-base0.80-2 Base package for clamav, an anti-virus > utili > ii clamav-daemon 0.80-2 Powerful Antivirus scanner daemon > ii clamav-freshcl 0.80-2 Downloads clamav virus databases from > the In Note this package here too.^^ > ii clamav-testfil 0.80-2 Use these files to test that your > Antivirus > ii libclamav1 0.80-2 Virus scanner library > ii libclamav1-dev 0.80-2 Clam Antivirus library development files > > BUT THIS IS THE MATTER: on the 2 machines there are different versions > of clamd anche clamdscan. Why che debian packages have not been updated > Is it normal that the same debian package version contains > different program versions > > server1# clamd -V > ClamAV 0.80/559/Thu Oct 28 15:08:33 2004 > server1# clamdscan -V > ClamAV 0.80/559/Thu Oct 28 15:08:33 2004 > > server2# clamd -V > ClamAV 0.80/560/Fri Oct 29 09:32:46 2004 > server2# clamdscan -V > ClamAV 0.80/560/Fri Oct 29 09:32:46 2004 *cough* That's "Program version/Database version/Database date". > Now, if i want v.560 on all machines must uninstall the packages and > reinstall them, because from the dpkg point of view the packages has not > changed !! Or just wait for freshclam to update server1... Did you do these at the same time, or was there a day between server1's output and server2's output? ^_^ -- --- Paul "TBBle" Hampson, MCSE 7th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: debian.org e-mail address and SPF/SRS
On Thu, Nov 04, 2004 at 12:15:19AM +0100, Osamu Aoki wrote: > I am facing a problem with my ISP started filtering incoming mails with > SPF. Since AOL adopted it, it seems becoming quite popular as I see it. [...] > SPF has known issue with e-mail forwarder such as pobox.com. I think > debian.org mail address is no exception. This is expected behavior. > > Since debian.org address is used frequently used to receive debian bug > report, this is not a desirable situation. Unless some serious concern > was raised here, I think implementing SRS[3] type infrastructure will be > nice. > > If you know easy way to avoid this problem exists, please let me know. > (Changing ISP is certainly an option.) That's more or less your option. Your current ISP feels that it is market-advantageous to do that for all it's customers, seemingly without a means for you to turn it off if you don't want it. As such, your option would be to firstly talk to your ISP about their practice, and explain that you, as a customer, do not want this service. If they are not amenable to providing you with the service you want, then you would be well advised to move to an ISP that will provide you with the service you want. Only time will tell if SPF will be a great marketing draw-card or not. - Matt signature.asc Description: Digital signature
debian.org e-mail address and SPF/SRS
Hi, Disclaimer: I am not asking Debian to use SPF[1] to filter incoming ML posts. If this has been discussed, excuse me. I am facing a problem with my ISP started filtering incoming mails with SPF. Since AOL adopted it, it seems becoming quite popular as I see it. I understand my ISP's rationale which is to reduce virus mails hitting ISP's mail server. I also understand that SPF will not be a bullet proof against mail forgery. It also seems that it is a relatively low CPU time cost method to reduce unwanted incoming messages. This SPF has caused very annoying problem to some people who implemented proper SPF policy with "-all" and tried to send me an e-mail through my DD account. The forwarded mail from Debian is REJECTED due to SPF policy on my ISP side.[2] SPF has known issue with e-mail forwarder such as pobox.com. I think debian.org mail address is no exception. This is expected behavior. Since debian.org address is used frequently used to receive debian bug report, this is not a desirable situation. Unless some serious concern was raised here, I think implementing SRS[3] type infrastructure will be nice. If you know easy way to avoid this problem exists, please let me know. (Changing ISP is certainly an option.) If it is a good idea to implement SRS at debian.org mail server, let's consider. Regards, Osamu References: [1] http://spf.pobox.com/mechanisms.html [2] Currently my ISP reject mail with "-all" policy. [3] http://spf.pobox.com/emailfwdpng.html
Re: Bug#279422: ITP: python-nltk -- A suite of Python libraries for natural language procesing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package is ready, it's name is python-nltk and can be downloaded from www.igaelica.com/debian. apt-get url is, deb www.igaelica.com/debian ./ Please report any bug or improvement Best regards, - -- Alberto Rodriguez Galdo [EMAIL PROTECTED] GPG 747A7479 El Martes, 2 de Noviembre de 2004 23:58, Alberto Rodriguez Galdo escribió: > Package: wnpp > Severity: wishlist > > * Package name: python-nltk > Version : 1.4.2 > Upstream Author : University of Pensylvania > * URL : http://nltk.sourceforge.net > * License : GPL > * Description : A suite of Python libraries for natural language > procesing > > NLTK, the Natural Language Toolkit, is a suite of Python libraries and > programs for symbolic and statistical natural language processing. NLTK > includes graphical demonstrations and sample data. It is accompanied > by extensive documentation, including tutorials that explain the > underlying concepts behind the language processing tasks supported by the > toolkit. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBiTh+wlFDGnR6dHkRAvm1AJ46SeuBZBStw5/jQ7EFWqqEqefriACfeo1j /8KaXsiaToJhmXJ1ueh/7Vs= =ynsu -END PGP SIGNATURE-
Bug#279555: ITP: wacom-tools -- support for Wacom graphics tablets in Debian
Package: wnpp Severity: wishlist Tools and documentation, mostly from linuxwacom.sf.net and my own experience getting one working on a Debian system today. Details TBA. Ron
Bug#279551: ITP: zsync -- A client-side implementation of the rsync algorithm
Package: wnpp Severity: wishlist * Package name: zsync Version : 0.0.4 Upstream Author : Colin Phipps <[EMAIL PROTECTED]> * URL : http://zsync.moria.org.uk/ * License : GPLv2 Description : A client-side implementation of the rsync algorithm This package allows updating of files from a remote web server without requiring a full download or a special remote server application. the description will be a bit more elaborate, talking it over with upstream. there will also be a libzsync and a libzsync-dev package to use it in other programs (apt for example ;) cu robert -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.9 Locale: LANG=C, [EMAIL PROTECTED] -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy
Scripsit Frank Küster <[EMAIL PROTECTED]> > And if you take the combination of both: Upstream source that > contains non-DFSG material and forbids to use the DFSG-free parts > without explicitly referring to the removed non-DFSG-free parts, > well, IANAL, and IANARODL[2], but I wouldn't like this. IAARODL. If the DFSG-free part cannot be distributed without the non-DFSG-free parts, then it was never DFSG-free in the first place. -- Henning Makholm "This imposes the restriction on any procedure statement that the kind and type of each actual parameter be compatible with the kind and type of the corresponding formal parameter."
Re: GPL and command-line libraries
On Tue, 2 Nov 2004, Josselin Mouette wrote: > If Mr Wontshare's client doesn't work without your software, this is > what I call a derivative work. Whether it is linked to it using ELF or > not is irrelevant. So anything that runs on Windows is a derivative work of Windows? This might not impact the GPL too much because of the OS exemption, but it would mean that Microsoft could legally prevent the publication of any program they want which only runs on Windows.
Bug#279494: ITP: apache2-redirtoservname -- Apache module to redirect browsers to the canonical server name
Package: wnpp Severity: wishlist * Package name: apache2-redirtoservname Version : 0.1 Upstream Author : Simon Richter <[EMAIL PROTECTED]> * URL : http://www.hogyros.de/misc * License : GPL + exception to allow linking against Apache Description : Apache module to redirect browsers to the canonical server name This module can automatically issue a HTTP redirect if someone accesses your server with anything other than the canonical hostname. It is most useful if you want people to be able to enter your hostname without "www." or have multiple domains in different TLDs that should all be redirected to the same site. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.4.22 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Re: Comparing FHS 2.3 and 2.1
* Quoting Joey Hess ([EMAIL PROTECTED]): > Manoj Srivastava wrote: > > an application needs to create more than one dot file then they should be > > placed in a subdirectory with a name starting with a '.' character, (a "dot > > directory"). In this case the configuration files should not start with the > > '.' > > character. > - vim (.viminfo, .vimrc, maybe .vim/) > - zsh (.zcompdump, .zlogin, .zshenv, .zshrc) - bash (.bashrc, .bash_profile) - Rolf
Re: GPL and command-line libraries
On Tue, Nov 02, 2004 at 09:53:21PM +0100, Wesley W. Terpstra wrote: > 4. Writing to debian-legal and asking for advice. Now that's a good idea. Why did you do that on debian-devel instead? -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
oi!
Quem é vc! _ MSN Hotmail, o maior webmail do Brasil. http://www.hotmail.com
Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy
Frank Küster <[EMAIL PROTECTED]> wrote: > [1] "Debian comes in three flavors: Stale, rusting, and broken, which > are renamed once or twice a decade. Actually, rusting is stale yet > currently, but it can't be officially released before 2004, because > Gnome2 and KDE3 aren't sufficiently outdated, and a messed-up inn for > broken is missing" It seems I deleted the text where this footnote should have been inserted... Even if I didn't make a point with it, I still hope you had fun... Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Several X applications refuse to start
On Thu, 28 Oct 2004, Sean Perry wrote: 2) this looks like a font issue (as you mentioned) try forcing the app to load 'fixed' as its font. Using emacs with fixed font works and I also found the problem which is descirbed in #279380. I think this bug is worth to be increased in severity but strangely the effect I observed on my laptop does not occure on other installations. I'd like to aks some "font-experts" if the remaining fonts.* files might make other applications crash and which further circumstances lead to this result. At least at my laptop was the removal of these files successful. Kind regards Andreas. -- http://fam-tille.de
Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy
Chris Waters <[EMAIL PROTECTED]> wrote: > On Mon, Nov 01, 2004 at 01:47:02PM -0600, Manoj Srivastava wrote: > >> How about this rule of thumb: If you get stuff from the >> primary NON DEBIAN distribution site, that is what you call >> upstream. What someone unconnected to debian, not using debian >> archives, downloads is what we also offer as upstream orig.tar.gz >> files. > > I think it's more important that our users *know what they're getting* > than that we try to enforce some sort of arbitrary distinction between > "Debian" and "upstream". I think Manoj made an important point in a reply to me when he stressed that a "source package" in Debian is a *.dsc file and the files mentioned therein, with their checksum. If you think that way, everybody who looks at a Debian source package still "knows what they're getting" if the putting-together is explained in a file in diff.gz, doesn't he? > Clarity is why I chose "107.0pre108" as a > version number. I don't see how it's that much different from our > various cvs-snapshot packages, except that in my case, upstream wasn't > using any sort of version control at the time I made the package - > they just had a loose collection of patches and replacement files > available on their website. In this case it seemed to me that upstream was not willing to prepare a release, to put together the pieces at that time. At least there was no consensus to do this. But you - both upstream developer and Debian developer - decided that it was time for putting together what was currently available, and create a Debian package. This was probably a good deal of work, and of thinking and deciding in the first place. I would argue that this was work for Debian - upstream as a team did not do it, and no other distribution will probably have used the same state of the project for packaging. And if it is work for Debian, it is appropriate to document it in files in diff.gz, isn't it? >> Pristine upstream means pristine upstream. Either get your >> notes added to upstream website, or put them in the diffs. > > We don't require "pristine upstream". For example, we remove non-DFSG > compliant portions. Many licenses require that changes be > documented. So if we modify the upstream source to remove the > non-DFSG portions, and _don't document that_ (because of a new policy > rule that forbids any debian-authored portions of _orig tarballs), > then we may be violating licenses. There may be a grey area, because even if *we* consider a source package to be "$package.dsc, sed -e '/^[^ ]/ d;/^ / s/.* //' $package.dsc", somebody else might still just look at the orig.tar.gz. On the other hand, this is a grey area also in a different sense: It restricts modification of the source, and the type of restriction is not grandfathered (at least not literally) by clause 4 of the DFSG. And if you take the combination of both: Upstream source that contains non-DFSG material and forbids to use the DFSG-free parts without explicitly referring to the removed non-DFSG-free parts, well, IANAL, and IANARODL[2], but I wouldn't like this. Regards, Frank [1] "Debian comes in three flavors: Stale, rusting, and broken, which are renamed once or twice a decade. Actually, rusting is stale yet currently, but it can't be officially released before 2004, because Gnome2 and KDE3 aren't sufficiently outdated, and a messed-up inn for broken is missing" [2] I Am Not A Regular Of Debian-Legal -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy
Henning Makholm <[EMAIL PROTECTED]> wrote: > To prevent this misunderstanding, perhaps change to > > For example, it is not sufficient reason to omit a file that it is > used only when buidling on MS-DOS. Similarly, a Makefile provided by > upstream should not be omitted even if the first thing your > debian/rules does is to overwrite it by running a configure script. Thanks, I changed it further so that even people like me can easily get the grammar: , | For example, it is not a sufficient reason for omitting a file that it | is used only when building on MS-DOS. Similarly, a Makefile provided | by upstream should not be omitted even if the first thing your | debian/rules does is to overwrite it by running a | configure script. ` I hope it is still understandable for native speakers... > Some minor typos, most certainly originally made by me: Thanks, corrected. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy
Hi Bill, hi all, I'd like to come back to one point of your mail: Bill Allombert <[EMAIL PROTECTED]> wrote: > If you have a whole directory of binary files, you might consider > making a new source package for them. (For example a Debian theme > for a program). I guess you really wanted to say "making a new, repackaged tar.gz file for them". But wouldn't it be the cleaner approach, at least if it is technically possible, to literally follow what you wrote: Create a new (Debian native) source package for the theme, the binary package of which can be either installed at runtime to change the appearance of the program, or used as a build-dependency? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
