Re: Who needs libcurl3?
Peter Samuelson <[EMAIL PROTECTED]> writes: > [Don Armstrong] >> All that needs to happen is that GPLed packages without an OpenSSL >> linking exception either need to: >> >> 1) Get a linking exception. >> 2) Stop linking with OpenSSL. > > 3) For indirect dependencies: make sure you're only using the bits >of the (for example) libcurl ABI which work whether or not it is >compiled against openssl. In that case it's really hard to >argue you're "linking to openssl". But one can argue that this needs an openssl free libcurl to be correctly distributable. Which was the suggestion to begin with I think. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On Mon, Jul 18, 2005 at 01:02:53AM -0500, Peter Samuelson wrote: > > [Don Armstrong] > > All that needs to happen is that GPLed packages without an OpenSSL > > linking exception either need to: > > 3) For indirect dependencies: make sure you're only using the bits >of the (for example) libcurl ABI which work whether or not it is >compiled against openssl. In that case it's really hard to >argue you're "linking to openssl". This is true for MOC, like for ogg123 whis is also licensed using "pure" GPL. -- Damian Pietras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removal of transitional dummy packages
On 7/17/05, Joerg Jaspert <[EMAIL PROTECTED]> wrote: > As we only support upgrades to the next release and not any other its > very clear to remove them from the archive. Does 'not supporting' equal 'requiring it to fail'?
Re: unreproducable bugs
On Sat, Jul 16, 2005 at 01:14:07AM +0100, Rich Walker wrote: > Yes, to rely on 1300 developers to all think of your cunning method of > solving a problem clearly makes sense. After all, to *write down* a > technique that solves the problem, and make it available to all of them > would stilt their creativity, hinder their intellect, and prevent the > development of a consistent style! I'm pretty sure I've come across this as a guideline in the maintainer docs, if not as a hard-and-fast rule. -- Jon Dowland http://jon.dowland.name/ PGP fingerprint: 7032F238 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NMUs wanted: C++ library packages in need of uploading
Steve Langasek writes: > librudiments0 already done. bug report filed to remove the source package from unstable. > maxdb-7.5.00 not critical, no dependent packages. the maintainer works on getting the package compiled with gcc-4.0 > stlport4.6 already done. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On Sun, Jul 17, 2005 at 03:19:54PM -0400, sean finney wrote: > > Why not building curl --without-sssl and --with-gnutls=/usr? Maybe a > > NMU? > > this is definitely NOT a reason to NMU libcurl. remember that it is > your package that is "broken". of course you could still file a The same issues as with libcurl applied to libldap2. They were considered a bug in libldap2 back then because half the distribution links it. Gave me a lot of recurring head aches. Basically I'd vote for avoiding license bombs like this in our archive. Most software is GPL and upstream seldom knows about those issues. Greetings Torsten signature.asc Description: Digital signature
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On Sun, Jul 17, 2005 at 11:09:04PM +0300, Don Armstrong wrote: > On Sun, 17 Jul 2005, Elimar Riesebieter wrote: > > apt-get remove --purge libssl0.9.7 gives me tons of packages. Just > > an estimation: We need to repack half of all packages then? > > NO.[1] > > All that needs to happen is that GPLed packages without an OpenSSL > linking exception either need to: > > 1) Get a linking exception. > 2) Stop linking with OpenSSL. How about indirect linking with OpenSSL? I'd really like to have libldap use OpenSSL again but I was told this breaks the LDAP support of a lot of packages since linking LDAP would pull OpenSSL. Greetings Torsten signature.asc Description: Digital signature
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On Mon, Jul 18, 2005 at 11:07:41AM +0200, Torsten Landschoff wrote: > > > apt-get remove --purge libssl0.9.7 gives me tons of packages. Just > > > an estimation: We need to repack half of all packages then? > > > > NO.[1] > > > > All that needs to happen is that GPLed packages without an OpenSSL > > linking exception either need to: > > > > 1) Get a linking exception. > > 2) Stop linking with OpenSSL. > > How about indirect linking with OpenSSL? I'd really like to have libldap > use OpenSSL again but I was told this breaks the LDAP support of a lot > of packages since linking LDAP would pull OpenSSL. Seems that part of developers think that indirect linking with OpenSSL is ok, and part think it's not. What is an official statement? regards fEnIo -- ,''`. Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo : :' : 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland `. `' phone:+48602383548 | proud Debian maintainer and user `- http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001 signature.asc Description: Digital signature
Re: Removal of transitional dummy packages
On Mon, Jul 18, 2005 at 10:51:23AM +0200, Olaf van der Spek wrote: > On 7/17/05, Joerg Jaspert <[EMAIL PROTECTED]> wrote: > > As we only support upgrades to the next release and not any other its > > very clear to remove them from the archive. > Does 'not supporting' equal 'requiring it to fail'? It equals "we have no expectation whatsoever that upgrades from woody to etch will work for *anyone*, so users are much better off if we deliver this message to them consistently instead of hinting with a couple of remaining transition packages here and there that it might work". We know from experience with sarge that we're already spread very thin where upgrade support is concerned, so it's important that we neither overpromise nor let ourselves be distracted by things that won't actually be of benefit to users. In this context, woody->sarge transition packages are just one form of useless cruft that we should strive to get rid of before the etch release. They're not the biggest source of cruft, but on the other hand they are (IMHO) one of the sources for which the proper course of action is clearest. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Removal of transitional dummy packages
Santiago Vila <[EMAIL PROTECTED]> writes:
> On Sun, 17 Jul 2005, Joerg Jaspert wrote:
>> On 10353 March 1977, Santiago Vila wrote:
we need to remove
from the archive all the Woody-to-Sarge transition dummy packages.
>>> No, that's not true, we don't *need* to remove woody-to-sarge dummy
>>> packages, as they are also woody-to-etch dummy packages.
>> We do not support that.
> There is no "we" here.
Oh, there is! *We* ('Debian') have no policy to force maintainers to
make direct upgrade paths from old releases possible, so some
packages support it, most don't. It's the same with downgrades: Some
people care about them and change their packages to make them, most
don't.
Marc, doubting that there are any problems to update the lg-* packages
From woody
--
BOFH #340:
Well fix that in the next (upgrade, update, patch release, service
pack).
pgpD7PQyKnXnQ.pgp
Description: PGP signature
snownews maintainership
Hi, the actual maintainer of the snownews rss reader package seems to be cast away. I talked to upstream and he has got no contact to him in the last time at all. I tried to wrote him to [EMAIL PROTECTED] and after 24 hours I got a delayed bounce... He isn't not available anymore and the upstream asked me if I would maintain the package. So I want to highjack the package. Any meanings? Regards Nico -- Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org VIM has two modes - the one in which it beeps and the one in which it doesn't -- encrypted mail preferred -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: snownews maintainership
> So I want to highjack the package. > Any meanings? Do it. Pop the trunk. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NMUs wanted: C++ library packages in need of uploading
On Sun, Jul 17, 2005 at 06:54:42PM -0700, Steve Langasek wrote: [...] > libparagui1.0 Uploaded. [...] regards fEnIo -- ,''`. Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo : :' : 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland `. `' phone:+48602383548 | proud Debian maintainer and user `- http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001 signature.asc Description: Digital signature
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
[Bartosz Fenski] > Seems that part of developers think that indirect linking with > OpenSSL is ok, and part think it's not. Yeah. Well. Stand back and look at why this 'linking' thing matters in the first place. The point is to determine whether one work is a "derivative" of another work. If it is not, copyright law doesn't let the author of the second work have any influence on the licensing of the first. If you link to libldap2 or libcurl3 but your program would work just as well whether or not those libraries have openssl support, it's really hard to argue that *you* are deriving your code from Eric Young or the OpenSSL project. Or vice versa. You wrote your code to call LDAP functions, or web downloading functions, you didn't care then and don't care now how those functions work. Didn't care then and don't care now whether they can utilize https:// or ldaps:// at runtime. The functions themselves were licensed to you in a manner you could use. The whole "linking is deriving" thing is shaky for other reasons too. For instance, it's pretty widely known or believed that mere interfaces can't be copyrighted. And when you get right down to it, when your program uses a library, it's really just using the published interface. But that's an argument for another day, and probably another list. > What is an official statement? There is none. Debian generally errs very conservatively with regard to license violations, though, because of the Tentacles of Evil principle. That is: if we ship some software and the authors don't mind how we're doing it but we're technically in violation of some license provision - and later one of the authors is bought out by some Big Evil Corporation - then the B.E.C. can cause a lot of trouble for Debian and our users. This is a situation Debian tries very hard to avoid. signature.asc Description: Digital signature
Re: Removal of transitional dummy packages
On Mon, 18 Jul 2005 02:40:32 -0700, Steve Langasek wrote: > In this context, woody->sarge transition packages are just one form of > useless cruft that we should strive to get rid of before the etch release. I agree and I've been busy getting rid of that cruft. It's a pleasure to see how much the maintainer scripts can be simplified on the basis of the assumption that the previous version is sarge or later. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removal of transitional dummy packages
On Mon, 18 Jul 2005, Marc 'HE' Brockschmidt wrote:
> Santiago Vila <[EMAIL PROTECTED]> writes:
> > On Sun, 17 Jul 2005, Joerg Jaspert wrote:
> >> On 10353 March 1977, Santiago Vila wrote:
> we need to remove
> from the archive all the Woody-to-Sarge transition dummy packages.
> >>> No, that's not true, we don't *need* to remove woody-to-sarge dummy
> >>> packages, as they are also woody-to-etch dummy packages.
> >> We do not support that.
> > There is no "we" here.
>
> Oh, there is! *We* ('Debian') have no policy to force maintainers to
> make direct upgrade paths from old releases possible, [...]
Unfortunately, we don't even have a policy to force maintainers to
make upgrade paths from the previous release possible (see Bug #196390).
If we are going to deliver consistently the message that upgrades that
skip releases are not supported and upgrades from the previous release
are supported, could we please agree that upgrades must be smooth, so
that a missing dummy package which makes a package not to be upgraded
as it is expected to be becomes a serious bug?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: snownews maintainership
Hi, * Clint Adams <[EMAIL PROTECTED]> [2005-07-18 12:02]: > > So I want to highjack the package. > > Any meanings? > > Do it. Pop the trunk. Ok because I don't really want to steal Jello the package I will make a new package with the needed changes and new upstream version, let him as the maintainer and hopefully someone can sponsor the upload. Thanks Nico -- Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org VIM has two modes - the one in which it beeps and the one in which it doesn't -- encrypted mail preferred -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: snownews maintainership
Re: Nico Golde in <[EMAIL PROTECTED]> > the actual maintainer of the snownews rss reader package > seems to be cast away. I talked to upstream and he has got > no contact to him in the last time at all. > > I tried to wrote him to [EMAIL PROTECTED] and after 24 hours > I got a delayed bounce... He isn't not available anymore and > the upstream asked me if I would maintain the package. > > So I want to highjack the package. > Any meanings? Yes. Go read (and understand) sections 5.9.5 and 7.4 of the developers-reference. Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: snownews maintainership
Hi, * Christoph Berg <[EMAIL PROTECTED]> [2005-07-18 13:00]: > Re: Nico Golde in <[EMAIL PROTECTED]> > > the actual maintainer of the snownews rss reader package > > seems to be cast away. I talked to upstream and he has got > > no contact to him in the last time at all. > > > > I tried to wrote him to [EMAIL PROTECTED] and after 24 hours > > I got a delayed bounce... He isn't not available anymore and > > the upstream asked me if I would maintain the package. > > > > So I want to highjack the package. > > Any meanings? > > Yes. Go read (and understand) sections 5.9.5 and 7.4 of the > developers-reference. I read it and thats why I asked before I have done something. Regards Nico -- Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org VIM has two modes - the one in which it beeps and the one in which it doesn't -- encrypted mail preferred -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On Mon, Jul 18, 2005 at 05:16:27AM -0500, Peter Samuelson wrote: > > [Bartosz Fenski] > > Seems that part of developers think that indirect linking with > > OpenSSL is ok, and part think it's not. > Yeah. Well. Stand back and look at why this 'linking' thing matters > in the first place. The point is to determine whether one work is a > "derivative" of another work. False. This is a requirement imposed by section 3 of the GPL, which makes no mention of derivative works. > If it is not, copyright law doesn't let the author of the second work > have any influence on the licensing of the first. It lets the author of the second work control the circumstances under which you are allowed to distribute *that work*. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Who needs libcurl3?
Torsten Landschoff <[EMAIL PROTECTED]> writes: > On Sun, Jul 17, 2005 at 11:09:04PM +0300, Don Armstrong wrote: >> On Sun, 17 Jul 2005, Elimar Riesebieter wrote: >> > apt-get remove --purge libssl0.9.7 gives me tons of packages. Just >> > an estimation: We need to repack half of all packages then? >> >> NO.[1] >> >> All that needs to happen is that GPLed packages without an OpenSSL >> linking exception either need to: >> >> 1) Get a linking exception. >> 2) Stop linking with OpenSSL. > > How about indirect linking with OpenSSL? I'd really like to have libldap > use OpenSSL again but I was told this breaks the LDAP support of a lot > of packages since linking LDAP would pull OpenSSL. > > Greetings > > Torsten I guess the savest way is to have a libldap-nossl-dev and libldap-ssl-dev. The former should have anything ssl derived removed. Packages without linking exception can then Build-Depend on libldap-nossl-dev. If the ssl and nonssl ldap has the same ABI (nonssl being a subset of ssl to be precise) the package can work with either lib then. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removal of transitional dummy packages
On Mon, 18 Jul 2005, Steve Langasek wrote: > On Mon, Jul 18, 2005 at 10:51:23AM +0200, Olaf van der Spek wrote: > > On 7/17/05, Joerg Jaspert <[EMAIL PROTECTED]> wrote: > > > As we only support upgrades to the next release and not any other its > > > very clear to remove them from the archive. > > > Does 'not supporting' equal 'requiring it to fail'? > > It equals "we have no expectation whatsoever that upgrades from woody to > etch will work for *anyone*, so users are much better off if we deliver this > message to them consistently instead of hinting with a couple of remaining > transition packages here and there that it might work". We know from > experience with sarge that we're already spread very thin where upgrade > support is concerned, so it's important that we neither overpromise nor let > ourselves be distracted by things that won't actually be of benefit to > users. > > In this context, woody->sarge transition packages are just one form of > useless cruft that we should strive to get rid of before the etch release. > They're not the biggest source of cruft, but on the other hand they are > (IMHO) one of the sources for which the proper course of action is clearest. In such case, could we please codify that in policy? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Your Message To scoug-general
Your message to the list scoug-general has been rejected. You are not a member of the list. For help on subscribing to the list, please send a message to [EMAIL PROTECTED] with the word "help" in the body of the message. Your humble mailing list software, Steward -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who needs libcurl3?
* Goswin von Brederlow ([EMAIL PROTECTED]) wrote: > I guess the savest way is to have a libldap-nossl-dev and > libldap-ssl-dev. The former should have anything ssl derived > removed. No, that was *worse*. We tried that before. The answer really is reasonably simple- just modify libldap2 to use GNUTLS. That was done w/ an older version of things involved. I expect it'll be done for the newer stuff. > Packages without linking exception can then Build-Depend on > libldap-nossl-dev. If the ssl and nonssl ldap has the same ABI (nonssl > being a subset of ssl to be precise) the package can work with either > lib then. Bleh. Let's just move off of OpenSSL where we can. This is a case where we can, and people have worked on it already, let's finish that off and this time get upstream to accept it (they're annoyingly anal about such things) and be done with it. Stephen signature.asc Description: Digital signature
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
hi, On Mon, Jul 18, 2005 at 11:06:13AM +0200, Torsten Landschoff wrote: > On Sun, Jul 17, 2005 at 03:19:54PM -0400, sean finney wrote: > > this is definitely NOT a reason to NMU libcurl. remember that it is > > your package that is "broken". of course you could still file a > > The same issues as with libcurl applied to libldap2. They were > considered a bug in libldap2 back then because half the distribution > links it. Gave me a lot of recurring head aches. yes, and the same with libmysqlclient, which is why there's no longer ssl support in the mysql packages :( sean -- signature.asc Description: Digital signature
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On 7/18/05, sean finney <[EMAIL PROTECTED]> wrote: > hi, > > On Mon, Jul 18, 2005 at 11:06:13AM +0200, Torsten Landschoff wrote: > > On Sun, Jul 17, 2005 at 03:19:54PM -0400, sean finney wrote: > > > this is definitely NOT a reason to NMU libcurl. remember that it is > > > your package that is "broken". of course you could still file a > > > > The same issues as with libcurl applied to libldap2. They were > > considered a bug in libldap2 back then because half the distribution > > links it. Gave me a lot of recurring head aches. > > yes, and the same with libmysqlclient, which is why there's no longer ssl > support in the mysql packages :( Wouldn't it be possible to support SSL transparently in such a way that the original package doesn't need to be modified?
Re: cpufrequtils init script in rcS.d
On Sat, Jul 16, 2005 at 12:39:03AM +0200, Bernd Eckenfels wrote: > In article <[EMAIL PROTECTED]> you wrote: > > Sorry. The main idea is making power management more effective, that's > > why earlier is better here. > > I dont see why this is the case. in the bootup phase the system is loaded > anyway, no need to throttle it. Well, I can actually imagine that most of the time at bootup is spent waiting for I/O to complete, HW probes and so on, nothing that CPU bound actually (AFAICT). > especially since this one minute does not > consume measurable amount of power. So there is still ne real reason > mentioned why a few seconds matter here. You don't know that actually. There are far too many usages to make a generic statement like that. I can't see nothing wrong or useless in trying to maximize battery power and/or minimize heat generation. -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who needs libcurl3?
Hi Goswin, On Mon, Jul 18, 2005 at 01:06:01PM +0200, Goswin von Brederlow wrote: > I guess the savest way is to have a libldap-nossl-dev and > libldap-ssl-dev. The former should have anything ssl derived > removed. No problem. But then I can just build libldap without ssl as the library built without SSL puts macros into the header files to disable ssl functionality iirc. Greetings Torsten signature.asc Description: Digital signature
Re: Who needs libcurl3?
On Mon, Jul 18, 2005 at 09:06:20AM -0400, Stephen Frost wrote: > No, that was *worse*. We tried that before. The answer really is > reasonably simple- just modify libldap2 to use GNUTLS. That was done w/ > an older version of things involved. I expect it'll be done for the > newer stuff. Working on that. At least theoretically - when I get time, yada, yada. > Bleh. Let's just move off of OpenSSL where we can. This is a case > where we can, and people have worked on it already, let's finish that > off and this time get upstream to accept it (they're annoyingly anal > about such things) and be done with it. I am not holding my breath... Greetings Torsten signature.asc Description: Digital signature
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On Mon, Jul 18, 2005 at 09:29:46AM -0400, sean finney wrote: > > The same issues as with libcurl applied to libldap2. They were > > considered a bug in libldap2 back then because half the distribution > > links it. Gave me a lot of recurring head aches. > > yes, and the same with libmysqlclient, which is why there's no longer ssl > support in the mysql packages :( That kind of ... sucks!? No hope have the support GnuTLS or something? Greetings Torsten signature.asc Description: Digital signature
Re: BTS version tracking
On Mon, Jul 18, 2005 at 12:06:29PM +0100, Colin Watson wrote: > A number of changes have been made to [EMAIL PROTECTED] [1] to > support this. Firstly, the 'close' and 'reassign' commands now take > extra version arguments, as follows: > > close 1234567 1.1 > reassign 1234567 example-package 2.0-1 How is a bug that's fixed in more than one version handled? For example, a security bug fixed in foo 1.1-sarge1 and foo 1.3. Assume 1.1 and 1.2 have the bug. -- Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who needs libcurl3?
* Torsten Landschoff ([EMAIL PROTECTED]) wrote: > On Mon, Jul 18, 2005 at 09:06:20AM -0400, Stephen Frost wrote: > > > No, that was *worse*. We tried that before. The answer really is > > reasonably simple- just modify libldap2 to use GNUTLS. That was done w/ > > an older version of things involved. I expect it'll be done for the > > newer stuff. > > Working on that. At least theoretically - when I get time, yada, yada. Steve Langasek had offered to help with this too. I'll poke him about it on IRC and see if he's still willing to help. > > Bleh. Let's just move off of OpenSSL where we can. This is a case > > where we can, and people have worked on it already, let's finish that > > off and this time get upstream to accept it (they're annoyingly anal > > about such things) and be done with it. > > I am not holding my breath... Well, if we can get a good patch written up and have it licensed under the OpenLDAP license and sent to them from the 'author', supposedly it'd get accepted. I guess we'll see. Stephen signature.asc Description: Digital signature
MACROdream
Hi debian-devel,My name is Daniel. I found you on http://www.opensubscriber.com/search?q=2005+fete+du+14+juillet. I am sorry if I intrude but I just have a quick question for you. Since you seem to be more acquainted with the Internet than I am, maybe you can share your thoughts. A year ago I had started posting my own macro work on my site at http://macrodream.iloweb.com. Many of my friends and members of my photo club here in Paris, France told me that I should create a real portal for macro photography. That's how I created http://macrodream.iloweb.coma c ouple of weeks ago. Now, could you have a look at it and tell me what you think? Go to http://macrodream.iloweb.com and please post a message in the site's forum to let me know what you think. You can also use the poll on the first page. I am also open to sharing the fun or building the community with other folks - if you want to publish articles, moderate a forum, or publish galleries of photos, please do so - just ask me through the forums and I'll make you an editor or moderator of the site with me. There is a very easy interface available. You don't need to be technical at all. Much thanks!Cheers, Daniel Nicollet, Paris, FranceContact me through the http://macrodream.iloweb.com forumor [EMAIL PROTECTED]
Re: Who needs libcurl3?
On Mon, 2005-07-18 at 16:36 +0200, Torsten Landschoff wrote: > On Mon, Jul 18, 2005 at 09:06:20AM -0400, Stephen Frost wrote: > > > No, that was *worse*. We tried that before. The answer really is > > reasonably simple- just modify libldap2 to use GNUTLS. That was done w/ > > an older version of things involved. I expect it'll be done for the > > newer stuff. > > Working on that. At least theoretically - when I get time, yada, yada. It's a big shame that Debian was not able to apply for Google Summer of Code. Seems like this would fit nicely. Ondrej. -- Ondrej Sury <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: BTS version tracking
On Mon, Jul 18, 2005 at 08:35:45AM -0600, Rob Sims wrote: > On Mon, Jul 18, 2005 at 12:06:29PM +0100, Colin Watson wrote: > > A number of changes have been made to [EMAIL PROTECTED] [1] to > > support this. Firstly, the 'close' and 'reassign' commands now take > > extra version arguments, as follows: > > > > close 1234567 1.1 > > reassign 1234567 example-package 2.0-1 > > How is a bug that's fixed in more than one version handled? For > example, a security bug fixed in foo 1.1-sarge1 and foo 1.3. Assume 1.1 > and 1.2 have the bug. So, foo 1.1-sarge1's changelog will look like this: foo (1.1-sarge1) stable; urgency=high * fix security bug in sarge (closes: #NN) -- Security Team <[EMAIL PROTECTED]> DATE foo (1.1) unstable; urgency=low * last upload before sarge -- Maintainer <[EMAIL PROTECTED]> DATE ... while foo 1.3's changelog will look like this: foo (1.3) unstable; urgency=high * fix security bug (closes: #NN) -- Maintainer <[EMAIL PROTECTED]> DATE foo (1.2) unstable; urgency=low * add a feature -- Maintainer <[EMAIL PROTECTED]> DATE foo (1.1) unstable; urgency=low * last upload before sarge -- Maintainer <[EMAIL PROTECTED]> DATE The BTS records that bug #NN was fixed in 1.1-sarge1 and 1.3, and let's say the bug was found in version 1.1. Since it has the changelogs (it gets these from ftp-master), it can build up a tree of which package versions are based on which other package versions, which in this case looks like this: 1.1 --> 1.1-sarge1 \ > 1.2 --> 1.3 Given that, it's easy to deduce that the bug affects both 1.1 and 1.2, but doesn't affect 1.1-sarge1, 1.3, or any version based on those (unless more information shows up, e.g. the bug recurs for some reason). If you ask for bugs in an affected version, or in a distribution that contains an affected version (let's say 1.2 is in testing and you ask for http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=foo&dist=testing), the bug shows up as open; if you ask for bugs in an unaffected version, or in a distribution that contains an unaffected version, the bug shows up as closed. Obviously, this is a fairly simple case and it can get a lot more complicated than that in practice ... Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debconf5 - videos of the talks and BOFs available
Will the slides be available in a central repository too? Having both videos and slides would be nice for who missed the event, like me :'( -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: unreproducable bugs
On 20050717T213903-0700, Thomas Bushnell BSG wrote: > Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> writes: > > > On 20050716T195244-0700, Thomas Bushnell BSG wrote: > >> That's a far cry different from someone wanting to enforce a > >> requirement. > > > > Who, in this thread, is this hypothetical someone? > > Right. Manoj asked: why should we have a requirement? Someone said > "here's why!" and I am simply pointing out that you can get what he > wanted without a requirement. My mistake then. My other comments, not directed at you, still apply, though. -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
dpkg: should it remove in reverse depends order?
Below is a log of a transaction with apt-get and dpkg to first install fontconfig and libfontconfig1, and then removing them. Installation goes nicely, but the removal fails, because dpkg removes libfontconfig1 first and only after it's done that does it remove fontconfig. Unfortunately, fontconfig's maintainer script calls fc-cache (via defoma Perl scripts that I don't really understand), which is linked against libfontconfig1 and therefore fails in the dynamic linker. fontconfig does depend on libfontconfig1, so I expected dpkg to remove the packages in the right order. Before I start bugging the dpkg maintainers, would someone like to confirm that I'm not misunderstanding something? [EMAIL PROTECTED]:/# apt-get install fontconfig libfontconfig1 Reading Package Lists... Done Building Dependency Tree... Done The following NEW packages will be installed: fontconfig libfontconfig1 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. Need to get 219kB of archives. After unpacking 598kB of additional disk space will be used. Get:1 http://liw.iki.fi sarge/main libfontconfig1 2.3.1-2 [112kB] Get:2 http://liw.iki.fi sarge/main fontconfig 2.3.1-2 [106kB] Fetched 219kB in 0s (2853kB/s) Preconfiguring packages ... Selecting previously deselected package libfontconfig1. (Reading database ... 9171 files and directories currently installed.) Unpacking libfontconfig1 (from .../libfontconfig1_2.3.1-2_i386.deb) ... Selecting previously deselected package fontconfig. Unpacking fontconfig (from .../fontconfig_2.3.1-2_i386.deb) ... Setting up fontconfig (2.3.1-2) ... Creating config file /etc/fonts/local.conf with new version Updating font configuration of fontconfig... Cleaning up category cid.. Cleaning up category truetype.. Cleaning up category type1.. Updating category type1.. Updating category truetype.. Updating category cid.. Regenerating fonts cache... done. Setting up libfontconfig1 (2.3.1-2) ... [EMAIL PROTECTED]:/# dpkg --remove fontconfig libfontconfig1 (Reading database ... 9211 files and directories currently installed.) Removing libfontconfig1 ... Removing fontconfig ... Purging font configuration of fontconfig... Purging category cid.. Purging category truetype.. Purging category type1.. fc-cache: error while loading shared libraries: libfontconfig.so.1: cannot open shared object file: No such file or directory [EMAIL PROTECTED]:/# -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg: should it remove in reverse depends order?
Lars Wirzenius <[EMAIL PROTECTED]> writes: > Below is a log of a transaction with apt-get and dpkg to first install > fontconfig and libfontconfig1, and then removing them. Installation goes > nicely, but the removal fails, because dpkg removes libfontconfig1 first > and only after it's done that does it remove fontconfig. Unfortunately, > fontconfig's maintainer script calls fc-cache (via defoma Perl scripts > that I don't really understand), which is linked against libfontconfig1 > and therefore fails in the dynamic linker. fontconfig does depend on > libfontconfig1, so I expected dpkg to remove the packages in the right > order. It does remove them in exactly the right order: Package: libfontconfig1 Depends: ..., fontconfig See, libfontconfig1 needs to be removed before fontconfig. The order is completly correct. BUT on the other hand: Package: fontconfig Depends: ..., libfontconfig1 (>= 2.3.0), ... The same goes for fontconfig. The problem is fontconfig / libfontconfig1. No one else is to blame. Cyclic depends will be broken at random places and will cause problems. This exact same cycle has come up in a recent discussion about depends cycle and I think the proposed solution was to move fc-cache into the library package and then remove the libfontconfig1 depends fontconfig. I think. Check for the thread for the full summary. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: snownews maintainership
On Mon, 2005-07-18 at 13:01 +0200, Nico Golde wrote: > I read it and thats why I asked before I have done > something. There is nothing in the MIA database about him and Echelon says that his last message is dated Wed, 06 Jun 2005. Probably he is just suffering from temporary mail failures. Kind regards, Philipp Kern signature.asc Description: This is a digitally signed message part
Re: cpufrequtils init script in rcS.d
On Mon, Jul 18, 2005 at 09:35:26PM +0200, Bernd Eckenfels wrote: > In article <[EMAIL PROTECTED]> you wrote: > > You don't know that actually. > > There are far too many usages to make a generic statement like that. > > I can't see nothing wrong or useless in trying to maximize battery > > power and/or minimize heat generation. > > Yes of course, however there is a big difference between possibility to > optimize and the Must-have claim we had before. After all, we just want to > understand why it is so important. Sorry, I probably didn't explain very well in the first instance. I'll retry: s/must/should/ in the rationale provided before :) I'd like to add another thing I forgot to mention in the first place: in its current form the initscript I intend to use is disabled through the use of an appropriate variable in /etc/default/cpufrequtils making it more a "possibility" than a "must-have". However it would still be good to do it early (IMO). :) -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Urgent news about TV
Hey [EMAIL PROTECTED], Do you like watching cable T.V.? PPV : Sports, Movies, Adult Channels, HBO ,Cinemax, Starz, OnDemand, Ect. And the best part is you can have all these channels with our product! Our website : filtersppv.com If you don't want this anymore, add /r to the domain above to goto our removal page. Thanks Alot, Sousa C. Wilbur [EMAIL PROTECTED]
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
hi, On Mon, Jul 18, 2005 at 03:40:30PM +0200, Olaf van der Spek wrote: > On 7/18/05, sean finney <[EMAIL PROTECTED]> wrote: > > yes, and the same with libmysqlclient, which is why there's no longer ssl > > support in the mysql packages :( > > Wouldn't it be possible to support SSL transparently in such a way > that the original package doesn't need to be modified? not without some major dlopen-style hackery, which i don't imagine upstream would support and neither christian nor i have the time/interest/desire to see done in debian-specific patches. On Mon, Jul 18, 2005 at 04:36:52PM +0200, Torsten Landschoff wrote: > On Mon, Jul 18, 2005 at 09:29:46AM -0400, sean finney wrote: > > yes, and the same with libmysqlclient, which is why there's no longer ssl > > support in the mysql packages :( > > That kind of ... sucks!? No hope have the support GnuTLS or something? it's totally feasible that it (and any other ssl-needing library) could be patched to use gnutls instead of openssl, but i'm not familiar enough with either API and would really prefer upstream to approve/include the functionality. if somebody did the hard work and provided a patch, and the mysql folks sounded somewhat postitive about it, i'd consider the possibility. of course this would all be moot if upstream authors got a clue about the full ramifications of the GPL with their software... On Mon, Jul 18, 2005 at 07:57:11PM +0200, Bernhard R. Link wrote: > Well, linking against openssl where gnutls support seems to be > available is at least an annoyance. The alternative is > to upload an alternative libcurl, duplicating the source code, > making it harder for everyone involved. So it is more than just > a avarage wishlist-bug where the maintainer's opinion is the last > word. the problem, from what i understand and from what istr, is that the API's aren't bit-for-bit compatible. given that openssl is not likely to change their license scheme any time soon, moving to something like gnutls does seem the preferable way to go supposing that someone is willing to do and maintain the work. however, it still very much is ultimately the maintainer's perogative whether or not to accept such an option, at least in the situation where upstream only supports openssl. if upstream supports both, you probably won't have a hard time convincing them to change over, and if not you'd at least have a leg to stand on with the technical comittee. sean -- signature.asc Description: Digital signature
Re: cpufrequtils init script in rcS.d
In article <[EMAIL PROTECTED]> you wrote: > You don't know that actually. > There are far too many usages to make a generic statement like that. > I can't see nothing wrong or useless in trying to maximize battery > power and/or minimize heat generation. Yes of course, however there is a big difference between possibility to optimize and the Must-have claim we had before. After all, we just want to understand why it is so important. Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lsb-base
* Marco d'Itri <[EMAIL PROTECTED]> [050717 18:50]: > I am considering switching the init scripts of my packages to lsb-base > (which means that it will have to be promoted to important priority, at > least). > If anybody has objections please voice them now. Is there a way to configure this to not create masses of processes and confusing the user with colors? Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lsb-base
On Jul 18, "Bernhard R. Link" <[EMAIL PROTECTED]> wrote: > Is there a way to configure this to not create masses of processes and > confusing the user with colors? You can write your own package which conflicts+provides lsb-base and implements /lib/lsb/init-functions. -- ciao, Marco signature.asc Description: Digital signature
Re: Yet another g++ transition page
On Monday 18 July 2005 10:24 am, Mike Furr wrote: > Of course, the results are based on Packages files, which means a lot > could have happened from the time it was last updated and when you're > viewing it. So be sure to check with the packages/buildds before doing > anything. It will be updated ~once/day. I think you need to take virtual packages into account; apt-based stuff is showing up in Level 1, which AIUI is wrong. Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ |"Is it too late to extricate myself| | from this plot line?" | |"Yes." -- Fluble | \ The Turtle Moves! -- http://www.lspace.org ---/ pgpS1k9shxFSY.pgp Description: PGP signature
Re: Yet another g++ transition page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Burrows wrote: > Whoops, I see. So, just to further my comprehension here, why doesn't apt > show up in the dependency tree of aptitude? Obviously libsigc has gone > through the transition already, so it's not listed, but I'm quite certain > that apt hasn't. Whoops, that would be a bug in that part that generates the individual pages. Jochen Voss wrote: > Just to let you know: the link labelled "gforge" (level 8) points to > the page http://people.debian.org/~mfurr/gxx/html/g/f/gforge.html > which doesn't exist. yep, same bug. It should be fixed in a few minutes... - -m -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC3BSZ7ZPKKRJLJvMRApJAAJ99N6Sjvk+Dl5BMBrQ1TPkvm/hL6QCffsj/ BFltxgZltBzYvfZBy2R/y5U= =8MhS -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reformatted Ubuntu Patches Repository
#include * Javier Candeira [Sun, Jul 17 2005, 06:52:05PM]: > > YOU ROCK!!! Ack, very nice, a beacon in the chaos of their patch repository. Regards, Eduard. -- Wie man sein Kind nicht nennen sollte: Dick Opf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debconf5 - videos of the talks and BOFs available
Holger Levsen wrote: > "the mighty video team", in boring alphabetical order (but you who where > there > know who they are), Andrew McMillan, Chris Halls, Erik Johansson, Henning > Sprang, Herman Robak, Holger Levsen, Javier Candeira, John Lightsey, > Kalle Boess, Martin Langhoff, Noel Koethe, Peter de Schrijver, Tore S Bekkedal > is proud to announce the availability of (most of, atm) the videos of the > officially scheduled talks and BOFs at debconf5. Thanks alot to the video team and everybody involved. I could not come to debconf in person and I am enjoying the videos very much. Cheers, Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: is it a bug to not depend on a library package needed for some binary?
> On 2005-07-17 14:00 PDT, Matthew Woodcraft writes: Matthew> There is a lot of discussion of this question in bug Matthew> 119517 (where the conclusion reached was that this is Matthew> sometimes ok). Wow, that was a long thread. Thanks for the pointer. I will file bugs if it there is no Recommends/Suggests and/or I can't find previous discussion of the issue. -- Karl 2005-07-18 12:46 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: snownews maintainership
hi, * Philipp Kern <[EMAIL PROTECTED]> [2005-07-18 22:02]: > On Mon, 2005-07-18 at 13:01 +0200, Nico Golde wrote: > > I read it and thats why I asked before I have done > > something. > > There is nothing in the MIA database about him and Echelon says that his > last message is dated Wed, 06 Jun 2005. Probably he is just suffering > from temporary mail failures. yes i saw this. i mailed to an entry in the bts and mailed him personally. if he will not reply in a month or so i will ask for mia. regards nico -- Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org VIM has two modes - the one in which it beeps and the one in which it doesn't -- encrypted mail preferred -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Yet another g++ transition page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Burrows wrote: > I think you need to take virtual packages into account; apt-based stuff is > showing up in Level 1, which AIUI is wrong. Well, it does the best it can. It resolves all of the information it has available. However, for example, apt-move has a dependency on libapt-pkg-libc6.3-5-3.3 which is not provided by any package currently in unstable so my tool has no possible way of resolving this. If it depended on libapt...-3.9, then it would correctly correlate this with the "apt" package. Cheers, - -Mike -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC2/O47ZPKKRJLJvMRAj+rAJ9XtHa9YzIp9z+/fnL0nn+qgq8bDQCaApe0 FYREkk1yIWNLD3jOMOmYUEc= =7FnW -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libcurl3-dev: A development package linked again gnutls needed
On 7/17/05, Marco d'Itri <[EMAIL PROTECTED]> wrote: > Upstream developers should get a clue and either properly license their > software, stop using libcurl or adding gnutls support to it. Upstream developers (and a lot of other people) should stop believing the FSF's FUD about how it's not legal to integrate (in an engineering sense) components offered under the GPL and GPL-incompatible licenses, especially OpenSSL. That claim is (IANAL, TINLA) utterly without foundation in the applicable law, not to mention profoundly hypocritical in light of the LPF's amicus brief in Lotus v. Borland and the incorporation of the OpenSSL interface spec in the shim bundled with GNU TLS. Knuckling under to it, where OpenSSL is concerned, amounts IMHO to collusion with an extra-legal anti-competitive strategy that may yet be proven against the FSF under a more appropriate choice of law by someone more genuinely affected and more legally competent than Daniel Wallace. Cheers, - Michael
Re: NMUs wanted: C++ library packages in need of uploading
On Monday, 18 July 2005 03:54, Steve Langasek wrote: > zipios++ I intended to NMU this one before the transition, so I guess I can NMU it now, do the transition and fix the crash in amd64. Best regards -- Isaac Clerencia at Warp Networks, http://www.warp.es Work: <[EMAIL PROTECTED]> | Debian: <[EMAIL PROTECTED]> pgp5sYsGHZMno.pgp Description: PGP signature
Re: Who needs libcurl3?
On Mon, 18 Jul 2005 the mental interface of Torsten Landschoff told: > Hi Goswin, > > On Mon, Jul 18, 2005 at 01:06:01PM +0200, Goswin von Brederlow wrote: > > > I guess the savest way is to have a libldap-nossl-dev and > > libldap-ssl-dev. The former should have anything ssl derived > > removed. > > No problem. But then I can just build libldap without ssl as the library > built without SSL puts macros into the header files to disable ssl > functionality iirc. In summary: libs linked again ssl need at least two dev-packages: libfoo-dev.deb and libfoo-ssl-dev.deb Right? Should it be worst to announce this to debian-devel-announce? Elimar -- Obviously the human brain works like a computer. Since there are no stupid computers humans can't be stupid. There are just a few running with Windows or even CE ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lsb-base
* Marco d'Itri ([EMAIL PROTECTED]) [050718 20:17]: > On Jul 18, "Bernhard R. Link" <[EMAIL PROTECTED]> wrote: > > > Is there a way to configure this to not create masses of processes and > > confusing the user with colors? > You can write your own package which conflicts+provides lsb-base and > implements /lib/lsb/init-functions. It would be better if there would be some configureable option in lsb-base. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: BTS version tracking
* Colin Watson ([EMAIL PROTECTED]) [050718 17:21]: > The BTS records that bug #NN was fixed in 1.1-sarge1 and 1.3, and > let's say the bug was found in version 1.1. Since it has the changelogs > (it gets these from ftp-master), it can build up a tree of which package > versions are based on which other package versions, which in this case > looks like this: How does the BTS cope with versions that are not available from ftp-master, but where the maintainer adds "found in" for them? Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Yet another g++ transition page
Hi Mike, On Mon, Jul 18, 2005 at 01:24:33PM -0400, Mike Furr wrote: > After starting writing a program to help me track my packages > dependencies for the g++ transition, I decided to put up the results for > the entire archive in case it was useful for others. Looks useful. Just to let you know: the link labelled "gforge" (level 8) points to the page http://people.debian.org/~mfurr/gxx/html/g/f/gforge.html which doesn't exist. I hope this helps, Jochen -- http://seehuhn.de/ signature.asc Description: Digital signature
Re: NMUs wanted: C++ library packages in need of uploading
On Monday, 18 July 2005 21:11, Isaac Clerencia wrote: > On Monday, 18 July 2005 03:54, Steve Langasek wrote: > > zipios++ > > I intended to NMU this one before the transition, so I guess I can NMU it > now, do the transition and fix the crash in amd64. Uhm, shouldn't cppunit be rebuilt before zipios++? -- Isaac Clerencia at Warp Networks, http://www.warp.es Work: <[EMAIL PROTECTED]> | Debian: <[EMAIL PROTECTED]> pgpaXyDbHjjb5.pgp Description: PGP signature
Yet another g++ transition page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After starting writing a program to help me track my packages dependencies for the g++ transition, I decided to put up the results for the entire archive in case it was useful for others. http://people.debian.org/~mfurr/gxx/ The main difference between my page and several of the others is that it uses information from Packages files for every architecture to decide if it is ready to be nmu'd. Therefore, it shows when a package has been uploaded, but not built on all architectures. Also, individual dependency graphs are available for each package affected by the transition (that my program could detect). Of course, the results are based on Packages files, which means a lot could have happened from the time it was last updated and when you're viewing it. So be sure to check with the packages/buildds before doing anything. It will be updated ~once/day. Cheers, - -Mike -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC2+XP7ZPKKRJLJvMRAl9JAJ9tZ6DxjpoJRIbXHiDJPNFCKxR3kwCcCDRI yDKE8hUj/lotuSgdk72qhr0= =HqpR -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who needs libcurl3?
hi, On Mon, Jul 18, 2005 at 09:52:32PM +0200, Elimar Riesebieter wrote: > In summary: > libs linked again ssl need at least two dev-packages: > libfoo-dev.deb and libfoo-ssl-dev.deb > > Right? No. as mentioned earlier, this is no fault of the library packages in question, and instead is the fault of upstream authors' and/or other package maintainers not comprehending the implications of the gpl. there were other options brought up in this thread that would be a better course of action. this also doesn't solve the problem, and will only complicate things further when another similar style license problem comes out. > Should it be worst to announce this to debian-devel-announce? no. sean -- signature.asc Description: Digital signature
Re: Yet another g++ transition page
On Monday 18 July 2005 11:23 am, Mike Furr wrote: > Daniel Burrows wrote: > > I think you need to take virtual packages into account; apt-based stuff > > is showing up in Level 1, which AIUI is wrong. > > Well, it does the best it can. It resolves all of the information it > has available. However, for example, apt-move has a dependency on > libapt-pkg-libc6.3-5-3.3 which is not provided by any package currently > in unstable so my tool has no possible way of resolving this. If it > depended on libapt...-3.9, then it would correctly correlate this with > the "apt" package. Whoops, I see. So, just to further my comprehension here, why doesn't apt show up in the dependency tree of aptitude? Obviously libsigc has gone through the transition already, so it's not listed, but I'm quite certain that apt hasn't. Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | Gil-Galad was an Elven king; | | of him the harpers sadly sing. | \- A duck! -- http://www.python.org / pgpbYE3zIw8F4.pgp Description: PGP signature
Robhatah iStore - Humanoids, Bipeds, DSPs, Sensors and Oscilloscopes
Title: Manus Dear Researcher, Robhatah is delighted to announce, for the first time, our great line up of robotic research platforms, DSPs, sensors, digital oscilloscopes and other robotic/electronic products. Do visit www.robhatah.com to visit our website and http://robhatah.com/cubecart/index.php to go directly to our online shopping cart. Visit our online shop now to receive superb prices on your early purchases. We wish you luck in your robotics endeavors and hope to be your biggest supporters in your research achievements. Sincerely, Bob Virtual Sales Department Robhatah Robotic Solutions www.robhatah.com PS: We encourage constant feedback/suggestions to better our services. Send us your comments by writing into [EMAIL PROTECTED]. Multiple Award winning Humanoid research robot - Manus I "Robust aluminium alloy body and off the shelf components enable maximum flexibility to the researcher" -> Manus-I tops again ! - FIRA '04 (HIT, China) -> Winner, FIRA 2003 (Hurosot) (NUS, Singapore) -> Winner, Singapore Robotic Games 2004 (NUS, Singapore) Height : 50 cm Weight : 2.5kg DOF: 17 Processors: 2 Motorola 16 bit DSPs Sensors: CMOS camera (Pan & Tilt), Electronic Compass, IR Sensor, Force Sensor, Optional Tilt Sensor Manus-I is capable of visually tracking and walking towards colored targets. It has dynamic walking and obstacle avoidance capabilities. The dimensions and specifications are designed to meet the FIRA-Humanoid competition rules. Manus-I can even kick a ball into a goal. Other capabilities include getting up from a seated position and climbing stairs. write into [EMAIL PROTECTED] to see some of our customer testimonials and to communicate directly to an expert. Biped Research Robot- Manus TLR Height : 35 cm Weight : 1.75kg DOF: 12 Processors: 2 Motorola 16 bit DSPs Sensors: Electronic Compass, IR Sensor, Force Sensor, Optional Tilt Sensor Manus-TLR is an ideal platform for educators and researchers to jump-start their own biped or humanoid projects.The system is fully modularized and allows researchers to modify or add new features. Rōbhatah team provides comprehensive technical support to help students and researchers. Click on image for more details on Manus-TLR. Alternatively, view our Biped page by clicking here. Portable Oscilloscope: Stingray Portable and stylish, Stingray combines the functions of Oscilloscope, Data Logger, Spectrum Analyser, Volt Meter, Frequency Meter and Signal Generator in a single instrument. Powered from USB, Stingray needs no external power supply. Stingray features simultaneous 12-bit sampling on both channels, a native sampling rate of 1MS/s ( 20MS/s for repetitive signals ), sophisticated hardware triggering including delayed time base and pulse width. It also has a 3rd channel which can be a waveform generator output or an external trigger input. Click on image for more details about the Stingray. Stereo Vision Enabled Research Robot - Bebop Bebop was designed to be an affordable solution for researchers and hobbyists in mobile robotics. FEATURES: -Mobile Chassis with 12V battery and charger -Embedded x86 processing system -Stereo-Vision sensor system -Real-time Linux-based operating system Click on image for more details on the Bebop. Alternatively, visit our Bebop page by clicking here. Heavy Duty DSP - Isopod IsoPod™_V2 is suitable for dedicated control of RC Servo motors, DC motors, BDCM, stepper motors, solenoids, and other bipolar power outputs, such as general converter/inverter applications, data collection and many networked control applications. Click on image for more details about the DSP. Extensive information can be found by clicking here. Unmatched Servo control DSP - Servopod A 16-bit DSP microcontroller, based on motorola DSP56F807 MPU embe
Re: NMUs wanted: C++ library packages in need of uploading
On Monday, 18 July 2005 21:22, Isaac Clerencia wrote: > On Monday, 18 July 2005 21:11, Isaac Clerencia wrote: > > On Monday, 18 July 2005 03:54, Steve Langasek wrote: > > > zipios++ > > > > I intended to NMU this one before the transition, so I guess I can NMU it > > now, do the transition and fix the crash in amd64. > > Uhm, shouldn't cppunit be rebuilt before zipios++? After having a look it looks like zipios++ should depend on cppunit, which depends on Qt. So we have *real* problems, tomorrow (or the day after tomorrow) a new version of Wesnoth will be released and we won't be able to play it!!! :P Best regards -- Isaac Clerencia at Warp Networks, http://www.warp.es Work: <[EMAIL PROTECTED]> | Debian: <[EMAIL PROTECTED]> pgpFA5s8iIRPM.pgp Description: PGP signature
Re: Yet another g++ transition page
Hi Mike, On Mon, Jul 18, 2005 at 04:44:11PM -0400, Mike Furr wrote: > Jochen Voss wrote: > > Just to let you know: ... > yep, same bug. I found another one ;-) The entry "configlet(configlet-frontends)" should be level 6 instead of 8. The tree starts out as configlet-frontends * python-configlet o python2.3-configlet + gksu but configlet-frontends, python-configlet, and python2.3-configlet are all built from the same source package. I think they only have to wait for gksu. Also, if possible, it might be useful to list for each package how many other packages from yout list depend on it. Then it will be easier to spot the real blockers in the very long level 1 list. All the best, Jochen -- http://seehuhn.de/ signature.asc Description: Digital signature
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
* sean finney <[EMAIL PROTECTED]> [050717 21:20]: > On Sun, Jul 17, 2005 at 09:04:57PM +0200, Elimar Riesebieter wrote: > > Why not building curl --without-sssl and --with-gnutls=/usr? Maybe a > > NMU? > > this is definitely NOT a reason to NMU libcurl. remember that it is > your package that is "broken". of course you could still file a > wishlist bug against libcurl asking to compile against gnutls > instead, but it's up to the maintainer in question to decide. Well, linking against openssl where gnutls support seems to be available is at least an annoyance. The alternative is to upload an alternative libcurl, duplicating the source code, making it harder for everyone involved. So it is more than just a avarage wishlist-bug where the maintainer's opinion is the last word. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg: should it remove in reverse depends order?
ma, 2005-07-18 kello 18:51 +0200, Goswin von Brederlow kirjoitti: > The problem is fontconfig / libfontconfig1. No one else is to > blame. Cyclic depends will be broken at random places and will cause > problems. Ah yes, of course, I should have realized that. Thanks. It's not a dpkg problem, and I can deal with it by adding some ignores to the piuparts command line. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318961: ITP: terralib -- A GIS classes and functions library.
Package: wnpp Severity: wishlist Owner: Marco Tulio Gontijo e Silva <[EMAIL PROTECTED]> * Package name: terralib Version : 3.0.3.2 Upstream Author : INPE/Tecgraf <[EMAIL PROTECTED]> * URL : http://www.terralib.org/ * License : LPGL Description : A GIS classes and functions library. TerraLib enables quick development of custom-built geographical applications using spatial databases. As a research tool, TerraLib is aimed at providing a rich and powerful environment for the development of GIScience research, enabling the development of GIS prototypes that include new concepts such as spatio-temporal data models, geographical ontologies and advanced spatial analysis techniques. TerraLib defines a geographical data model and provides support for this model over a range of different DBMS (MySQL, PostgreSQL, ORACLE e ACCESS), and is implemented as a library of C++ classes and functions, written in ANSI-C++ (INCITS / ISO/ IEC 14882:1998). . Homepage: http://www.terralib.org/ Terralibs latest stable release is 3.0.3 build 2, and I think it's important to have it in debian cause it's being widely used. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-2-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Yet another g++ transition page
Hi Mike, On Mon, Jul 18, 2005 at 01:24:33PM -0400, Mike Furr wrote: > After starting writing a program to help me track my packages > dependencies for the g++ transition, I decided to put up the results for > the entire archive in case it was useful for others. > http://people.debian.org/~mfurr/gxx/ > The main difference between my page and several of the others is that it > uses information from Packages files for every architecture to decide > if it is ready to be nmu'd. Therefore, it shows when a package has been > uploaded, but not built on all architectures. Also, individual > dependency graphs are available for each package affected by the > transition (that my program could detect). > Of course, the results are based on Packages files, which means a lot > could have happened from the time it was last updated and when you're > viewing it. So be sure to check with the packages/buildds before doing > anything. It will be updated ~once/day. Nice. :) Wishlist request: could you have it tally the total number of packages whose transition depends on each package in the list, and print that number next to the source package name? Better yet, could the list be sorted by this number? :) That would certainly be helpful in identifying which packages should be given the highest priority. Thanks, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Who needs libcurl3?
Hi Stephen, On Mon, Jul 18, 2005 at 10:53:02AM -0400, Stephen Frost wrote: > > Working on that. At least theoretically - when I get time, yada, yada. > > Steve Langasek had offered to help with this too. I'll poke him about > it on IRC and see if he's still willing to help. That's not too helpful. I don't really want to support code I did not understand. I'd rather write it myself or have Steve care about problems in it... Greetings Torsten signature.asc Description: Digital signature
Re: Removal of transitional dummy packages
On Mon, 18 Jul 2005, Santiago Vila wrote: > On Mon, 18 Jul 2005, Steve Langasek wrote: > > In this context, woody->sarge transition packages are just one > > form of useless cruft that we should strive to get rid of before > > the etch release. They're not the biggest source of cruft, but on > > the other hand they are (IMHO) one of the sources for which the > > proper course of action is clearest. > > In such case, could we please codify that in policy? Surely the release manager's decision on the matter when properly publisized is information enough? Don Armstrong -- Tell me something interesting about yourself. Lie if you have to. -- hugh macleod http://www.gapingvoid.com/archives/batch20.php http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who needs libcurl3?
* Torsten Landschoff ([EMAIL PROTECTED]) wrote: > Hi Stephen, > > On Mon, Jul 18, 2005 at 10:53:02AM -0400, Stephen Frost wrote: > > > Working on that. At least theoretically - when I get time, yada, yada. > > > > Steve Langasek had offered to help with this too. I'll poke him about > > it on IRC and see if he's still willing to help. > > That's not too helpful. I don't really want to support code I did not > understand. I'd rather write it myself or have Steve care about problems > in it... The idea is to get upstream to include/support it... Stephen signature.asc Description: Digital signature
Bug#318983: ITP: libccscript3 -- GNU Common C++ framework for embedded scripting (update to package version 3)
Package: wnpp Severity: wishlist Owner: Mark Purcell <[EMAIL PROTECTED]> * Package name: libccscript3 Version : 0.7.0 Upstream Author : David Sugar <[EMAIL PROTECTED]> * URL : http://www.gnu.org/software/ccscript/ * License : GPL Description : GNU Common C++ framework for embedded scripting (update to package version 3) A new and highly optimized release series of the ccScript engine. Includes major improvements in the use of locking and symbol lookup operations. This is the version 3 upstream release of libccscript. I propose to package libccscript-dev & libccscript3-0.7-0, which won't conflict with the existing Debian libccscript v2 packages, which I also maintain. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-2-686 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318987: ITP: libccaudio2 -- GNU ccAudio2 - a C++ class framework for processing audio files
Package: wnpp Severity: wishlist Owner: Mark Purcell <[EMAIL PROTECTED]> * Package name: libccaudio2 Version : 0.7.6 Upstream Author : David Sugar <[EMAIL PROTECTED]> * URL : http://www.gnu.org/software/ccaudio * License : GPL Description : GNU ccAudio2 - a C++ class framework for processing audio files The GNU ccAudio package offers a highly portable C++ class framework for developing applications which manipulate audio streams and various disk based audio file formats. At the moment ccaudio is primarly a class framework for handling .au, .wav (RIFF), and various .raw audio encoding formats under Posix and win32 systems, though it may expand to become a general purpose audio and soundcard support library. Support for controlling CD audio devices has recently been added as well as support for codecs and other generic audio processing services. This is the next version of libccaudio which I am also the current Debian maintainer for. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-2-686 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Gia ve may bay
Xin vui long gui cho chung toi gia ve may bay khu hoi cho 2 nguoi di tu Noi Bai toi Thuong Hai,Trung Quoc trong cuoi thang 7. Thanks Ms Huyen 0912646876
Re: cpufrequtils init script in rcS.d
* Mattia Dongili | On Sat, Jul 16, 2005 at 12:39:03AM +0200, Bernd Eckenfels wrote: | > In article <[EMAIL PROTECTED]> you wrote: | > > Sorry. The main idea is making power management more effective, that's | > > why earlier is better here. | > | > I dont see why this is the case. in the bootup phase the system is loaded | > anyway, no need to throttle it. | | Well, I can actually imagine that most of the time at bootup is spent | waiting for I/O to complete, HW probes and so on, nothing that CPU bound | actually (AFAICT). If you take a look at http://www.planetarytramp.net/bootchart/bootchart-20041210-1934.png, you will see that it actually is CPU-bound in some places and I/O-bound in other. S20 runs after about twenty seconds. I really don't think having your CPU run at full speed for twenty seconds is going to matter much for your battery life. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NMUs wanted: C++ library packages in need of uploading
Updates to this list: On Sun, Jul 17, 2005 at 06:54:42PM -0700, Steve Langasek wrote: > libccaudio -- I'm preparing to work on this one > libccscript -- uploaded by the maintainer > libchipcard > libcrypto++ > libgwenhywfar > libinti1.0 > libktoblzcheck > libmodplug -- I've just NMUed this one > libmusicbrainz-2.1 > libparagui1.0 -- uploaded by the maintainer > librudiments0 -- uploaded by the maintainer > libsdl-sge > libsigcx > libtagcoll > libxbase > libxml++ > maxdb-7.5.00 > omniorb4 > openbabel > socketapi > stlport4.6 -- uploaded by the maintainer > strutilsxx > taglib > wfmath > wxwindows2.4 -- uploaded by the maintainer > xplc Cheers, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
