Re: multiarch status update
On Thu, May 11, 2006 at 06:12:42PM -0300, Daniel Ruoso wrote: > And what if dpkg knows about it and handle arch-independant packages in > a different way? There is nothing dpkg can do. Package-1.0 has a hardcoded reference to /usr/share/foo/bar (provided by some other package) and expects it to be version 1. Package-2.0 has a hardcoded reference to /usr/share/foo/bar and expects it to be version 2 which is not compatible with version 1. If you install package-1.0 and package-2.0 simultaneously one of them _will_ break. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes
#include * Miles Bader [Fri, May 12 2006, 03:08:47PM]: > Don Armstrong <[EMAIL PROTECTED]> writes: > > Just because something is also political statement doesn't make it > > evil or wrong. > > Yup. > > I think it's rather rude to respond to an ITP by publicly questioning > the choice of license (as long as it's a valid license for Debian). IMO there was no subtle offense, and no rejection because of license. But the wording could have been better: "Please consider asking the upstream to change a license to a more friendly one. GPL in a support (library) package has too much impact, especially on packages with other free but slightly GPL-incompatible licenses". Eduard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes
also sprach Don Armstrong <[EMAIL PROTECTED]> [2006.05.12.0758 +0200]: > This means that you need to either license your work under the > GPL, or a license which is compatible with the GPL. [It also means > that you'll need to provide your source code, but one would hope > you were going to do that anyway.] Which means that I, if I wanted to use cxxtools from my code, would need to relicence all of my code (Artistic Licence) to a new licence (Clarified Artistic Licence), which is not even available on fsf.org, gnu.org, or opensource.org, only on some independent server in Italy. Anyway, it's best if I stop this now. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system "people don't want a president to say 'never'. using violence is never the first choice of the president". -- george w. bush signature.asc Description: Digital signature (GPG/PGP)
Re: exp. lightspeed disappeared
Steinar H. Gunderson wrote: > Perhaps it fixed itself? :-) yes it did. The reason I posted is that, when I posted, the page http://packages.debian.org/lightspeed was showing the kfreebsd binary but not the i386 binary that I had uploaded...I was very puzzled! thanks for checking a. ps: it seems anyway that there are some weird issue with archives: see http://permalink.gmane.org/gmane.linux.debian.devel.general/100417 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#366900: ITP: asterisk-prompt-es-co -- Colombian Spanish voice prompts for the Asterisk PBX
Le jeudi 11 mai 2006 à 18:33 -0500, Santiago Ruano Rincón a écrit : > Package: wnpp > Severity: wishlist > Owner: "Santiago Ruano Rincón" <[EMAIL PROTECTED]> > > > * Package name: asterisk-prompt-es-co > Version : 0.0.20060503 > Upstream Author : Avatar Ltda. <[EMAIL PROTECTED]> > * URL : http://www.avatar.com.co/ > * License : GPL > Description : Colombian Spanish voice prompts for the Asterisk PBX > > These are Colombian Spanish voice prompts for the Asterisk PBX, courtesy > of Avatar Ltda., Colombia. > . > You need this package if you intend to run Asterisk and wish to support > Spanish-speaking callers. You should probably join the pkg-voip-maintainers team instead of packaging it on your own. I put their mailing-list in copy of this mail. Hope it helps -- Jérôme Warnier FLOSS Consultant http://beeznest.net
Re: Intent to hijack Bacula (Heads up, Get The Facts!) (long)
Le vendredi 12 mai 2006 à 03:13 +0200, José Luis Tallón a écrit : > Please tell me how in hell can you justify accusing me of not testing my > packages, when you have obviously not done so. > You seem to have some fixation with uploading, don't you?? Six versions > in 24h ? > Instead of uploading many half-baked packages, you could try getting one > right before uploading. > It is hardly justifiable to build and upload that many packages if you > already foresee many more fixes needing to go in. I don't want to comment on the rest, as you are turning ridiculous, but let me just give you this advice: release early, release often. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes
On Thu, May 11, 2006 at 05:35:35PM +0200, Frank Küster wrote: > Michael Banck <[EMAIL PROTECTED]> wrote: > > Seconds, since when do we consider the GPL to be viral? > > Don't know about you, but the FSF does - it has created the LGPL because > of this. Actually, they don't. They consider the GPL a perfectly valid license for a library; however, they also consider that in some cases, it *may* be better to use the LGPL instead. Just not all of them. Why do you think they * Never released libreadline under anything else than the GPL, * Renamed the LGPL from the "Library GPL" to the "Lesser GPL"? -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Mime Support
Hi, we are working for a distro. For that we are using a debian installer for installing the deb packages with a double click on a deb package and also incorporated into our distro. But the problem is:At the first time when we try to install we need to check the open with the deb_installer option in properties. Once it is checked we are able to install all other deb pacakge through the installer without any problem. But how can we do this for the first time itself. that is what ever deb package we are downloading it shd by default open with the installer. For invoking this option which pacakge we need to alter.I heard something about mime-support package. Is there anything to be done in this package or anything else.Help PleaseRegards Indraveni What makes Sachin India's highest paid sports celebrity?, Share your knowledge on Yahoo! India Answers Send instant messages to your online friends - NOW
Re: Intent to hijack Bacula (END)
John Goerzen wrote: > On Fri, May 12, 2006 at 03:13:31AM +0200, José Luis Tallón wrote: > > Jose, > > Before I comment on a few things, I want to make something clear to you. > > You have repeatedly accused me of having something personal against you, > both in public and in private. > It definitively has looked like that over time. NMUs are not personal attacks. I know that and appreciate them. The attitude and comments which went along with them were offensive to me however. > I cannot recall ever having even *heard* of your existance prior to > looking at Bacula, and didn't know a thing about you until later yet. > Don't worry, you have won. Congratulations, mister "Official Maintainer of Bacula in Debian". Time to step out for a while. > [snip] > > What's more, I WOULD HOPE PEOPLE WOULD DO IT FOR ME. I have maintained > my fair share of packages over the years, and I have also orphaned or > given up packages for adoption over the years. I've been NMU'd, even > recently. > > I am not mad at that. In fact, I am glad that these things have > happened. (I wish it hadn't been necessary, but I'm glad that people > have stepped up to do it when it was.) > I did thank you for your NMU, and hurried to request your patches. That's a fact. > A key difference is that I recognized when someone else would be better > able to take care of a package, and amicably arranged with them to do > so. > Well... I said "no"(for the time being) and you didn't respect that. Instead, you simply proceeded with the hijack. > [snip] > > I don't say this to try to prove that I'm some mighty Debian developer. > I'm not, and I know it. I say this because I want you to understand > something that you may not have had a chance to experience yet -- that > is, that there is more to getting satisfaction from a project than doing > everything yourself. > I do know that. It's the manners that I don't like. > I think the best compliment for a Debian developer is for a *user* of > Debian to say, "Wow, *Debian* is a solid OS that Just Works." > > NMUs make Debian better. They definitively do. > Hijacking of packages, as in this case, can make Debian better too. Only when done in a proper way (my own POV, anyway) > Remember, from the Social Contract, that Debian's priorities are its users > and Free Software. > Indeed. Those have been mine, even though you and some others differ. I cared about my users when I packaged Bacula for the first time almost three years ago. > Attitudes like this will ensure that there is always half a year left > until Etch is released. > I beg to differ, but I can understand your point. >> Still much more than two months left for the base freeze. A transition >> takes 10 days at most. >> > > If you get the package right to start with, and uploaded on time. Which > history indicates is not likely. > Well... different conditions lead to different results. I have had a Bacula-1.38.9-1 of my own ready for a couple days already, but it hasn't been uploaded. Before you say anything: the one who was going to make the upload seems to prefer waiting until this thread ended instead of uploading the fixes. And not, it wasn't because of technical concerns, and it wasn't rover. Now it's too late. Thanks for nothing. >>> * The last upload for Bacula was almost a year ago. >>> >>> >> There were no upstream releases for over six months, either. >> > > But there were RC bugs against it in Debian for over a year. You needed > to make a new upload. > As has been recently recognized publicly, it wasn't over a year old; And it had only been promoted to RC recently. > Then your testing standards are insufficient for an upload to sid. You > have uploaded packages that would not even *install from scratch* on > most machines. > Well... I fixed the bugs I found before every upload. Definitively the subset of machines you and I are talking about are different. There's nothing wrong with that, but then... >>> [snip] >> The fact that you uploaded six versions of Bacula to NEW within one day >> gives an idea of the level of testing you give them. >> > > That is not correct. Here are the dates of the "NEW" acknowledgments > from the ftp-master scripts for my uploads. > > Date: Wed, 03 May 2006 14:02:23 -0700 > Date: Mon, 08 May 2006 14:02:15 -0700 > Date: Tue, 09 May 2006 07:17:11 -0700 > Date: Wed, 10 May 2006 11:17:05 -0700 > Date: Wed, 10 May 2006 20:47:09 -0700 > Date: Thu, 11 May 2006 15:17:12 -0700 > > BTW, you *KNEW* that your "six versions of bacula within one day" was > inaccurate because the Debian Installer scripts CC'd you on every one of > those messages whose dates I have just listed. > I failed to check the dates for those. Sorry. Anyway, my point referred to the latest ones anyway. > It only takes a few minutes to do a full build, and far less to do > a partial build after making minor tweaks, and my machines aren't as > powerful as that. But I did test my pac
Re: Intent to hijack Bacula (Heads up, Get The Facts!) (long)
Josselin Mouette wrote: > Le vendredi 12 mai 2006 à 03:13 +0200, José Luis Tallón a écrit : > >> Please tell me how in hell can you justify accusing me of not testing my >> packages, when you have obviously not done so. >> You seem to have some fixation with uploading, don't you?? Six versions >> in 24h ? >> Instead of uploading many half-baked packages, you could try getting one >> right before uploading. >> It is hardly justifiable to build and upload that many packages if you >> already foresee many more fixes needing to go in. >> > > I don't want to comment on the rest, as you are turning ridiculous, but > let me just give you this advice: release early, release often. > If that was easy for me, I would (I mean in Debian) It should have been as easy as for John and yourself since late 2004. But it still isn't. Nothing more to say on this. J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes
* martin f krafft <[EMAIL PROTECTED]> [060512 09:50]: > also sprach Don Armstrong <[EMAIL PROTECTED]> [2006.05.12.0758 +0200]: > > This means that you need to either license your work under the > > GPL, or a license which is compatible with the GPL. [It also means > > that you'll need to provide your source code, but one would hope > > you were going to do that anyway.] > > Which means that I, if I wanted to use cxxtools from my code, would > need to relicence all of my code (Artistic Licence) to a new licence > (Clarified Artistic Licence), which is not even available on > fsf.org, gnu.org, or opensource.org, only on some independent server > in Italy. So cxxtools authors should allow you to use their code in your application even if they are not allowed to use your code in theirs? This is of course no unreasonable petition, but I suggest noone to fullfil it without additional reasons. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes
also sprach Bernhard R. Link <[EMAIL PROTECTED]> [2006.05.12.1254 +0200]: > So cxxtools authors should allow you to use their code in your > application even if they are not allowed to use your code in theirs? > This is of course no unreasonable petition, but I suggest noone to > fullfil it without additional reasons. "No reason to fight fire with fire" -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system fitter, healthier, more productive like a pig, in a cage, on antibiotics -- radiohead signature.asc Description: Digital signature (GPG/PGP)
Re: Getting rid of circular dependencies, stage 4
On Wed, May 10, 2006 at 07:31:58PM +0200, Dagfinn Ilmari Mannsåker wrote: >Brendan O'Dea <[EMAIL PROTECTED]> writes: > >> On Wed, May 10, 2006 at 04:20:19PM +0200, Pierre Habouzit wrote: >>> (In fact, IMHO nothing should depends from perl-modules at all). >> >> Correct. I'd prefer that nothing did. > >Is this documented anywhere? If is really is the case that nothing >should depend on perl-modules (but rather on perl itself), the Perl >Policy should mention it in the dependencies section. Perl Policy is intentionally vague about the way that the package is split up (into perl, perl-modules or whatever). The intent was to allow the maintainer to choose the most appropriate split (if any) and to mandate only the existence of `perl-base', and ensure that installing the package `perl' would provide a working Perl interpreter. Section 5.2 describes program dependencies, and refers only to `perl' or `perl-base'. The first paragraph could perhaps be re-worded as: Programs which require Perl modules must specify a dependency on the `perl' package. Note that it doesn't say that you shouldn't depend on perl-modules, merely that you must depend on perl. >> Selecting a random entry from that list with a versioned dependency, >> 'munin': >> >> Depends: perl (>= 5.6.0-16), perl-modules (>= 5.8.0) | >> libparse-recdescent-perl, [...] > >Speaking as co-maintainer of munin, should we just change that to "perl >(>= 5.8.0) | libparse-recdescent-perl" instead? Won't lintian complain >about a duplicate relation on perl in that case, or has that been fixed? > >(We want the packages to be installabe on woody with the minimum amount >of fuss, so we don't want to just depend on perl (>= 5.8.0)). That dependency is fine. I chose it as an example of where not having the reverse dependency could cause problems. This is the sort of thing which I'd prefer not to see: Package: vrms Depends: perl-modules perl would be correct. Package: libdbi-perl Depends: perl (>= 5.8.4-5) | perl-modules, perlapi-5.8.4, libc6 (>= 2.3.5-1), libplrpc-perl A specific version of perl or *any* version of perl-modules? Package: babygimp Depends: perl, perl-modules, perl-tk Redundant. Package: pdbv Depends: perl-base (>= 5.6.0), perl-modules, liblocale-gettext-perl, libtie-ixhash-perl, coreutils (>= 4.5.0) | fileutils (>= 4.1), debconf (>= 1.0.32) The first two should be replaced by "perl (>= 5.6.0)". etc. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack Bacula
* Riku Voipio ([EMAIL PROTECTED]) wrote: > On Thu, May 11, 2006 at 03:05:17PM +0300, Riku Voipio wrote: > > On Thu, May 11, 2006 at 01:09:11PM +0200, Roberto Lumbreras wrote: > > > The package has bugs, lots of them, and for that reason has been removed > > > from testing, well done, unstable it is here for that. > > > > Uh no. I find it scary that you share this same idea as the original > > bacula maintainer. Unstable is NOT a graveyard for packages with RC > > bugs years old! > > Uh, I owe Jose a apology. The oldest RC bug was not RC for over a year, > it was promoted to RC just recently. It's not like the bug changed... It was RC before just initially mis-filed... Enjoy, Stephen signature.asc Description: Digital signature
Re: Intent to hijack Bacula (Heads up, Get The Facts!) (long)
John Goerzen <[EMAIL PROTECTED]> writes: > I would do this regardless of who the maintainer was. I seem to recall > possibly doing it for some Perl HTML package that was in a similar > situation to Bacula in the late 90s, but I can't really remember. I'm > sure you could dig up links. It was the URI package, and you were totally justified. As, from what I see, you are in this case---not that my opinion should carry much weight other than in the "takes a (former) derelict maintainer to know one". :) Mike -- A steeple full of swallows that could never ring the bell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: track GCC 4.1 bugs
Processing commands for [EMAIL PROTECTED]: > block 366820 by 339921 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 275774 355163 355165 355189 355325 355326 355352 355396 355463 355598 355599 355663 355738 355739 355741 355744 355841 355980 355983 355986 355988 355989 355990 355992 355993 355996 355997 355998 356003 356004 356093 356098 356100 356109 356110 356111 356113 356115 356116 356121 356153 356155 356156 356157 356159 356160 356161 356163 356168 356169 356170 356171 356173 356174 356175 356176 356228 356229 356232 356233 356234 356238 356240 356241 356242 356244 356245 356246 356248 356303 356304 356305 356321 356322 356323 356324 356361 356362 356366 356367 356370 356374 356405 356422 356423 356424 356425 356428 356436 356439 356440 356442 356444 356445 356453 356455 356516 356517 356522 356540 356546 356549 356564 356570 356574 356579 356582 356583 356585 356590 356592 356597 356598 356601 356606 356611 356620 356634 356636 356646 356679 356684 356691 356767 356875 356878 356881 356892 356893 356964 356965 356967 356968 356970 356971 356972 356979 356980 357056 357057 357059 357061 357064 357070 357084 357096 357111 357112 357113 357117 357119 357182 357184 357186 357189 357190 357316 357317 357322 357324 357325 357328 357334 357335 357339 357340 357357 357358 357359 357360 357376 357380 357382 357383 357401 357402 357403 357404 357408 357447 357455 357467 357476 357478 357479 357481 357483 357490 357513 357552 357555 357556 357557 357558 357565 357566 357600 357601 357614 357640 357644 357648 357651 357656 357659 357687 357710 357711 357717 357720 357748 357750 357770 357774 357789 357810 357825 357849 357861 357863 357864 357866 357897 357901 357959 357960 357961 357962 357964 357967 357995 357996 358053 358062 358068 358069 358074 358075 358077 358087 358090 358096 358206 358207 358208 358212 358214 358218 358219 358221 358228 358240 358243 358259 358261 358263 358271 358277 358280 358281 358282 358284 358285 358286 358287 358289 358290 358291 358292 358293 358294 358298 358300 358301 358449 358542 358582 358591 358643 358644 358650 358881 358884 358886 361331 361333 361334 361335 361336 361389 361396 361766 364814 366753 366821 Blocking bugs added: 339921 > block 366820 by 366963 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 275774 339921 355163 355165 355189 355325 355326 355352 355396 355463 355598 355599 355663 355738 355739 355741 355744 355841 355980 355983 355986 355988 355989 355990 355992 355993 355996 355997 355998 356003 356004 356093 356098 356100 356109 356110 356111 356113 356115 356116 356121 356153 356155 356156 356157 356159 356160 356161 356163 356168 356169 356170 356171 356173 356174 356175 356176 356228 356229 356232 356233 356234 356238 356240 356241 356242 356244 356245 356246 356248 356303 356304 356305 356321 356322 356323 356324 356361 356362 356366 356367 356370 356374 356405 356422 356423 356424 356425 356428 356436 356439 356440 356442 356444 356445 356453 356455 356516 356517 356522 356540 356546 356549 356564 356570 356574 356579 356582 356583 356585 356590 356592 356597 356598 356601 356606 356611 356620 356634 356636 356646 356679 356684 356691 356767 356875 356878 356881 356892 356893 356964 356965 356967 356968 356970 356971 356972 356979 356980 357056 357057 357059 357061 357064 357070 357084 357096 357111 357112 357113 357117 357119 357182 357184 357186 357189 357190 357316 357317 357322 357324 357325 357328 357334 357335 357339 357340 357357 357358 357359 357360 357376 357380 357382 357383 357401 357402 357403 357404 357408 357447 357455 357467 357476 357478 357479 357481 357483 357490 357513 357552 357555 357556 357557 357558 357565 357566 357600 357601 357614 357640 357644 357648 357651 357656 357659 357687 357710 357711 357717 357720 357748 357750 357770 357774 357789 357810 357825 357849 357861 357863 357864 357866 357897 357901 357959 357960 357961 357962 357964 357967 357995 357996 358053 358062 358068 358069 358074 358075 358077 358087 358090 358096 358206 358207 358208 358212 358214 358218 358219 358221 358228 358240 358243 358259 358261 358263 358271 358277 358280 358281 358282 358284 358285 358286 358287 358289 358290 358291 358292 358293 358294 358298 358300 358301 358449 358542 358582 358591 358643 358644 358650 358881 358884 358886 361331 361333 361334 361335 361336 361389 361396 361766 364814 366753 366821 Blocking bugs added: 366963 > -- Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366978: ITP: bonfire -- CD/DVD burning application for GNOME
Package: wnpp Severity: wishlist Owner: "Ondrej Sury" <[EMAIL PROTECTED]> * Package name: bonfire Version : 0.3.0 Upstream Author : Philippe Rouquier <[EMAIL PROTECTED]> * URL : http://perso.wanadoo.fr/bonfire/ * License : GPL Programming Lang: C Description : CD/DVD burning application for GNOME Easy to use CD/DVD burning application where you can: * Burn, Copy and Erase CD/DVD * On-the-fly burning of CD/DVD * Append data to multisession CD/DVD * Burn Audio CD * CD-Text writing for Audio CD -- 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.15-22-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Possible transition to GCC 4.1 for etch: coordinated NMUs
* Martin Michlmayr <[EMAIL PROTECTED]> [2006-05-12 18:07]: > - Mon, May 29 - Mon, May 12: 2 weeks of coordinated NMUs. Please >email me privately if you're interested in helping out. > - Mon, May 12 - Thu, May 15: recompilation of the whole archive with >GCC 4.1 on several architecture to identify unresolved issues. > - Thu, May 15: send a report to the release team Obviously this should be June 12 and June 15. Thanks to Clint for pointing this out. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc 4.1 or not
On Thu, 11 May 2006, Martin Michlmayr wrote: I didn't hit this problem myself yet, but it has been mentioned on sparclinux list that 4.1 currently miscompiles the sparc kernel. Do you know if this still happens, and if so, whether someone has tracked it down? I only became aware of it a couple of days ago, and will try to reproduce the problem during the weekend. Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[VAC] Broke my wrist, afk 3-6 weeks
I can type -- slowly -- but I won't be doing any package maintenance for three to six weeks. Cheers, Shaun
Bug#366984: ITP: klone -- web application development framework
Package: wnpp Severity: wishlist Owner: Kari Pahula <[EMAIL PROTECTED]> * Package name: klone Version : 1.1.0 Upstream Author : KoanLogic Srl <[EMAIL PROTECTED]> * URL : http://www.koanlogic.com/kl/cont/gb/html/klone.html * License : GPLv2 or later Programming Lang: C Description : web application development framework KLone is a fully-featured, multiplatform, web application development framework, targeted especially for embedded systems and appliances. . It is a self-contained solution which includes a web server and an SDK for creating WWW sites with both static and dynamic content. When using KLone, there's absolutely no need for any additional component: neither the HTTP/S server (e.g. Apache, Netscape, Roxen), nor the typical active pages engine (PHP, Perl, ASP, Python). . KLone does everything, and does it fast and small. . KLone blends the HTTP/S server application together with its content and configuration into a single executable file. The site developer writes his/her dynamic pages in C/C++ (in usual scripting style: <% /* code */ %>) and uses KLone to transform them into embeddable, compressed native code with the native C/C++ compiler. The result is then linked to the HTTP/S server skeleton to obtain one single, ROM-able, binary file. This means that he/she can get: - easy, complete and unfiltered interaction with the host operating system - dynamic pages in native compiled code, which in turn implies - fast execution and - small overall application footprint - all of this without giving up the common functionality of web application frameworks such as sessions, parsing of form variables, cookies, etc -- 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.15.6 Locale: LANG=C, LC_CTYPE=fi_FI (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#366900: ITP: asterisk-prompt-es-co -- Colombian Spanish voice prompts for the Asterisk PBX
Hi Jerome, Am Freitag, den 12.05.2006, 11:11 +0200 schrieb Jerome Warnier: > Le jeudi 11 mai 2006 à 18:33 -0500, Santiago Ruano Rincón a écrit : > > Package: wnpp > > Severity: wishlist > > Owner: "Santiago Ruano Rincón" <[EMAIL PROTECTED]> > > * Package name: asterisk-prompt-es-co > You should probably join the pkg-voip-maintainers team instead of > packaging it on your own. I put their mailing-list in copy of this mail. Well, just for the record, Santiago is already a member of pkg-voip. I've just updated Santiago's account in alioth. He was already joined as santiago-guest. Now that he's officially become DD, all that needed adjustment was the reference to his new account name. Thus, I'm pretty sure that he'll maintain this new pack in pkg-voip. Thanks for your help nevertheless. ;) -- Best regards, Kilian signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#367007: ITP: libnet-z3950-zoom-perl -- Perl extension implementing the ZOOM API for Information Retrieval via Z39.50
Package: wnpp Severity: wishlist Owner: gregor herrmann <[EMAIL PROTECTED]> * Package name: libnet-z3950-zoom-perl Version : 1.08 Upstream Author : Mike Taylor <[EMAIL PROTECTED]> * URL : http://search.cpan.org/~mirk/Net-Z3950-ZOOM/lib/Net/Z3950/ZOOM.pm * License : Same as Perl, i.e. GPL or Artistic Licence Programming Lang: Perl Description : Perl extension implementing the ZOOM API for Information Retrieval via Z39.50 This module provides a nice, Perlish implementation of the ZOOM Abstract API described and documented at http://zoom.z3950.org/api/ . The ZOOM module is implemented as a set of thin classes on top of the non-OO functions provided by this distribution's Net::Z3950::ZOOM module, which in turn is a thin layer on top of the ZOOM-C code supplied as part of Index Data's YAZ Toolkit. Because ZOOM-C is also the underlying code that implements ZOOM bindings in C++, Visual Basic, Scheme, Ruby, .NET (including C#) and other languages, this Perl module works compatibly with those other implementations. (Of course, the point of a public API such as ZOOM is that all implementations should be compatible anyway; but knowing that the same code is running is reassuring.) . Homepage: http://search.cpan.org/~mirk/Net-Z3950-ZOOM/lib/Net/Z3950/ZOOM.pm Additional comments: * libnet-z3950-zoom-perl is the "successor" of libnet-z3950-perl. * libnet-z3950-zoom-perl currently FTBFS on Debian because it depends on (lib)yaz(-dev) >= 2.1.11, and unfortunately only 2.1.8 is in Debian; the current upstream version is 2.1.18; cf. #359265 gregor -- .''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4 : :' : debian: the universal operating system - http://www.debian.org/ `. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/ `-NP: Josh With: Did you read that letter signature.asc Description: Digital signature
Re: Possible transition to GCC 4.1 for etch: coordinated NMUs
* Martin Michlmayr <[EMAIL PROTECTED]> [2006-05-12 18:07]: > I have filed the following meta bug to keep track of GCC 4.1 build > failures in packages: #366820 As it turns out, bug blockers currently don't display information about the package those bugs are in and what their status is (e.g. if there's a patch already). Brian M. Carlson has kindly created a user tag (ftbfs-4.1. user [EMAIL PROTECTED]) which we can use: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-4.1;[EMAIL PROTECTED] -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Possible transition to GCC 4.1 for etch: coordinated NMUs
Martin Michlmayr <[EMAIL PROTECTED]> writes: > As it turns out, bug blockers currently don't display information > about the package those bugs are in and what their status is (e.g. if > there's a patch already). But this could be added. It would be a nice feature to request. (Hint hint) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Possible transition to GCC 4.1 for etch: coordinated NMUs
* Thomas Bushnell BSG <[EMAIL PROTECTED]> [2006-05-12 15:01]: > > As it turns out, bug blockers currently don't display information > > about the package those bugs are in and what their status is (e.g. if > > there's a patch already). > > But this could be added. It would be a nice feature to request. > (Hint hint) I didn't mention that I've already filed a wishlist bug. ;-) #367021 -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367028: ITP: cpulimit -- limits the cpu usage of a process
Package: wnpp Severity: wishlist Owner: gregor herrmann <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: cpulimit Version : 1.1 Upstream Author : Angelo Marletta <[EMAIL PROTECTED]> * URL : http://marlon80.interfree.it/cpulimit/ * License : LGPL Programming Lang: C Description : limits the cpu usage of a process cpulimit is a simple program that attempts to limit the cpu usage of a process (expressed in percentage, not in cpu time). This is useful to control batch jobs, when you don't want then to eat too much cpu. It does not act on the nice value or other priority stuff, but on the real cpu usage. Besides it is able to adapt itself to the overall system load, dynamically and quickly. . Homepage: http://marlon80.interfree.it/cpulimit/ gregor - -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'experimental'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.200605061601 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEZQUkOzKYnQDzz+QRAm20AKDcV1+xXzE3axQ0j/TwoRun9v249ACfXJlu P700h5S7IdV+tRzjpLj5xL8= =UNTB -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#367028: ITP: cpulimit -- limits the cpu usage of a process
On Fri, 2006-05-12 at 23:59 +0200, gregor herrmann wrote: [snip] > Description : limits the cpu usage of a process > > cpulimit is a simple program that attempts to limit the cpu usage of a > process (expressed in percentage, not in cpu time). This is useful to > control batch jobs, when you don't want then to eat too much cpu. It does not > act on the nice value or other priority stuff, but on the real cpu usage. > Besides it is able to adapt itself to the overall system load, dynamically > and quickly. > . > Homepage: http://marlon80.interfree.it/cpulimit/ I thought nice was supposed to handle these kinds of things, and that a busy CPU is a *good* thing. What Linux needs are batch queues. (Anyone who has used OpenVMS or MVS-z/OS knows what I'm talking about.) Obviously, though, that's a way OT discussion. -- - Ron Johnson, Jr. Jefferson, LA USA Peace Thru Superior Firepower -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#367028: ITP: cpulimit -- limits the cpu usage of a process
On Fri, May 12, 2006 at 05:34:23PM -0500, Ron Johnson wrote: > > Description : limits the cpu usage of a process > > cpulimit is a simple program that attempts to limit the cpu usage of a > > process (expressed in percentage, not in cpu time). This is useful to > > control batch jobs, when you don't want then to eat too much cpu. It does > > not > > act on the nice value or other priority stuff, but on the real cpu usage. > I thought nice was supposed to handle these kinds of things, and > that a busy CPU is a *good* thing. On an otherwise idle box even a process (re-)niced to 19 uses all the CPU. That might be desirable often but in other cases (e.g. when CPU temperature is an issue) you might still want to say "assign this process only xy% of CPU resources". gregor -- .''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4 : :' : debian: the universal operating system - http://www.debian.org/ `. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/ `-NP: Django Reinhardt: Brazil signature.asc Description: Digital signature
Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes
On Fri, May 12, 2006 at 12:35:50PM +0200, Wouter Verhelst wrote: > On Thu, May 11, 2006 at 05:35:35PM +0200, Frank Küster wrote: > > Michael Banck <[EMAIL PROTECTED]> wrote: > > > Seconds, since when do we consider the GPL to be viral? > > > > Don't know about you, but the FSF does - it has created the LGPL because > > of this. > > Actually, they don't. They consider the GPL a perfectly valid license > for a library; That doesn't refute the statement that FSF considers the GPL viral. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#367028: ITP: cpulimit -- limits the cpu usage of a process
On Sat, May 13, 2006 at 12:47:31AM +0200, gregor herrmann wrote: > On an otherwise idle box even a process (re-)niced to 19 uses all the > CPU. That might be desirable often but in other cases (e.g. when > CPU temperature is an issue) you might still want to say "assign this > process only xy% of CPU resources". Linux's ``conservative'' scaling governor ignores nice'd processes for calculating the desired CPU speed. Do you have a case in mind where CPU scaling is insufficient? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#367028: ITP: cpulimit -- limits the cpu usage of a process
On Fri, May 12, 2006 at 07:31:56PM -0500, Matthew R. Dempsky wrote: > > On an otherwise idle box even a process (re-)niced to 19 uses all the > > CPU. That might be desirable often but in other cases (e.g. when > > CPU temperature is an issue) you might still want to say "assign this > > process only xy% of CPU resources". > Linux's ``conservative'' scaling governor ignores nice'd processes for > calculating the desired CPU speed. Do you have a case in mind where CPU > scaling is insufficient? CPU scaling TTBOMK * doesn't work for all CPUs; * is more complex than a single binary; * works on the CPU as a whole and not on single processes. IMO tuning the frequency of the CPU is something different than adjusting the CPU usage of a process. gregor -- .''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4 : :' : debian: the universal operating system - http://www.debian.org/ `. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/ `- signature.asc Description: Digital signature
Re: Testing security archive move
On Saturday 13 May 2006 04:49, Neil McGovern wrote: > The Debian testing security team is pleased to announce the integration > of the secure testing archive to http://security.debian.org Many congratulations to all involved. This is a great step forward. pgpFr8qClVXrr.pgp Description: PGP signature
Re: Getting rid of circular dependencies, stage 4
On Wednesday 10 May 2006 16:21, Daniel Schepler wrote: > Le Mardi 09 Mai 2006 22:49, Bill Allombert a écrit : > > Debian Qt/KDE Maintainers > > ... > > > libkcal2b > > libkdepim1a > > It looks like these two have circular dependencies because libkdepim > depends on libkcal, while a couple of the standard libkcal plugins > (namely kcal_kabc.so and kcal_remote.so) depend on libkdepim. I don't > see any easy way to disentangle these. At least three possibilities: (*) most systems probably have both installed anyway, so why not merge the packages? (Back to kdepim-libs...) (*) have libkcal2b only recommend libkdepim1a (*) split libkcal2b into the lib and a separate libkcal-plugins package. -- vbi -- Confession is good for the soul only in the sense that a tweed coat is good for dandruff. -- Peter de Vries pgpVy0xsMsgYg.pgp Description: PGP signature
