Bug#557196: ITP: r-cran-epicalc -- GNU R Epidemiological calculator
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-epicalc Version : 2.10.0.0 Upstream Author : Virasakdi Chongsuvivatwong * URL : http://cran.r-project.org/web/packages/epicalc * License : GPL-2+ Programming Lang: R Description : GNU R Epidemiological calculator Functions making R easy for epidemiological calculation. . Datasets from Dbase (.dbf), Stata (.dta), SPSS(.sav), EpiInfo(.rec) and Comma separated value (.csv) formats as well as R data frames can be processed to do make several epidemiological calculations. I will maintain this package in the Debian Med team. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') 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#557199: ITP: r-cran-epir -- GNU R Functions for analysing epidemiological data
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-epir Version : 0.9-19 Upstream Author : Mark Stevenson * URL : http://cran.r-project.org/web/packages/epiR * License : GPL-2+ Programming Lang: R Description : GNU R Functions for analysing epidemiological data A package for analysing epidemiological data. Contains functions for directly and indirectly adjusting measures of disease frequency, quantifying measures of association on the basis of single or multiple strata of count data presented in a contingency table, and computing confidence intervals around incidence risk and incidence rate estimates. Miscellaneous functions for use in meta-analysis, diagnostic test interpretation, and sample size calculations. I will maintain this package in the Debian Med team. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') 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#557200: ITP: r-cran-medadherence -- GNU R Medication Adherence: Commonly Used Definitions
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-medadherence Version : 1.01 Upstream Author : Xiangyang Ye * URL : http://cran.r-project.org/web/packages/medAdherence/ * License : GPL-2+ Programming Lang: R Description : GNU R Medication Adherence: Commonly Used Definitions Adherence is defined as "the extent to which a person's behavior coincides with medical or health advice", which is very important, for both clinical researchers and physicians, to identify the treatment effect of a specific medication(s). . A variety of measures have been developed to calculate the medication adherence. Definitions and methods to address adherence differ greatly in public literature. Choosing which definition should be determined by overall study goals. This package provides the functions to calculate medication adherence based on commonly used definitions. Remark: I'll maintain this package in the Debian Med team. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Package formats and software distribution on Linux
Eugene Gorodinsky, 2009-11-20 02:01:19 +0200 : > There is a sort of oligopoly in linux because of package management. > There are several main distros which have a lot of package maintainers > and a lot of packages as a result of this. Smaller distros need to > choose between compatibility with existing packages and innovation > (whatever that may be) [...] > A universal package format would benefit these distributions, since a > lot less resources would have to be spent in order to create a new > distribution. I've read that several times, but I still must be missing something. My impression is that your poins is essentially the following: 1. it's too much work for "small distros" to use any new format instead of one of the big established ones; 2. let's reduce the number of big established formats to one. If that's approximately correct, then aren't these points in contradiction? I think the choice of established formats actually benefits the "smaller distros" since they can pick the one more adapted to their needs. Interesting questions nevertheless :-) Roland. -- Roland Mas [...] ou une dent pourrie [...] -- in Variations sur un thème imposé -- Signatures à collectionner, série n°2, partie 2/3. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Anjal package needs RPATH, which is considered an error
Dear List, I'm facing an issue when packaging the Anjal [1] mail client for Debian. Anjal is another GUI front-end for Evolution designed for small form factor devices. So naturally Anjal depends upon many .so libraries in the Evolution package. But those .so libraries is considered private by Evolution so they are installed in /usr/lib/evolution/2.28. To use them Anjal is built by using RPATH that point to /usr/lib/evolution/2.28, and this is considered by lintian to be an error (it was warning before). Evolution upstream developers don't agree to move those Evolution .so libraries into /usr/lib since they are private, should not be used by other programs and there's no intention to maintain a stable API of them. Anjal is considered a part of Evolution project so the API between Anjal and Evolution will be maintained by Evo upstream. So any suggestions on how can I package Anjal for Debian and use the .so files in the evolution package? My idea is to create symlinks of those libraries in /usr/lib/anjal/0.1/ so Anjal won't need to use RPATH that point to /usr/lib/evolution/2.28/. Though I'm not sure if this is a clean way. Thank you very much. [1] http://live.gnome.org/Anjal/ -- Li, Yan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Anjal package needs RPATH, which is considered an error
On Fri, Nov 20, 2009 at 04:17:57PM +0800, Li, Yan wrote: > Dear List, > > I'm facing an issue when packaging the Anjal [1] mail client for > Debian. > > Anjal is another GUI front-end for Evolution designed for small form > factor devices. So naturally Anjal depends upon many .so libraries in > the Evolution package. But those .so libraries is considered private > by Evolution so they are installed in /usr/lib/evolution/2.28. To use > them Anjal is built by using RPATH that point to > /usr/lib/evolution/2.28, and this is considered by lintian to be an > error (it was warning before). > > Evolution upstream developers don't agree to move those Evolution .so > libraries into /usr/lib since they are private, should not be used by > other programs and there's no intention to maintain a stable API of > them. Anjal is considered a part of Evolution project so the API > between Anjal and Evolution will be maintained by Evo upstream. > > So any suggestions on how can I package Anjal for Debian and use the > .so files in the evolution package? > > My idea is to create symlinks of those libraries in > /usr/lib/anjal/0.1/ > so Anjal won't need to use RPATH that point to > /usr/lib/evolution/2.28/. > Though I'm not sure if this is a clean way. Why not put a lintian override ? Your explanation sounds like a good reason to me. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#557202: ITP: r-cran-diagnosismed -- GNU R Diagnostic test accuracy evaluation for medical professionals
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-diagnosismed Version : 0.2.2.2 Upstream Author : Pedro Brasil * URL : http://cran.r-project.org/web/packages/DiagnosisMed * License : GPL-2+ Programming Lang: R Description : GNU R Diagnostic test accuracy evaluation for medical professionals DiagnosisMed is a package to analyze data from diagnostic test accuracy evaluating health conditions. It is being built to be used by health professionals. This package is able to estimate sensitivity and specificity from categorical and continuous test results including some evaluations of indeterminate results, or compare different categorical tests, and estimate reasonble cut-offs of tests and display it in a way commonly used by health professionals. No graphical interface is avalible yet. Remark: I intend to maintain this package in the Debian Med team. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Anjal package needs RPATH, which is considered an error
Mike: > Why not put a lintian override ? Your explanation sounds like a good > reason to me. Thank you. I'm contacting Lintian maintainers. -- Li, Yan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Anjal package needs RPATH, which is considered an error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Li, Yan schrieb: > Mike: >> Why not put a lintian override ? Your explanation sounds like a good >> reason to me. > > Thank you. I'm contacting Lintian maintainers. You have to set and install your own lintian overrides in your package in the .lintian-overrides file. See e.g. man 1 dh_lintian - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAksGZDoACgkQ2XA5inpabMf1IwCeI+7Hdog6QCH4THsoI6jj87r7 L6UAn0rhwplhAcHXbs7W1iA/E4gzglNz =06oT -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Some questions on format "3.0 (quilt)" multi-origin
Hi, I'm working on switching dovecot package to format "3.0 (quilt)" and I wish to use the multi-origin option, because it comes as three source tar.gz [1][2][3] plus a patch [4]. I've done the initial switch [5] and it works quite well, but i have some general questions: 1) Dovecot is maintained as a team, so we need a VCS to coordinate our efforts (ATM it is svn), but I'm not able to find a VCS-buildpackage tool that support multiple origins. Is there anyone? 2) Talking of an hypothetic VCS-buildpackage using pristine-tar or similar tools, how it can known which component tarball need it to extract to create the right build environment? May be we should define a standard place under the debian/source directory for such information. 3) When a new version of a component is released, how to handle it in the new source format? I can't find any standard place where to put meta informations regarding extra origin tarball. I'll appreciate if somebody can help me on these points. Regards, Marco [1] http://www.dovecot.org/releases/1.2/dovecot-1.2.7.tar.gz [2] http://www.rename-it.nl/dovecot/1.2/dovecot-1.2-sieve-0.1.13.tar.gz [3] http://www.rename-it.nl/dovecot/1.2/dovecot-1.2-managesieve-0.11.9.tar.gz [4] http://www.rename-it.nl/dovecot/1.2/dovecot-1.2.7-managesieve-0.11.9.diff.gz [5] http://www.prato.linux.it/~mnencia/debian/dovecot/ -- - |Marco Nenciarini| Debian/GNU Linux Developer - Plug Member | | mnen...@prato.linux.it | http://www.prato.linux.it/~mnencia | - Key fingerprint = FED9 69C7 9E67 21F5 7D95 5270 6864 730D F095 E5E4 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Some questions on format "3.0 (quilt)" multi-origin
Hi, On Fri, Nov 20, 2009 at 11:28:56AM +0100, Marco Nenciarini wrote: > 3) When a new version of a component is released, how to handle it in > the new source format? I can't find any standard place where to put meta > informations regarding extra origin tarball. I don't think there exist one. And as the .tar.gz has to change names anyway because otherwise it'd be the same I think the only option left in this case is something like dovecot_1.2.7.orig-libsieve-0.1.13.tar.gz Unfortunately that needs a stable update (1.14.27) before you can use this... (because of the -) :( And if you need a libsieve dir then you need to create a symlink. /me has to do the same game for openoffice.org and ooo-build. Grüße/Regards, Rene -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Mahesh Rathore has invited you to create a Plurk.com account
I have been using Plurk and I think you should check it out! Accept my invitation by going to: http://www.plurk.com/eworldtradefair/invite/2 Check out my profile at: http://www.plurk.com/eworldtradefair Plurk.com - Your life, on the line -- If you don't wish to receive emails from Plurk, click this link: http://www.plurk.com/unsubscribe?bemail=ZGViaWFuLWRldmVsQGxpc3RzLmRlYmlhbi5vcmc%3D&key=6e6a04f4b16650a694337e34ffd0ab4c You can contact Plurk at http://www.plurk.com/contact Plurk.com, 2425 Matheson Blvd 8th Floor, Suite 813 Mississauga, Ontario L4W 5K4 Canada
Ridiculously large packages
Umm... Package: nexuiz-data Priority: optional Section: games Installed-Size: 782252 Maintainer: Debian Games Team Architecture: all Version: 2.5.2-1 Recommends: nexuiz (>= 2.5.2) | nexuiz-server (>= 2.5.2) Suggests: nexuiz-music (>= 2.5.2) Conflicts: nexuiz (<< 2.5.2), nexuiz-server (<< 2.5.2) Filename: pool/main/n/nexuiz-data/nexuiz-data_2.5.2-1_all.deb Size: 793400238 ... If you ever want this to be available on Debian CDs, you're going to have to do something about the size. For now, I'm going to blacklist this package altogether. -- Steve McIntyre, Cambridge, UK.st...@einval.com < sladen> I actually stayed in a hotel and arrived to find a post-it note stuck to the mini-bar saying "Paul: This fridge and fittings are the correct way around and do not need altering" -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Ridiculously large packages
Steve McIntyre (20/11/2009): > If you ever want this to be available on Debian CDs, you're going to > have to do something about the size. For now, I'm going to blacklist > this package altogether. And you didn't see Urban Terror and its 700+ MB yet! Speaking of which, what's the status of data.debian.org? IIRC, it's been in the pipe for 2+ years at the very least (was already mentioned during DC'07). :) Mraw, KiBi. signature.asc Description: Digital signature
Re: Ridiculously large packages
Cyril Brulebois (20/11/2009): > And you didn't see Urban Terror and its 700+ MB yet! Speaking of > which, what's the status of data.debian.org? IIRC, it's been in the > pipe for 2+ years at the very least (was already mentioned during > DC'07). :) OOH. http://ftp-master.debian.org/wiki/projects/data/ Mraw, KiBi. signature.asc Description: Digital signature
Re: Bits from the FTPMaster meeting
Am 15.11.2009 16:15, schrieb Joerg Jaspert: > multiple outstanding and intrusive patches got merged. We also discussed > various outstanding topics, a few of which we can report about already, > a few others where we still have to gather more information. This > process, either asking our lawyers or various other people, has already > been started. May I guess that "asking our lawyers" also covers the topic around ffmpeg and related (possibly patent threatened, mostly multimedia-related) packages? Will you keep us (i.e. pkg-multimedia maintainers team) informed in that case? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Some questions on format "3.0 (quilt)" multi-origin
On Fri, Nov 20, 2009 at 11:28:56AM +0100, Marco Nenciarini wrote:
> 2) Talking of an hypothetic VCS-buildpackage using pristine-tar or
> similar tools, how it can known which component tarball need it to
> extract to create the right build environment? May be we should
> define a standard place under the debian/source directory for such
> information.
I think we should too.
A recurring devscript request (which will become even more recurring now
with 3.0 and multi-origin) is to have support for downloading multiple
tarballs in uscan. See #531321 for more details.
In essence, the problem can be summarized as follows. Uscan is aware
only of one source tarball, and of only one current package version. The
former part is easy to fix (it amount to supporting multi-tarball
debian/watch file); the latter part is harder, because uscan has only
changelog to know latest upstream version imported available in Debian.
Having a place where to write which 3.0 tarballs compose the final "orig
upstream source" *and* the latest version imported into Debian will
solve both yours and the uscan problem.
Note that the uscan problem is not just a matter of making easy to
download several tarballs at once, but is rather part of the workflow we
now need to manage multi-tarballs packages (e.g. I want to be notified
when a single tarball of a whole got a new upstream release; currently
this is not doable with available tools).
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
nexuiz-data does not fit on a single CD
Package: nexuiz-data
Version: 2.5.2-1
Severity: serious
Any reason for not reporting this as a proper bug? Doing that with this
post.
On Fri, Nov 20, 2009 at 10:36:10AM +, Steve McIntyre wrote:
> Umm...
>
> Package: nexuiz-data
> Installed-Size: 782252
Dear maintainer,
the Debian CD team (in the person of Steve McIntyre) has noted the
enormous size of nexuiz-data, which means the package won't fit on a
single CD. I'm setting severity serious because this de facto means the
package cannot be distributed to our CD users. I agree that the severity
can be controversial since we have other ways of distributing packages;
feel free to downgrade, better if after discussion with the release team
(even better by reducing the size ;-))
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: nexuiz-data does not fit on a single CD
On Fri, 2009-11-20 at 14:00 +0100, Stefano Zacchiroli wrote: > the Debian CD team (in the person of Steve McIntyre) has noted the > enormous size of nexuiz-data, which means the package won't fit on a > single CD. I'm setting severity serious because this de facto means the > package cannot be distributed to our CD users. I agree that the severity > can be controversial since we have other ways of distributing packages; > feel free to downgrade, better if after discussion with the release team > (even better by reducing the size ;-)) This is silly. I haven't seen bug reports about packages not fitting in diskettes, and it would not make any sense if they were filed! =). The world moved on, CDs are getting too small. It's a technical limitation which can be overcome by using the network, or bigger media, such as DVDs. While I think blacklisting the package for CDs is a pragmatical decision, making the package smaller should be just desirable, not a (specially RC!) bug. See you, -- Gustavo Noronha Silva Debian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: nexuiz-data does not fit on a single CD
On Fri, 20 Nov 2009 11:59:07 -0200 Gustavo Noronha Silva wrote: > On Fri, 2009-11-20 at 14:00 +0100, Stefano Zacchiroli wrote: > This is silly. I haven't seen bug reports about packages not fitting in > diskettes, and it would not make any sense if they were filed! =). I thought this was why we had dpkg-split, so not exactly the same problem. > The world moved on, CDs are getting too small. It's a technical > limitation which can be overcome by using the network, or bigger media, > such as DVDs. While I think blacklisting the package for CDs is a > pragmatical decision, making the package smaller should be just > desirable, not a (specially RC!) bug. Or supporting dpkg-split for this case too? But probably not worth the effort for just a handful of packages that arguably would benefit from being broken into more manageable-sized packages anyway. Ben -- ,-. nSLUGhttp://www.nslug.ns.ca sy...@sanctuary.nslug.ns.ca \`' Debian http://www.debian.orgsy...@debian.org ` [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: nexuiz-data does not fit on a single CD
Gustavo Noronha Silva wrote: > On Fri, 2009-11-20 at 14:00 +0100, Stefano Zacchiroli wrote: >> the Debian CD team (in the person of Steve McIntyre) has noted the >> enormous size of nexuiz-data, which means the package won't fit on a >> single CD. I'm setting severity serious because this de facto means the >> package cannot be distributed to our CD users. I agree that the severity >> can be controversial since we have other ways of distributing packages; >> feel free to downgrade, better if after discussion with the release team >> (even better by reducing the size ;-)) > > This is silly. I haven't seen bug reports about packages not fitting in > diskettes, and it would not make any sense if they were filed! =). > > The world moved on, CDs are getting too small. It's a technical > limitation which can be overcome by using the network, or bigger media, > such as DVDs. While I think blacklisting the package for CDs is a > pragmatical decision, making the package smaller should be just > desirable, not a (specially RC!) bug. Ack. People which use computers which did not came with a DVD reader built in are probably not able to play nexuiz anyway as it needs a pretty fastCPU and graphics card to be fun :) -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org 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: nexuiz-data does not fit on a single CD
severity 557218 important
thanks
On Fri, Nov 20, 2009 at 11:59:07AM -0200, Gustavo Noronha Silva wrote:
> On Fri, 2009-11-20 at 14:00 +0100, Stefano Zacchiroli wrote:
> > the Debian CD team (in the person of Steve McIntyre) has noted the
> > enormous size of nexuiz-data, which means the package won't fit on a
> > single CD. I'm setting severity serious because this de facto means the
> > package cannot be distributed to our CD users. I agree that the severity
> > can be controversial since we have other ways of distributing packages;
> > feel free to downgrade, better if after discussion with the release team
> > (even better by reducing the size ;-))
>
> This is silly. I haven't seen bug reports about packages not fitting in
> diskettes, and it would not make any sense if they were filed! =).
Apparently, a lot of people (not only you, also people on IRC) have
missed the following bits of the above quoted text:
> > feel free to downgrade
So, let me clarify, I just wanted to prod a decision on whether we want
for our packages the property that packages fit on a CD. Nothing more
than that (besides of course submitting a bug report, that helps keeping
track of the issue).
Personally I completely agree with what you said, CD (at least as a
medium to get the whole of Debian) are the past and I couldn't care less
about supporting them. That, in my eyes, does not solve our problem of
deciding whether we want to support them _nevertheless_, given that CD
are not so long in the past, and given that not every citizen in the
world has a bandwidth capable of downloading 750 Mb.
That said, I'm downgrading severity, but doing that IMO would not solve
our need to decide on this issue.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Some questions on format "3.0 (quilt)" multi-origin
On Fri, Nov 20, 2009 at 11:28:56AM +0100, Marco Nenciarini wrote: > > Hi, > I'm working on switching dovecot package to format "3.0 (quilt)" and I > wish to use the multi-origin option, because it comes as three source > tar.gz [1][2][3] plus a patch [4]. > > I've done the initial switch [5] and it works quite well, but i have > some general questions: > > 1) Dovecot is maintained as a team, so we need a VCS to coordinate our > efforts (ATM it is svn), but I'm not able to find a VCS-buildpackage > tool that support multiple origins. Is there anyone? > svn-bp team is working on it...tho no progress yet. -- _ Ryan Niebur ryanrya...@gmail.com signature.asc Description: Digital signature
Re: nexuiz-data does not fit on a single CD
On 2009-11-20, Stefano Zacchiroli wrote: > Personally I completely agree with what you said, CD (at least as a > medium to get the whole of Debian) are the past and I couldn't care less > about supporting them. That, in my eyes, does not solve our problem of > deciding whether we want to support them _nevertheless_, given that CD > are not so long in the past, and given that not every citizen in the > world has a bandwidth capable of downloading 750 Mb. Sorry, but there are more options than CD and downloading: DVDs. And that's a viable solution here, IMHO. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Ridiculously large packages
On Friday 20 November 2009, Steve McIntyre wrote:
> If you ever want this to be available on Debian CDs, you're going to
> have to do something about the size. For now, I'm going to blacklist
> this package altogether.
Even though they do technically still fit on a CD, you may want to consider
excluding the following packages as well, as including them essentially
means having roughly 4 CD images dedicated to 9 packages.
53450 vtk-doc_5.2.1-11_all.deb
395642608 root-system-doc_5.24.00-1_all.deb
357422076 sauerbraten-data_0.0.20090504-1_all.deb
306308472 openarena-data_0.8.1-2_all.deb
250166552 fgfs-base_1.9.0-1_all.deb
235440078 kwwidgets-doc_1.0.0~cvs20090825-2_all.deb
220393788 alien-arena-data_7.0-1_all.deb
211831974 fgfs-base_1.0.0-2_all.deb
206728944 ember-media_0.5.7-1_all.deb
The selection was size >2 from:
.../debian/pool$ ls -lR | grep "\.deb$" | awk '{print $5 " " $8}' | \
sort -rn | head -n 25
Cheers,
FJP
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Package formats and software distribution on Linux
]] Eugene Gorodinsky | However I'm not proposing to have a single true package format for all | distributions. Rather my idea is to have a distribution-specific | package format for packages that are distribution-specific, and a | universal package format for packages that aren't specific. Isn't this what the LSB package format is? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: common, FHS-compliant, default document root for the various web servers
Heya, sorry for the delay.
On Sun, Nov 15, 2009 at 11:15:56PM +0100, sean finney wrote:
> > Inherently, such a proposal applies to static content, not CGI
> > applications. I fail to see where lay problems about unconfigured static
> > content.
>
> read-only static content unpacked from packages is certainly not an
> issue wrt being "unconfigured", but i was given the impression by other
> folks in this thread that the scope was not this narrow.
I might have contributed to that impression when I mentioned that
cgi-bin is already configured in some web servers. Sorry about that, the
proposal was initially for static content only, to actually find an
uniform solution to most of the outstanding RC bugs
dir-or-file-in-var-www.
Still, a related question to answer is: do we want CGIs installed under
/usr/lib/cgi-bin/ to be enabled by default? I believe currently the
answer is that they are enabled "yes and no", in the sense that with
some web servers you first need to add the CGI module / handler, but
beside that they do work.
> but at the same time, if we're only talking about static content at
> this filesystem location, i wonder about the overall utility/benefit
> of standardizing on a location in the first place. how many webapp
> packages in debian consist of only read-only static content, which
> would be helped by such a standardization?
>
> wrt the issue about namespacing and default URL's (i guess this is
> a seperate issue from fs location, really) i'm unconvinced about the
> benefits outweighing the costs. has anyone considered putting up the
> arguments for it in a DEP?
I've thought about that, but I don't have Debian time to offer alone on
that, right now. The first step would be the one you propose: testing
packages (the current dir-or-file-in-var-www buggy would be a good
start, I think) to check how many of them can be made to work by such a
change. Deciding whether CGI bin are enabled by default as asked above
of course has an impact on this.
If you are interested in working on this, we can try drafting something
together.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: nexuiz-data does not fit on a single CD
On Fri, 2009-11-20 at 15:23 +0100, Bernd Zeimetz wrote: > Ack. People which use computers which did not came with a DVD reader built in > are probably not able to play nexuiz anyway as it needs a pretty fastCPU and > graphics card to be fun :) Well, you see, my current computer (Lenovo x200s) does not have an optical drive at all. I had to install Debian using an usb stick. It does have a fast enough CPU and graphics card to play nexuiz though, mind you. My point is that the fact that our packages are showing the age of the media we still want to support should not be a bug. See you, -- Gustavo Noronha Silva Debian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: nexuiz-data does not fit on a single CD
On Fri, Nov 20, 2009 at 01:33:29PM -0200, Gustavo Noronha Silva wrote: > On Fri, 2009-11-20 at 15:23 +0100, Bernd Zeimetz wrote: > > Ack. People which use computers which did not came with a DVD reader built > > in > > are probably not able to play nexuiz anyway as it needs a pretty fastCPU and > > graphics card to be fun :) > > Well, you see, my current computer (Lenovo x200s) does not have an > optical drive at all. I had to install Debian using an usb stick. It > does have a fast enough CPU and graphics card to play nexuiz though, > mind you. > > My point is that the fact that our packages are showing the age of the > media we still want to support should not be a bug. It surely is a bug for those who care about CDs. But Zack's point is: should it be RC, normal, minor, or wontfix ? Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Ridiculously large packages
On Friday 20 November 2009, Steve McIntyre wrote: > For now, I've added a cutoff of 300,000,000 bytes as a maximum package > size for adding to CDs. That means that the following 3 packages will > be dropped from the squeeze CD builds: > > 306308472 pool/main/o/openarena-data/openarena-data_0.8.1-2_all.deb > 53450 pool/main/v/vtk/vtk-doc_5.2.1-11_all.deb > 793400238 pool/main/n/nexuiz-data/nexuiz-data_2.5.2-1_all.deb > > The debian-cd code will automatically pick up on dependencies too, so > any packages that *depend* on these will also be dropped. Would it be possible to generate a list of excluded packages and add that as a README on CD1? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Ridiculously large packages
On Fri, Nov 20, 2009 at 04:21:21PM +0100, Frans Pop wrote:
>On Friday 20 November 2009, Steve McIntyre wrote:
>> If you ever want this to be available on Debian CDs, you're going to
>> have to do something about the size. For now, I'm going to blacklist
>> this package altogether.
>
>Even though they do technically still fit on a CD, you may want to consider
>excluding the following packages as well, as including them essentially
>means having roughly 4 CD images dedicated to 9 packages.
>
>53450 vtk-doc_5.2.1-11_all.deb
>395642608 root-system-doc_5.24.00-1_all.deb
>357422076 sauerbraten-data_0.0.20090504-1_all.deb
>306308472 openarena-data_0.8.1-2_all.deb
>250166552 fgfs-base_1.9.0-1_all.deb
>235440078 kwwidgets-doc_1.0.0~cvs20090825-2_all.deb
>220393788 alien-arena-data_7.0-1_all.deb
>211831974 fgfs-base_1.0.0-2_all.deb
>206728944 ember-media_0.5.7-1_all.deb
>
>The selection was size >2 from:
>.../debian/pool$ ls -lR | grep "\.deb$" | awk '{print $5 " " $8}' | \
> sort -rn | head -n 25
For now, I've added a cutoff of 300,000,000 bytes as a maximum package
size for adding to CDs. That means that the following 3 packages will
be dropped from the squeeze CD builds:
306308472 pool/main/o/openarena-data/openarena-data_0.8.1-2_all.deb
53450 pool/main/v/vtk/vtk-doc_5.2.1-11_all.deb
793400238 pool/main/n/nexuiz-data/nexuiz-data_2.5.2-1_all.deb
The debian-cd code will automatically pick up on dependencies too, so
any packages that *depend* on these will also be dropped.
For DVD and BD disks we'll accept any size (for now).
This should also be added to the release notes, please.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"It's actually quite entertaining to watch ag129 prop his foot up on
the desk so he can get a better aim." [ seen in ucam.chat ]
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: nexuiz-data does not fit on a single CD
On Fri, Nov 20, 2009 at 02:00:18PM +0100, Stefano Zacchiroli wrote: >Package: nexuiz-data >Version: 2.5.2-1 >Severity: serious > >Any reason for not reporting this as a proper bug? Doing that with this >post. True, should have done that too. Thanks. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: nexuiz-data does not fit on a single CD
On Fri, 2009-11-20 at 16:47 +0100, Mike Hommey wrote: > It surely is a bug for those who care about CDs. But Zack's point is: > should it be RC, normal, minor, or wontfix ? minor =) -- Gustavo Noronha Silva Debian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Ridiculously large packages
On Fri, Nov 20, 2009 at 05:01:07PM +0100, Frans Pop wrote: >On Friday 20 November 2009, Steve McIntyre wrote: >> For now, I've added a cutoff of 300,000,000 bytes as a maximum package >> size for adding to CDs. That means that the following 3 packages will >> be dropped from the squeeze CD builds: >> >> 306308472 pool/main/o/openarena-data/openarena-data_0.8.1-2_all.deb >> 53450 pool/main/v/vtk/vtk-doc_5.2.1-11_all.deb >> 793400238 pool/main/n/nexuiz-data/nexuiz-data_2.5.2-1_all.deb >> >> The debian-cd code will automatically pick up on dependencies too, so >> any packages that *depend* on these will also be dropped. > >Would it be possible to generate a list of excluded packages and add that >as a README on CD1? Good idea, yes. -- Steve McIntyre, Cambridge, UK.st...@einval.com "C++ ate my sanity" -- Jon Rabone -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Ridiculously large packages
On Fri, Nov 20, 2009 at 4:21 PM, Frans Pop wrote: > On Friday 20 November 2009, Steve McIntyre wrote: >> If you ever want this to be available on Debian CDs, you're going to >> have to do something about the size. For now, I'm going to blacklist >> this package altogether. > > Even though they do technically still fit on a CD, you may want to consider > excluding the following packages as well, as including them essentially > means having roughly 4 CD images dedicated to 9 packages. > > 53450 vtk-doc_5.2.1-11_all.deb Slightly off topic, but I have been login some recommendations to divide the size of this package by at least a factor of 2. Reference (will be updated whenever tracking system process my mail) : http://bugs.debian.org/cgi-bin/pkgreport.cgi?package=vtk-doc Cheers -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#557245: large packages dropped from CDs
package: release-notes x-debbugs-cc: debian...@lists.debian.org, debian-devel@lists.debian.org On Freitag, 20. November 2009, Steve McIntyre wrote: > For now, I've added a cutoff of 300,000,000 bytes as a maximum package > size for adding to CDs. That means that the following 3 packages will > be dropped from the squeeze CD builds: > > 306308472 pool/main/o/openarena-data/openarena-data_0.8.1-2_all.deb > 53450 pool/main/v/vtk/vtk-doc_5.2.1-11_all.deb > 793400238 pool/main/n/nexuiz-data/nexuiz-data_2.5.2-1_all.deb > > The debian-cd code will automatically pick up on dependencies too, so > any packages that *depend* on these will also be dropped. > > For DVD and BD disks we'll accept any size (for now). > > This should also be added to the release notes, please. On Freitag, 20. November 2009, Frans Pop wrote: > Would it be possible to generate a list of excluded packages and add that > as a README on CD1? cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Ridiculously large packages
On Fri, Nov 20, 2009 at 04:18:54PM +, Steve McIntyre wrote: >On Fri, Nov 20, 2009 at 05:01:07PM +0100, Frans Pop wrote: >>On Friday 20 November 2009, Steve McIntyre wrote: >>> For now, I've added a cutoff of 300,000,000 bytes as a maximum package >>> size for adding to CDs. That means that the following 3 packages will >>> be dropped from the squeeze CD builds: >>> >>> 306308472 pool/main/o/openarena-data/openarena-data_0.8.1-2_all.deb >>> 53450 pool/main/v/vtk/vtk-doc_5.2.1-11_all.deb >>> 793400238 pool/main/n/nexuiz-data/nexuiz-data_2.5.2-1_all.deb >>> >>> The debian-cd code will automatically pick up on dependencies too, so >>> any packages that *depend* on these will also be dropped. >> >>Would it be possible to generate a list of excluded packages and add that >>as a README on CD1? > >Good idea, yes. And I now have code to generate the following as README.excluded on CD1: (example from currently-running squeeze i386 CD run) == For size reasons, the following packages were excluded from this disc set: nexuiz-data openarena-data and that caused the following packages to be removed because of dependencies: nexuiz nexuiz-dbg nexuiz-server nexuiz-server-dbg openarena openarena-server == -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ITP: mercurial-buildpackage (for those who care about Mercurial)
2009/11/19 Goswin von Brederlow : > Jens Peter Secher writes: [...] >> * Support dpkg source format 3.0. > > Integration of the hg stacked patches extenstion (don't remember the > name, the one giving you qpull/qpush) with 3.0 (quilt) format? As I see it, there is no need for using Mercurial Queues (mq) with mercurial-buildpackage because dpkg-source format "3.0 (quilt)" has the same purpose as mq, namely to wrap around quilt to achieve automatic patch handling. To clarify, assume you have downloaded the sample1 package from http://people.debian.org/~hertzog/packages/debsrc3.0 which is in format "3.0 (quilt)". To put it under Mercurial control, do $ mercurial-initrepo sample1 $ cd sample1 $ mercurial-importdsc ../sample1_1.0-1.dsc $ vi debian/changelog (Add a new entry 1.0-2.) (Then hack away on a nice new feature touching a lot of files.) $ mercurial-buildpackage Now dpkg-source will have created a patch file debian/patches/debian-changes-1.0-2 containing all your hacks. When you are satisfied, you can do $ quilt rename nice-new-feature.diff to give the patch a better name. You can then start on another feature, which will again end up as debian/patches/debian-changes-1.0-2 until you give it a better name. Or did you have something else in mind? >> * Only one repository. Branches are used to keep upstream separate. > > Support for pristine-tar? Sure, just put place your pristine tarballs in ../ and you are fine. :-) There is no support for keeping the pristine tarballs in the Mercurial repository, and I do not really see any point in doing so: The pristine tarball can be retrieved from upstream and/or the Debian pool. But I might have missed some use cases... Cheers, -- Jens Peter Secher. _DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
leftover /usr/X11R6 references
/usr/X11R6 is gone but code trying to use it lives on. Today I noticed gnome-settings-daemon doing this every 2 seconds for an unknown reason that I have not yet tracked down: inotify_add_watch(20, "/usr/X11R6/lib/X11", IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR) = -1 ENOENT (No such file or directory) That led to this: j...@gnu:/usr/lib>grep usr/X11R6 *.so.* Binary file libQtGui.so.4 matches Binary file libQtGui.so.4.5 matches Binary file libQtGui.so.4.5.3 matches Binary file libSDL-1.2.so.0 matches Binary file libSDL-1.2.so.0.11.2 matches Binary file libXaw.so.7 matches Binary file libXaw7.so.7 matches Binary file libXaw7.so.7.0.0 matches Binary file libXcursor.so.1 matches Binary file libXcursor.so.1.0.2 matches Binary file libgd.so.2 matches Binary file libgd.so.2.0.0 matches Binary file libgksu2.so.0 matches Binary file libgksu2.so.0.0.2 matches Binary file libjack.so.0 matches Binary file libjack.so.0.0.28 matches Binary file libjackserver.so.0 matches Binary file libjackserver.so.0.0.28 matches Binary file libkdeui.so.5 matches Binary file libkdeui.so.5.3.0 matches Binary file libnetpbm.so.10 matches Binary file libnetpbm.so.10.0 matches Binary file libqt-mt.so.3 matches Binary file libqt-mt.so.3.3 matches Binary file libqt-mt.so.3.3.8 matches Binary file librpm.so.0 matches Binary file librpm.so.0.0.0 matches And anywhere I look I can find more: r...@gnu:/etc>git grep usr/X11R6 | wc -l 52 r...@gnu:/usr/lib>grep usr/X11R6 -r . ./python2.5/site-packages/numpy/distutils/system_info.py:library_dirs = /usr/X11R6/lib [...] There are probably more references total than can be sensibly removed, but perhaps it would be worth adding some targeted lintian checks to warn about uses in places, like libraries, where it probably indicates the library is doing unnecessary work of including the directory in a search path? -- see shy jo signature.asc Description: Digital signature
Re: leftover /usr/X11R6 references
Le vendredi 20 novembre 2009 à 17:41 -0500, Joey Hess a écrit : > /usr/X11R6 is gone but code trying to use it lives on. > > Today I noticed gnome-settings-daemon doing this every 2 seconds for an > unknown > reason that I have not yet tracked down: > > inotify_add_watch(20, "/usr/X11R6/lib/X11", > IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR) > = -1 ENOENT (No such file or directory) It’s probably the fontconfig monitor, checking whether /usr/X11R6/lib/X11/fonts appears, since this directory is referenced in fonts.conf. Of course it’s not expected to do that every 2 seconds, it should only do it upon startup. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: leftover /usr/X11R6 references
Package: libxcursor1
Version: 1:1.1.9-1
On Fri, Nov 20, 2009 at 17:41:32 -0500, Joey Hess wrote:
> /usr/X11R6 is gone but code trying to use it lives on.
>
[...]
> Binary file libXaw.so.7 matches
> Binary file libXaw7.so.7 matches
> Binary file libXaw7.so.7.0.0 matches
http://cgit.freedesktop.org/xorg/lib/libXaw/tree/src/Pixmap.c#n671
static char *default_path =
"%H/%T/%N:%P/include/X11/%T/%N:/usr/X11R6/include/X11/%T/%N:/usr/include/X11/%T/%N:%N";
Shouldn't be a problem because /usr/include/X11 comes first (%P is /usr).
> Binary file libXcursor.so.1 matches
> Binary file libXcursor.so.1.0.2 matches
debian/rules:
--with-cursorpath=~/.icons:\$${datadir}/icons:/usr/share/pixmaps:/usr/X11R6/lib/X11/icons
\
No idea why we still have this, this should probably be fixed.
Cheers,
Julien
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Ridiculously large packages
[dropping debian-cd for this subthread] On Fri, Nov 20, 2009 at 8:01 PM, Cyril Brulebois wrote: > Cyril Brulebois (20/11/2009): >> And you didn't see Urban Terror and its 700+ MB yet! Speaking of >> which, what's the status of data.debian.org? IIRC, it's been in the >> pipe for 2+ years at the very least (was already mentioned during >> DC'07). :) > > OOH. http://ftp-master.debian.org/wiki/projects/data/ That is from 2008 :) http://lists.debian.org/debian-devel/2008/05/msg00970.html Would definitely be nice to see it come to fruition though. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ITP: mercurial-buildpackage (for those who care about Mercurial)
Jens Peter Secher writes: > 2009/11/19 Goswin von Brederlow : >> Jens Peter Secher writes: > [...] >>> Â * Support dpkg source format 3.0. >> >> Integration of the hg stacked patches extenstion (don't remember the >> name, the one giving you qpull/qpush) with 3.0 (quilt) format? > > As I see it, there is no need for using Mercurial Queues (mq) with > mercurial-buildpackage because dpkg-source format "3.0 (quilt)" has > the same purpose as mq, namely to wrap around quilt to achieve > automatic patch handling. Not quite. The Mecurial Queues are under version control. That means I can check out last months patch series, bisect changes, see who changed what when and so on. All in a way mercurial users are use to. > To clarify, assume you have downloaded the sample1 package from > http://people.debian.org/~hertzog/packages/debsrc3.0 which is in > format "3.0 (quilt)". To put it under Mercurial control, do > > $ mercurial-initrepo sample1 > $ cd sample1 > $ mercurial-importdsc ../sample1_1.0-1.dsc > $ vi debian/changelog > (Add a new entry 1.0-2.) > (Then hack away on a nice new feature touching a lot of files.) > $ mercurial-buildpackage > > Now dpkg-source will have created a patch file > debian/patches/debian-changes-1.0-2 containing all your hacks. > > When you are satisfied, you can do > > $ quilt rename nice-new-feature.diff > > to give the patch a better name. > > You can then start on another feature, which will again end up as > debian/patches/debian-changes-1.0-2 until you give it a better name. > > Or did you have something else in mind? That means people have to use quilt and mercurial. With mercurisl queues you would have only mercurial and the quilt part is hidden. I'm not saying mercurial queues should be forced onto the user but I think it would be nice to support them. >>> Â * Only one repository. Â Branches are used to keep upstream separate. >> >> Support for pristine-tar? > > Sure, just put place your pristine tarballs in ../ and you are fine. :-) > > There is no support for keeping the pristine tarballs in the Mercurial > repository, and I do not really see any point in doing so: The > pristine tarball can be retrieved from upstream and/or the Debian > pool. But I might have missed some use cases... pristine-tar does not put the tarball into the repository. It only stores the delta between taring up the upstream branch and the actual upstream orig.tar.gz. That way you can clone a repository and build without first having to go hunting around for the orig.tar.gz. Please look at it and look how git-buildpackage uses pristine-tar. I find this feature quite important as it saves a lot of time when having to do a quick fix for a package. > Cheers, MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: leftover /usr/X11R6 references
Hi Dne Fri, 20 Nov 2009 17:41:32 -0500 Joey Hess napsal(a): > Binary file librpm.so.0 matches > Binary file librpm.so.0.0.0 matches lib/psm.c:static const char * const SCRIPT_PATH = "PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin"; I don't think it causes any harm. > There are probably more references total than can be sensibly removed, > but perhaps it would be worth adding some targeted lintian checks to warn > about > uses in places, like libraries, where it probably indicates the library is > doing unnecessary work of including the directory in a search path? Is this really worth of diversion from upstream? -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: Bits from the FTPMaster meeting
Hi! On Sun, 2009-11-15 at 22:22:52 +, Neil Williams wrote: > On Sun, 15, Nov, 2009 at 02:37:56PM -0500, Joey Hess spoke thus.. > > Note that debootstrap does not support data.tar.bz2. > > debootstrap-1.0.20/functions: extract > > progress "$p" "$#" EXTRACTPKGS "Extracting packages" > packagename="$(echo "$pkg" | sed 's,^.*/,,;s,_.*$,,')" > info EXTRACTING "Extracting %s..." "$packagename" > ar -p "./$pkg" data.tar.gz | zcat | tar -xf - This has been fixed now in debootstrap's svn. I've also sent now a set of patches to use dpkg-deb instead of ar when available. > deb-gview is also affected by this but I haven't had any bug reports. > Fairly easy to fix that in deb-gview though due to the use of > libarchive. > > multistrap will also be affected. Well, IMO any program implementing .deb extraction w/o using something like --fsys-tarfile, --extract or --control from dpkg-deb (until we have the upcoming libdpkg...), should be prepared to handle the format described in deb(5), and deserves a bug otherwise. The fact that the Debian archive only accepts a subset of the valid .deb format, or that we might not want to have bzip2 compressed packages in the base system is a matter of policy in Debian, and does not mean others might want to do otherwise. regards, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: possible MBF about Policy 8.2 (Shared library support files)
On Thu, Nov 19, 2009 at 05:41:11AM +0100, Goswin von Brederlow wrote: > >> I detected 1063 possible violations with some percentage of false > >> positives. Since those are too many to go through by hand I filtered a > >> bit for the location of the violating files: > >> /etc/ : 137 packages > >> /bin/ or /usr/bin : 285 packages > >> /sbin/ or /usr/sbin/: 47 packages > >> Still too many for one go and a huge overlap between the 3 cases so I > >> picked just packages that contained a shared library (as witnessed by > >> a shlibs file in the control.tar.gz) and files in /etc/. I considered > >> any file in /etc/ that does not contain a version in its path or name > >> that would make it distinct from a future SOVERSION in violation of > >> 8.2. I (hopefully) removed all false positives (leaving 126 packages). > This is true. On its own none of them are a policy violation if you > want to nit-pick. Only when a new SONAME is uploaded with the same > files is the policy really violated. > For that I have 2 things to consider: > 1) How sure are you the SONAME never changes? How sure are you the > file will be obsolete in the next SONAME? How sure are you that you > will remember to rename all files on a SONAME change? If there is even > the slightest doubt the name should be changed now to a safe name so > the package is prepared for all eventualities. > With a verry few exceptions (like libc6) the risk of a future > collision is just to big. If that means you have to add a version to > the conffile or split the package now instead of in a year or two that > is regrettable but something I hope can be lived with. In the case of certain libraries: *very* sure. If you aren't sure which ones are sure, then I think a mass bugfiling is premature. > 2) Multiarch (are you hating that word yet?) is a release goal for squeeze > With multiarch the library should be installable for multiple > architectures so that (different) binaries from multiple architectures > that depend on it can be installed. E.g. /usr/bin/bar and /usr/bin/baz > both depending on libfoo. > If libfoo contains conffiles then they will give a file collision in > dpkg preventing the installation of more than one architecture. Having > the conffile in libfoo-common (Arch: all) avoids that. Using the arch > tripplet in the path or name avoids it too but should be only used > when conffiles are architecture specific. The present aim for dpkg multiarch support in squeeze is to allow reference counting of conffiles provided by multiarch packages, precisely so that we don't have to have gratuitous splits of packages for conffiles that can reasonably be shared between the libraries on multiple architectures. Furthermore, in the event that a conffile *can't* reasonably be shared between architectures, it's at least as appropriate for the path of the conffile to be qualified with the *architecture*, *instead of* with the version. So I don't think multiarch is a suitable rationale for an MBF here. And as for soname transitions: frankly, conffiles are much less of a problem (nowadays, thanks to Replaces: working correctly) than non-conffile config files, which your MBF appears not to address at all. Non-conffile config files in shared library packages are incredibly bad, because there's no right way to purge the shared lib package in that case. > Multiarch is actualy the reason libc-bin was created recently as > thereis no libc7 anywhere in sight that would require it. So jump on > the wagon and get your package prepared to meat the challenge of > multiarch. libc-bin was split because of *binaries* that need to be shared between architectures, not because of conffiles. Moving the conffiles to libc-bin was a reasonable thing to do given that a split was already happening, but absent the need for such a -bin package, I don't think conffiles in shared lib packages are a serious issue. Only when the soname changes and the conffile does not do we have a policy violation, and I don't consider it appropriate to make library maintainers do extra work outside of an actual library transition to satisfy this additional requirement. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#557303: ITP: libmoosex-role-withoverloading-perl -- Moose extension for roles that support overloading
Package: wnpp Owner: Jonathan Yu Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libmoosex-role-withoverloading-perl Version : 0.03 Upstream Author : Florian Ragwitz * URL : http://search.cpan.org/dist/MooseX-Role-WithOverloading/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : Moose extension for roles that support overloading MooseX::Role::WithOverloading allows you to write a Moose::Role which defines overloaded operators and allows those operator overloadings to be composed into the classes/roles/instances it's compiled to, while plain Moose::Roles would lose the overloading. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
