Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed
Roberto C. Sánchez wrote, Thursday, April 17, 2008 2:24 AM On Wed, Apr 16, 2008 at 04:25:46PM +0100, Matthew Johnson wrote: do you have updated devscripts? debsign signs the dsc then updates the md5 hash in the changes before signing that. It needs to update the sha checks as well. The latest devscripts does. Will the devscripts in stable be updated to handle this? If so, when? If not, why not? (If you're looking for an answer from the maintainers of a package it's probably safer to ask them directly rather than assuming they read every post on debian-devel; admittedly several of us do, but... :-) I'm not convinced it meets the SRM team's criteria for a stable update, as laid out in http://release.debian.org/stable/4.0/4.0r3/ et al. 2.10.25 should migrate to testing over the weekend, so hopefully a bpo package won't be too much longer. In the meantime it's fairly easy to backport yourself, as several people have already done, or simply copy the new script over from an unstable machine. Other than the update for the new .changes file format, there have been relatively little changes to debsign since the version in etch, and those have all been bugfixes. Cheers, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed
On Thu, 17 Apr 2008, Adam D. Barratt wrote: >> Will the devscripts in stable be updated to handle this? If so, when? >> If not, why not? > > (If you're looking for an answer from the maintainers of a package it's > probably safer to ask them directly rather than assuming they read every > post on debian-devel; admittedly several of us do, but... :-) > > I'm not convinced it meets the SRM team's criteria for a stable update, > as laid out in http://release.debian.org/stable/4.0/4.0r3/ et al. It doesn't hurt to ask however. Ubuntu is also rushing a last-minute update in hardy to avoid this problem. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#476521: ITP: lua-orbit -- MVC framework for lua
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: lua-orbit Version: 2.0rc1 Upstream Author: Kepler project URL: http://orbit.luaforge.net License: MIT/X Description: MVC framework for lua -- Enrico Tassi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Should -dev packages providing .pc files depend on pkg-config?
On Wed, Apr 16, 2008 at 07:57:00PM +0200, Gabor Gombas wrote: > On Wed, Apr 16, 2008 at 07:15:53PM +0200, Goswin von Brederlow wrote: > > > You are missing the point. > > > > What if the library says "You must call /usr/bin/foo during build"? > > But the library can't say "foo must come from a Debian package". What if > I have my local replacement? Why should I be forced to install a package > that is now useless for me (and installing it would only cause confusion > as there are now two different tools with the same name present in > $PATH)? How is this different with _any_ dependency on the system? Do you suggest that iceweasel should drop its libgtk dependency, because users might want to use their own compiled version of it? Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: Should -dev packages providing .pc files depend on pkg-config?
This one time, at band camp, Goswin von Brederlow said: > > You are missing the point. > > What if the library says "You must call /usr/bin/foo during build"? Which package is this? > The libarry does not use foo, only the user, so no depends? > Or idoes forcing users to use foo make foo part of the API and hence > the library should depend on it? If you require something to be run, you get the dependency. Is there some package where any of this is relevant? -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Should -dev packages providing .pc files depend on pkg-config?
On Thu, Apr 17, 2008 at 01:44:55AM -0500, Manoj Srivastava wrote: > >> > What if the library says "You must call /usr/bin/foo during build"? > >> > >> How does the library say that? Why can't I just have gcc -o baz baz.c > >> -lfoo > >> > >> How can the library make that not work? > > > By not shipping the libraries in /usr/lib: > > >> pkg-config --libs valgrind > > -L/usr/lib/valgrind/amd64-linux -lcoregrind -lvex -lgcc > > And how exactly does this prevent me from doing: > baz: baz.c > gcc -o baz baz.c -L/usr/lib/foo/amd64-linux -lfoo By changing the paths and library names often. If upstream says pkg-config is the only supported thing, and all other methods, in particular direct linking, should be expected to break every time a new version comes out, then pkg-config is indeed how things must be done. If you don't, you get an FTBFS in a binNMU, which would not have been there if you would have used upstream's build system. Of course it is always possible for a package maintainer to divert from his upstream, and in some cases it is a very good idea, too. But when you do this, you're taking over a part of upstream. Only the library package maintainer can do this (not the maintainer for packages linking to the library). If you want to guarantee a stable interface when using -l for your library, even when upstream doesn't, go right ahead. But it's not the only way, and if a library package maintainer follows his upstream in requiring pkg-config, then packages depending on his -dev package will _need_ to use that method. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: Should -dev packages providing .pc files depend on pkg-config?
On Thu, Apr 17, 2008 at 07:58:44AM +0200, Tollef Fog Heen wrote: > Yes, in the simple case, you can just do this. In the more complex > case (which upstream might want to cater for), you need to use > pkg-config. No. Even in this case, I _don't_ need to use pkg-config. I just should be able to parse the .pc file, but I can do that with my own tools without calling pkg-config at all. It's the information inside the .pc file that has importance, not the choice of the tool that parses the .pc file. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Should -dev packages providing .pc files depend on pkg-config?
On Thu, Apr 17, 2008 at 12:02:20PM +0200, Bas Wijnen wrote: > How is this different with _any_ dependency on the system? Do you > suggest that iceweasel should drop its libgtk dependency, because users > might want to use their own compiled version of it? iceweasel _uses_ libgtk. A -dev package that ships a .pc file does _not_ use pkg-config - it just provides a data file that pkg-config (or some other similar tool) can use. If you want an analogy, think about -data packages: $ apt-cache show console-data | grep ^Depends: Depends: debconf | debconf-2.0, debconf (>= 0.5) | debconf-2.0 Notice it does not depend on console-tools or kbd, even though you need one of them to make use of the data. The same thing holds for .pc files - they are just data files that some other tool can process. Gabor [Of course, as has been already mentioned in this thread, if the -dev package also ships a script that calls pkg-config, then it should depend on pkg-config, but for a different reason.] -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Should -dev packages providing .pc files depend on pkg-config?
On Wed, Apr 16, 2008 at 07:21:15PM +0100, Neil Williams wrote: > > According to the suggested definition, if a package using this library > > chooses to use foo-config, it doesn't call pkg-config directly (and it > > may not call it at all, this depends on the inner workings of > > foo-config). > > During the time that foo-config calls pkg-config, the -dev package > containing foo-config must depend on pkg-config. That follows logically > from the "you call it, you depend on it" model. This isn't the case for other packages though, so it would be a special case for -dev packages. For normal packages, it is well possible to ship a script which some people may want to use (but many will not), and adding the script's dependencies only to Suggests, for example. > If we stick with the idea of "you call it, you depend on it", these > situations become a lot clearer. I think it is best to do this for -dev packages indeed. Or do you think it should be extended to all packages? On Wed, Apr 16, 2008 at 10:12:26PM +0200, Jakob Bohm wrote: >2. If libfoo-dev contains scripts which would typically be called by > packages that Depend, Pre-Depend or Build-Depend on libfoo-dev, then > anything needed by those scripts should (RFC-should) be ordinary > Depends for the libfoo-dev package. For instance if programs building > against libfoo would typically call /usr/bin/foo-config-get, then > anything called by foo-config-get (such as pkg-config or perl) would > need to be listed as Depends for libfoo-dev. Note that this does not > extend to anything otherwise needed by callers to take advantage of > files in libfoo-dev. For instance the presence of .h files in > libfoo-dev does not imply a Depends: c-compiler, nor would .pc files > imply a Depends: pkg-config. Right. But the problem is when "programs would typically call" changes into "programs may call", and the script is supposed to be opaque (so the package depeding on the -dev package is not supposed to need knowledge about the script's internals). For normal packages, in such a case, a Depends is too strong. But for -dev packages it seems reasonable. >3. Similarly, the fact that libfoo Depends: libbar for its runtime needs > has no reason to imply that libfoo-dev should Depend: libbar-dev, such > a need would arise only if the public (not private) .h files for libfoo > #include some files provided only by by libbar-dev etc or if libfoo.a > is included and useless without libbar.a. A weaker dependency > (Recommends or Suggests) would be sufficient if only rarely used public > .h files or rarely linked members of libfoo.a need libbar-dev. This weaker dependency is a problem if the symbols are used in public headers, but the fact that they are used is not actually "public". That is, people linking to libfoo should not need to know that they are linking to libbar as well. In such a case, analogous to the helper scripts case above, a Depends: is needed as well, and it cannot be weaker. Because if it would be, programs linking to libfoo and using that header file will fail to compile. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed
On Thu, Apr 17, 2008 at 08:48:21AM +0100, Adam D. Barratt wrote: > Roberto C. Sánchez wrote, Thursday, April 17, 2008 2:24 AM > > > On Wed, Apr 16, 2008 at 04:25:46PM +0100, Matthew Johnson wrote: > >>do you have updated devscripts? debsign signs the dsc then updates the > >>md5 hash in the changes before signing that. It needs to update the sha > >>checks as well. The latest devscripts does. > > >Will the devscripts in stable be updated to handle this? If so, when? > >If not, why not? > > (If you're looking for an answer from the maintainers of a package it's > probably safer to ask them directly rather than assuming they read every > post on debian-devel; admittedly several of us do, but... :-) > > I'm not convinced it meets the SRM team's criteria for a stable update, as > laid out in http://release.debian.org/stable/4.0/4.0r3/ et al. > > 2.10.25 should migrate to testing over the weekend, so hopefully a bpo > package won't be too much longer. In the meantime it's fairly easy to > backport yourself, as several people have already done, or simply copy the > new script over from an unstable machine. Other than the update for the new > .changes file format, there have been relatively little changes to debsign > since the version in etch, and those have all been bugfixes. > IMO, that sort of misses the point. While I maintain quite a few packages in Debian, the only places I run unstable/testing are in one VM (for testing/reproducing/fixing bugs that I cannot reproduce in stable) and in some chroots. The point is that I should be able to build my packages inside of a pbuilder or other type of chroot, sign the package on my host system and be reasonably sure that my package will be accepted into the archive. If the archive software breaks compatibility with the current stable release of (insert name of whatever tool is affected, specifically devscripts in this case), then it looks bad on Debian. Now, I do occasionally use backports and I also backport things on my own when I need it. However, this is a change that affects every single DD who runs stable as a primary system (which I am certain is a significant number) and should be handled through official channels, such as a special "DSA" (or comparable since this is not really a security issue) or at the very least through a point release (however, those can be spaced rather far apart). Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Should -dev packages providing .pc files depend on pkg-config?
Gabor Gombas <[EMAIL PROTECTED]> writes: > On Thu, Apr 17, 2008 at 07:58:44AM +0200, Tollef Fog Heen wrote: > >> Yes, in the simple case, you can just do this. In the more complex >> case (which upstream might want to cater for), you need to use >> pkg-config. > > No. Even in this case, I _don't_ need to use pkg-config. I just should > be able to parse the .pc file, but I can do that with my own tools > without calling pkg-config at all. It's the information inside the .pc > file that has importance, not the choice of the tool that parses the .pc > file. > > Gabor Then your own tool or a dummy deb should provide pkg-config. Just like when you use your own make implementation you would provide make so build-essential is still happy. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed
Le 17 avr. 08 à 13:04, Roberto C. Sánchez a écrit : IMO, that sort of misses the point. While I maintain quite a few packages in Debian, the only places I run unstable/testing are in one VM (for testing/reproducing/fixing bugs that I cannot reproduce in stable) and in some chroots. The point is that I should be able to build my packages inside of a pbuilder or other type of chroot, sign the package on my host system and be reasonably sure that my package will be accepted into the archive. If the archive software breaks compatibility with the current stable release of (insert name of whatever tool is affected, specifically devscripts in this case), then it looks bad on Debian. The problem is the same with lintian, that you need to backport regularly. (Lintian being arch:all, of course, that's much easier). Of course it would have been great to have the devscripts backport before the dpkg update, but it the ten day period leading to devscripts transitioning to testing/bpo, it's easy do use, e.g., pbuilder login to sign your packages. Inconvenient, but easy. T. PGP.sig Description: Ceci est une signature électronique PGP
yorick-yeti built on mips but not installed after two weeks
Hi, One of my packages, [1]yorick-yeti has been [2]built successfully on all official platforms, including [3]mips on Fri 28 Mar, but the mips package is still [2]not installed on the archive. It is held out of Lenny for this reason. I sent an e-mail to [EMAIL PROTECTED] on Tue 8 Apr to no avail. What should I do to get the package to transition? [1] http://packages.debian.org/yorick-yeti [2] http://buildd.debian.org/~jeroen/status/package.php?p=yorick-yeti [3] http://buildd.debian.org/build.php?arch=mips&pkg=yorick- yeti&ver=6.2.2-2 Best regards, Thibaut. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ADD me For Exchange
ADD me For Exchange
${devlibs:Depends} results in libstdc++6-4.1-dev
Hi,
when trying to update libgenome-1.3-1-dev I noticed that the variable
${devlibs:Depends} is turned into a dependency from a libstdc++6 which
is shipped with gcc-4.1 instead of using libstdc++6-4.2-dev or even
libstdc++6-4.3-dev. Quoting from my *.build log in an up to date
pbuilder environment:
...
g++ -shared -nostdlib /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crti.o
/usr/lib/gcc/i486-linux-gnu/4.2.3/crtbeginS.o .libs/gnFilter.o
.libs/gnCompare.o .libs/gnTranslator.o .libs/gnSourceFactory.o
.libs/gnFeature.o .libs/gnSourceQualifier.o .libs/gnFileContig.o
.libs/gnSourceSpec.o .libs/gnFileSource.o .libs/gnFASSource.o
.libs/gnFragmentSpec.o .libs/gnStringSpec.o .libs/gnGBKSource.o
.libs/gnStringTools.o .libs/gnGenomeSpec.o .libs/gnLocation.o
.libs/gnRAWSource.o .libs/gnBaseFeature.o .libs/gnSEQSource.o
.libs/gnSequence.o .libs/gnContigSpec.o .libs/gnSourceHeader.o
.libs/gnException.o .libs/gnFastTranslator.o .libs/gnPosSpecificTranslator.o
.libs/gnDefs.o -L/usr/lib/gcc/i486-linux-gnu/4.2.3
-L/usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.2.3/../../.. -lstdc++ -lm -lc
-lgcc_s /usr/lib/gcc/i486-linux-gnu/4.2.3/crtendS.o
/usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crtn.o -Wl,-soname -Wl,libG!
enome-1.3.so.1 -o .libs/libGenome-1..3.so.1.0.3
...
and I also maintain an unstable chroot where I forced gcc to gcc-4.3
where I got:
...
g++ -shared -nostdlib /usr/lib/gcc/i486-linux-gnu/4.3.1/../../../../lib/crti.o
/usr/lib/gcc/i486-linux-gnu/4.3.1/crtbeginS.o .libs/gnFilter.o
.libs/gnCompare.o .libs/gnTranslator.o .libs/gnSourceFactory.o
.libs/gnFeature.o .libs/gnSourceQualifier.o .libs/gnFileContig.o
.libs/gnSourceSpec.o .libs/gnFileSource.o .libs/gnFASSource.o
.libs/gnFragmentSpec.o .libs/gnStringSpec.o .libs/gnGBKSource.o
.libs/gnStringTools.o .libs/gnGenomeSpec.o .libs/gnLocation.o
.libs/gnRAWSource.o .libs/gnBaseFeature.o .libs/gnSEQSource.o
.libs/gnSequence.o .libs/gnContigSpec.o .libs/gnSourceHeader.o
.libs/gnException.o .libs/gnFastTranslator.o .libs/gnPosSpecificTranslator.o
.libs/gnDefs.o -L/usr/lib/gcc/i486-linux-gnu/4.3.1
-L/usr/lib/gcc/i486-linux-gnu/4.3.1/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.3.1/../../.. -lstdc++ -lm -lc
-lgcc_s /usr/lib/gcc/i486-linux-gnu/4.3.1/crtendS.o
/usr/lib/gcc/i486-linux-gnu/4.3.1/../../../../lib/crtn.o -Wl,-soname -Wl,libG!
enome-1.3.so.1 -o .libs/libGenome-1..3.so.1.0.3
...
which in my eyes gives good reasons for a libstdc++6-4.2-dev or
libstdc++6-4.3-dev dependency, respectively - but I always get
libstdc++6-4.1-dev dependency for the final package. Any idea
what went wrong here?
Kind regards
Andreas.
--
http://fam-tille.de
Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed
Thibaut Paumard <[EMAIL PROTECTED]> writes: > Le 17 avr. 08 à 13:04, Roberto C. Sánchez a écrit : >> IMO, that sort of misses the point. While I maintain quite a few >> packages in Debian, the only places I run unstable/testing are in >> one VM >> (for testing/reproducing/fixing bugs that I cannot reproduce in >> stable) >> and in some chroots. The point is that I should be able to build my >> packages inside of a pbuilder or other type of chroot, sign the >> package >> on my host system and be reasonably sure that my package will be >> accepted into the archive. If the archive software breaks >> compatibility >> with the current stable release of (insert name of whatever tool is >> affected, specifically devscripts in this case), then it looks bad on >> Debian. > > The problem is the same with lintian, that you need to backport > regularly. (Lintian being arch:all, of course, that's much easier). You do not need lintian to upload a package. You do have to sign. > Of course it would have been great to have the devscripts backport > before the dpkg update, but it the ten day period leading to > devscripts transitioning to testing/bpo, it's easy do use, e.g., > pbuilder login to sign your packages. Inconvenient, but easy. > > T. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ${devlibs:Depends} results in libstdc++6-4.1-dev
On Thu, Apr 17, 2008 at 14:18:06 +0200, Andreas Tille wrote:
> Hi,
>
> when trying to update libgenome-1.3-1-dev I noticed that the variable
> ${devlibs:Depends} is turned into a dependency from a libstdc++6 which
> is shipped with gcc-4.1 instead of using libstdc++6-4.2-dev or even
> libstdc++6-4.3-dev. Quoting from my *.build log in an up to date
> pbuilder environment:
>
Sounds like d-shlibs is broken. See #374049.
Cheers,
Julien
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed
Le 17 avr. 08 à 14:25, Goswin von Brederlow a écrit : Thibaut Paumard <[EMAIL PROTECTED]> writes: Le 17 avr. 08 à 13:04, Roberto C. Sánchez a écrit : The problem is the same with lintian, that you need to backport regularly. (Lintian being arch:all, of course, that's much easier). You do not need lintian to upload a package. You do have to sign. Right, lintian is a should, not a must. T.
Re: Misc development news (#6) (DEB_BUILD_OPTIONS=noopt)
On Wed, Apr 16, 2008, Manoj Srivastava wrote: > Hmm. Smells a lot like: Yes, it's the same, except eating less screen space; I don't particularly care how it ends up being implemented -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed
On Thu, Apr 17, 2008 at 02:25:02PM +0200, Goswin von Brederlow wrote: > Thibaut Paumard <[EMAIL PROTECTED]> writes: > > > Le 17 avr. 08 à 13:04, Roberto C. Sánchez a écrit : > >> IMO, that sort of misses the point. While I maintain quite a few > >> packages in Debian, the only places I run unstable/testing are in > >> one VM > >> (for testing/reproducing/fixing bugs that I cannot reproduce in > >> stable) > >> and in some chroots. The point is that I should be able to build my > >> packages inside of a pbuilder or other type of chroot, sign the > >> package > >> on my host system and be reasonably sure that my package will be > >> accepted into the archive. If the archive software breaks > >> compatibility > >> with the current stable release of (insert name of whatever tool is > >> affected, specifically devscripts in this case), then it looks bad on > >> Debian. > > > > The problem is the same with lintian, that you need to backport > > regularly. (Lintian being arch:all, of course, that's much easier). > > You do not need lintian to upload a package. You do have to sign. > Additionally, running lintian inside the chroot is trivial and does not require transporting the GPG key into the chroot. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
DDs using stable (Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed)
* Roberto C. Sánchez [Thu, 17 Apr 2008 07:04:39 -0400]: > IMO, that sort of misses the point. While I maintain quite a few > packages in Debian, the only places I run unstable/testing are in one VM > (for testing/reproducing/fixing bugs that I cannot reproduce in stable) > and in some chroots. So, uhm, how do you test your packages? > this is a change that affects every single > DD who runs stable as a primary system (which I am certain is a > significant number) In an ideal world, they'd be a minority. I really wonder what the reality is, though. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Polar - Nothing left to say -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed
On Thu, Apr 17, 2008 at 07:04:39AM -0400, Roberto C. Sánchez wrote: > On Thu, Apr 17, 2008 at 08:48:21AM +0100, Adam D. Barratt wrote: > > 2.10.25 should migrate to testing over the weekend, so hopefully a bpo > > package won't be too much longer. In the meantime it's fairly easy to > > backport yourself, as several people have already done, or simply copy the > > new script over from an unstable machine. Other than the update for the new > > .changes file format, there have been relatively little changes to debsign > > since the version in etch, and those have all been bugfixes. > > > IMO, that sort of misses the point. While I maintain quite a few > packages in Debian, the only places I run unstable/testing are in one VM > (for testing/reproducing/fixing bugs that I cannot reproduce in stable) > and in some chroots. The point is that I should be able to build my > packages inside of a pbuilder or other type of chroot, sign the package > on my host system and be reasonably sure that my package will be > accepted into the archive. If the archive software breaks compatibility > with the current stable release of (insert name of whatever tool is > affected, specifically devscripts in this case), then it looks bad on > Debian. You're mixing stable and unstable tools. You have to expect that you may run into incompatibilities -- that happens with feature development. As far as I know, we only require that *upgrades* from one stable release to the next stable release will work, not intermingling tools between them. The only thing about this that looks bad, IMO, is that we had some bad timing on uploads (which happens in unstable) and that we have developers who can't pay attention to debian-devel-announce. devscripts (and the debsign tool) is simply a convenience package and not having an up-to-date version of the package does not prevent you from doing your work. You can just as easily run dpkg-buildpackage in a chroot to build your packages and that has been generating proper signed .changes files the entire time. On the plus side, debsign is now more resilient to future changes in the Format of .changes files (as will mergechanges in the next upload). This only changes *when* the reject happens though (at debsign run instead of at upload), not whether it happens at all. Hopefully other tools which parse the .changes file have also learned from this experience and taken similar steps to prevent operating on Formats they don't understand. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: DDs using stable (Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed)
On Thu, Apr 17, 2008 at 05:27:35PM +0200, Adeodato Simó wrote: > * Roberto C. Sánchez [Thu, 17 Apr 2008 07:04:39 -0400]: > > > IMO, that sort of misses the point. While I maintain quite a few > > packages in Debian, the only places I run unstable/testing are in one VM > > (for testing/reproducing/fixing bugs that I cannot reproduce in stable) > > and in some chroots. > > So, uhm, how do you test your packages? > As I mentioned, I have a test setup for that. However, it is just that, a test setup. Other than that, I run the latest version of my own packages on all my stable machines. > > this is a change that affects every single > > DD who runs stable as a primary system (which I am certain is a > > significant number) > > In an ideal world, they'd be a minority. I really wonder what the > reality is, though. > As do I. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed
On Thu, Apr 17, 2008 at 11:34:06AM -0400, James Vega wrote: > > You're mixing stable and unstable tools. You have to expect that you may run > into incompatibilities I expect such a thing. For example, building packages with svn-buildpackage runs a 'debian/rules clean' before going into the chroot. With debhelper level 6 packages, this fails on Etch. I add '--svn-dont-clean' for those packages and am extra careful to not let any cruft filter in. > -- that happens with feature development. As far as I > know, we only require that *upgrades* from one stable release to the next > stable release will work, not intermingling tools between them. The only > thing about this that looks bad, IMO, is that we had some bad timing on > uploads (which happens in unstable) and that we have developers who can't pay > attention to debian-devel-announce. > Well, I pay attention to d-d-a and even read the message that you refer to. However never at any time I think that upgrading dpkg to introduce new checksum fields (and a newer format version) would result in package uploads being rejected. > devscripts (and the debsign tool) is simply a convenience package and not > having an up-to-date version of the package does not prevent you from doing > your work. You can just as easily run dpkg-buildpackage in a chroot to build > your packages and that has been generating proper signed .changes files the > entire time. > Only if the unstable chroot or system has my key in it. Of course, without gpg-agent it is a realy hassle if you are trying to build and upload lots of packages. > On the plus side, debsign is now more resilient to future changes in the > Format of .changes files (as will mergechanges in the next upload). This only > changes *when* the reject happens though (at debsign run instead of at > upload), not whether it happens at all. Hopefully other tools which parse the > .changes file have also learned from this experience and taken similar steps > to prevent operating on Formats they don't understand. > This certainly good. However, perhaps dak should have been changed to accept both format versions (1.7 and 1.8), instead of just rejecting the old one right away. This could have been continued until some fixed time after the release of Lenny. It is just a suggestion. I am living with the situation for now, because I still need to work on my packages and my groups' packages and upload them. However, I think that the whole thing was gone about in a rather uncoordinated fashion. To me, that is what looks bad. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed
On Thu, Apr 17, 2008 at 12:56:01PM -0400, Roberto C. Sánchez wrote: > On Thu, Apr 17, 2008 at 11:34:06AM -0400, James Vega wrote: > > On the plus side, debsign is now more resilient to future changes in the > > Format of .changes files (as will mergechanges in the next upload). This > > only > > changes *when* the reject happens though (at debsign run instead of at > > upload), not whether it happens at all. Hopefully other tools which parse > > the > > .changes file have also learned from this experience and taken similar steps > > to prevent operating on Formats they don't understand. > > > This certainly good. However, perhaps dak should have been changed to > accept both format versions (1.7 and 1.8), instead of just rejecting the > old one right away. This isn't a problem with dak. It was one with debsign. debsign operates on the generated .dsc and .changes files from a build instead of signing the .dsc and then creating the .changes as part of the build like dpkg-buildpackage does. To do so, it must change information in the .changes file regarding the size and checksum of the .dsc file. Since that wasn't being done, dak rightly rejected the uploads because the size and checksums listed didn't match that of the uploaded .dsc file. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed
On Thu, Apr 17, 2008 at 12:56:01 -0400, Roberto C. Sánchez wrote: > This certainly good. However, perhaps dak should have been changed to > accept both format versions (1.7 and 1.8), instead of just rejecting the > old one right away. This could have been continued until some fixed > time after the release of Lenny. dak doesn't reject Format: 1.7 changes files (it still needs to accept packages built for stable, if nothing else). However it rejects Format: 1.8 changes files where the checksums don't match, which is what happens if you build with sid's dpkg-dev but use a debsign that doesn't know about the new checksums and doesn't update them. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#476573: preinst fails on etch->sid dist-upgrade with old unopkg
Package: openoffice.org-voikko Version: 2.2-2 Severity: serious Unfortunately I didn't think about/notice this either, but a etch->sid dist-upgrade with openoffice.org-voikko involved now fails with the scriplets using -env. Stripped log from the dist-upgrade: Preconfiguring packages ... [...] Preparing to replace openoffice.org-impress 2.0.4.dfsg.2-7etch4 (using .../openoffice.org-impress_1%3a2.4.0-4_i386.deb) ... Unpacking replacement openoffice.org-impress ... Preparing to replace libwpd8c2a 0.8.7-6 (using .../libwpd8c2a_0.8.14-1_i386.deb) ... Unpacking replacement libwpd8c2a ... Selecting previously deselected package libwpg-0.1-1. Unpacking libwpg-0.1-1 (from .../libwpg-0.1-1_0.1.2-1_i386.deb) ... Preparing to replace openoffice.org-draw 2.0.4.dfsg.2-7etch4 (using .../openoffice.org-draw_1%3a2.4.0-4_i386.deb) ... Unpacking replacement openoffice.org-draw ... Preparing to replace openoffice.org-math 2.0.4.dfsg.2-7etch4 (using .../openoffice.org-math_1%3a2.4.0-4_i386.deb) ... Unpacking replacement openoffice.org-math ... [...] Selecting previously deselected package openoffice.org-style-andromeda. Unpacking openoffice.org-style-andromeda (from .../openoffice.org-style-andromeda_1%3a2.4.0-4_all.deb) ... Replacing files in old package openoffice.org-common ... Preparing to replace openoffice.org-base 2.0.4.dfsg.2-7etch4 (using .../openoffice.org-base_1%3a2.4.0-4_i386.deb) ... Unpacking replacement openoffice.org-base ... Preparing to replace openoffice.org-calc 2.0.4.dfsg.2-7etch4 (using .../openoffice.org-calc_1%3a2.4.0-4_i386.deb) ... Unpacking replacement openoffice.org-calc ... dpkg: openoffice.org-java-common: dependency problems, but removing anyway as you request: openoffice.org depends on openoffice.org-java-common; however: Package openoffice.org-java-common is to be removed. (Reading database ... 15147 files and directories currently installed.) Removing openoffice.org-java-common ... (Reading database ... 15093 files and directories currently installed.) Preparing to replace openoffice.org-writer 2.0.4.dfsg.2-7etch4 (using .../openoffice.org-writer_1%3a2.4.0-4_i386.deb) ... Unpacking replacement openoffice.org-writer ... electing previously deselected package openoffice.org-java-common. Unpacking openoffice.org-java-common (from .../openoffice.org-java-common_1%3a2.4.0-4_all.deb) ... Preparing to replace openoffice.org-common 2.0.4.dfsg.2-7etch4 (using .../openoffice.org-common_1%3a2.4.0-4_all.deb) ... Unpacking replacement openoffice.org-common ... [...] Preparing to replace openoffice.org-voikko 1.1-4+b2 (using .../openoffice.org-voikko_2.2-2_i386.deb) ... locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory Oo2-voikko removed from OpenOffice.org. [Java framework] The file: vnd.sun.star.expand:$URE_INTERNAL_LIB_DIR/sunjavaplugin.so does not exist.javaldx failed! [Java framework] The file: vnd.sun.star.expand:$URE_INTERNAL_LIB_DIR/sunjavaplugin.so does not exist.javaldx failed! Removing extension ...[Java framework] The file: vnd.sun.star.expand:$URE_INTERNAL_LIB_DIR/sunjavaplugin.so does not exist.javaldx failed! ERROR: unexpected option -env:UserInstallation=file:///tmp/tmp.MgnQE28200! Use unopkg --help (short -h) to print all options. dpkg: error processing /var/cache/apt/archives/openoffice.org-voikko_2.2-2_i386.deb (--unpack): subprocess pre-installation script returned error exit status 1 locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory ERROR: postinst abort-upgrade 2.2-2 Preparing to replace openoffice.org 2.0.4.dfsg.2-7etch4 (using .../openoffice.org_1%3a2.4.0-4_i386.deb) ... Unpacking replacement openoffice.org ... dpkg: regarding .../openoffice.org-core_1%3a2.4.0-4_i386.deb containing openoffice.org-core: openoffice.org-voikko conflicts with openoffice.org-core (>= 2.0.4.dfsg.2.1) openoffice.org-core (version 1:2.4.0-4) is to be installed. dpkg: error processing /var/cache/apt/archives/openoffice.org-core_1%3a2.4.0-4_i386.deb (--unpack): conflicting packages - not installing openoffice.org-core Errors were encountered while processing: /var/cache/apt/archives/openoffice.org-voikko_2.2-2_i386.deb /var/cache/apt/archives/openoffice.org-core_1%3a2.4.0-4_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) $ dpkg -l openoffice.org-core Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-=--
Re: ${devlibs:Depends} results in libstdc++6-4.1-dev
On Thu, 17 Apr 2008, Julien Cristau wrote:
when trying to update libgenome-1.3-1-dev I noticed that the variable
${devlibs:Depends} is turned into a dependency from a libstdc++6 which
is shipped with gcc-4.1 instead of using libstdc++6-4.2-dev or even
libstdc++6-4.3-dev. Quoting from my *.build log in an up to date
pbuilder environment:
Sounds like d-shlibs is broken. See #374049.
Hmmm, this sounds very close to my problem and thus I keep the bug
in CC (maintainer and reporter please se [1] for a full description
of the problem), but if I try
$ apt-cache show libstdc++6-dev | grep Version
Version: 3.4.6-6
I get even at these days 3.4.6 (which is strange anyway) but which gives
no explanation for the 4.1 dependency I faced.
This is simply strange.
Kind regards
Andreas.
[1] http://lists.debian.org/debian-devel/2008/04/msg00559.html
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed
On Thu, 17 Apr 2008, James Vega wrote: that we have developers who can't pay attention to debian-devel-announce. ... or rather who pay attention but are to stupid to parse it correctly to obtain this very piece of information. Feel free to call me stupid because to failied to see a connection between the broken upload and the announcement. This inability was probably amplified by the fact that I failed to upload even two days _before_ the d-d-a announcement. devscripts (and the debsign tool) is simply a convenience package and not having an up-to-date version of the package does not prevent you from doing your work. You can just as easily run dpkg-buildpackage in a chroot to build your packages and that has been generating proper signed .changes files the entire time. Agreed - provided I have nice friends who patiently explain in a way that even people like me are able to understand. I think it is better to explain before such things happen. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed
On Thu, Apr 17, 2008 at 07:06:52PM +0200, Julien Cristau wrote: > On Thu, Apr 17, 2008 at 12:56:01 -0400, Roberto C. Sánchez wrote: > > > This certainly good. However, perhaps dak should have been changed to > > accept both format versions (1.7 and 1.8), instead of just rejecting the > > old one right away. This could have been continued until some fixed > > time after the release of Lenny. > > dak doesn't reject Format: 1.7 changes files (it still needs to accept > packages built for stable, if nothing else). However it rejects Format: > 1.8 changes files where the checksums don't match, which is what happens > if you build with sid's dpkg-dev but use a debsign that doesn't know > about the new checksums and doesn't update them. > OK. My mistake. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed
Hi, On Thu Apr 17, 2008 at 10:38:38 +0200, Raphael Hertzog wrote: > On Thu, 17 Apr 2008, Adam D. Barratt wrote: > >> Will the devscripts in stable be updated to handle this? If so, when? > >> If not, why not? > > > > (If you're looking for an answer from the maintainers of a package it's > > probably safer to ask them directly rather than assuming they read every > > post on debian-devel; admittedly several of us do, but... :-) > > > > I'm not convinced it meets the SRM team's criteria for a stable update, > > as laid out in http://release.debian.org/stable/4.0/4.0r3/ et al. > > It doesn't hurt to ask however. Ubuntu is also rushing a last-minute > update in hardy to avoid this problem. I don't see anything which warrants a stable upload here. Greetings Martin -- Martin Zobel-Helas <[EMAIL PROTECTED]> | Debian Release Team Member Debian & GNU/Linux Developer | Debian Listmaster Public key http://zobel.ftbfs.de/5d64f870.asc - KeyID: 5D64 F870 GPG Fingerprint: 5DB3 1301 375A A50F 07E7 302F 493E FB8E 5D64 F870 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Neu: Handbuch Gesundheitswesen im Umbruch
Guten Tag Als Co-Heausgeber erlaube ich mir, Sie auf eine für das Gesundheitswesen einzigartige Neu-Publikation aufmerksam zu machen, mit besonderem Fokus Spitäler. Mit über 40 Fachautoren habe ich und meine 3 Co-Herausgeber versucht, den Umbruch der nächsten Jahre im Schweizer Gesundheitswesen darzulegen. Und dies auf eine Art und Weise, wie es noch nicht bestand. Wir haben uns dabei immer an den folgenden drei Kernfragen orientiert: - Wie sehen die Prozesse im Gesundheitswesen im Einzelnen aus? - Welches sind die massgeblichen Veränderungskräfte? - Was sind die Auswirkungen der Veränderungen auf Strategie und Kernprozesse der Spitäler, - Leistungserbringer, Krankenversicherer und der Pharma-Industrie? Die Konzeption des Schweizer Gesundheitswesens beinhaltet spannende Aspekte, welche für die künftige Reform des Deuschen Gesundheitswesens interessante Gedanken und Themen vorwegnimmt und thematisiert. Weitere Informationen entnehmen Sie den Links. Mit herzlichem Gruss und Dank für die Aufmerksamkeit Link zum Inhaltsverzeichnis http://www.ehealthcare.ch/data/_product_documents/_articles/6764/Inhaltsverzeichnis%20Handbuch.pdf Link zur Informationsbroschüre http://www.ehealthcare.ch/data/_product_documents/_articles/6764/Handbuch_flyer_einzeln.pdf Direktlink Bestellung: http://www.ehealthcare.ch/app/article/index.cfm?fuseaction=OpenArticle&aoid=6764&lang=DE Im Namen der Herausgeber Michael Egli Meet the future of healthcare - meet the leaders _ eHealthCare.ch Kongress Kompendium Campus Services Konferenz und Fachausstellung 24./ 25. September 2008 TREND CARE AG, Bahnhofstrasse 40, CH-6210 Sursee Tel.: +41 (0)41 925 76 89 Fax: +41 (0)41 925 76 80 www.ehealthcare.ch; [EMAIL PROTECTED] Zum Abmelden klicken Sie bitte hier: : http://004.frnl.de/box.php?funcml=unsub2&nl=114&mi=190&email=debian-devel%40lists.debian.org
Neu: Handbuch Gesundheitswesen im Umbruch
Guten Tag Als Co-Heausgeber erlaube ich mir, Sie auf eine für das Gesundheitswesen einzigartige Neu-Publikation aufmerksam zu machen, mit besonderem Fokus Spitäler. Mit über 40 Fachautoren habe ich und meine 3 Co-Herausgeber versucht, den Umbruch der nächsten Jahre im Schweizer Gesundheitswesen darzulegen. Und dies auf eine Art und Weise, wie es noch nicht bestand. Wir haben uns dabei immer an den folgenden drei Kernfragen orientiert: - Wie sehen die Prozesse im Gesundheitswesen im Einzelnen aus? - Welches sind die massgeblichen Veränderungskräfte? - Was sind die Auswirkungen der Veränderungen auf Strategie und Kernprozesse der Spitäler, - Leistungserbringer, Krankenversicherer und der Pharma-Industrie? Die Konzeption des Schweizer Gesundheitswesens beinhaltet spannende Aspekte, welche für die künftige Reform des Deuschen Gesundheitswesens interessante Gedanken und Themen vorwegnimmt und thematisiert. Weitere Informationen entnehmen Sie den Links. Mit herzlichem Gruss und Dank für die Aufmerksamkeit Link zum Inhaltsverzeichnis http://www.ehealthcare.ch/data/_product_documents/_articles/6764/Inhaltsverzeichnis%20Handbuch.pdf Link zur Informationsbroschüre http://www.ehealthcare.ch/data/_product_documents/_articles/6764/Handbuch_flyer_einzeln.pdf Direktlink Bestellung: http://www.ehealthcare.ch/app/article/index.cfm?fuseaction=OpenArticle&aoid=6764&lang=DE Im Namen der Herausgeber Michael Egli Meet the future of healthcare - meet the leaders _ eHealthCare.ch Kongress Kompendium Campus Services Konferenz und Fachausstellung 24./ 25. September 2008 TREND CARE AG, Bahnhofstrasse 40, CH-6210 Sursee Tel.: +41 (0)41 925 76 89 Fax: +41 (0)41 925 76 80 www.ehealthcare.ch; [EMAIL PROTECTED] Zum Abmelden klicken Sie bitte hier: : http://004.frnl.de/box.php?funcml=unsub2&nl=114&mi=189&email=debian-devel%40lists.debian.org
Work-needing packages report for Apr 18, 2008
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 429 (new: 8) Total number of packages offered up for adoption: 100 (new: 1) Total number of packages requested help for: 43 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: 4digits (#476133), orphaned 3 days ago Description: A guess-the-number game, aka Bulls and Cows Installations reported by Popcon: 63 linux-ftpd-ssl (#476132), orphaned 3 days ago Description: FTP server with SSL encryption support Installations reported by Popcon: 181 lockvc (#475781), orphaned 5 days ago Description: screensaver to lock your Linux console(s) Installations reported by Popcon: 174 netkit-ftp-ssl (#476131), orphaned 3 days ago Description: FTP client with SSL encryption support Installations reported by Popcon: 530 selinux-basics (#476192), orphaned 3 days ago Description: SELinux basic support Installations reported by Popcon: 369 xfonts-wqy (#476130), orphaned 3 days ago Description: WenQuanYi Bitmap Song CJK font Installations reported by Popcon: 2050 xslide (#476426), orphaned yesterday Description: XSL editing mode for Emacs Installations reported by Popcon: 76 xsnow (#476129), orphaned 3 days ago (non-free) Description: Bring Christmas to your desktop Installations reported by Popcon: 574 421 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: xplanet (#476179), offered 3 days ago Description: render images of the earth Reverse Depends: junior-toys Installations reported by Popcon: 1457 99 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apache2 (#470795), requested 35 days ago Description: Co-maintainer wanted Reverse Depends: adzapper ampache apache2 apache2-dbg apache2-mpm-event apache2-mpm-itk apache2-mpm-perchild apache2-mpm-prefork apache2-mpm-worker apache2-prefork-dev (148 more omitted) Installations reported by Popcon: 38124 apt-build (#365427), requested 719 days ago Description: Need new developer(s) Installations reported by Popcon: 1043 ara (#450876), requested 158 days ago Description: utility for searching the Debian package database Installations reported by Popcon: 123 athcool (#278442), requested 1269 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 258 bash-completion (#472468), requested 24 days ago Description: programmable completion for the bash shell Installations reported by Popcon: 3581 cfs (#458061), requested 111 days ago Description: Cryptographic Filesystem Installations reported by Popcon: 114 cvs (#354176), requested 784 days ago Description: Concurrent Versions System Reverse Depends: crossvc cvs-autoreleasedeb cvs-buildpackage cvs2cl cvs2html cvschangelogbuilder cvsconnect cvsd cvsdelta cvsps (13 more omitted) Installations reported by Popcon: 23639 dctrl-tools (#448284), requested 173 days ago Description: Command-line tools to process Debian package information Reverse Depends: aptfs debian-goodies dlocate feta haskell-devscripts hg-buildpackage mlmmj sbuild simple-cdd Installations reported by Popcon: 6790 dpkg (#282283), requested 1244 days ago Description: dselect: a user tool to manage Debian packages Reverse Depends: alien alsa-source apt-build apt-cross apt-src backuppc build-essential bzr-builddeb clamsmtp crosshurd (101 more omitted) Installations reported by Popcon: 78560 drscheme (#402589), requested 493 days ago Description: PLT scheme programming environment Reverse Depends: drscheme minlog proofgeneral-minlog Installations reported by Popcon: 402 elvis (#432298), requested 283 days ago Description: powerful clone of the vi/ex text editor (with X11 support) Reverse Depends: elvis elvis-console elvis-tools Installations reported by Popcon: 300 fglrx-driver (#454993), requested 131 days ago (non-free) Description: non-free AMD/ATI r5xx, r6xx display driver Reverse Depends: fglrx-amdcccle fglrx-control fglrx-driver fglrx-glx fglrx-glx-ia32 Installations reported by Popcon: 2398 gento
sumeh lasita wants to chat
--- sumeh lasita wants to stay in better touch using some of Google's coolest new products. If you already have Gmail or Google Talk, visit: http://mail.google.com/mail/b-e21bdacb68-9494b30a6d-dc92d96744032b8f You'll need to click this link to be able to chat with sumeh lasita. To get Gmail - a free email account from Google with over 2,800 megabytes of storage - and chat with sumeh lasita, visit: http://mail.google.com/mail/a-e21bdacb68-9494b30a6d-0716163643 Gmail offers: - Instant messaging right inside Gmail - Powerful spam protection - Built-in search for finding your messages and a helpful way of organizing emails into "conversations" - No pop-up ads or untargeted banners - just text ads and related information that are relevant to the content of your messages All this, and its yours for free. But wait, there's more! By opening a Gmail account, you also get access to Google Talk, Google's instant messaging service: http://www.google.com/talk/ Google Talk offers: - Web-based chat that you can use anywhere, without a download - A contact list that's synchronized with your Gmail account - Free, high quality PC-to-PC voice calls when you download the Google Talk client Gmail and Google Talk are still in beta. We're working hard to add new features and make improvements, so we might also ask for your comments and suggestions periodically. We appreciate your help in making our products even better! Thanks, The Google Team To learn more about Gmail and Google Talk, visit: http://mail.google.com/mail/help/about.html http://www.google.com/talk/about.html (If clicking the URLs in this message does not work, copy and paste them into the address bar of your browser). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
