.publicidad para mail alta eficacia bajo precio fio
Consiga que sus ganancias crezcan al nivel nivel más alto Que su producto o servicio lo conozca todo Lima Cumplimos 12 años al servicio de las empresas peruanas y lo festejamos ofreciéndole grandes oportunidades Una enorme cantidad de clientes satisfechos nos respaldan Diseño del correo sin costo adicional Busque nuestra web en google como: "publicidad total peru" Consultas teléfono: 451 65 97 O contestando este correo Todo este texto le fue alcanzado gracias a los servicios de : empresa de difusión de boletines de comercio Lima Perú Dayana Idalgo telefono 451-65-97 // 7-64-18-15 avenida insurgentes 7 66 sn miguel solo es preciso escribirnos haciendo constar que no es de su agrado y su cuenta sera retirada -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aa1101c0d8e5483eae448de5214c3...@pc-3
Bug#585183: general: .deb packages open with Archive Manager by default, not Package Installer
On Wed, 09 Jun 2010 22:20:18 +0100 di wrote: > Package: general > Severity: normal > Tags: squeeze > > In GNOME the default open action for when double-clicking on a .deb > package is to open with Archive Manager, which then complains 'Could > not create the archive: Archive type not supported.' deb-gview supports viewing the contents of the .deb, it's just not the default (or a part of the default GNOME install) - it could be if people want that. > The context menu shows as the second option 'Open with GDebi Package > Installer', and I think it would be hard to argue against this being > a better default, especially seeing as archive manager can't > understand .debs itself from a clean install... I would argue against an installer being a suitable default - installing random .deb files downloaded from who knows where is not a good idea. The default should be to show what is in the .deb. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpop2LkKZ8Ag.pgp Description: PGP signature
maintainer rejected completing the UPG checks (was: test if primary group, with only implicit membership of the user?)
My perception was that the consensus reached was that we wanted umask relaxation to be safe. Bug#583970: pam_umask "usergroups": test if primary group, with only implicit membership of the user Closed on Sun, 6 Jun 2010 15:32:43 -0700: > I don't think this is a check that it makes sense to add to > pam_umask. This isn't part of the *definition* of user-private > groups, it's just a feature of the most common *implementation* of > UPG. IMHO the same holds true for the username and user-ID checks in place, they are not strictly required for an UPG implementation. If the group can be considered to be a private group (and be granted write permissions) is ultimately only determinable by the user looking at and knowing/trusting the members of his primary group. What distros do is, they add certain properties to UPGs to be able to recognize the UPGs that are set up by their tools. Completing the set of checks to match the set of properties of distro's UPG implementation increases the security of the common implementation of UPGs. It eliminats the cases of insecure umask relaxation! Because the set of checks is incomplete (does not cover the specific properties added) I'd even consider it a security relevant bug, not only a wishlist item. Even if the check would not be enabled by default upstream, Debian could (and according articulated security concerns, Debian probably should) enable it, because Debian's UPG implementation supports those UPG properties. (Well, at least the one that is checked with the above test. The UID==GID alignment will be fixed.) Cheers, Christian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100610134950.709a9...@smtp.tu-bs.de
Re: Parallellizing the boot in Debian Squeeze - ready for wider testing
[Stefano Zacchiroli] > If you are ready to monitor the issue closely, I don't see any > problem in switching the default now in unstable, see how it goes, > and then decide later on if revert back to the current default in > Squeeze time. The switch to parallel booting was done 2010-05-14 in unstable, and entered testing 2010-05-26. As far as I can see, it is holding up fairly well. These are the issues I am aware of that was exposed by the parallel booting: A race condition between nvidia drivers and kdm was made to trigger more often (#582550, #583312), wicd seem unable to do NFS mounts and set up the network correctly (#508289, #581586), and parallel booting fail completely with OpenVZ (#583562 fixed/worked around by todays sysvinit upload). I expect all of these to find some solution before Squeeze is released, but can not guarantee it, of course. There is also an issue with bootchart reporting a slower boot for some machines(#581907) , but I am starting to believe this is an artifact of how bootchart measure the boot time (as in stopping the clock too early in the non-parallel measurement), and not really a regression in real boot speed. What are the opinions on this? Should we continue with parallel booting, or go back to sequential boot for Squeeze? Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flocfj6l3w@login1.uio.no
Bug#585439: ITP: spring-roo -- lightweight and rapid Java application development tool
Package: wnpp Severity: wishlist Owner: Miguel Landaeta * Package name: spring-roo Version : 1.0.2.RELEASE Upstream Author : SpringSource Inc. * URL : http://www.springsource.org/roo * License : GPL-3 Programming Lang: Java Description : lightweight and rapid Java application development tool Spring Roo is an open source software tool that uses convention-over-configuration principles to provide rapid application development of Java-based enterprise software. The resulting applications use common Java technologies such as Spring Framework, Java Persistence API, Java Server Pages, Apache Maven and AspectJ among many other standards. Spring Roo's stated mission statement is to "fundamentally and sustainably improve Java developer productivity without compromising engineering integrity or flexibility". -- Miguel Landaeta, miguel at miguel.cc secure email with PGP 0x7D8967E9 available at http://keyserver.pgp.com/ "Faith means not wanting to know what is true." -- Nietzsche -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100610144034.ga3...@miguel.cc
Xen for Squeeze, 3.4 or 4.0
Hi folks I'm currently thinking about which version of Xen supporting in Squeeze. There are two possibilities: 3.4 and 4.0. 3.4 is currently in testing and unstable, 4.0 is in experimental. Xen 3.4 === Pros - Proofed to be stable Cons - NUMA-mode only opt-in, no infos about stability - Fails on several modern machines because of IO-APIC problems Xen 4.0 === Pros - NUMA - More tested with the Kernel in Squeeze Cons - Quite new My personal preference would be to go with 4.0. Bastian Cc debian-devel, as there was quite a few discussions about this matter in the last months. -- Peace was the way. -- Kirk, "The City on the Edge of Forever", stardate unknown -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100610155428.ga12...@wavehammer.waldi.eu.org
[RESENT] Re: Xen for Squeeze, 3.4 or 4.0
Whoops, wrong recipient. On Thu, Jun 10, 2010 at 05:54:28PM +0200, Bastian Blank wrote: > I'm currently thinking about which version of Xen supporting in Squeeze. > There are two possibilities: 3.4 and 4.0. 3.4 is currently in testing > and unstable, 4.0 is in experimental. > > Xen 3.4 > === > Pros > - Proofed to be stable > Cons > - NUMA-mode only opt-in, no infos about stability > - Fails on several modern machines because of IO-APIC problems > > Xen 4.0 > === > Pros > - NUMA > - More tested with the Kernel in Squeeze > Cons > - Quite new > > My personal preference would be to go with 4.0. > > Bastian > > Cc debian-devel, as there was quite a few discussions about this matter > in the last months. -- Vulcans worship peace above all. -- McCoy, "Return to Tomorrow", stardate 4768.3 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100610155858.ga13...@wavehammer.waldi.eu.org
Re: Xen for Squeeze, 3.4 or 4.0
Le jeudi 10 juin 2010 à 17:54 +0200, Bastian Blank a écrit : > Xen 4.0 > === > Pros > - NUMA > - More tested with the Kernel in Squeeze > Cons > - Quite new > > My personal preference would be to go with 4.0. Your description sounds like it will be a lot easier to support 4.0, so unless there is a known blocking issue with it, I tend to agree with you. -- .''`. Josselin Mouette : :' : `. `' “If you eat pasta without sauce, it is nothing `- short of communism.” -- Marie -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1276186702.20720.3.ca...@meh
ITP: libdata-formvalidator-constraints-datetime-perl -- D::FV constraints for dates and times
Package: wnpp Owner: Alan Haggai Alavi Severity: wishlist *** Please type your report below this line *** * Package name: libdata-formvalidator-constraints-datetime-perl Version : 1.11 Upstream Author : Michael Peters * URL : http://search.cpan.org/dist/Data-FormValidator- Constraints-DateTime/ * License : GPL, Artistic Programming Lang: Perl Description : D::FV constraints for dates and times This package provides constraint routines for Data::FormValidator for dealing with dates and times. It provides an easy mechanism for validating dates of any format (using strptime(3)) and transforming those dates (as long as you 'untaint' the fields) into valid DateTime objects, or into strings that would be properly formatted for various database engines. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) -- The difference makes the difference. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201006102158.44379.alanhag...@alanhaggai.org
Re: [RESENT] Re: Xen for Squeeze, 3.4 or 4.0
2010/6/10 Bastian Blank : >> My personal preference would be to go with 4.0. I completely agree. Probably more people will use pvops kernel with 4.0 instead 3.4, so hopefully it will be better tested. -- Łukasz Oleś -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktil0pdsnzzoxhz7h29vgchihvpovxqg5adshc...@mail.gmail.com
Re: A lot of pending packages
On Fri, 11 Jun 2010 06:01:27 +0800, Thomas Goirand wrote: > My 2nd suggestion is coming from the Maemo platform (the OS behind > the Nokia n900 that is Debian based). In Maemo, there is a "devel" > repository that includes apps that aren't necessarily in good shape. The > users know that fact when they are adding the repository which contains > packages that are not necessarily as tested, and wont complain. I'm not sure I like this idea. Although I also sometimes install "inoffical packages", when I look at the packages with RC bugs I'm constantly suprised about the amount of low-quality packages we already have in the archive (when poor lintian has to emit page after page of errors and warnings ...). I understand that this new archive area would be "non-offical", but still my fear is that users won't distinguish and those packages would be considered as "Debian packages" and might have the risk of shedding a bad light on Debian quality. Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe `-NP: Schmetterlinge: Der Schuß von hinten signature.asc Description: Digital signature
Re: PLS Add My ID - joes...@gmail.com
On Tue, Jun 8, 2010 at 3:58 PM, Joe Walter wrote: > Hi to All, > > Please add my mail-id for web design. > > My mail-id:* dedicatedwebservi...@gmail.com* > > -- > Thanks, > Joe Walter. > SEO Analyst >
Re: A lot of pending packages
Petter Reinholdtsen wrote: > My sponsoring preferences are available from > http://people.skolelinux.org/pere/debian-sponsoring.html >. To > make sure I have direct contact with the prospective package > maintainer and avoid a backlog of packages I should have sponsored, I > want to be contacted on IRC about sponsoring. So to me, > mentors.debian.net is a nice repository to find the source, and > uploading there is not the last step a future package maintainer need > to take to get her packages sponsored. > Hi, Before I write anything else: I only need to have my Debian accounts created and I'll be a DD. So, I am kind of seeing things with 2 different viewpoint at the same time: from my sponsoree and future DD. I got 2 suggestions to make about sponsoring. These are just raw ideas that I am sending, I'm not sure if they are good, but I just want to share what's in my mind. Feel free to comment and explain why I'm wrong. Maybe we could imagine a kind of survey that the sponsor would write, to tell how the new maintainer performed with his package, just right after it has been sponsored. That of course, be some added sponsor's work, but it could be kept small. My 2nd suggestion is coming from the Maemo platform (the OS behind the Nokia n900 that is Debian based). In Maemo, there is a "devel" repository that includes apps that aren't necessarily in good shape. The users know that fact when they are adding the repository which contains packages that are not necessarily as tested, and wont complain. I wonder if we could have such a repository in Debian, so that new maintainers would have their packages sent there. We would have to discuss what would be the rules to get from devel to SID. What I have in mind could be checks like: - the maintainer has been responsive for a period of time - the packages of the maintainer have been in good shape as well The issue really being the way the maintainer is reacting to issues, rather than the issues themselves. The advantage of this system would be that we wouldn't need so much check to have apps going to devel. We could even think about it as a big bazaar of ongoing work that would not need checks at all (apart of course, licensing, that would still need strong checks). This would prevent people from not being happy about sponsorship in SID. The devel repository could be said as NOT part of Debian, just like contrib and non-free. Now, combine the 2 ideas. If a (new) maintainer has X good sponsor surveys, then his package(s) would go from the devel repository to SID automatically (after a DD checks for it manually and agree on the decision), and he would gain the rights to have his packages go directly to SID when they get sponsored. Don't get me wrong, the idea is to have LESS checks on the sponsored packages, rather than too much, so that we would have a faster sponsoring process (new maintainers will be happy, sponsors too), while still maintaining intensive quality checks in SID / testing. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c1160b7.5050...@goirand.fr
Re: [Pkg-xen-devel] [RESENT] Re: Xen for Squeeze, 3.4 or 4.0
Łukasz Oleś wrote: > 2010/6/10 Bastian Blank : >>> My personal preference would be to go with 4.0. > > I completely agree. Probably more people will use pvops kernel with > 4.0 instead 3.4, so hopefully it will be better tested. Hi Bastian, I have been running Xen 4.0.0 on my laptop since you made the Debian package, and there wasn't a single glitch (apart maybe the hibernate function which I don't really care about). Using an old version of Xen that already receives less attention from upstream isn't a bright idea. I believe that 4.0.1 will soon be released, which has many fixes. There's lots of new interesting features in 4.x too (like blktap2, which I believe you could re-add in the Debian package as the issue with OpenSSL was only the md5 thing, I suppose you saw it). My vote goes for 4.0.x. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c117666.3090...@goirand.fr
Re: A lot of pending packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/10/2010 06:01 PM, Thomas Goirand wrote: > Petter Reinholdtsen wrote: > My 2nd suggestion is coming from the Maemo platform (the OS behind > the Nokia n900 that is Debian based). In Maemo, there is a "devel" > repository that includes apps that aren't necessarily in good shape. The > users know that fact when they are adding the repository which contains > packages that are not necessarily as tested, and wont complain. > Isn't this already called experimental? If not, how would it differ? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBCAAGBQJMEX+zAAoJEKj/C3qNthmTs2gP/At420Y2EMm80++NEPftTAy4 HuRdWwIpKQ7diwWKkqeSsYVSFtFA52MAYn/Us+nTE/M7IYVf5gxjiwuL4JClFAxW /IjZ3lhd6jnYmAUVWhIWpxg5WJhjkMwDxIsjBdIbeAgUD7OMI38VaXuwOh1hGzo0 x5RiY3/jiiVKrZdb07uqGigvPuF8B2lNP0c5zePHeNl/Syt9uA4GO/wrzCLsZz1x O2Vs2ng9N5pxWTLw2T61cRC9dynEhZeqQlhbqVaSIuw7xCTJQPh1L4/awVXHXp60 /Q2oc2pMjfAFtI/noAqPbhH+tWeRq1P2+JePEopRkVT0KZA4o8qDo0PrXH4am5xq CSczIY2Hq3sc/ZT3eEnB1LflT3Tj2vJYjowo2XG5Ua2nvcEru9M49kiQlLYXCLj0 wc/fFAXc6+VPHEUGdBk417dYPbipH7WKPkleyglv9DJDxRljIg1LYVVQZyQ9XDCo b05b5Rh/Kyq0JN0G1aUF4roOOGYoTTLPSbkheH5OO6BhhcOfUUZKO4mA8hcm4gxQ v45cflqyHJHE5UY2sIE3WpMYWC2fVuM+NQAk6Vlk3bUh43EPtHqLE8VwVZEAiKDz /baPfEEFohz2bf0q8lfrE+rdFFEwQz8P/CajGf3xs45bLTMdU0ZlAlMLAii4Bzrc IV/FeK0utzNYrEHLDsEm =IiwS -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c117fb8.10...@gmail.com
Work-needing packages report for Jun 11, 2010
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 627 (new: 3) Total number of packages offered up for adoption: 132 (new: 6) Total number of packages requested help for: 65 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: offlineimap (#585035), orphaned 2 days ago Description: IMAP/Maildir synchronization and reader support Installations reported by Popcon: 561 timidity (#585039), orphaned 2 days ago Description: Software sound renderer (MIDI sequencer, MOD player) Reverse Depends: exult solfege songwrite timidity-daemon timidity-el timidity-interfaces-extra Installations reported by Popcon: 4807 webcalendar (#585088), orphaned yesterday Description: PHP-Based multi-user calendar Installations reported by Popcon: 122 624 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: autounit (#585423), offered today Description: C unit testing framework interfacing well with autotools Reverse Depends: libautounit-dev Installations reported by Popcon: 18 bookmarkbridge (#585421), offered today Description: tool to synchronize bookmarks between browsers Installations reported by Popcon: 149 gtimelog (#585145), offered yesterday Description: minimal timelogging system Installations reported by Popcon: 111 pstoedit (#585060), offered 2 days ago Description: PostScript and PDF files to editable vector graphics converter Reverse Depends: autotrace libautotrace-dev libautotrace3 libpstoedit-dev pstoedit purifyeps Installations reported by Popcon: 13248 pstotext (#585061), offered 2 days ago Description: Extract text from PostScript and PDF files Reverse Depends: dhelp steam Installations reported by Popcon: 1364 scribes (#584529), offered 6 days ago Description: simple, slim and sleek, yet powerful text editor for GNOME Installations reported by Popcon: 140 126 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apt-cross (#540341), requested 307 days ago Description: retrieve, build and install libraries for cross-compiling Reverse Depends: apt-cross emdebian-crush Installations reported by Popcon: 341 apt-xapian-index (#567955), requested 129 days ago Description: maintenance tools for a Xapian index of Debian packages Reverse Depends: adept ept-cache fuss-launcher Installations reported by Popcon: 12084 ara (#450876), requested 942 days ago Description: utility for searching the Debian package database Installations reported by Popcon: 114 asymptote (#517342), requested 468 days ago Description: script-based vector graphics language inspired by MetaPost Installations reported by Popcon: 1305 athcool (#278442), requested 2053 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 144 boinc (#511243), requested 518 days ago Description: BOINC distributed computing Reverse Depends: boinc-app-milkyway boinc-app-seti boinc-dbg Installations reported by Popcon: 1608 chromium-browser (#583826), requested 11 days ago Description: Chromium browser Reverse Depends: chromium-browser chromium-browser-dbg chromium-browser-l10n gecko-mediaplayer sun-java6-plugin Installations reported by Popcon: 1266 cvs (#354176), requested 1568 days ago Description: Concurrent Versions System Reverse Depends: crossvc cvs-autoreleasedeb cvs-buildpackage cvs2cl cvs2html cvschangelogbuilder cvsconnect cvsd cvsps cvsservice (11 more omitted) Installations reported by Popcon: 24806 dctrl-tools (#448284), requested 957 days ago Description: Command-line tools to process Debian package information Reverse Depends: aptfs debian-goodies debtree dlocate haskell-devscripts javahelper libsbuild-perl linux-patch-debianlogo simple-cdd ubuntu-dev-tools Installations reported by Popcon: 13135 debtags (#567954), requested 129 days ago Description: Enables support for package tags Reverse Depends: debtags-edit goplay packagesearch Installations reported by Popcon: 2641 dietlibc (#544060), requested 286 days ago Description: diet
Re: [RESENT] Re: Xen for Squeeze, 3.4 or 4.0
On Fri, 11 Jun 2010, Bastian Blank wrote: > On Thu, Jun 10, 2010 at 05:54:28PM +0200, Bastian Blank wrote: > > I'm currently thinking about which version of Xen supporting in Squeeze. > > There are two possibilities: 3.4 and 4.0. 3.4 is currently in testing > > and unstable, 4.0 is in experimental. > > > > Xen 3.4 > > === > > Pros > > - Proofed to be stable Not on my machines it hasn't. One i386 server which ran Lenny/Xen for ages without problems (since before Lenny was released) is now running Xen 3.4 from Unstable and it's not going particularly well. The other day it was in a cycle of booting and crashing when loading 2.6.32, I booted 2.6.26 and then before the init scripts finished I rebooted with 2.6.32 and it worked. Different machines require different amounts of memory reserved for Dom0 for unknown reasons. A couple of other machines which according to the Xen web site have suitable CPUs won't boot the Xen kernels that are currently in Unstable. It just seems flakey to me. > > Cons > > - NUMA-mode only opt-in, no infos about stability > > - Fails on several modern machines because of IO-APIC problems It fails on plenty of i386 machines (P3 class) for me. > > Xen 4.0 > > === > > Pros > > - NUMA > > - More tested with the Kernel in Squeeze > > Cons > > - Quite new > > > > My personal preference would be to go with 4.0. Based on my experience with Xen I think that we should have both. Then if one doesn't work we can try the other. My impression of Xen stability is that trying two different versions and hoping that one will work is a good strategy for any given server. Bastian, thanks a lot for all your great work on this, it's very important to me and to lots of other people! But through no fault of anyone in the Debian project I expect that an ideal result of one version that works well for almost everyone can't be achieved. PS It would be nice if we could get Grub2 updated to boot Xen kernels. My SE Linux Play Machine is offline right now because I messed up the Grub2 configuration so badly that it won't even give me a boot menu. -- russ...@coker.com.au http://etbe.coker.com.au/ My Main Blog http://doc.coker.com.au/ My Documents Blog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201006111223.05183.russ...@coker.com.au
Bug#585498: ITP: libaudio-ecasound-perl -- Perl binding to the ecasound sampler, recorder, fx-processor
Package: wnpp Severity: wishlist Owner: jo...@pobox.com * Package name: libaudio-ecasound-perl Version : 0.93 Upstream Author : Brad Bowman * URL : http://search.cpan.org/dist/Audio-Ecasound * License : Artistic Programming Lang: Perl Description : Perl binding to the ecasound sampler, recorder, fx-processor Audio::Ecasound provides perl bindings to the ecasound control interface of the ecasound program. You can use perl to automate or interact with ecasound so you don't have to turn you back on the adoring masses packed into Wembly Stadium. Ecasound is a software package designed for multitrack audio processing. It can be used for audio playback, recording, format conversions, effects processing, mixing, as a LADSPA plugin host and JACK node. Version >= 2.2.X must be installed to use this package. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100611020012.11721.32042.report...@sprite
Re: [RESENT] Re: Xen for Squeeze, 3.4 or 4.0
Russell Coker wrote: > Based on my experience with Xen I think that we should have both. Then if > one > doesn't work we can try the other. I don't think having to do a double work is a good idea. > My impression of Xen stability is that trying two different versions and > hoping that one will work is a good strategy for any given server. Do you also hang garlic on the server, to bring good luck? COME ON... this is computer science here, not voodoo! You should test things, see what works best, and go with it. If you see bugs, try to remove them. > Bastian, thanks a lot for all your great work on this, it's very important to > me and to lots of other people! I agree. > But through no fault of anyone in the Debian project I expect that an ideal > result of one version that works well for almost everyone can't be achieved. I don't agree (see above). Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c11d1f5.3010...@goirand.fr
Re: [RESENT] Re: Xen for Squeeze, 3.4 or 4.0
[3.4 vs. 4.0 ...] > > Based on my experience with Xen I think that we should have both. Then if > one > doesn't work we can try the other. > > My impression of Xen stability is that trying two different versions and > hoping that one will work is a good strategy for any given server. > > Bastian, thanks a lot for all your great work on this, it's very important to > me and to lots of other people! > [...] I have no idea how much work that is, but I do agree that having both versions would be the optimal solution. Still, I completely understand that this likely is infeasible given limited man power - but thank you very much for nicely maintaining the Xen packages, I do truly enjoy using the packages in stable on our servers without a single glitch! Thanks a lot, Michael pgpgg3twMOIyS.pgp Description: PGP signature
RE: [Pkg-xen-devel] [RESENT] Re: Xen for Squeeze, 3.4 or 4.0
> > PS It would be nice if we could get Grub2 updated to boot Xen kernels. My SE > Linux Play Machine is offline right now because I messed up the Grub2 > configuration so badly that it won't even give me a boot menu. > I'm running grub from squeeze with a hand-compiled xen 4.0.1-rc. There are a few quirks with it (it eats the first parameter for each kernel/module) but that's workaroundable. It would be nice if it could automatically detect xen kernels when you update-grub it though... or maybe that's what you were asking? Adding a custom section to the .d directory works but is a bit messy. James -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aec6c66638c05b468b556ea548c1a77d01997...@trantor
Re: [RESENT] Re: Xen for Squeeze, 3.4 or 4.0
On Fri, 11 Jun 2010, Thomas Goirand wrote: > Russell Coker wrote: > > Based on my experience with Xen I think that we should have both. Then > > if one doesn't work we can try the other. > > I don't think having to do a double work is a good idea. I agree that doubling the work is generally a bad idea. If having two versions supported means that neither is supported properly then it makes sense to cut one - in which case I think we should drop 3.4 as it works badly enough for me that I can't imaging 4.0 being worse. But I suspect that leaving 3.4 in it's current state would be a reasonable option, it works well on two out of five systems I've tried it on and it doesn't fail badly on machine three. > > My impression of Xen stability is that trying two different versions and > > hoping that one will work is a good strategy for any given server. > > Do you also hang garlic on the server, to bring good luck? COME ON... > this is computer science here, not voodoo! You should test things, see > what works best, and go with it. If you see bugs, try to remove them. Sometimes you test two options and find that for some systems one works well and for other systems the other works well. Then if both options are available you can get most (maybe all) systems working well, but if one option isn't available then some systems don't work well. -- russ...@coker.com.au http://etbe.coker.com.au/ My Main Blog http://doc.coker.com.au/ My Documents Blog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201006111659.15101.russ...@coker.com.au
