Bug#561443: ITP: linuxsampler -- realtime audio sampler
Package: wnpp Severity: wishlist Owner: Alessio Treglia * Package name: linuxsampler Version : 1.0.0 Upstream Author : Christian Schoenebeck * URL : http://www.linuxsampler.org/ * License : GPL-2 Programming Lang: C++ Description : realtime audio sampler LinuxSampler is a work in progress. It's goal is to produce a free software audio sampler with professional grade features. . It offers disk streaming capability and supports the Gigasampler format which is currently considered to be the best sampler format in regards of possibilities and sound quality. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561448: libpam-alreadyloggedin: Fake sense of security?
Package: libpam-alreadyloggedin Version: 0.3-1 Severity: important Hello, I am seriously concerned by the fake sense of security that such tool provides (I must say that some other pam modules are scarry). For instance, using vlock and libpam-alreadyloggedin on the same machine provides the same level of security as a blank password, if not less. As of 2009, where most people use either XWindow/ssh/screen, I see little benefit using this tool (YMMV). Please, add appropriate warning to this package description and README. Thank you for your effort. Franklin BTW, It is recommended to submit an ITP bug before uploading a new package in the archive, so other DDs can provide feed-back. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ITA: dict-gcide
Hi Pablo, On Wednesday 16 Dec 2009 13:49:18 Pablo Duboue wrote: > > RS> Probably we just host it on alioth and let interested parties > contribute to RS> and use it. > > RS> Any suggestions on a different name ? Or should we just use the old one > ? > > What about GCIDE2? And what about merging in wiktionary? > Merging wiktionary would definitely be great. But that'd be a tough task. In fact, I am not sure if we should even maintain a fork. Maintaining it (as a hosted project) as upstream is going to be a herculean task. It will require a lot of effort, time and commitment to it. Also, I don't think I have the necessary skill set to maintain a project of this magnitude as upstream. I am a user for it but upstream maintenance is going to be a different thing. For the current database that it is, IMO NMUing it, as has been happening might be the best bet. This way we don't lose this software (and all the data it brings with it). But if there are many people with interest in it to maintain, I think we could set up a team and work together. Regards, Ritesh -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." signature.asc Description: This is a digitally signed message part.
Re: ITA: dict-gcide
On Thu, Dec 17, 2009 at 4:01 PM, Ritesh Raj Sarraf wrote:
> But if there are many people with interest in it to maintain, I think we could
> set up a team and work together.
Lets do it. I'm in.
(however, with having huge number of packages holding in my arm, I'll
be occasional uploader (until you become DD ;)) or bug-fixer. Fine?)
--
Cheers,
Kartik Mistry | 0xD1028C8D | IRC: kart_
Debian GNU/Linux Developer | Identica: @kartikm
Blogs: {ftbfs, kartikm}.wordpress.com
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: What is the best place for package meta-data ?
Le mercredi 16 décembre 2009 à 10:14 +0900, Charles Plessy a écrit : > Dear Guillem and Olivier, > > yes, I have been pointed DOAP (and PackageMap) on the debian-qa and > debian-mentors mailing lists. I have spent a couple of hours this week reading > things about “Semantic web” and related things. My conclusion is that the > languages for linking concepts that are formalised in RDF files (XML, Notation > 3, Turtle, N-triples, …), are too complex compared to simple YAML files. > However, if we consider the DOAP as a simple list of keywords on which to > standardise, then I can do my best to stick to them as far as possible. RDF+XML may be too complex and verbose and probably has many other aspects that can be criticized, but it is nevertheless a standard that's the only one so far that helps contruct the Semantic Web (unless using other forms of RDF, like RDFa)... so do whatever you want, but if you limit yourself to custom ad-hoc local formats, and don't use standards, you'll limit the potential reuse of what you did for so-far unexpected applications. It's up to you to eventually think beyond current needs, and then open the door for others to build on top of what you did, on the Semantic Web ;) Best regards, -- Olivier BERGER http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC Ingénieur Recherche - Dept INF Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561349: Processed: Re: Bug#561349: Login Credentials not honoured
reassign 561349 pam tags 561349 + unreproducible thanks On Donnerstag, 17. Dezember 2009, S.D.A. wrote: > Care to elaborate? Please attach the contents of /etc/pam* to this bug report. thanks, Holger signature.asc Description: This is a digitally signed message part.
Processed: Re: Bug#561349: Processed: Re: Bug#561349: Login Credentials not honoured
Processing commands for cont...@bugs.debian.org: > reassign 561349 pam Bug #561349 [general] otherr: login credentials aren't honoured Bug reassigned from package 'general' to 'pam'. > tags 561349 + unreproducible Bug #561349 [pam] otherr: login credentials aren't honoured Added tag(s) unreproducible. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dh_config_model_upgrade: package upgrade with Config::Model
On Wednesday 16 December 2009 17:40:55 Neil Williams wrote:
> No. The package should simply exit cleanly with a successful return
> value if perl does not exist, letting everything else proceed as before.
> The postinst itself needs to check - that way, Emdebian doesn't have to
> patch every package using dh_config_model.
Ok. Here's the new postinst snippet injected by dh_config_model_upgrade:
# In case of error (error in configuration file or model bug), the
# configuration file is left as is.
# testing perl is required to avoid problem in embedded environments
if [[ -e /usr/bin/perl ]]
then
echo "config-edit is upgrading %PACKAGE% configuration with model
%MODEL%."
config-edit -model %MODEL% -ui none -save %OPTION% || \
echo "WARNING: upgrade with config-edit failed: Run 'config-edit -model
%MODEL% -force %OPTION%' and save the configuration."
fi
Does this fit the bill ?
> An alternative is to make dh_config_model* into a no-op if a build
> environment variable is set. DEB_BUILD_OPTIONS="noconfigmodel" or
> something. With this set, it has to be entirely equivalent to
> dh_config_model not appearing in debian/rules at all.
Ok. Unless somebeody complains, I will add this at the beginning of
dh_config_model_upgrade:
if ($ENV{DEB_BUILD_OPTIONS} =~ /noconfigmodel/) {
warn "dh_config_model_upgrade: DEB_BUILD_OPTIONS specifies
'noconfigmodel',
exiting ...\n";
exit;
}
> It would be so much better if this whole implementation was in C - as
> long as nothing in the config model tried to execute the cross-built
> executable on the build system. Then the ability to disable it via a
> build option would be truly orthogonal to the actual issue of whether
> perl exists.
Well, a C implementation of the core part of Config::Model is possible, but it
would take a while to create. I don't have the bandwidth for this.
All the best
Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: SpamAssassin is run on Alioth, but its results are ignored
Hello, 2009/12/17 Ben Hutchings : > On Thu, 2009-12-17 at 01:03 +0100, Carl Fürstenberg wrote: >> On Thu, Dec 17, 2009 at 00:12, Stephen Gran wrote: >> 3. I feel your attitude isn't well suited for an Debian developer. Try >> be more helpful instead of sounding like a dick. > > If this was the first bug report from jidanni, sure, but jidanni is a > regular bug reporter and really ought to have learned better by now. I had the ocasion to meet jidanni in one of his talks on bug reporting [1]. The paper of a bug reporter is not patching or anything else but point the problem. I think most of his reports are well written and provide enough hits to reproduce the issues, but why people have this *odd* feeling on him? I personally do not know, I can understand it, but he is not doing anything bad, just helping to improve the system/infrastructure, etc... Take in mind, that some people work offline or with modem lines, which retrieving lots of MB for source to patch it is quite a bit of time. I also feel hurt, when people that I personally know gets treated this way. Please, be kind! :-) [1] http://jidanni.org/comp/bug_reporter.html -- Héctor Orón "Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us." -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dh_config_model_upgrade: package upgrade with Config::Model
On Thu, Dec 17, 2009 at 8:24 AM, Dominique Dumont wrote: > On Wednesday 16 December 2009 17:40:55 Neil Williams wrote: >> No. The package should simply exit cleanly with a successful return >> value if perl does not exist, letting everything else proceed as before. >> The postinst itself needs to check - that way, Emdebian doesn't have to >> patch every package using dh_config_model. > > Ok. Here's the new postinst snippet injected by dh_config_model_upgrade: > > # In case of error (error in configuration file or model bug), the > # configuration file is left as is. > > # testing perl is required to avoid problem in embedded environments > if [[ -e /usr/bin/perl ]] '[[' for testing is a bashism. This should be if [ -e /usr/bin/perl ] or more accurately if [ -x /usr/bin/perl ] -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dh_config_model_upgrade: package upgrade with Config::Model
On Thursday 17 December 2009 14:24:48 Dominique Dumont wrote:
> Unless somebeody complains, I will add this at the beginning of
> dh_config_model_upgrade:
>
> if ($ENV{DEB_BUILD_OPTIONS} =~ /noconfigmodel/) {
> warn "dh_config_model_upgrade: DEB_BUILD_OPTIONS specifies
> 'noconfigmodel', exiting ...\n";
>exit;
> }
>
After reading (again) debhelper(7), I think it's better to exit silently if
DH_NO_ACT is set.
All the best
Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dh_config_model_upgrade: package upgrade with Config::Model
Will there be premade modules for the usual suspects? for example Apache, INI, perl-hash, JSON, basic shell source, debcontrol/rfc-2822, xml etc... Or is it meant that each package should reinvent the wheel/copy-paste? Also I think there should be a "simple mode", there the model is only defined for the general file format (as above), which can be activated with only a commandline argument to dh_config_config_model, without the need to write perl code/understand what a model is (not all devs can this kind of thingis). -- /Carl Fürstenberg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561485: RFP: libmoosex-simpleconfig-perl - A Moose role for setting attributes from a simple configfile
Package: wnpp Severity: wishlist * Package name: libmoosex-simpleconfig-perl Version : 0.04 Upstream Author : Brandon L. Black, * URL or Web page : http://search.cpan.org/dist/MooseX-SimpleConfig/ * License : Perl (Artistic and GPL) Description : MooseX::SimpleConfig - A Moose role for setting attributes from a simple configfile Depends on, and enhances, MooseX::ConfigFromFile, that already has a ITP bug open[1]. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543953 -- Guillaume Chambriat -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561487: ITP: yorick-optimpack -- optimization of large scale problems for the Yorick language
Package: wnpp Severity: wishlist Owner: Thibaut Paumard * Package name: yorick-optimpack Version : 1.3 Upstream Author : Éric Thiébaut * URL : http://www-obs.univ-lyon1.fr/labo/perso/eric.thiebaut/optimpack.html * License : GPL-2+ Programming Lang: C, Yorick Description : optimization of large scale problems for the Yorick language OptimPack is a portable C library which implements algorithms for optimization of large scale problems with bound constraints. Large scale means some million variables (e.g. pixel values) or more. . The most important algorithm is VMLM-B: a variable metric method with limited memory requirements and, possibly, bound constraints on the parameters. The algorithm is based on limited memory BFGS updates with Moré & Thuente inexact line search and gradient projection to account for bounds. . This package contains a Yorick plug-in based on OptimPack. I am the maintainer of 13 yorick-related packages already in main. OptimPack in required for another package I will ITP right away: yorick-mira. MiRA is used on a regular basis by several persons at my workplace. Best regards, Thibaut. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561490: ITP: yorick-mira -- optical intreferometry image reconstruction within Yorick
Package: wnpp Severity: wishlist Owner: Thibaut Paumard * Package name: yorick-mira Version : 0.9.9 Upstream Author : Éric Thiébaut * URL : http://www-obs.univ-lyon1.fr/labo/perso/eric.thiebaut/mira.html * License : GPL-2+ Programming Lang: Yorick Description : optical intreferometry image reconstruction within Yorick MiRA is an algorithm for image reconstruction from data provided by optical interferometers. It is written in the Yorick language and operated through the Yorick interpreter. . MiRA won the 2008' Interferometric Imaging Beauty Contest organized by International Astronomical Union (IAU) to compare the image synthesis algorithms designed for optical interferometry. In a nutshell, MiRA proceeds by direct minimization of a penalized likelihood. This penalty is the sum of two terms: a likelihood term (typically a χ2) which enforces agreement of the model with the data, plus a regularization term to account for priors. The priors are required to lever the many degeneracies due to the sparseness of the spatial frequency sampling. MiRA implements many different regularizations (quadratic or edge-preserving smoothness, total variation, maximum entropy, etc.) and let the user defines his own priors. The likelihood penalty is modular and designed to account for available data of any kind (complex visibilities, powerspectra and/or closure phase). One of the strength of MiRA is that it is purely based on an inverse problem approach and can therefore cope with incomplete data set; for instance, MiRA can build an image without any Fourier phase information. Input data must be in OI-FITS format. MiRA is used at my workplace. I am the maintainer of all 13 yorick-related source packages already in main. Best regards, Thibaut. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
devref and policy should agree on where to document tarball repacking
Package: developers-reference Version: 3.4.3 On Thu, Dec 10, 2009 at 04:45:33PM -0800, Russ Allbery wrote: > Charles Plessy writes: > > while checking the section 6.7.8.2 of the Developers reference > > (“Repackaged upstream source”) in the context on another thread on this > > list > > (http://lists.debian.org/msgid-search/d921045c2e3ae5ecfba088e9d82eb...@drazzib.com), > > I found the following : > > A repackaged .orig.tar.gz > > 1. should be documented in the resulting source package. Detailed > > information on how the repackaged source was obtained, and on how > > this can be reproduced should be provided in debian/copyright. It > > is also a good idea to provide a get-orig-source target in your > > debian/rules file that repeats the process, as described in the > > Policy Manual, Main building script: debian/rules. > > I have no strong opinion on the subject, but I think that either the > > Developers Reference should be modified to reflect current consensus and > > practice, or in contrary the section 6.7.8.2 of the Dev. Ref. argues for > > the incorporation of the removing information in the DEP-5 > > machine-readable format. > I personally still believe this information belongs in debian/copyright, > not in README.source. README.source might be appropriate if there are > detailed instructions required for how someone else would create a new > upstream source tarball, but debian/copyright is the appropriate location > to describe the provenance of the upstream tarball, which in my opinion > should include a human-readable description of transformations applied to > it. I have a slight, but not overwhelming, preference for having this in README.source rather than in debian/copyright; however, I think the more important issue here by far is that policy and the devref currently recommend including the same information in two different places, and this duplication is bad and inevitably leads to *both* locations being unreliable sources for this information. Moving this to a bug on the devref (per my personal preference); if consensus is that debian/copyright is the right place for this, then we can reassign it to policy, but one way or the other one of these documents should be changed to agree with the other. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: DEP-5: removed files
On Tue, Dec 08, 2009 at 09:56:29AM +0900, Charles Plessy wrote: > Given that the purpose of DEP-5 is to make information available to machines, > my feeling is also that there is no need for a new field, unless there is a > commitemnt to parse the license information about removed files in a > programmatic way. IMHO, *if* the conclusion is that this information belongs in debian/copyright, it should be incorporated in the DEP as a standardized field. In the meantime, we might want to work through the concern raised in an earlier thread about having the DEP explicitly permit free-form text in debian/copyright outside of its defined stanzas. > While duplication of information should be avoided, there are still a couple > of > justifications why the license of removed files could be summarised. First, > most get-orig-source targets in debian/rules let the removed files transit on > the user's machine. The "get-orig-source" target is not a user interface, it's a developer interface. I expect developers to know what they're about. > Similarly, some VCS that are available through ‘debcheckout’ also contain > a copy of the removed files in their upstream branch. For these cases, I > think that debian/copyright is a relevant place to declare the license of > the removed files, since they may actually be really there! I disagree. debian/copyright is not an interface for documenting the license status of arbitrary VCS branches, it's an interface for documenting the license status of Debian packages. Since any VCS branch that includes the debian/copyright should (assuming a rational universe) also *not* include the removed files in question, there should be no need to document the license of these files in debian/copyright - and any branch that does include those files should also include the upstream license information. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#561499: ITP: python-django-dajaxice -- agnostic and easy to use ajax library for django
Package: wnpp Severity: wishlist Owner: Angel Abad * Package name: python-django-dajaxice Version : 0.0.1 Upstream Author : Benito Jorge Bastida * URL : http://wiki.github.com/jorgebastida/dajaxice * License : BSD Programming Lang: Python Description : agnostic and easy to use ajax library for django Easy to use ajax library for django, all the presentation logic resides outside the views and doesn't require any JS Framework. Dajaxice uses the unobtrusive standard-compliant (W3C) XMLHttpRequest 1.0 object. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#561401: heimdal: FTBFS: Uses quilt in debian/rules, patches fail to apply.
On Wed, Dec 16, 2009 at 05:07:48PM -0800, Russ Allbery wrote: > > With older versions of dpkg-dev, if quilt isn't already available, > dpkg-source will use its own internal mechanism to apply the patch series, > and that internal method did not maintain the .pc directory. If the > patches are applied that way, quilt will not think that any patches are > applied and hence quilt pop will do nothing, but then quilt push will > fail to apply the patches because they've already been applied. > > Maybe that buildd has that older version of dpkg-dev? Yes, some run the one outside the chroot, which is the one from stable. I'm not sure if there is any intetion to fix dpkg-dev in stable. Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dh_config_model_upgrade: package upgrade with Config::Model
On Thu, 17 Dec 2009 14:24:48 +0100
Dominique Dumont wrote:
> On Wednesday 16 December 2009 17:40:55 Neil Williams wrote:
> > No. The package should simply exit cleanly with a successful return
> > value if perl does not exist, letting everything else proceed as
> > before. The postinst itself needs to check - that way, Emdebian
> > doesn't have to patch every package using dh_config_model.
>
> Ok. Here's the new postinst snippet injected by
> dh_config_model_upgrade:
>
> # In case of error (error in configuration file or model bug), the
> # configuration file is left as is.
>
> # testing perl is required to avoid problem in embedded environments
> if [[ -e /usr/bin/perl ]]
> then
> echo "config-edit is upgrading %PACKAGE% configuration with model
> %MODEL%."
> config-edit -model %MODEL% -ui none -save %OPTION% || \
> echo "WARNING: upgrade with config-edit failed: Run
> 'config-edit -model %MODEL% -force %OPTION%' and save the
> configuration." fi
>
> Does this fit the bill ?
With the later removal of the bashism, yes. Thanks.
> > An alternative is to make dh_config_model* into a no-op if a build
> > environment variable is set. DEB_BUILD_OPTIONS="noconfigmodel" or
> > something. With this set, it has to be entirely equivalent to
> > dh_config_model not appearing in debian/rules at all.
>
> On Thursday 17 December 2009 14:24:48 Dominique Dumont wrote:
> > Unless somebeody complains, I will add this at the beginning of
> > dh_config_model_upgrade:
> >
> > if ($ENV{DEB_BUILD_OPTIONS} =~ /noconfigmodel/) {
> > warn "dh_config_model_upgrade: DEB_BUILD_OPTIONS specifies
> > 'noconfigmodel', exiting ...\n";
> >exit;
> > }
> >
>
> After reading (again) debhelper(7), I think it's better to exit
> silently if DH_NO_ACT is set.
DH_NO_ACT still needs debian/rules to be modified or else all debhelper
routines would be disabled; we need an option that is specific to
dh_config_model without having to edit debian/rules.
I think DEB_BUILD_OPTIONS is still useful, whether or not
dh_config_model outputs the warning is neither here nor there for my
purposes.
> > It would be so much better if this whole implementation was in C -
> > as long as nothing in the config model tried to execute the
> > cross-built executable on the build system. Then the ability to
> > disable it via a build option would be truly orthogonal to the
> > actual issue of whether perl exists.
>
> Well, a C implementation of the core part of Config::Model is
> possible, but it would take a while to create. I don't have the
> bandwidth for this.
The debconf maintainers aren't the cdebconf maintainers; it's not
unusual for someone else to step up as long as the interface in the
perl version is suitable for porting to C. So the real issue is that
config::model tries hard to make an interface that can be implemented
in another language.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
pgpfqmJbHkYCG.pgp
Description: PGP signature
con nosotros tu disfrutas tu boda
¿Quieres tu Boda en la Playa? ODA Eventos y Bodaclick México te regalan la tornaboda En ODA Eventos te lo organizamos todo. ODA EVENTOS Cancún y Riviera Maya (998) 267 9783 odaeven...@didaskein.com Conoce aquí sobre TU TORNABODA DE REGALO http://clicks.skem1.com/v/?u=d83c9825f6fd48db896cbab4c833d369&g=949&c=4687&p=712f9f0803e38887423f8594d3397b55&t=2 -lugares -ceremonias -banquetes -fotografía, video y música -transportación terrestre y aérea -hospedaje -invitaciones, obsequios, flores -y todos los complementos BENEFICIOS DE PONER TODA LA ORGANIZACION EN NUESTRAS MANOS *Conocimiento *Garantía de éxito This message sent by: TuFolleto.com Cancún Q. Roo, Mexico 77500 Go to the following url to unsubscribe http://clicks.skem1.com/manage/?g=949&c=4687&p=712f9f0803e38887423f8594d3397b55&l=0 About this list: http://clicks.skem1.com/manage/about_list.php?g=949&c=4687&p=712f9f0803e38887423f8594d3397b55
Re: Bug#560863: ITP: lamson -- The Python SMTP Server
Heiko Schlittermann wrote: > FYI, from the FAQ of lamson: > http://lamsonproject.org/docs/faq.html > --- > Debian and CentOS are notorious for being dinosaurs. Both distributions of > Linux suffer from the false rationale that older software is more stable > and > secure. The reality is that the stability or security of a piece of > software is > not a function of its age, and in many cases the newer versions of > software > will typically fix many stability and performance problems. Despite this > fact, > these two variants of Linux are notorious for back-porting patches from > later > versions to older versions rather than just using the newer version. Sounds like one wants to check with the upstream what their plan to handle security issues is. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#560863: ITP: lamson -- The Python SMTP Server
On Tue, 2009-12-15 at 12:20 +0100, Heiko Schlittermann wrote: > Sebastian Otaegui (Sa 12 Dez 2009 22:26:56 CET): > > Package: wnpp > > > > * Package name: lamson > > FYI, from the FAQ of lamson: > http://lamsonproject.org/docs/faq.html > --- > Debian and CentOS are notorious for being dinosaurs. Both distributions of > Linux suffer from the false rationale that older software is more stable > and > secure. The reality is that the stability or security of a piece of > software is > not a function of its age, and in many cases the newer versions of > software > will typically fix many stability and performance problems. I often find it amazing how upstream don't seems to have a clue of what releasing a distribution is all about (i.e integration of components, testing, documentation, long term support, easy security update during that period, easy installation...). Organisations and end-users just want to install an application and then use it (i.e not spending their time upgrading it, adjusting the configuration, migrating data...). And we can't really blame them, most of these stuffs aren't their job anyway. Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Work-needing packages report for Dec 18, 2009
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: 658 (new: 14) Total number of packages offered up for adoption: 131 (new: 3) Total number of packages requested help for: 54 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: bygfoot (#560848), orphaned 5 days ago Description: soccer (football) manager game featuring the most important European leagues Installations reported by Popcon: 152 esmtp (#561302), orphaned yesterday Description: User configurable relay-only MTA Reverse Depends: esmtp-run Installations reported by Popcon: 210 gambit (#561254), orphaned 2 days ago Description: Game theory analysis software and tools Installations reported by Popcon: 53 gambit-doc (#561255), orphaned 2 days ago Description: documentation for gambit Installations reported by Popcon: 44 libfrontier-rpc-perl (#561129), orphaned 3 days ago Description: Perl module to implement RPC calls using XML requests Reverse Depends: cipux-rpc-tools libcipux-rpc-perl xml-rpc-api2txt Installations reported by Popcon: 195 mailreader (#561127), orphaned 3 days ago Description: Simple, but powerful WWW mail reader system Installations reported by Popcon: 28 openrpg (#560847), orphaned 5 days ago Description: client/server application to play RPG over the Internet Installations reported by Popcon: 91 pgn-extract (#561252), orphaned 2 days ago Description: Portable Game Notation (PGN) extractor Installations reported by Popcon: 51 sffview (#561202), orphaned 2 days ago Description: Structured Fax File (SFF) Viewer Installations reported by Popcon: 66 sphinx2 (#560849), orphaned 5 days ago Description: speech recognition utilities Reverse Depends: libsphinx2-dev sphinx2-bin Installations reported by Popcon: 273 tex-chess (#561256), orphaned 2 days ago Description: Chess fonts for TeX/LaTeX Installations reported by Popcon: 107 tex-skak (#561257), orphaned 2 days ago Description: Chess fonts for TeX/LaTeX Installations reported by Popcon: 64 xpaint (#560990), orphaned 4 days ago Description: simple paint program for X Installations reported by Popcon: 1239 xview (#560744), orphaned 6 days ago Description: XView UI toolkit library and client programs Reverse Depends: arb circlepack imaze-xview olwm workman xjove xview-clients xview-examples xviewg-dev xvmount Installations reported by Popcon: 439 644 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: mediawiki-metavidwiki (#560772), offered 5 days ago Description: A MediaWiki extension for associative temporal metadata Installations reported by Popcon: 57 mediawiki-semediawiki (#560773), offered 5 days ago Description: Semantic MediaWiki helps to organise and search MediaWiki content Reverse Depends: mediawiki-metavidwiki Installations reported by Popcon: 91 xdaliclock (#561233), offered 2 days ago Description: Melting digital clock Installations reported by Popcon: 727 128 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 132 days ago Description: retrieve, build and install libraries for cross-compiling Reverse Depends: apt-cross emdebian-buildsupport emdebian-qa emdebian-rootfs emdebian-tools libemdebian-tools-perl Installations reported by Popcon: 318 ara (#450876), requested 767 days ago Description: utility for searching the Debian package database Installations reported by Popcon: 112 asymptote (#517342), requested 293 days ago Description: script-based vector graphics language inspired by MetaPost Installations reported by Popcon: 1165 athcool (#278442), requested 1878 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 165 boinc (#511243), requested 343 days ago Description: BOINC distributed computing Reverse Depends: boinc-app-milkyway boinc-app-seti boinc-dbg Installations reported by Popcon: 1654 cvs (#354176), requested 1393 days ago Description: Concurrent Versions System Reverse Depends: crossvc cvs-autoreleasedeb cvs-buildpac
Help with uscan
Hi all, I'm trying to write a debian/watch file for an upstream package which has a version number 1.2.3-rc4. For the debian package I need to drop the dash from the version number to give a debian version number of 1.2.3rc4. Any clues on how to do this? If I just use: package-(.*).tar.gz uscan complains that it can't find the current version (1.2.3rc4) on the server. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Help with uscan
Erik de Castro Lopo wrote: > uscan complains that it can't find the current version (1.2.3rc4) on > the server. I'm currently doing: version=3 opts=filenamemangle=s/-// \ http://example.com/files/ package-(.*).tar.gz Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Help with uscan
El vie, 18-12-2009 a las 14:14 +1100, Erik de Castro Lopo escribió: > I'm trying to write a debian/watch file for an upstream package which > has a version number 1.2.3-rc4. For the debian package I need to drop > the dash from the version number to give a debian version number of > 1.2.3rc4. Hi Erik, You can use uversionmangle (see uscan manpage), but I think you should use 1.2.3~rc4 instead of 1.2.3rc4 because 1.2.3rc4 > 1.2.3 (see dpkg --compare-versions). Try something like: opts="uversionmangle=s/-rc/~rc/" http://site/package-(.*).tar.gz Regards, Ruben Molina signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Help with uscan
Erik de Castro Lopo writes: > Any clues on how to do this? If I just use: > >package-(.*).tar.gz For a start, you should replace the allows-empty match ‘(.*)’ with one that requires at least one character ‘(.+)’. That's orthogonal to the behaviour you're describing. though. > uscan complains that it can't find the current version (1.2.3rc4) on > the server. Can you give us the full URL so that we can test our proposals before posting them? -- \ “If we don't believe in freedom of expression for people we | `\ despise, we don't believe in it at all.” —Noam Chomsky, | _o__) 1992-11-25 | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Help with uscan
Ben Finney wrote: > For a start, you should replace the allows-empty match ‘(.*)’ with one > that requires at least one character ‘(.+)’. Noted. Thanks. > Can you give us the full URL so that we can test our proposals before > posting them? http://zhevny.com/specimen/files/specimen-0.5.2-rc3.tar.gz Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Help with uscan
Erik de Castro Lopo writes: > I'm trying to write a debian/watch file for an upstream package which > has a version number 1.2.3-rc4. For the debian package I need to drop > the dash from the version number Why do you need to drop the hyphen? A hyphen is perfectly valid in the upstream version string. > to give a debian version number of 1.2.3rc4. You're making a non-native package (i.e. making a Debian package of a work of general use independent of Debian). That version string is not a valid Debian version string for a non-native package. Instead, the Debian version string should be the upstream version string (mangled if necessary for the version comparison to work), followed by the Debian release component separate by a hyphen. Note that this does *not* conflict with hyphens in the upstream version string. What you'll probably need to do, if I can guess, is to mangle the upstream version string so their special-keyword games play properly with Debian's version comparison semantics. That is, I suspect you want ‘1.2.3-rc4’ to compare *earlier* than ‘1.2.3’, which it doesn't; hence mangling will be required. If you could post the actual URL to the upstream source location, more specific advice could be offered. -- \ “Truth would quickly cease to become stranger than fiction, | `\ once we got as used to it.” —Henry L. Mencken | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Help with uscan
Erik de Castro Lopo wrote: > Hi all, > > I'm trying to write a debian/watch file for an upstream package which > has a version number 1.2.3-rc4. For the debian package I need to drop > the dash from the version number to give a debian version number of > 1.2.3rc4. > > Any clues on how to do this? If I just use: > >package-(.*).tar.gz > > uscan complains that it can't find the current version (1.2.3rc4) on > the server. I have a solution. The upstream version number is 0.5.2-rc3 which is invalid for a non-native package and the current version of the package in debian, 0.5.2rc3, doesn't compare correctly. Therefore the debian package should be 0.5.2~rc3 (with a tilde) and the debian/watch file should be: version=3 opts=versionmangle=s/-rc/~rc/ \ http://zhevny.com/specimen/files/ specimen-(.+).tar.gz Thanks to all who responded, both here and on IRC. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Help with uscan
Erik de Castro Lopo writes: >http://zhevny.com/specimen/files/specimen-0.5.2-rc3.tar.gz Okay. The current list at http://zhevny.com/specimen/files/> shows the following tarball files: specimen-0.5.1.1.tar.gz specimen-0.5.1.tar.gz specimen-0.5.2-rc1.tar.gz specimen-0.5.2-rc2.tar.gz specimen-0.5.2-rc3.tar.gz I will work on the assumption that there will, in future, be a ‘specimen-0.5.2.tar.gz’ and that the intended meaning will be for that to be *later* than all the above. As it stands, though, ‘0.5.2’ will always compare earlier than ‘0.5.2ANYTHINGATALL’, the opposite of what your upstream apparently wants; which is why special keywords in version strings throw a spanner in the works. But the clever Debian folks have come up with a reasonably sane way to accomodate weird upstream version-comparison perversions. That is done with an exception to the comparisons, using the tilde ‘~’ (see Debian policy §5.6.12. for the details). So you'll need to mangle the upstream version string into a version string that will actually compare the way upstream expects it to: # debian/watch # Debian uscan file for ‘libspecimen’ package. # Manpage: uscan(1) # Compulsory line, this is a version 3 file. version=3 # Current version from Cheese Shop. opts="uversionmangle=s/-([a-z]+\d+)$/~$1/" \ http://zhevny.com/specimen/files/specimen-(.+).tar.gz Using that watch file, I get the following result: $ uscan --package libspecimen --upstream-version 0.5.1 --watchfile watch libspecimen: Newer version (0.5.2~rc3) available on remote site: http://zhevny.com/specimen/files/specimen-0.5.2-rc3.tar.gz (local version is 0.5.1) Not downloading as --package was used. Use --download to force downloading. Hope that helps. -- \ “Giving every man a vote has no more made men wise and free | `\ than Christianity has made them good.” —Henry L. Mencken | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Help with uscan
Erik de Castro Lopo writes: > The upstream version number is 0.5.2-rc3 which is invalid for a > non-native package No, it's fine for the upstream version string to contain a hyphen. See Debian policy §5.6.12., where the hyphen is explicitly listed as one of the valid characters in the upstream version string component. -- \ “Those who write software only for pay should go hurt some | `\ other field.” —Erik Naggum, in _gnu.misc.discuss_ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Help with uscan
Ben Finney writes: > # Current version from Cheese Shop. > opts="uversionmangle=s/-([a-z]+\d+)$/~$1/" \ > http://zhevny.com/specimen/files/specimen-(.+).tar.gz Erm. Ignore the comment line; clearly I cut-and-paste from one of my own packages and failed to edit the comment accordingly. -- \“When in doubt tell the truth. It will confound your enemies | `\ and astound your friends.” —Mark Twain, _Following the Equator_ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561556: ITP: lxde-icon-theme -- LXDE Standard icon theme
Package: wnpp Severity: wishlist Owner: "Andrew Lee (李健秋)" * Package name: lxde-icon-theme Version : 0.0.1 Upstream Author : Hong Jen Yee (PCMan) * URL : http://lxde.org * License : (LGPL) Programming Lang: (etc.) Description : LXDE Standard icon theme This package contains lxde-icon-theme which is the default icon theme for LXDE, also known as nuoveXT2 icon theme. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
