Re: apt-get not working anymore
Klaus Ethgen writes: > Hi, > > Am Sa den 5. Sep 2009 um 20:06 schrieb Goswin von Brederlow: >> % rmadison apt >>apt | 0.6.46.4-0.1 | etch-m68k | source, m68k >>apt | 0.6.46.4-0.1 | oldstable | source, alpha, amd64, arm, hppa, >> i386, ia64, mips, mipsel, powerpc, s390, sparc >>apt | 0.6.46.4-0.1+etch1 | oldstable-proposed-updates | source, >> alpha, amd64, arm, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc >>apt | 0.7.20.2+lenny1 |stable | source, alpha, amd64, arm, >> armel, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc >>apt | 0.7.20.2+squeeze1 | testing-proposed-updates | source, alpha, >> amd64, armel, hppa, i386, ia64, mips, powerpc, s390, sparc >>apt | 0.7.22.2 | testing | source, alpha, amd64, hppa, i386, >> kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc >>apt | 0.7.22.2+b2 | testing | armel, ia64 >>apt | 0.7.23.1 | unstable | source, alpha, amd64, armel, hppa, >> hurd-i386, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, >> s390, sparc >> >> >> Reduce your sources.list, possibly to just unstable main, apt-get update, >> apt-get install apt, revert sources.list, enjoy. > > Uh, sorry to not making that clear enough. _I_ know how to (temporarily) > fix that. But the problem is that the stable version has a hard limit > which is not that far away from real setups. And I want not to hear the > crying if every user add a bug report cause he is not able to fix it > themself. The problem does not appear in stable systems. Only when you pile on repository after repository. Especialy if you pile on old-stable, stable, testing and unstable all together. > And a simple upgrade to the unstable version is no solution as there is > several dependencies which are incompatible between stable and unstable. > (On my system this was only libapt-pkg-perl which makes several packages > to get purged when installing the unstable version.) > > Am Sa den 5. Sep 2009 um 20:18 schrieb Hans-J. Ullrich: >> APT::Cache-Limit "1"; > > Doesn't help as the limit is hard coded in apt. Just look at the source. > The problem was fixed in versions after stable. No surprise there. The problem is not the amount of memory used but the number of packages. The old apt can only handle 65536 packages and stable has somewhat above 2. So one release is fine. Two releases just work. 3 release can make it give the above error. > Regards >Klaus MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Of the use of native packages for programs not specific to Debian.
Wouter Verhelst writes: > On Mon, Sep 07, 2009 at 11:22:30AM +0200, Giacomo A. Catenazzi wrote: >> We have a lot of troubles when upstreams ship a debian/ directory >> in upstream tarball, thus I'll expect derivatives will have similar >> problems > > I don't see it that way. > > The reason why we have 'a lot of troubles' when upstreams ship a debian/ > directory, is because upstreams usually supply that directory as a > courtesy to make life 'easier' for those people who want to build a > Debian package out of their SCM repository, and that as a result, they > are usually not even remotely Policy-compliant. Thus, we need to do a > *lot* of work to get them integrated properly; and any files that keep > lying around in debian/ might interfere with other things. And that quickly goes away when upstream accepts patches that fix their debian directory. I don't see that as a *lot* of work at all. It just means you need a good relationship with upstream so changes to the debian dir are merged upstream quickly. If you have write access to upstreams RCS then I don't see this as a problem at all. > Debian packages from the Debian distribution usually are > policy-compliant and maintained, so this kind of problem does not > manifest itself as often for our downstreams And as we were talking about packages where the debian maintainer is also upstream this problem also doesn't manifest for Debian itself. > (of course there are packages that are not maintained nor > policy-compliant, but then they don't tend to live long in the > distribution). MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#546895: ITP: libwww-freshbooks-api-perl -- Perl Interface to the Freshbooks API
Package: wnpp Severity: wishlist Owner: Dusty Wilson * Package name: libwww-freshbooks-api-perl Version : 0.1.0 Upstream Author : Anthony Decena * URL : http://search.cpan.org/dist/WWW-FreshBooks-API/ * License : GPL Programming Lang: Perl Description : Perl Interface to the Freshbooks API WWW::FreshBooks::API is a Perl module that provides an object-oriented interface to the freshbooks.com invoicing and time tracking service. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#545949: who should cleanup /var/lib/update-rd.d ? should it be cleaned up at all?
Hi, I've just rescheduled piuparts testing for 233 failed packages in sid which were affected by #545949, which has been fixed now - thanks for that. No packages in squeeze were affected. regards, Holger signature.asc Description: This is a digitally signed message part.
Bug#546919: ITP: python-pycuda -- module to access Nvidia‘s CUDA parallel computation API
Package: wnpp Severity: wishlist Owner: Yaroslav Halchenko * Package name: python-pycuda Version : 0.93 Upstream Author : Andreas Kloeckner * URL : http://mathema.tician.de/software/pycuda * License : MIT Programming Lang: C++, Python Description : module to access Nvidia‘s CUDA parallel computation API PyCUDA lets you access Nvidia‘s CUDA parallel computation API from Python. Several wrappers of the CUDA API already exist–so what’s so special about PyCUDA? * Object cleanup tied to lifetime of objects. This idiom, often called RAII in C++, makes it much easier to write correct, leak- and crash-free code. PyCUDA knows about dependencies, too, so (for example) it won’t detach from a context before all memory allocated in it is also freed. * Convenience. Abstractions like pycuda.driver.SourceModule and pycuda.gpuarray.GPUArray make CUDA programming even more convenient than with Nvidia’s C-based runtime. * Completeness. PyCUDA puts the full power of CUDA’s driver API at your disposal, if you wish. * Automatic Error Checking. All CUDA errors are automatically translated into Python exceptions. * Speed. PyCUDA’s base layer is written in C++, so all the niceties above are virtually free. * Helpful Documentation. To be submitted into contrib section due to dependency on nvcc (non-free, not yet in Debian either). Additional things needed to be package prior: http://pypi.python.org/pypi/pytools -- MIT license -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Of the use of native packages for programs not specific to Debian.
I agree that debian/ files likely don't cause a "whole lot of trouble" to us (it should only be a line to remove it using debian/rules prior to building? but I'm not 100% sure on that). However, I don't think that it not being tremendously burdensome on us in Debian is sufficient justification to permit or encourage this behaviour. On Wed, Sep 16, 2009 at 4:41 AM, Goswin von Brederlow wrote: > Wouter Verhelst writes: > >> On Mon, Sep 07, 2009 at 11:22:30AM +0200, Giacomo A. Catenazzi wrote: >>> We have a lot of troubles when upstreams ship a debian/ directory >>> in upstream tarball, thus I'll expect derivatives will have similar >>> problems >> >> I don't see it that way. >> >> The reason why we have 'a lot of troubles' when upstreams ship a debian/ >> directory, is because upstreams usually supply that directory as a >> courtesy to make life 'easier' for those people who want to build a >> Debian package out of their SCM repository, and that as a result, they >> are usually not even remotely Policy-compliant. Thus, we need to do a >> *lot* of work to get them integrated properly; and any files that keep >> lying around in debian/ might interfere with other things. > > And that quickly goes away when upstream accepts patches that fix > their debian directory. I am both the upstream maintainer of several Perl modules, for which I am also one of the Debian package maintainers. I personally am just pragmatic, and provide only what is necessary at various points -- so, upstream packages contain what is necessary to install via the standard Perl-ish way (CPAN shell), and the Debian packages contain this plus some Debian-specific stuff. One of the issues I would have with putting debian/ files upstream (beyond just being unexpected by the user since it's probably very uncommon in the wild) is that I would need to sync changes that the other pkg-perl team members submit, since we maintain packages as a team. It just seems a whole lot of work for little gain. > > I don't see that as a *lot* of work at all. It just means you need a > good relationship with upstream so changes to the debian dir are > merged upstream quickly. If you have write access to upstreams RCS > then I don't see this as a problem at all. > >> Debian packages from the Debian distribution usually are >> policy-compliant and maintained, so this kind of problem does not >> manifest itself as often for our downstreams > > And as we were talking about packages where the debian maintainer is > also upstream this problem also doesn't manifest for Debian itself. > >> (of course there are packages that are not maintained nor >> policy-compliant, but then they don't tend to live long in the >> distribution). And the problem is that users really don't know which is which, so upstream is just being a jerk and confusing their users :). Not to mention that it would reflect badly on our packages in Debian, as people would say, "damn Debian packages, this one wouldn't even build, it sucks!!!" I think someone (tm) should do a study and see just how difficult it is to deal with debian/ files in an upstream tarball. I take it that our scripts probably handle this sort of thing transparently, or that the effected files are removed prior to build time. > > MfG > Goswin > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: responsibility for iptables bug
Marco d'Itri wrote: > On Sep 14, jida...@jidanni.org wrote: > >> LB> You could file this a a wishlist bug report against the iptables >> LB> package, and see if the maintainer wish to add this file (or a larger >> LB> /etc/sysctl.d/iptables.conf with some sane defaults). > What makes you believe that the kernel defaults are not sane? > This is an extra feature which is not required by most people, has a > computational and memory cost and should not be enabled unless needed. > This bug should just be closed, or at least only commented by people who > actually know what they are talking about. This bug should *NOT* be closed. Getting a deprecation warning for a simple and common use of iptables is a bug somewhere, either in iptables or the kernel. And I really fail to understand why the iptables maintainer thinks it is useful in any way to tag this bug wontfix without any comment at all. Are people supposed to live with that deprecation warning forever? I'd expect that Debian provides useful defaults, running in such a warning is not useful. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#546831: ITP: perdition-pbs -- POP / IMAP Before SMTP Tool
Horms wrote: > Package: wnpp > Severity: wishlist > Owner: Horms > > > * Package name: perdition-pbs > Version : 1.0.0 > Upstream Author : Simon Horman > * URL : http://www.vergenet.net/linux/perdition/pbs.shtml > * License : GPL > Programming Lang: C > Description : POP / IMAP Before SMTP Tool People are still using pop/imap before smtp? OMG. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: responsibility for iptables bug
On Sep 16, Bernd Zeimetz wrote: > This bug should *NOT* be closed. Getting a deprecation warning for a simple > and > common use of iptables is a bug somewhere, either in iptables or the kernel. Sometimes life is just not how we would like it to be, and by accepting this you could save much anger and anxiety... > in any way to tag this bug wontfix without any comment at all. Are people > supposed to live with that deprecation warning forever? I'd expect that Debian No, I expect that it will be removed along with CONFIG_NF_CT_ACCT. > provides useful defaults, running in such a warning is not useful. Indeed, the default is already useful and does not need to be changed. Maybe the warning should be disabled, but I do not care about it and I expect neither do the kernel maintainers. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#546831: ITP: perdition-pbs -- POP / IMAP Before SMTP Tool
On Sep 16, Bernd Zeimetz wrote: > People are still using pop/imap before smtp? OMG. People are also still using 10 years old systems in production, so anything that helps integrating them in modern infrastructure is useful. -- ciao, Marco signature.asc Description: Digital signature
Re: replacing libreadline5-dev build dependency with libreadline-dev
On Sun, Sep 13, 2009 at 11:21:11PM -0500, Manoj Srivastava wrote: > On Sun, Sep 13 2009, Matthias Klose wrote: > > > Both libreadline-dev (>= 6.0) and libreadline6-dev are now available > > in unstable and testing. If possible, please replace the > > libreadline5-dev build dependency with libreadline-dev, so that in > > future changes of the libreadline soname binNMU's can be used for this > > kind of update. > > I had libreadline5-dev | libreadline-dev, based on the premise > that the former would be a concrete package, and the latter not, but I > am now using > libreadline-dev | libreadline6-dev | libreadline5-dev > to be friendly to back porters (thus the prepend, not replace) librealine-dev used to be a virtual package. If it is now a standard package, I don't even see why libreadline6-dev exists at all. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#546936: ITP: r-cran-igraph -- GNU R package for igraph
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: r-cran-igraph Version : 0.5.2 Upstream Author : Gabor Csardi * URL : http://cran.r-project.org/web/packages/igraph/ * License : GPL Programming Lang: R Description : GNU R package for igraph Routines for simple graphs and network analysis. igraph can handle large graphs very well and provides functions for generating random and regular graphs, graph visualization, centrality indices and much more. -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable'), (200, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#546941: ITP: libclass-accessor-children-perl -- Automated child-class/accessor generation
Package: wnpp Severity: wishlist Owner: Dusty Wilson * Package name: libclass-accessor-children-perl Version : 0.02 Upstream Author : Yusuke Kawasaki * URL : http://search.cpan.org/dist/Class-Accessor-Children/ * License : Perl (Artistic|GPL1+) Programming Lang: Perl Description : Automated child-class/accessor generation This module automagically generates child classes which have accessor/mutator methods. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#546991: ITP: python-texml -- Convert TeXML to LaTeX or ConTeXt
Package: wnpp Severity: wishlist Owner: Neskie Manuel * Package name: python-texml Version : 2.0.1 Upstream Author : Oleg Parashchenko * URL : http://sourceforge.net/projects/getfo/ * License : Personal (see below) Programming Lang: Python Description : Convert TeXML to LaTeX or ConTeXt TeXML is an XML syntax for TeX. The processor transforms the TeXML markup into the TeX markup, escaping special and out-of-encoding characters. The intended audience is developers who automatically generate [La]TeX or ConTeXt files. --- License Information: Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. -- System Information: Debian Release: 5.0 APT prefers jaunty-security APT policy: (500, 'jaunty-security'), (500, 'jaunty') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#546995: ITP: eog-plugins -- set of plugins for Eye of GNOME
Package: wnpp Severity: wishlist Owner: Emilio Pozuelo Monfort * Package name: eog-plugins Version : 2.28.0 Upstream Author : Lucas Rocha * URL : http://live.gnome.org/EyeOfGnome/Plugins * License : GPL2+ Programming Lang: C, Python Description : set of plugins for Eye of GNOME This package contains a set of plugins for Eye of GNOME. (the long description will be expanded when the packaging is done, possibly with the list of plugins and what they do). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#547006: ITP: libiterator-simple-perl -- Simple iterator and utilities
Package: wnpp Severity: wishlist Owner: Dusty Wilson * Package name: libiterator-simple-perl Version : 0.05 Upstream Author : Rintaro Ishizaki * URL : http://search.cpan.org/dist/Iterator-Simple/ * License : Perl (GPL-1+|Artistic) Programming Lang: Perl Description : Simple iterator and utilities Iterator::Simple is yet another general-purpose iterator utility. A rather simple, but powerful and fast iterator. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#546831: ITP: perdition-pbs -- POP / IMAP Before SMTP Tool
On Wed, Sep 16, 2009 at 04:04:04PM +0200, Bernd Zeimetz wrote: > Horms wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Horms > > > > > > * Package name: perdition-pbs > > Version : 1.0.0 > > Upstream Author : Simon Horman > > * URL : http://www.vergenet.net/linux/perdition/pbs.shtml > > * License : GPL > > Programming Lang: C > > Description : POP / IMAP Before SMTP Tool > > People are still using pop/imap before smtp? OMG. I was surprised too! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#546831: ITP: perdition-pbs -- POP / IMAP Before SMTP Tool
Marco d'Itri wrote: > On Sep 16, Bernd Zeimetz wrote: > >> People are still using pop/imap before smtp? OMG. > People are also still using 10 years old systems in production, so > anything that helps integrating them in modern infrastructure is > useful. If I remember right I've disabled pop/imap before smtp on the last server about 10 years ago... -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: responsibility for iptables bug
You people are lucky you have me on board. Because I am a very simple minded person. All I know is I use some thing documented there on the iptables man page, and I get a warning. I noticed that warning because I happened to look in /var/log/syslog one day. The warning says something worse will happen in the future unless something gets fixed. If we are not supposed to use that thing, that fact should be stated on the iptables man page. Otherwise "you are selling cars whose axles you know will break in the future, and not warning the consumer about it." -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
[DEP-5] Short license names (was: Re: DEP-5: query about possible inheritence of License:)
Le Mon, Sep 14, 2009 at 12:48:04PM +0200, Stefano Zacchiroli a écrit : > > Question on this (because the current draft does not look particularly > clear on that topic, at least to my own reading): is it true that > arbitrary keywords can be used in License fields to reference license > blocks expanded later on or not? In particular, I'm worried about the > case where there are different "other" licenses in a given package, that > still need to be reused. Can we in those cases use, e.g., "other1", > "other2", etc., or possibly even more telling names? Hello Stefano, I added the ’Other’ short name in order to allow to leave the first line of the license field empty when the license is so unique that it does not make sense to invent a short name that would not mean much to people if it were displayed. In case of collecting statistics, I thought that ‘Other’ would fit better than an empty string. But thanks to your email, I realise that this would lead to information loss, for instance if using the machine-readable copyright file, a parser would print the list of all the files with their license; in complex cases it would not be possible to know if two files have the same ‘Other’ license. Given that identifiers like ‘Other1’, ’Other2’… are ugly or even confusing, and that the machine-readable format has the goal to be very human-readable as well, I propose to remove the default to ’other’ from the DEP and leave the responsability of dealing with empty first lines to the parsers. Of course, for licenses that have no short name proposed by the DEP, the person writing the copyright file is free to pick whatever makes sense instead of leaving the field empty. You nicely summarised this in the patch you sent previously. I would like to take the opportunity to make a few additional comments on license short names. This is one part of the proposal where a lot of things from the old wiki version were reworked and simplified. I invite the contributors of the wiki page to check the current version on the DEP website and tell us if they have concerns with our changes. First, for the BSD licenses, it became clear from this spring’s discussions that each variant is a completely different license given that it requires to cite different copyrights and forbids to use different names for advertisement or endorsement, and that factorising them would infringe them. Therefore, the parts of the proposal for doing a fine classification were dropped, in favor of calling these licences by their name. Second, since having a formal short name syntax to distinguish the BSD licenses by their variations was not possible, we removed the part of the proposal describing a formal grammar for the short names, whose purpose was to extend this concept. Nevertheless, this leaves us in a situation where the machine-readable format can not indicate that a license is derived from a very frequent template such as the BSD license. For that case, I think that we could add a ’Similar to’ qualifier, like in the following example: Copyright: © 2009 John Doe Corporation License: similar to BSD All rights reserved. . Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. Neither the name of the John Doe Corporation nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. . THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND [Disclaimer cut here, but would be included in real life] Then, for the most common license templates, the DEP could provide an annex describing which parts are allowed to differ in order to be called ’similar’ It could disallow the use of ’Similar to’ for the licenses not listed in the annex. This would avoid to have to invent arbitrary names for rare licenses, but does not solve the problem that there can be many ’similar’ but different licenses in the same package. Again, the parsers could do some work behind the scene to address that issue in a way that fits their function (display, statistics, checking, …) Have a nice day, PS: please notify me in private if you think I am using the wrong list for this discussion, or if you think that I should keep on posting on -devel even if others think I am using the wrong list… -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Of the use of native packages for programs not specific to Debian.
Goswin von Brederlow wrote: Wouter Verhelst writes: On Mon, Sep 07, 2009 at 11:22:30AM +0200, Giacomo A. Catenazzi wrote: We have a lot of troubles when upstreams ship a debian/ directory in upstream tarball, thus I'll expect derivatives will have similar problems I don't see it that way. The reason why we have 'a lot of troubles' when upstreams ship a debian/ directory, is because upstreams usually supply that directory as a courtesy to make life 'easier' for those people who want to build a Debian package out of their SCM repository, and that as a result, they are usually not even remotely Policy-compliant. Thus, we need to do a *lot* of work to get them integrated properly; and any files that keep lying around in debian/ might interfere with other things. And that quickly goes away when upstream accepts patches that fix their debian directory. I don't see that as a *lot* of work at all. It just means you need a good relationship with upstream so changes to the debian dir are merged upstream quickly. If you have write access to upstreams RCS then I don't see this as a problem at all. Yes, but I use cdbs for my packages, and I don't want to force upstream to use the same tools. But now I've found an other problem: On native package the debian/changelog is also used for upstream changelog: upstreams tend to package their packages as native. But I'll pack it as normal package. With the 3.0 source format the upstream changelog (if it is in debian) will be removed (which could maybe is a problem with the GPL licenses: we distribute in the sources the changelog, but we hide/delete it, when unpacking). Thus non debian specific package, which are also native, should (must on GPL licensed packages) have a separate "upstream" changelog. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
