Re: The 'git' Debian package in squeeze
On Thu, Sep 17, 2009 at 05:06:02PM +0200, Vincent Danjean wrote: > Note that adding a release (squeeze) without a git package will not > solve the problem: the git/lenny package will not be removed from > the system without an explicit action of the administrator. > And the administrator can already remove the empty git/lenny package. Having a release in between with no git package means that the git package will be reported as 'obsolete' in frontends such as aptitude, so users who pay attention to such things on upgrade have an opportunity to take action. -- 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 signature.asc Description: Digital signature
Re: Transitional (dummy) packages considered silly
Magnus Holmgren wrote: > When a binary package is renamed or split, as well as if several packages are > merged under a new name, transitional packages are normally created, which > depend on the new packages, which in turn Replaces and Conflicts with, and > possibly Provides, the old packages. I find those dummy packages as silly to > create as to uninstall after upgrading. Seconded. > I propose a new control field called e.g. Supersedes that will provide the > same semantics. In its simplest form, a renamed package will declare that it > Supersedes the old package name. That will be considered equivalent to > conflicting with/replacing earlier versions of the superseded package, as > well > as providing a new version of it, just like a dummy package. Multiple > packages > can supersede the same package (but they should probably be the same > version), > and one package can of course supersede many others. > I support this, however with not implying Conflicts/Replaces/Provides when Supersedes is specified. Supersedes would be just a 'proposal' to a package manager to remove old package name and install the new one, i.e. explicitly declared upgrade path. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer signature.asc Description: OpenPGP digital signature
Bug#547274: ITP: gource -- graphical source control visualisation for git and CVS
Package: wnpp Severity: wishlist Owner: Francois Marier * Package name: gource Version : 0.11 Upstream Author : Andrew Caudwell * URL : http://code.google.com/p/gource/ * License : GPLv3+ Programming Lang: C++ Description : graphical source control visualisation for git and CVS OpenGL-based 3D visualisation tool for git and CVS source control repositories. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: The 'git' Debian package in squeeze
On Thu, Sep 17, 2009 at 11:06:11AM -0500, Peter Samuelson wrote: > Well, except _not_ to abet the hostile takeover of a > project name that has been around since ... I don't know, > but the Debian package goes back to 1997. In what way is it hostile? Do you really believe that leaving things the way they are is in the best interest of our users? > I know git is the awesomest thing since tla, but I'm > disappointed that 8 or 9 years of seniority did not, in > the end, count for anything. I believe the upstream was last modified in 1997. So that's 12 years of "seniority", but it's also 12 years in which the upstream source was essentially unmaintained. If we really did decide that our priority was packages, rather than users, I'd hope some other metric than age was used to resolve any such conflicts. -- Jon Dowland signature.asc Description: Digital signature
Re: Packages that download/install unsecured files
On Thu, Sep 17, 2009 at 09:26:38PM +0200, Christoph Anton Mitterer wrote: > 2) Package installation already downloads something and > installs this e.g. some font packages (msttcorefonts) or > documentations (susv2/3) do this. Personally I dislike this mode of operation. I don't like lots of code running in postinsts as root to perform e.g. downloads (examples: flashplugin-nonfree) and subsequent processing (unpacking, running shell scripts, etc.). In addition you don't get the size of the downloaded blobs as part of your package's Install-Size and in many cases in the past its been possible to have the package marked as installed correctly despite it not actually working. In the case of flashplugin-nonfree I frequently hit a problem where it would invoke wget which would wait for a long time for network timeouts, stalling the upgrade process, due to a non-defined http_proxy environment variable in my session's context. I tried to solve this problem for game data at least using "game-data-packager", which is designed after "java-package", which was (at the time I looked) the only tool which I thought approached the problem in a sane way. -- Jon Dowland signature.asc Description: Digital signature
Bug#547299: ITP: libtry-tiny-perl -- Perl module providing minimal try/catch
Package: wnpp Severity: wishlist Owner: Ansgar Burchardt * Package name: libtry-tiny-perl Version : 0.02 Upstream Author : Yuval Kogman * URL : http://search.cpan.org/dist/Try-Tiny/ * License : MIT Programming Lang: Perl Description : Perl module providing minimal try/catch Try::Tiny provides bare bones try/catch statements that are designed to minimize common mistakes with eval blocks, and NOTHING else. . This is unlike TryCatch which provides a nice syntax and avoids adding another call stack layer, and supports calling return from the try block to return from the parent subroutine. These extra features come at a cost of a few dependencies, namely Devel::Declare and Scope::Upper which are occasionally problematic, and the additional catch filtering uses Moose type constraints which may not be desirable either. . The main focus of this module is to provide simple and reliable error handling for those having a hard time installing TryCatch, but who still want to write correct eval blocks without 5 lines of boilerplate each time. Try::Tiny is required by the new release of Moose (libmoose-perl). Regards, Ansgar -- 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.
Charles Plessy wrote: Le Fri, Sep 18, 2009 at 12:51:14AM +0200, Wouter Verhelst a écrit : What I'm trying to discuss here is that Debian Developers who package their own software as Debian native packages should be allowed to do so Hi Wouter and everybody, it seems to me that the difficulties in this discussion come from the fact that ’native’ is used to mean two different things: - Packages using a dpkg format called ‘native’. - Software made by Debian for Debian. No, I don't think so, because this was the core of discussion (see the subject). But I think there was some confusion because I started this sub-thread as question of "debian/" directory on upstream, thus having Debian as "downstream distribution" (and interpreting upstream as "upstream distribution") Wouter takes the more orthodox interpretation, where we don't have any "upstream distribution". I still think that converting a (non debian specific) package into native package is not nice to downstreams, and probably egoistic (= debian centric). But anyway it is not a big issue, so I don't think we should continue discussing it. Every developer will decide if going native or not. [ My mails in this week was about a new possible problem that I discovered, but it is more about dpkg-source 3.0 then the native format ] This creates confusion, as there are arguments in favor of using the format called ‘native’ for software not specific to Debian, but on the othe hand there is a general perception that if a package uses a native format, the software has special ties to Debian. Interestingly, when the format ‘3.0 (git)’ will be accepted in our archive, there may be a lot of ‘native’ programs that will be using a non-native package format. AFAIK the only supported format will be "3.0 (native)", "3.0 (quilt)". The other 3.0 format were considered "experimental" and discouraged. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Packages that download/install unsecured files
On 9/18/09, Patrick Matthäi wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Michael S Gilbert schrieb: >> On Thu, 17 Sep 2009 21:26:38 +0200 Christoph Anton Mitterer wrote: >>> Hi. >>> >>> Some time ago, I've wrote several bug reports to packages, that download >>> files from some non-apt-secured sources of the web, and install them. >> >> i also started a similar discussion a while back, which was met with >> mixed opinion [0]. i tried to lay out the full spectrum of issues >> related to this problem, but many just focused on the non-free aspect. >> no consensus was reached. >> >> checksums are a good start, but if the data itself is non-free (or >> closed or obscured), then how can you be sure it is not malicious? >> >> i think it is a matter of trust, and maybe the key would be that scripts >> should only accept the external data if it is signed and hashed by an >> authenticated DD's gpg key. > > This would be a good option. But I think you do not have access to the > upstream files and also you can not sign them, maybe upstream itself > also do not want to do it. > > Hosting them on my own host is also not a good option. you could host just the hashes for the external files (signed with your key) on your site. then you wouldn't have to duplicate upstream's data files nor spend (much) of your own bandwidth (since the hash files should be fairly small in most cases). or maybe there could be a hash.debian.org or a project on alioth to centralize the hashes? mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Packages that download/install unsecured files
Michael S Gilbert wrote: > you could host just the hashes for the external files (signed with > your key) on your site. then you wouldn't have to duplicate > upstream's data files nor spend (much) of your own bandwidth (since > the hash files should be fairly small in most cases). > > or maybe there could be a hash.debian.org or a project on alioth to > centralize the hashes? At least for the geoip package, there's no need for a DD to take the binaries from upstream, and sign so that the package can validate it upon download. Geoip upstream provides the source of these binary databases, so all we need to do is find a consistent and reliable way to get new database updates, built from source by debian and propagated through the usual apt repositories. This looks like a good candidate for volatile/backports. Looks like this method works well for clamav-data and other similar packages which needs to update databases frequently on stable/oldstable. Regards, Tom Feiner signature.asc Description: OpenPGP digital signature
Re: Packages that download/install unsecured files
On 2009-09-18, Tom Feiner wrote: > Looks like this method works well for clamav-data and other similar packages > which needs to update databases frequently on stable/oldstable. clamav-data is scheduled for deletion as soon as volatile moves onto ftp-master, so that's no precedent. (I.e. there is opposition against daily builds entering the archive without real developers signing them.) 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: Packages that download/install unsecured files
Philipp Kern wrote: > On 2009-09-18, Tom Feiner wrote: >> Looks like this method works well for clamav-data and other similar packages >> which needs to update databases frequently on stable/oldstable. > > clamav-data is scheduled for deletion as soon as volatile moves onto > ftp-master, so that's no precedent. (I.e. there is opposition against > daily builds entering the archive without real developers signing them.) > Ah, I was not aware of this. So what is the best practice in this case, where a package needs an updated database on a regular basis (monthly basis in case of geoip)? Thanks, Tom Feiner signature.asc Description: OpenPGP digital signature
Re: Packages that download/install unsecured files
On Fri, 18 Sep 2009 19:06:21 +0300, Tom Feiner wrote: > Philipp Kern wrote: > > On 2009-09-18, Tom Feiner wrote: > >> Looks like this method works well for clamav-data and other similar > >> packages > >> which needs to update databases frequently on stable/oldstable. > > > > clamav-data is scheduled for deletion as soon as volatile moves onto > > ftp-master, so that's no precedent. (I.e. there is opposition against > > daily builds entering the archive without real developers signing them.) > > > > Ah, I was not aware of this. So what is the best practice in this case, where > a package needs an updated database on a regular basis (monthly basis in case > of geoip)? i don't think that there is any standard at this point, and maybe the outcome of this discussion should be a standardized solution. my suggestion could potentially be a one-size-fits-all solution for all of the cases mentioned so far: antivirus updates, gps/geographical updates, game data updates (often non-free), printer firmware updates (often non-free), non-free font updates, non-free firmware/driver updates, etc. anything i've missed? however, i think that since these packages are depending on information outside of the debian archive, most (if not all) should be hosted under the contrib section (since users without internet access will encounter reduced/limited functionality). and especially for those scripts depending on non-free external data. mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Packages that download/install unsecured files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael S Gilbert schrieb: > On 9/18/09, Patrick Matthäi wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Michael S Gilbert schrieb: >>> On Thu, 17 Sep 2009 21:26:38 +0200 Christoph Anton Mitterer wrote: Hi. Some time ago, I've wrote several bug reports to packages, that download files from some non-apt-secured sources of the web, and install them. >>> i also started a similar discussion a while back, which was met with >>> mixed opinion [0]. i tried to lay out the full spectrum of issues >>> related to this problem, but many just focused on the non-free aspect. >>> no consensus was reached. >>> >>> checksums are a good start, but if the data itself is non-free (or >>> closed or obscured), then how can you be sure it is not malicious? >>> >>> i think it is a matter of trust, and maybe the key would be that scripts >>> should only accept the external data if it is signed and hashed by an >>> authenticated DD's gpg key. >> This would be a good option. But I think you do not have access to the >> upstream files and also you can not sign them, maybe upstream itself >> also do not want to do it. >> >> Hosting them on my own host is also not a good option. > > you could host just the hashes for the external files (signed with > your key) on your site. then you wouldn't have to duplicate > upstream's data files nor spend (much) of your own bandwidth (since > the hash files should be fairly small in most cases). Hmm good idea :) - -- /* 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) iEYEARECAAYFAkqzzKEACgkQ2XA5inpabMdsSQCgg0+9S6my1TCXUZoFn6nR3+N4 tCwAn3ukfDSdOovEl/eoZx3eTU7YUgYi =YMqo -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Quick analysis of the Python dist-packages transition
Hi, starting from Python 2.6, the Debian packages look for modules in a different directory: /usr/lib/python2.6/dist-packages instead of /usr/lib/python2.X/site-packages. This is handled transparently by python-central and python-support, but at install time, distutils (the thingy behind “python setup.py”) installs modules in another directory by default, and the packaging has to cope with it. Therefore, a number of packages have to be fixed before they can work with python2.6. Practically speaking, this is the only thing that prevents python2.6 from entering unstable. This is a first attempt at listing packages needing to be fixed. There are 1396 source packages using python-central or python-support in Debian. (The analysis excludes packages not using them since they are already broken.) * 505 of these packages do not use distutils and should not be affected, still shipping files to site-packages/. However, according to Scott Kimmermann (who handled parts of this transition in Ubuntu), python-central does not look for modules in /usr/lib/python2.6/site-packages, so most modules using it are broken. If this is the case, python-central needs to be NMUed to handle such packages. * 73 packages don’t use the shipped setup.py and use a Debian-specific installation system (e.g. to install modules in a private directory). * 818 packages use distutils/setuptools for installation. I - CDBS: 310 packages CDBS needs updating to work with python2.6. A patch was proposed by Martin Pitt in #537373 and the maintainers have already agreed for a NMU, so it’s just a matter of uploading it. In the meantime, Piotr Ożarowski proposed another idea (setting --install-lib instead of --install-layout) which looks much cleaner, so we’ll probably use that approach instead. In all cases this will be done soon. * 269 CDBS packages should not be affected. * 41 packages fiddle with site-packages. If either Martin’s or Piotr’s approach is used, they won’t need updating. II - DH: 143 packages Debhelper has already been updated so that dh uses --install-layout=deb. * 141 DH packages should already work. * 2 packages fiddle with site-packages and need updating. III - Debhelper: 438 packages * 52 packages already use --install-layout=deb and don’t play with site-packages. * 246 packages don’t, but should work as well provided that we ensure python-central is fixed. * 73 packages fiddle with site-packages and need updating. Overall summary: * CDBS needs to be updated (should be done in a week at most). * python-central needs a NMU to handle /usr/lib/python2.6/site-packages as a source directory. * 75 Python packages need to be updated, the dd-list is attached. If there are no objections, I will submit a MBF for those 75 packages in a few days. Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling Daniel Leidert (dale) pymol (U) Adam Cécile (Le_Vert) hellanzb Nicolas FRANCOIS (Nekral) translate-toolkit Marco Presi (Zufus) matplotlib (U) Francesc Altet pytables Kumar Appaiah harvestman (U) python-goopy (U) Nacho Barrientos Arias rdflib Ernesto Nadir Crespo Avila pythoncard pyx Michael Banck pymol (U) Julien BLACHE eikazo Jérémy Bobbio python-clientform (U) python-mechanize (U) W. Martin Borgert trac (U) A. Maitland Bottoms mayavi Giacomo Catenazzi bauble Ondrej Certik matplotlib (U) Jesus Climent trac (U) Kevin Coyner kodos LI Daobing pymol (U) Debian Bazaar Maintainers bzr-builddeb Debian Games Team libtpclient-py Debian Python Modules Team constraint ctypes (U) inotifyx (U) logilab-constraint matplotlib pastedeploy (U) pastewebkit (U) pyscard (U) python-docutils python-goopy python-kinterbasdb python-memcache (U) python-pyglew python-pytils (U) python-reportlab (U) sqlobject (U) webhelpers (U) Debian X Strike Force ccsm Debian/Ubuntu Zope Team python-clientform python-mechanize python-tz zope.interface Debichem Team pymol Barry deFreese libtpclient-py (U) Cédric Delfosse gaphor Benjamin Drung matplotlib (U) Alexandre Fayolle constraint (U) logilab-constraint (U) matplotlib (U) pyqonsole xmldiff Sean Finney ccsm (U) Gustavo Franco gdebi gdebi (U) John Goerzen pygopherd Debian QA Group kphotobymail synopsis Mikhail Gusarov python-pytils Anders Hammarquist python-meld3 supervisor Magnus Holmgren pyscrabble Adam C. Powell, IV pysparse Michael Janssen bittorrent Matthias Klose gadfly lxml python-gnuplot python-imaging python-reportlab python-scientifi
Re: Packages that download/install unsecured files
On Thu, 2009-09-17 at 23:13 +0100, Steve Kemp wrote: > 4) The package downloads insecure code and directly executes it. I'd have counted these to (1),... because downloading and "just" installing means automatically, that it's likely to be executed at some point. Of course it's even worse if this is definitely sure ;) Chris. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Packages that download/install unsecured files
On Fri, 2009-09-18 at 12:37 +0100, Jon Dowland wrote: > Personally I dislike this mode of operation. I don't like > lots of code running in postinsts as root to perform e.g. > downloads (examples: flashplugin-nonfree) and subsequent > processing (unpacking, running shell scripts, etc.). Of course,.. but with some packages,... it's not possible otherwise,.. (due to license issues). But let me add to my previous proposals, that the policy should be changed in such a way that: - A package might only download install/execute remote data or code, if license forbids direct distribution or if the data/code is so volatile,.. that makes completely no sense to package it (regularly). The later exception should nearly never apply to code, but only to data (virus-signatures, spamassasin rules, and that like). > In > addition you don't get the size of the downloaded blobs as > part of your package's Install-Size and in many cases in > the past its been possible to have the package marked as > installed correctly despite it not actually working. Yeah,.. at least the install-size should be correctable by the maintainer by simply setting it manually in the control file. Chris. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#547350: ITP: sinfo -- Monitoring tool for computer clusters using broadcasts
Package: wnpp Severity: wishlist Owner: Gaudenz Steinlin * Package name: sinfo Version : 0.0.33 Upstream Author : Jürgen Rinas * URL : http://www.ant.uni-bremen.de/whomes/rinas/sinfo/ * License : GPL Programming Lang: C++ Description : Monitoring tool for computer clusters using broadcasts Sinfo is a monitoring tool that uses network broadcasts to distribute information about the status of a cluster node on your local network. It broadcasts CPU, memory usage, network load, and information about the top 5 processes of each computer. Sinfo consists of a daemon running on each node to distribute the information and an ncurses frontend to monitor the nodes. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Packages that download/install unsecured files
On Thu, 2009-09-17 at 23:02 -0400, Michael S Gilbert wrote: > checksums are a good start, but if the data itself is non-free (or > closed or obscured), then how can you be sure it is not malicious? Of course not at all but we should try to secure as much as possible and close as many holes as possible. In case of closed source,.. if upstream goes evil,.. we will never be able to do anything. Perhaps one should split those source out of non-free, so that: non-free == non-dfsg compliant, but "open source code". closed-section == non-dfsg and closed (e.g. Adobe flash). Of course one could ban such totally closed software completely from debian,.. but I think this would be a bad idea,.. at least some of them is quite important (e.g. nvidia) for so many users. But an own section could be worth it. If it's not upstream that gets evil, but just some man-in-the-middle attackt,.. verifying closed source stuff will still improve security, as I've described in my mail before. > i think it is a matter of trust, and maybe the key would be that scripts > should only accept the external data if it is signed and hashed by an > authenticated DD's gpg key. Yeah,.. as I've said,.. the signatures/hashes to those files/data/code should always be under Debian's control,... not just e.g. downloading (https secured) md5 hashes from Adobe's website,.. and verify them against the most recent flash version should NOT be done by the package. This should be done by the Debian maintainer. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Quick analysis of the Python dist-packages transition
Le vendredi 18 septembre 2009 à 21:18 +0200, Josselin Mouette a écrit :
> * 246 packages don’t, but should work as well provided that we
> ensure python-central is fixed.
I forgot to explain how exactly it needs to be fixed.
> * python-central needs a NMU to
> handle /usr/lib/python2.6/site-packages as a source directory.
It needs to support /usr/local/lib/python2.6/{dist,site}-packages as
well. Otherwise, 83 more packages will have to be changed.
--
.''`. 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: Packages that download/install unsecured files
On Fri, 2009-09-18 at 18:19 +0300, Tom Feiner wrote: > Geoip upstream provides the source of these binary databases, so all we need > to do is find a consistent and reliable way to get new database updates, built > from source by debian and propagated through the usual apt repositories. This > looks like a good candidate for volatile/backports. Looks like this method > works well for clamav-data and other similar packages which needs to update > databases frequently on stable/oldstable. Of course,.. if the data could be included directly into a package that would be much better, but this is not possible for all packages. If it is possible,.. the maintainer should of course still try to verify his sources/data using upstream signatures/hases/etc. In case it is not possible to include it in the package,... the control or "power" on the hashes/signatures should be held by someone from Debian. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Packages that download/install unsecured files
On Fri, 2009-09-18 at 12:22 -0400, Michael Gilbert wrote: > however, i think that since these packages are depending on information > outside of the debian archive, most (if not all) should be hosted under > the contrib section (since users without internet access will encounter > reduced/limited functionality).and especially for those scripts > depending on non-free external data. Uhm.. difficult question,.. The thing is,.. (IMHO),.. the user could still use another data source that is DFSG-compliant. Let's take the geoip example (under the assumtion the binaries and libs are DFSG compliant, but the data not). Binaries+libs could (right now) should be allowed to go into main,.. if it's possible to use "other" geoip-data (regardless of whether there's already a provider for this or not),... Only if the program data is so much tied to upstream, that there probably cannot be a free provider,.. it should be forced to non-free. Chris. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
libjpeg62-dev -> libjpeg-dev transition
Dear developers, There is a new version of libjpeg in the archive (JPEG7), but is it not yet cleared for building packages against it. If your package Build-Depends on libjpeg62-dev, please change to 'libjpeg-dev' (without the 62) to ease the transition. Cheers, -- Bill. Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: libjpeg62-dev -> libjpeg-dev transition
On Sat, Sep 19, 2009 at 12:04:32AM +0200, Bill Allombert wrote: > Dear developers, > > There is a new version of libjpeg in the archive (JPEG7), but is it > not yet cleared for building packages against it. > > If your package Build-Depends on libjpeg62-dev, please change to 'libjpeg-dev' > (without the 62) to ease the transition. libjpeg-dev is a virtual package, so a real package should also be listed as build-dep. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: libjpeg62-dev -> libjpeg-dev transition
On Sat, Sep 19, 2009 at 12:04:32AM +0200, Bill Allombert wrote: > Dear developers, > > There is a new version of libjpeg in the archive (JPEG7), but is it > not yet cleared for building packages against it. > > If your package Build-Depends on libjpeg62-dev, please change to 'libjpeg-dev' > (without the 62) to ease the transition. Err no, please don't. First I'd like to see packages already build-depending on libjpeg-dev to be rebuilt against a libjpeg7 that provides libjpeg-dev. In order to do that please provide a libjpeg6 not providing libjpeg-dev and a libjpeg7-dev which does provides it. I'll put blocks in my hint file to be sure that both those packages will migrate in testing together (I'm unsure if britney is clever enough to block them until all the binNMUs are done, I don't think it is). Then please ask for binNMUs of all the package that B-D on libjpeg-dev. Then we will let that migrate. _Only then_ you will open a mass bug on all packages that b-d on libjpeg62-dev to ask them to move to libjpeg-dev instead, so that the transition remains manageable. Doing it the other way ensures loads of pain to come. I'm not sure if we're ready for this transition yet though, I'll let luk or other RA/RM check if now is the best moment to do so. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org signature.asc Description: Digital signature
Re: Quick analysis of the Python dist-packages transition
Josselin Mouette writes: > Therefore, a number of packages have to be fixed before they can work > with python2.6. Practically speaking, this is the only thing that > prevents python2.6 from entering unstable. This is a first attempt at > listing packages needing to be fixed. Thank you for this work, and for communicating the results in these forums. This also allows us to have a better idea how far Python 2.6 is From unstable. -- \ “A thorough reading and understanding of the Bible is the | `\ surest path to atheism.” —Donald Morgan | _o__) | Ben Finney pgp1E80cLICsR.pgp Description: PGP signature
Re: Quick analysis of the Python dist-packages transition
On Fri, 18 Sep 2009, Josselin Mouette wrote: > If there are no objections, I will submit a MBF for those 75 packages in > a few days. Go ahead, we have waited too much for python 2.6 already. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
