Bug#560279: ITP: libenv-path-perl -- Perl module implementing advanced operations on path variables
Package: wnpp Severity: wishlist Owner: Salvatore Bonaccorso * Package name: libenv-path-perl Version : 0.18 Upstream Author : David Boyce * URL : http://search.cpan.org/dist/Env-Path/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl module implementing advanced operations on path variables Env::Path presents an object-oriented interface to path variables, defined as that subclass of environment variables which name an ordered list of filesystem elements separated by a platform-standard separator. . Env::Path is for cases where you need to insert or remove interior path entries, strip redundancies, operate on a pathvar without having to know whether the current platform uses ":" or ";", operate on a pathvar which may have a different name on different platforms, etc. Note: This module is needed as dependency for 'cope'. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Can quilt delete files?
Peter Samuelson (10/12/2009): > Easier just to 'rm' ... but also, note that 'rename' will need some > sort of Build-depends: perl. Which sort? | -(cy...@talisker)-(~)-() | $ apt-cache show perl|egrep '^(Package|Build-Essential)' | Package: perl | Build-Essential: yes Mraw, KiBi. signature.asc Description: Digital signature
Re: Can quilt delete files?
[Daniel Leidert]
> Alternatively:
>
> build:
> find . -name "*.jar" -exec rename 's/$/.orig/' "{}" ";"
>
> clean:
> find . -name "*.jar.orig" -exec rename 's/\.orig$//' "{}" ";"
Easier just to 'rm' ... but also, note that 'rename' will need some
sort of Build-depends: perl.
And uh, while you're at it, may as well replace ";" with + above.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: licensecheck and debian/copyright
2009/12/9 Jérémy Lal : > Hi, > is there a way to automatically remove from licensecheck ouput all > the files already described in debian/copyright (when it's properly > formatted) ? > > Jérémy. > Doesn't know how to parse debian/copyright because it could be free-form. There isn't DEB-5 debian/copyright parser available. So this cannot be implemented in licensecheck yet. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
licensecheck and debian/copyright
Hi, is there a way to automatically remove from licensecheck ouput all the files already described in debian/copyright (when it's properly formatted) ? Jérémy. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#560254: ITP: python-django-shorturls -- A short URL handler for Django applications
Package: wnpp Severity: wishlist Owner: Janos Guljas * Package name: python-django-shorturls Version : 1.0.1 Upstream Author : Jacob Kaplan-Moss * URL : http://pypi.python.org/pypi/django-shorturls * License : BSD Programming Lang: Python Description : A short URL handler for Django applications A custom URL shortening application for Django, including easy rev=cannonical support. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#560255: ITP: nordugrid-arc-nox -- Grid Middleware of the NorduGrid
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: nordugrid-arc-nox Version : 1.0.0 * URL : http://www.nordugrid.org/ * License : Apache Programming Lang: C++ Description : Grid Middleware of the NorduGrid The NorduGrid is a collaboration aiming at development, maintenance and support of the free Grid middleware, known as the Advanced Resource Connector (ARC). . The Advanced Resource Connector (ARC) brings computing resources together across institutional boundaries. This concept is commonly referred to as a "computational grid". Historically, grids address the organisation of distributed storage of data and parallel computation, but arbitrary services are thinkable. . Just like the web, ARC has its roots in the IT infrastructure that was erected to analyse the experiments for high energy physics at CERN. The first release, ARC-0.x, was dependent on Globus, the current release keeps that compatibility but can also be used independently. . With ARC-nox, formerly ARC-1, the user gains flexibility with additional services and more supported platforms. The service developer notices that even for persistent functionality across the two major versions, what has been a script on the server side once, that was repeatedly started and ran through, this has now become a service. Those are only started once and can then be queried, which is far more efficient, far more responsive, and is no longer stateless but can observe changes of values over time. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#560216: Missing symbol HEIMDAL_KRB5_1.0
Hello Debian-devel! What do I do about this issue: On Wed, Dec 09, 2009 at 09:07:45PM +0100, Guido Günther wrote: > $ krb5-auth-dialog -A > krb5-auth-dialog: /usr/lib/libkrb5.so.25: version `HEIMDAL_KRB5_1.0' not > found (required by krb5-auth-dialog) If I look through the library with objdump, I see HEIMDAL_KRB5_2.0 defined not HEIMDAL_KRB5_1.0. My guess is that upstream have increased the version number of the library versioned symbols, but did not increase the soname number. Is this wrong? It feels wrong to me. Is this something I should be reporting back to upstream? Thanks. -- Brian May -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#560213: ITP: gtkhash -- GTK+ utility for computing checksums and more
Package: wnpp Severity: wishlist Owner: Alessio Treglia * Package name: gtkhash Version : 0.3.0 Upstream Author : Tristan Heaven * URL : http://gtkhash.sourceforge.net * License : GPL Programming Lang: C Description : GTK+ utility for computing checksums and more A GTK+ utility for computing message digests or checksums using the mhash library. . Currently supported hash functions include MD5, SHA1, SHA256, SHA512, RIPEMD, HAVAL, TIGER and WHIRLPOOL. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#560178: ITP: unicode-screensaver -- screensaver displaying unicode characters
Hi, Am Mittwoch, den 09.12.2009, 19:37 +0100 schrieb Andreas Tille: > On Wed, Dec 09, 2009 at 02:48:00PM +0100, Joachim Breitner wrote: > > It works with xscreensaver or gnome-screensaver. > > Did you found any trick how it works with xscreensaver? For myself the > greatest showstopper for a perfect screensaver (at least for showing off > to my non-Linux colleagues) is bug #237296. How does > unicode-screensaver work around this bug? I use fontconfig and freetype to render the characters. xscreensaver shuns extra dependencies like this, that’s why my hack will not enter the official distribution. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Should ucf be of priority required?
On Wed, Dec 09 2009, Patrick Schoenfeld wrote:
> Hi Manoj,
>
> On Mon, Dec 07, 2009 at 12:12:36PM -0600, Manoj Srivastava wrote:
>> > For me this assumes that data created during this task belongs to
>> > the package that requested the creation of the data in the first
>> > place.
>>
>> That breaks abstraction and encapsulation.
>
> I'm not sure if I share that view point. The point is to provide
> a certain interface to a different application to store and access
> data whereas the using application does not have to take care of the
> internal structures and consistency of the data.
That would be fine if ucf did that: but it does not. You should
not look at ucf as something that provides an application an interface
to store stuff without having to worry about structure and
consistency. It his here to help your package ask questions about
whether or not the end user wants to use you configuration file, or
theirs, or something else.
> That doesn't mean that the data in question (generally) generally
> becomes a part that belongs to the interface provider. Consider a
> database for example. It is encapsulated in the sense, that its only
> public interface is a query language. But anyways the data stored in
> the database does not belong to the database. Or would you say it
> does? But still, you have a right point, in the matter that the
> database could say that a DROP-operation only removes the data from
> the working set, not from the history. For example if this is required
> for consistency reasons.
>
> I know that this comparison has its flaws, because in the ucf case
> the data in question is just a file registration and therefore more a
> state information as data.
The comparison is false because you start with a wrong premise:
that ucf is here to help your app store data in the first place. The
data storage is incidental to the primary operation, asking the user
questions. And the data is a cache: all it does is help optimize away
questions that need not be asked based on the enteries in the
registry. You can blow away the registry and still only pay the penalty
of ucf asking the user once again what they want to do with a
configuration file.
> BUT according to the manpage not purging the data from the ucf
> database has practical effects for the package, so its of high
> interest for the database that the purge operation happened.
Yes, and the man page says how you should do the purge
*assuming that ucfr is on the system*. If it is not, don't bother.
The common case usage is not when you decide to dump ucf before
the purge, in which case it is no longer so important since when you
remove ucf you render all data collected so far as untrustworthy.
> That leads to the point where I have to ask you about something
> in the manpage.
>
> Lets say I'd do the following:
> - Install a package that uses ucf
> - Remove the package
> - Remove ucf
> - Purge the package using ucf
> - Re-install the purged package (and therefore pull ucf in again)
>
> What would happen? The manpage says that running ucf purge in the
> postrm *is required* because otherwise a new installation wouldn't
> work properly ("no action is taken"). That would mean that in this
> case something would go wrong.
> Now I had a quick look at your maintainer scripts and noticed that you
> divert the old data away on installation. Would that mean that whats
> beeing said in the manpage is not true in the above stated case,
> because ucf starts with a new registry anyway?
Right. The man page does not mention every corner case, but the
software still does the right thing.
> Apart from this: If you always start with a new registry on
> installation how does that play together with packages that are
> removed, but not purged and reinstalled later on? E.g. they wouldn't
> be registered anymore although their modified configuration is still
> laying around?
Sure. And the worst case effect is that the user is asked a
question on next update. All the registry does is to optimize away some
questions the users have been asked before.
If the user removes and re-installs ucf, they get to answer the
questions again. That's what you get for dumping a precious, cute, and
useful package like ucf, only to realize the error of your ways and
have to reinstall it 'cause you can't live without it.
manoj
--
I develop for Linux for a living, I used to develop for DOS. Going from
DOS to Linux is like trading a glider for an F117. -- Lawrence Foard,
entr...@world.std.com
Manoj Srivastava
Re: Bug#560178: ITP: unicode-screensaver -- screensaver displaying unicode characters
On Wed, Dec 09, 2009 at 02:48:00PM +0100, Joachim Breitner wrote: > I'm about to upload this to Debian: > > * Package name: unicode-screensaver > Version : 0.1 > Upstream Author : Joachim Breitner > * URL : > http://www.joachim-breitner.de/projects#unicode-screensaver > * License : MIT/X > Programming Lang: C > Description : screensaver displaying unicode characters > > The unicode-screensaver is a simple screensaver application that repeatedly > randomly picks an unicode character and displays it in a very large font > size together with its unicode code point and the character name. > . > It works with xscreensaver or gnome-screensaver. Did you found any trick how it works with xscreensaver? For myself the greatest showstopper for a perfect screensaver (at least for showing off to my non-Linux colleagues) is bug #237296. How does unicode-screensaver work around this bug? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
Hi Manoj,
On Mon, Dec 07, 2009 at 12:12:36PM -0600, Manoj Srivastava wrote:
> > For me this assumes that data created during this task belongs to
> > the package that requested the creation of the data in the first
> > place.
>
> That breaks abstraction and encapsulation.
I'm not sure if I share that view point. The point is to provide
a certain interface to a different application to store and access
data whereas the using application does not have to take care of the
internal structures and consistency of the data.
That doesn't mean that the data in question (generally) generally
becomes a part that belongs to the interface provider. Consider a
database for example. It is encapsulated in the sense, that its only
public interface is a query language. But anyways the data stored
in the database does not belong to the database. Or would you say it
does? But still, you have a right point, in the matter that the database
could say that a DROP-operation only removes the data from the working
set, not from the history. For example if this is required for
consistency reasons.
I know that this comparison has its flaws, because in the ucf case
the data in question is just a file registration and therefore more a
state information as data. BUT according to the manpage not purging
the data from the ucf database has practical effects for the package,
so its of high interest for the database that the purge operation
happened.
> > And it includes providing an interface that does exactly what
> > is it told to do.
>
> Sorry. This is not the software paradigm you are looking for. In
> keeping with modular (and object oriented) design, ucf provides certain
> facilities. It keeps internal state, but that is opaque to the user.
Hm, yeah, probably you are (partly) right. ucf should be able to do what
it wants to do, as long as the promise of the interface is kept.
That means for ucf purge to remove the registered config file from the
working set, but if ucf wants to keep a history file containing the
information about that file it can do that.
> > For you the data belongs to ucf and it can do with it whatever it
> > wants to do. So if a postrm requested to purge the file from the
> > database it would also be okay, if ucf didn't do that.
>
> Nope. No other package gets to muck around with the internal
> structures and data for any utility, and that includes files hidden
> from the application. The API is provided for a purpose: use it, and do
> not break encapsulation by delving into internal details of the
> implementation.
Actually I consider that I argumented the wrong way, because I described
my problem by an effect and not the right one. You are right that
the internal details of how ucf stores the data are its own beer.
But the original question had nothing to do with that, although this
might have been implied.
That leads to the point where I have to ask you about something
in the manpage.
Lets say I'd do the following:
- Install a package that uses ucf
- Remove the package
- Remove ucf
- Purge the package using ucf
- Re-install the purged package (and therefore pull ucf in again)
What would happen? The manpage says that running ucf purge in the postrm
*is required* because otherwise a new installation wouldn't work
properly ("no action is taken"). That would mean that in this case
something would go wrong.
Now I had a quick look at your maintainer scripts and noticed that
you divert the old data away on installation. Would that mean that whats
beeing said in the manpage is not true in the above stated case, because
ucf starts with a new registry anyway?
Apart from this: If you always start with a new registry on installation
how does that play together with packages that are removed, but not
purged and reinstalled later on? E.g. they wouldn't be registered
anymore although their modified configuration is still laying around?
> > I won't go further trying to change what I think is wrong. You as the
> > ucf maintainer decided that collecting garbage is okay, because
> > its not garbage in your opinion. Most other people agreed to that or
> > didn't comment at all (including those persons who agree with me).
> > It doesn't matter anyway. Its been a corner case from the beginning,
> > a seldom one additionally. There is work on-going or at least planned
> > to merge ucf functionality into dpkg, which is the better solution
> > IMHO anyway and will probably fix my "problem".
>
> I was not aware that dpkg was going to expand and work with non
> conffiles: most of the work is for providing ucf-like handling of
> conffiles, not for configuration files, unless I am misreading
> something.
The dpkg roadmap [1] has a point "Extend conffile support, merge back
ucf", which is probably exactly that.
Best Regards,
Patrick
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@list
Re: Bug#559761: ITP: release -- provides information about the current releases
2009/12/9 Benjamin Drung : > Am Montag, den 07.12.2009, 09:03 +0100 schrieb Frank Lin PIAT: >> On Mon, 2009-12-07 at 00:14 +0100, Benjamin Drung wrote: >> > For Debian I need some informations: Until when were following >> > releases supported: buzz, rex, bo, hamm, slink, and potato? >> >> See http://wiki.debian.org/DebianReleases but I didn't/couldn't find the >> information for bo/rex/buzz. Anyone ? > > I found that page, too. The wikipedia page of Debian did not contain > more information. The proper source for this information is the Project History document, available online at http://www.debian.org/doc/manuals/project-history/ch-releases.en.html or in the debian-history package. Regards Javier -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#560178: ITP: unicode-screensaver -- screensaver displaying unicode characters
Package: wnpp Severity: wishlist Owner: Joachim Breitner -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I’m about to upload this to Debian: * Package name: unicode-screensaver Version : 0.1 Upstream Author : Joachim Breitner * URL : http://www.joachim-breitner.de/projects#unicode-screensaver * License : MIT/X Programming Lang: C Description : screensaver displaying unicode characters The unicode-screensaver is a simple screensaver application that repeatedly randomly picks an unicode character and displays it in a very large font size together with its unicode code point and the character name. . It works with xscreensaver or gnome-screensaver. Greetings, Joachim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAksfqo4ACgkQ9ijrk0dDIGxZnQCeNRaMHnz6oOjxCx/nCV/l8GvZ RnYAoKtBBdO48Jlc/0A1QOrI9B1Znmn6 =fCrJ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: defaulting to net.ipv6.bindv6only=1 for squeeze
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marco d'Itri wrote: > On Oct 24, Marco d'Itri wrote: >> I am proposing to set net.ipv6.bindv6only=1 by default for new >> installations > Done, let's see what breaks. :-) All of Java, it seems [1]. I'm very surprised this breakage was known in advance [2] but no bugs were filed (TTBOMK) before making this change. Hoping it can be fixed quickly. Cheers, Marcus [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560056 [2] http://lists.debian.org/debian-devel/2009/10/msg00573.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAksfkwsACgkQXjXn6TzcAQnXCgCgv9Xfp/lolYlCiHtdKPAd5EbQ RVcAoMc3QmI/7BckQzkWjn3UbLn2lAAG =J5Kj -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#559761: ITP: release -- provides information about the current releases
[Benjamin Drung] > * distro-release-info This seem to me like the best name of the suggested names. > Should i rename the scripts, too? I believe it would be best if the program name and the package name was the same. 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
Re: Bug#559802: CVE-2009-3736 local privilege escalation
Hi! On Tue, 2009-12-08 at 10:23:41 -0500, Michael Gilbert wrote: > > CVE-2009-3736[0]: > > | ltdl.c in libltdl in GNU Libtool 1.5.x, and 2.2.6 before 2.2.6b, > > | attempts to open a .la file in the current working directory, which > > | allows local users to gain privileges via a Trojan horse file. > > So, as i interpret the issue, the difference here is that libtool will > load any and all .la and .a file available on the LD_LOAD_LIBRARY path; > whereas python will load modules in the current directory only if they > are specifically called from the script. I think you mean LD_LIBRARY_PATH? And then I don't think that's a problem, if you add ‘.’ to LD_LIBRARY_PATH then you get to keep the pieces, in the same way if you add it to PATH. > I have just recently realized that LD_LOAD_LIBRARY has a relatively > safe default that does not include the current working directory. > Given this fact, I believe that the impact is rather limited (only > users that have modified that LD_LOAD_LIBRARY path are affected; and > i'm sure there are those who have done this, but it is a minor subset > of all debian users). If you are talking about LD_LIBRARY_PATH, then the default is for it to be empty. > Hence, I think that for any package embedding libtool, updates should > be pushed in stable-proposed-updates, rather than DSAs. As for libtool > itself, it may still make sense to issue a DSA. > > If there is concurrence on this assessment, I will send a message along > these lines to all of the bugs that I submitted. The following are the conditions needed to trigger either of the problematic cases, AFAIUI. Both problems only happen iff: * The caller requests to load a filename with a ‘.la’ extension (explicitly via lt_dlopen or implicitly via lt_dlopenext). * The filename does not have a directory component. For the ‘.la’ problem: * It will try to load the filename from the current directory iff the search in all the other paths didn't succeed. Which includes the paths from the dependency_libs field from the ‘.la’ file, LTDL_LIBRARY_PATH, LD_LIBRARY_PATH, and the system default paths from libltdl. So this will mostly only happen when the plugin is not installed, but the application requests it. For the ‘.a’ problem: * If the ‘.la’ file contains a non-empty “old_library” variable, then it will try to load the static library name from the current directory. So this will happen if the static version of the plugin was built. regards, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Can quilt delete files?
Put all the *jar files in the debian/clean file and they will be removed by the clean rule. You'll need debhelper compat 7 for this, though. Fabian -- Dipl.-Phys. Fabian Greffrath Ruhr-Universität Bochum Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT) Universitätsstr. 150, IB 3/134 D-44780 Bochum Telefon: +49 (0)234 / 32-26334 Fax: +49 (0)234 / 32-14227 E-Mail: greffr...@leat.ruhr-uni-bochum.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#560088: ITP: python-portio -- low level port I/O for Linux
Ron Johnson, le Wed 09 Dec 2009 01:28:26 -0600, a écrit : > On 2009-12-08 17:42, Dmitrijs Ledkovs wrote: > >2009/12/8 Ben Hutchings : > >I'm working on a parallel LCD interface with my custom PCB and I > >wanted interactive way to use parallel port. Found this decided to > >package it for myself and anyone else. Why using that when you have all ioctls to do the same portably in ? Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
