Re: intend to hijack GnuPG
On 2008-05-02, Stefano Zacchiroli <[EMAIL PROTECTED]> wrote: > > --zYM0uCDKw75PZbzx > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Fri, May 02, 2008 at 07:36:25PM +, Sune Vuorela wrote: >> Yes. But after I have seen Laszlo Boszormenyi bughandling in sqlite3, I >> think I actually would prefer current maintainance of gnupg. >>=20 >> 478980 and 478337 > > Whatever it might have happened on those 2 bug reports, which I haven't > read, I find really annoying your public blaming behaviour. Didn't this thread by the way more or less start with public blaming of current gnupg maintainer? > Either step > in and offer help or shut up. gnupg is a a bit too important package to be maintained by just anyone. I wouldn't have objected if it was unimportant leaf package - as all people have to start somewhere in learning packaging. This is why I am not shutting up. I hope most people will speak up publically in such cases. [1] - oh - and about offering to help: I was so far the one filed the "should this package be orphaned"-bug against gnupg. And I am planning to follow up on that. (476418) /Sune [1] I am not blaming people for introducing bugs. That can happen. The issue is how people handle it and tries to fix it up. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479152: ITP: core -- Jane Street Capital's alternative standard library for OCaml
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli <[EMAIL PROTECTED]> * Package name: core Version : 0.5.0 Upstream Author : Jane Street Holding <[EMAIL PROTECTED]> * URL : http://ocaml.janestcapital.com/?q=node/13 * License : LGPL Programming Lang: OCaml Description : Jane Street Capital's alternative standard library for OCaml Core is Jane Street Capital's alternative standard library for OCaml. . Core does a number of things: it provides tail recursive versions of non tail recursive functions in the standard library; changes the signature of many of the standard modules; includes generic serialization for most types, and adds some entirely new modules and new functionality within existing modules. . Beware: Core extends some functionality from OCaml's standard library, and outright changes or replaces other. The goal is not to preserve complete compatibility with the standard. The package is being worked on at git://git.debian.org/git/pkg-ocaml-maint/packages/core.git (already writable to debian-ocaml-maint contributors; help is welcome from them as well as from anyone interested). Cheers. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479160: ITP: sexplib310 -- automated conversions between OCaml-values and S-expressions
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli <[EMAIL PROTECTED]> * Package name: sexplib310 Version : 3.7.4 Upstream Author : Markus Mottl <[EMAIL PROTECTED]> * URL : http://www.janestcapital.com/ocaml/ * License : LGPL Programming Lang: OCaml Description : automated conversions between OCaml-values and S-expressions Sexplib library contains functionality for parsing and pretty-printing S-expressions. . Sexplib also contains a preprocessing module for Camlp4, which can be used to automatically generate code from type definitions for efficiently converting OCaml-values to S-expressions and vice versa. In combination with the parsing and pretty-printing functionality this frees users from having to write their own I/O-routines for the datastructures they define. Possible errors during automatic conversions from S-expressions to OCaml-values are reported in a very human-readable way. . Another module contained in Sexplib you to extract and replace sub-expressions in S-expressions. The package is being worked on at git://git.debian.org/git/pkg-ocaml-maint/packages/sexplib310.git (already writable to debian-ocaml-maint contributors; help is welcome from them as well as from anyone interested). Sexplib is a dependency for Core (see ITP #479152). -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#479152: ITP: core -- Jane Street Capital's alternative standard library for OCaml
On Sat, May 03, 2008 at 11:13:50AM +0200, Stefano Zacchiroli wrote: > * Package name: core This package name is a little bit too generic. Better one may be ocaml-core. > Version : 0.5.0 > Upstream Author : Jane Street Holding <[EMAIL PROTECTED]> This does not really look like a name of a human. > Description : Jane Street Capital's alternative standard library for > OCaml Is "Jane Street Capital" a generic term? Better remove it from the short description: "Alternative standard library for OCaml". >Core is Jane Street Capital's alternative standard library for OCaml. Duplication? Bastian -- Conquest is easy. Control is not. -- Kirk, "Mirror, Mirror", stardate unknown signature.asc Description: Digital signature
Bug#479161: ITP: sexplib -- Automatic S-Expression for OCaml
Package: wnpp Severity: wishlist Owner: Sylvain Le Gall <[EMAIL PROTECTED]> * Package name: sexplib Version : 3.7.4 Upstream Author : Jane Street Holding <[EMAIL PROTECTED]> * URL : http://ocaml.janestcapital.com/?q=node/13 * License : LGPL + linking exception Programming Lang: OCaml Description : Automatic S-Expression for OCaml This library contains functionality for parsing and pretty-printing S-expressions. In addition to that it contains an extremely useful preprocessing module for Camlp4, which can be used to automatically generate code from type definitions for efficiently converting OCaml-values to S-expressions and vice versa. This library allows you to extract and replace sub-expressions in S-expressions. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22.6-vs2.2.0.3-core2 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479162: ITP: type-conv -- Camlp4 preprocessor type conversions support for OCaml
Package: wnpp Severity: wishlist Owner: Sylvain Le Gall <[EMAIL PROTECTED]> * Package name: type-conv Version : 1.5.0 Upstream Author : Jane Street Holding <[EMAIL PROTECTED]> * URL : http://ocaml.janestcapital.com/?q=node/13 * License : LGPL + linking exception Programming Lang: OCaml Description : Camlp4 preprocessor type conversions support for OCaml This library factors out functionality needed by different preprocessors that generate code from type specifications, because this functionality cannot be duplicated without losing the ability to use these preprocessors simultaneously. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22.6-vs2.2.0.3-core2 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479164: ITP: bin-prot -- Binary protocol generator for OCaml
Package: wnpp Severity: wishlist Owner: Sylvain Le Gall <[EMAIL PROTECTED]> * Package name: bin-prot Version : 1.0.5 Upstream Author : Jane Street Holding <[EMAIL PROTECTED]> * URL : http://ocaml.janestcapital.com/?q=node/13 * License : LGPL + linking exception Programming Lang: OCaml Description : Binary protocol generator for OCaml This library contains functionality for reading and writing OCaml-values in a type-safe binary protocol. These functions provide a safe way of performing I/O on any extensionally defined data type. Functions, objects, and values whose type is bound through a polymorphic record field are not supported, but everything else is. . There is no support for cyclic or shared values and only little endian computer architectures are supported. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22.6-vs2.2.0.3-core2 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#479152: ITP: core -- Jane Street Capital's alternative standard library for OCaml
[ adding back the Cc to the bug report ] On Sat, May 03, 2008 at 12:01:17PM +0200, Bastian Blank wrote: > On Sat, May 03, 2008 at 11:13:50AM +0200, Stefano Zacchiroli wrote: > > * Package name: core > > This package name is a little bit too generic. Better one may be > ocaml-core. "core" is the name used by upstream for its tarballs, hence I would have liked to have it as the Debian source package name. However I agree with your concern and I will change it back. > > Version : 0.5.0 > > Upstream Author : Jane Street Holding <[EMAIL PROTECTED]> > This does not really look like a name of a human. Does it need to be? The libraries is developed by a company and the copyright is held by the company. Maybe I can in this specific case (as I've contacts within the company) discover who actually wrote the code, but in the general case it won't be possible. So I presume that setting the upstream author / copyright to a non-humans should be supported somehow. > > Description : Jane Street Capital's alternative standard library for > > OCaml > Is "Jane Street Capital" a generic term? Better remove it from the short > description: "Alternative standard library for OCaml". Nope, there have been in the past other projects like that in the OCaml community, this one is identified within the community via the company name. > >Core is Jane Street Capital's alternative standard library for OCaml. > Duplication? Nope: short vs long description. Or are you suggesting the first line of long is too similar to the whole short description? Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -<%>- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: intend to hijack GnuPG
On Sat, May 03, 2008 at 09:29:35AM +, Sune Vuorela wrote: > >> Yes. But after I have seen Laszlo Boszormenyi bughandling in sqlite3, I > >> think I actually would prefer current maintainance of gnupg. > > Whatever it might have happened on those 2 bug reports, which I haven't > > read, I find really annoying your public blaming behaviour. > Didn't this thread by the way more or less start with public blaming of > current gnupg maintainer? Not really (IMO). It started with facts on the state of a package and on the MIA status of its only maintainer. On the contrary you have been speculating on the future (in)ability of someone to maintain gpg. Anyhow, my post has probably been too rude and I'm sorry for that, but I really don't think that yours was the way to go. First you need to give Laszlo a chance, based on the fact that he started the hijack procedure, not somebody else. Then, if you think the work is too much for just him go and help. And quite frankly, starting as you did is probably not the good way to set up the ground for synergistic collaboration: it will just piss off people. Yeah, people -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -<%>- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: intend to hijack GnuPG
On 2008-05-03, Stefano Zacchiroli <[EMAIL PROTECTED]> wrote: > the MIA status of its only maintainer. On the contrary you have been > speculating on the future (in)ability of someone to maintain gpg. > Anyhow, my post has probably been too rude and I'm sorry for that, but I > really don't think that yours was the way to go. First you need to give > Laszlo a chance, based on the fact that he started the hijack procedure, > not somebody else. I probably could do a long reply here including questioning: - public requests of support should not be answered publically if unsupportive ? - should we take chances on core packages just to give people a chance? - the date for filing #476418 and the date of intend to hijack email But as I think I can only agree with zack in that we disagree, I think I will end it here. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problems for making kernel module
On Fri, 2008-05-02 at 09:22 +0900, 서청원 wrote: > I got this message during compiling module. > > > > Building modules, stage 2. > > MODPOST > > WARNING: "tasklist_lock" [ /Red/src/Red.ko] undefined! > > make[1]: Leaving directory `/usr/src/linux-headers-2.6.18-4-686' > > > > > > Actually, Red.ko had made but can not load the module due to the > unknown symbol (tasklist_lock). > > > > What’s the problem?? I can see the symbol is exported in the > linux-header-2.6.18-4-686/include/linux/sched.h. No, it has external linkage within the kernel proper. That's not the same thing as being exported. (But it probably shouldn't be mentioned in this header.) > I couldn’t understand why it is shown “undefined”?? > > > > Also during searching about this problem, I read this - for linux > kernel 2.6.18, the symbol does NOT export any more …. Is this right??? Right. The export was removed by this change: commit c59923a15c12d2b3597af913bf234a0ef264a38b Author: Christoph Hellwig <[EMAIL PROTECTED]> Date: Mon Jul 10 04:45:40 2006 -0700 [PATCH] remove the tasklist_lock export As announced half a year ago this patch will remove the tasklist_lock export. The previous two patches got rid of the remaining modular users. Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> which was merged between 2.6.17 and 2.6.18. > If it is, is there any way to use the symbol ‘tasklist_lock’? > There is my only guess, it is needed the license to use this symbol. Nope. This is the reason it was un-exported: Why: tasklist_lock protects the kernel internal task list. Modules have no business looking at it, and all instances in drivers have been due to use of too-lowlevel APIs. Having this symbol exported prevents moving to more scalable locking schemes for the task list. Ben. -- Ben Hutchings The most exhausting thing in life is being insincere. - Anne Morrow Lindberg signature.asc Description: This is a digitally signed message part
Re: Using sgid binaries to defend against LD_PRELOAD/ptrace()
On Wed, Apr 30, 2008 at 10:46:29AM +0200, Martin Pitt wrote: > Josselin Mouette [2008-04-30 10:17 +0200]: > > This looks indeed like a reasonable alternative if we don't get the > > noptrace group ; it would be easy to patch gksu/gnome-keyring/... with > > the same stuff. > > I agree, and give the other possible attack scenarios it doesn't make > much sense to throw a lot of effort (with noptrace group, etc.) at it. In that case I'm inclined to leave it alone since adding a new group to base-passwd really ought to involve converting it to debconf, and I haven't quite mustered the enthusiasm to take care of that yet. That said, if you decide you want to do it, having (say) a core PolicyKit package do 'addgroup --system noptrace' in its postinst would be fine as an interim measure; it doesn't *have* to be a global static group, and even if we eventually decide that we do want to turn it into one then that's not a problem. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
libqglviewer and two versions of Qt.
Hi, I maintain the libqglviewer library - OpenGL 3D viewer library based on Qt. Currently the library is linked against Qt3, but there are requests about libqglviewer with Qt4[1][2]. My question is: how long will Qt3 be available in Debian? I assume it will be available in lenny - if not, please correct me. So, I believe I need to provide two versions of libqglviewer - one linked with Qt3 and one with Qt4. I have some doubts about the issue and I'd be glad to hear your advice. 1. If there is a package with build-dependency on libqglviewer-dev how should the maintainer of the package be able to select which linking option (s)he choose? 2. Shall I provide two -dev packages, one providing .pc file for Qt3 linked library and one for Qt4? 3. Should the packages conflict with each other or not? 4. How should the packages (either -dev as shared libraries) be named? 5. Is there in Debian any other library suffering from similar problem? I'd like to take a look into used solution. If you noticed any others problems I have not though about, please let me know about them too. Best regards Artur PS. I'm subscribed to debian-devel but not to debian-qt-kde. If you are in doubt please Cc me, I'll deal with duplicates. [1] http://bugs.debian.org/471893 [2] http://bugs.debian.org/477387 -- ciekawe zderzenie kulturowe: w piździawicy in the middle of nowhere wyłania się z bieli pani dżokejka na koniu, byrdłoczerzy i eskadra treserów psów. Patrzą na siebie wszyscy w milczeniu i ze zdziwnieniem, jak można tak się męczyć dla tak głupiego hobby i odchodzą bez zrozumienia /emkaj/ signature.asc Description: Digital signature
Attention: /usr/share/file/magic{,.mime} removal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, file or rather libmagic1 ships its magic files in /usr/share/file/, namely this used to be: /usr/share/file/magic /usr/share/file/magic.mgc /usr/share/file/magic.mime /usr/share/file/magic.mime.mgc where as *.mgc are the binary files which are used by file/libmagic, and the others are the conlgomerated source files *for informational purposes only*. The sources have never been used by file for anything, and nobody shall do this either[0]. However, as of file version 4.24, the format of the sources has changed in order to compile the mime files from the magics automatically[1]. This means, that if you are using the magic or magic.mime files directly, your package will break anyway. Additionally since file 4.24, those packages that need/want to introduce new magics unknown to file (and for strange reasons are not considering it to include in the debian file package or upstream), can now do it by storing their magic snippeds in /usr/share/file/, and call file - --compile to produce the binary magics file (more on that at a later point). In unstable (and testing, soon), this has been avoided by an extra step of dumping a plain magic file in the old format and including the legacy copy of magic.mime from file version 4.23[2]. As soon as lenny is released, these will disappear and you're supposed to eventually convert your packages. Probably, I will also fill bug reports before lenny release to affected packages. Regards, Daniel [0] they *could* change format suddenly, only the library and its bindings are safe. [1] which is a big improvement and means, that the mime entries are no longer endlessly lacking behind to catch up with the magics. [2] this won't be updated to 4.24 though, so really don't use it anymore if you want to have recent magics. - -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIHF/h+C5cwEsrK54RAiCsAKCgINMg/u9PaufJ2+KHrEoW73qejgCcCG9C MmMzwiblFWKjQ9nyZbCtJXw= =UsQm -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libqglviewer and two versions of Qt.
Hi, > My question is: how long will Qt3 be available in Debian? > I assume it will be available in lenny - if not, please correct me. yes, Qt3 will be available in lenny. > So, I believe I need to provide two versions of libqglviewer - one linked > with Qt3 and one with Qt4. I have some doubts about the issue and I'd be > glad to hear your advice. > > 1. If there is a package with build-dependency on libqglviewer-dev how >should the maintainer of the package be able to select which linking >option (s)he choose? > 2. Shall I provide two -dev packages, one providing .pc file for Qt3 linked >library and one for Qt4? > 3. Should the packages conflict with each other or not? > 4. How should the packages (either -dev as shared libraries) be named? > 5. Is there in Debian any other library suffering from similar problem? I'd >like to take a look into used solution. you can take a look to libavahi, libpoppler or libqwt: libqwt5-qt3 - Qt3 widgets library for technical applications (runtime) libqwt5-qt3-dev - Qt3 widgets library for technical applications (development) libqwt5-qt4 - Qt4 widgets library for technical applications (runtime) libqwt5-qt4-dev - Qt4 widgets library for technical applications (development) we have appended qt version to each -dev/lib path packages to make them co-installable. cheers, Fathi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libqglviewer and two versions of Qt.
Hi, >> So, I believe I need to provide two versions of libqglviewer - one linked >> with Qt3 and one with Qt4. I have some doubts about the issue and I'd be >> glad to hear your advice. [...] > you can take a look to libavahi, libpoppler or libqwt: > > libqwt5-qt3 - Qt3 widgets library for technical applications (runtime) > libqwt5-qt3-dev - Qt3 widgets library for technical applications (development) > libqwt5-qt4 - Qt4 widgets library for technical applications (runtime) > libqwt5-qt4-dev - Qt4 widgets library for technical applications (development) > > we have appended qt version to each -dev/lib path packages to make them > co-installable. you should also mention that your include directories, library names and SONAMEs deviate from upstream, which might not be the best thing. I favor to support Qt 4.x without any SONAME changes etc. Depending on the particular situation of your package, you should decide whether you want to support Qt 3.x at all and whether the dev-package should be co-installable. In this case, you could change the library file name, SONAME etc. just for the Qt 3.x based packages. Joachim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Attention: /usr/share/file/magic{,.mime} removal
* Daniel Baumann <[EMAIL PROTECTED]> [080503 14:52]: > file or rather libmagic1 ships its magic files in /usr/share/file/, > namely this used to be: > > /usr/share/file/magic > /usr/share/file/magic.mgc > /usr/share/file/magic.mime > /usr/share/file/magic.mime.mgc > > where as *.mgc are the binary files which are used by file/libmagic, and > the others are the conlgomerated source files *for informational > purposes only*. The sources have never been used by file for anything, > and nobody shall do this either[0]. > [0] they *could* change format suddenly, only the library and its > bindings are safe. And where is this documented? (It has a documentation for the format, so I guess if that was supposed to be "writing" only, that was a canonical place to state it). > In unstable (and testing, soon), this has been avoided by an extra step > of dumping a plain magic file in the old format and including the legacy > copy of magic.mime from file version 4.23[2]. As soon as lenny is > released, these will disappear and you're supposed to eventually convert > your packages. Thanks for the warning and the compaitibility wrapper. But please also advertise that a bit wider. Just a mail to debian-devel is hardly enough when breaking an advertised interface. > Probably, I will also fill bug reports before lenny release to affected > packages. xfm is one of them. Perhaps I will find the time to file a list of whishlist bugs to extend libmagic so it can be used instead of parsing the files itself. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479198: ITP: libdbicx-testdatabase-perl -- Create a temporary database from a DBIx::Class::Schema
Package: wnpp Severity: wishlist Owner: Antony Gelberg <[EMAIL PROTECTED]> * Package name: libdbicx-testdatabase-perl Version : x.y.z Upstream Author : Name <[EMAIL PROTECTED]> * URL : http://www.example.org/ * License : (GPL, LGPL, BSD, MIT/X, etc.) Programming Lang: (C, C++, C#, Perl, Python, etc.) Description : Create a temporary database from a DBIx::Class::Schema This module creates a temporary SQLite database, deploys your DBIC schema, and then connects to it. This lets you easily test your DBIC schema. Since you have a fresh database for every test, you don't have to worry about cleaning up after your tests, ordering of tests affecting failure, etc. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
building a package two times
This is my first attempt at building inn2 two times from the same source with no duplication of debian/rules and of the debhelper config files. I do not like much the src_files stuff, but it's shorter than embedding lndir in the package like I did for udev and udev-udeb. Please let me know if you have ideas about how to make this simpler and/or more elegant. The complete package will be available in a few hours at http://www.bofh.it/~md/debian/ (please test if it you can, I do not have yet a news server running unstable). #!/usr/bin/make -f SHELL+= -e QUILT_STAMPFN := .stamp-patched include /usr/share/quilt/quilt.make D-std := $(CURDIR)/debian/inn2 D-lfs := $(CURDIR)/debian/inn2-lfs D = $(D-$*) B = $(CURDIR)/build-$* ## # this code deals with building a second inn2-lfs package from the same # source, but only on 32 bit architectures # Ideally new future 32 bit architectures should not bother with inn2-lfs # and just enable LFS by default. DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH) ifeq ($(DEB_HOST_ARCH),amd64) FLAVORS := std else ifeq ($(DEB_HOST_ARCH),ia64) FLAVORS := std else ifeq ($(DEB_HOST_ARCH),ppc64) FLAVORS := std else ifeq ($(DEB_HOST_ARCH),s390x) FLAVORS := std else FLAVORS := std lfs endif std_configure_flags = lfs_configure_flags = --enable-largefiles std_dh_clean_opts = -pinn2 -pinn2-inews -p inn2-dev lfs_dh_clean_opts = -pinn2-lfs std_dh_movefiles_opts = -pinn2 -pinn2-inews -p inn2-dev lfs_dh_movefiles_opts = -pinn2-lfs -pinn2-lfs-inews -p inn2-lfs-dev ifeq ($(FLAVORS),std) no_package := --no-package=inn2-lfs endif # the upstream source needs to be copied in the flavor-specific build dirs src_files := $(shell find . -maxdepth 1 \ -and -not -name . -and -not -name debian -and -not -name .pc \ -and -not -name 'build-*' -and -not -name '.stamp-*') ## DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) ifeq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE)) CROSS := --build $(DEB_HOST_GNU_TYPE) else CROSS := --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE) endif clean: unpatch rm -rf .stamp-* build-* [ ! -f Makefile.global ] || $(MAKE) distclean # delete the cloned debhelper configuration find debian -maxdepth 1 -type l -and -name 'inn2-lfs*' -print0 \ | xargs --no-run-if-empty -0 rm # delete packages which are not in control but are built anyway rm -rf debian/inn2-lfs-dev/ debian/inn2-lfs-inews/ dh_clean debian/po/templates.pot: debian/inn2.templates debconf-updatepo configure: $(addprefix .stamp-configure-, $(FLAVORS)) .stamp-configure-%: $(QUILT_STAMPFN) dh_testdir mkdir -p $B for dir in $(src_files); do cp -ldpR $$dir $B; done cd $B && \ _PATH_PERL=/usr/bin/perl \ ac_cv_path__PATH_AWK=awk \ ac_cv_path__PATH_EGREP=egrep \ ac_cv_path__PATH_SED=sed \ ac_cv_path__PATH_SORT=sort \ ac_cv_path__PATH_UUX=uux \ ac_cv_path_PATH_GPGV=/usr/bin/gpgv \ ac_cv_path_GETFTP=wget \ ac_cv_search_dbm_open=-ldb \ LDFLAGS="$(LDFLAGS) -Wl,--as-needed" \ ./configure \ --with-perl \ --enable-ipv6 \ --prefix=/usr/lib/news \ --mandir=/usr/share/man \ --includedir=/usr/include/inn \ --with-db-dir=/var/lib/news \ --with-etc-dir=/etc/news \ --with-filter-dir=/etc/news/filter \ --with-lib-dir=/usr/lib/news \ --with-log-dir=/var/log/news \ --with-run-dir=/var/run/news \ --with-spool-dir=/var/spool/news \ --with-tmp-dir=/var/spool/news/incoming/tmp \ --with-berkeleydb=/usr \ --with-kerberos=/usr \ --with-sendmail=/usr/sbin/sendmail \ $($*_configure_flags) $(CROSS) cd $B && \ mkdir ssl/ ssl/nnrpd/ && \ cd ssl/ && \ ln -s ../Makefile.global ../include ../storage ../history . && \ cd nnrpd/ && ln -s ../../nnrpd/* . touch $@ build: $(addprefix .stamp-build-, $(FLAVORS)) #debian/po/templates.pot .stamp-build-%: .stamp-configure-% dh_testdir cd $B && $(MAKE) cd $B/ssl/nnrpd/ && $(MAKE) \ SSLLIB='-L/usr/lib -lssl -lcrypto -ldl' SSLINC='-DHAVE_SSL=1' touch $@ install1-%: .stamp-build-% dh_testdir dh_testroot dh_clean -k $($*_dh_clean_opts) cd $B && $(MAKE) install DESTDIR=$D sh -e extra/dh_cloneconf inn2 inn2-lfs dh_movefiles $($*_dh_movefiles_opts) --sourcedir=$(subst $(CURDIR)/,,$D) # move back this one mv $D-dev/
Bug#479203: ITP: libclass-workflow-perl -- Lightweight workflow system
Package: wnpp Severity: wishlist Owner: Antony Gelberg <[EMAIL PROTECTED]> * Package name: libclass-workflow-perl Version : 0.09 Upstream Author : Yuval Kogman <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/Class-Workflow/ * License : GPL / Artistic Programming Lang: Perl Description : Lightweight workflow system Assists in building a state machine, with states and transitions between those states. It also provides for restrictions i.e. transitions that are not allowed. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
phpgedview (Web based genealogy) up for adoption
Hi, I've put my package phpgedview up for adoption. It's a web based genealogy program that can import, display and edit files in the gedcom standard. The package is in reasonable shape but I don't use it anymore. If you're interested in maintaining it, please take it. If you need help or sponsoring, I'm available for that. Thijs pgpNRCOUiOhkv.pgp Description: PGP signature
Re: being released from the hot seat
Le May 2, 2008 05:37:00 pm Andreas Barth, vous avez écrit : > Hi, > > good news for me that Marc 'HE' Brockschmidt didn't become DPL (though I > think he would've been a good DPL), so I managed to convince him to > become Release Manager. Of course, Luk stays Release Manager, and I will > also continue to help releasing Lenny as release wizard. Thanks for the announcement. Nevertheless, I reiterate my question about release team roles (http://lists.debian.org/debian-devel/2007/06/msg00900.html). If role changes are going to be announced on d-d-a, the difference between them should be well documented. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479206: ITP: libcurses-ui-poe-perl -- A subclass makes Curses::UI POE Friendly
Package: wnpp Severity: wishlist Owner: Antony Gelberg <[EMAIL PROTECTED]> * Package name: libcurses-ui-poe-perl Version : 0.11 Upstream Author : Scott McCoy <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/Curses-UI-POE/ * License : GPL / Artistic Programming Lang: Perl Description : A subclass makes Curses::UI POE Friendly This is a subclass for Curses::UI that enables it to work with POE. It is designed to simply slide over Curses::UI. Keeping the API the same and simply forcing Curses::UI to do all of its event handling via POE, This is a subclass for Curses::UI that enables it to work with POE. It is designed to simply slide over Curses::UI. Keeping the API the same and simply forcing Curses::UI to do all of its event handling via POE, instead of internal to itself. This allows you to use POE behind the scenes for things like networking clients, without Curses::UI breaking your programs' functionality. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: libdbicx-testdatabase-perl -- Create a temporary database from a DBIx::Class::Schema
Oops, I was a bit trigger-happy there. Corrected: * Package name: libdbicx-testdatabase-perl Version : 0.01 Upstream Author : Jonathan Rockway <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/DBICx-TestDatabase/ * License : GPL / Artistic Programming Lang: Perl Description : Create a temporary database from a DBIx::Class::Schema -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Attention: /usr/share/file/magic{,.mime} removal
In article <[EMAIL PROTECTED]> you wrote: > where as *.mgc are the binary files which are used by file/libmagic, and > the others are the conlgomerated source files *for informational > purposes only*. The sources have never been used by file for anything, > and nobody shall do this either[0]. So how can a sysadmin add rules? > However, as of file version 4.24, the format of the sources has changed > in order to compile the mime files from the magics automatically[1]. > This means, that if you are using the magic or magic.mime files > directly, your package will break anyway. So it looks to me that file is recreating the (cached) binary versions from the "information purpose only" source files, right? Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Attention: /usr/share/file/magic{,.mime} removal
Bernhard R. Link wrote: >> [0] they *could* change format suddenly, only the library and its >> bindings are safe. > > And where is this documented? (It has a documentation for the format, so > I guess if that was supposed to be "writing" only, that was a canonical > place to state it). what do you mean, documentation about the format, documentation about the recent change, or documentation about to not modify /usr/share/file/magic* directly? > Thanks for the warning and the compaitibility wrapper. But please also > advertise that a bit wider. Just a mail to debian-devel is hardly enough > when breaking an advertised interface. err, this is a first attention mail approximately 4 to 6 month before lenny release.. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Attention: /usr/share/file/magic{,.mime} removal
Bernd Eckenfels wrote:
> So how can a sysadmin add rules?
just like before, /etc/magic and /etc/magic.mime. this change is only
about packages wrongly using /usr/share/file/magic{,.mime}.
>> However, as of file version 4.24, the format of the sources has changed
>> in order to compile the mime files from the magics automatically[1].
>> This means, that if you are using the magic or magic.mime files
>> directly, your package will break anyway.
>
> So it looks to me that file is recreating the (cached) binary versions from
> the "information purpose only" source files, right?
no, /usr/share/file/magic.mgc and magic.mime.mgc are files own magics,
they are not supposed to be recompiled or touched by anyone after they
have been installed.
however, what i was writing about is that since version 4.24, file is
able to use other binary magic files *in addition*. if you are a package
wanting to ship your own magics or mimes, you compile them at
installation time into /usr/share/file/$package.mgc, which then will be
used by file automatically.
--
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email: [EMAIL PROTECTED]
Internet: http://people.panthera-systems.net/~daniel-baumann/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: building a package two times
On 03/05/2008, Marco d'Itri wrote: > DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH) > ifeq ($(DEB_HOST_ARCH),amd64) > FLAVORS := std > else ifeq ($(DEB_HOST_ARCH),ia64) > FLAVORS := std > else ifeq ($(DEB_HOST_ARCH),ppc64) > FLAVORS := std > else ifeq ($(DEB_HOST_ARCH),s390x) > FLAVORS := std > else > FLAVORS := std lfs > endif Since you have “FLAVORS := std” in every case but the last one, why not using findstring, so as to factorize a bit? Mraw, KiBi. pgpUT1PHDwphK.pgp Description: PGP signature
Re: Attention: /usr/share/file/magic{,.mime} removal
Daniel Baumann wrote: >> So it looks to me that file is recreating the (cached) binary versions from >> the "information purpose only" source files, right? > > no, /usr/share/file/magic.mgc and magic.mime.mgc are files own magics, > they are not supposed to be recompiled or touched by anyone after they > have been installed. > > however, what i was writing about is that since version 4.24, file is > able to use other binary magic files *in addition*. if you are a package > wanting to ship your own magics or mimes, you compile them at > installation time into /usr/share/file/$package.mgc, which then will be > used by file automatically. the 'automatic' was refering to the file sources. magics were created from magic/Magdir/* files; and completely independent of that, there was another list containing mime entries. Those should have been kept in sync, but oviously, the were not and constantly lacking behind. Now, the mime informations are in the same files in magic/Magdir/* as an addition of the file magic syntax, so mime entries can be created from the same sources as the magics automatically. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Attention: /usr/share/file/magic{,.mime} removal
* Daniel Baumann <[EMAIL PROTECTED]> [080503 18:39]: > Bernhard R. Link wrote: > >> [0] they *could* change format suddenly, only the library and its > >> bindings are safe. > > > > And where is this documented? (It has a documentation for the format, so > > I guess if that was supposed to be "writing" only, that was a canonical > > place to state it). > > what do you mean, documentation about the format, documentation about > the recent change, or documentation about to not modify > /usr/share/file/magic* directly? I mean there is no documentation that the file is not to be used directly, rather documentation about this file in a way suggesting it is supposed to be a public interface. (comparing this to the documentation of the libmagic library, the library looks more like a private interface in comparision) > > Thanks for the warning and the compaitibility wrapper. But please also > > advertise that a bit wider. Just a mail to debian-devel is hardly enough > > when breaking an advertised interface. > > err, this is a first attention mail approximately 4 to 6 month before > lenny release.. For upstream changes 4 to 6 months is a very short time (especially if it is not simple changes, but you are requesting to replace whole subsystems with some library, which will most likely mean to also have to get upstream changes in some prior unused library). Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479221: ITP: libautobox-perl -- Allows calling methods on builtin Perl types
Package: wnpp Severity: wishlist Owner: Antony Gelberg <[EMAIL PROTECTED]> * Package name: libautobox-perl Version : 2.23 Upstream Author : chocolateboy <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/autobox/ * License : GPL / Artistic Programming Lang: Perl Description : Allows calling methods on builtin Perl types The autobox pragma endows Perl's core data types with the capabilities of first-class objects. This allows methods to be called on ARRAY refs, HASH refs, CODE refs and raw scalars in exactly the same manner as blessed references. The autoboxing is transparent: boxed values are not blessed into their (user-defined) implementation class (unless the method elects to bestow such a blessing) - they simply use its methods as though they are. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#479206: ITP: libcurses-ui-poe-perl -- A subclass makes Curses::UI POE Friendly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/03/08 11:03, Antony Gelberg wrote: [snip] > > This is a subclass for Curses::UI that enables it to work with POE. It > is designed to simply slide over Curses::UI. Keeping the API the same > and simply forcing Curses::UI to do all of its event handling via > POE, This is a subclass for Curses::UI that enables it to work > with POE. It is designed to simply slide over Curses::UI. Keeping > the API the same and simply forcing Curses::UI to do all of its event > handling via POE, instead of internal to itself. This allows you to > use POE behind the scenes for things like networking clients, without > Curses::UI breaking your programs' functionality. I think you duplicated some sentences in the long description. - -- Ron Johnson, Jr. Jefferson LA USA We want... a Shrubbery!! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIHLcQS9HxQb37XmcRAsWZAKCgOpD34Yq93rQSvYGeWvT6wHEBLQCgggIj IoKwJPSNGkTe3J7T+gEV1Ok= =b2a3 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#479206: ITP: libcurses-ui-poe-perl -- A subclass makes Curses::UI POE Friendly
Ron Johnson wrote: On 05/03/08 11:03, Antony Gelberg wrote: [snip] This is a subclass for Curses::UI that enables it to work with POE. It is designed to simply slide over Curses::UI. Keeping the API the same and simply forcing Curses::UI to do all of its event handling via POE, This is a subclass for Curses::UI that enables it to work with POE. It is designed to simply slide over Curses::UI. Keeping the API the same and simply forcing Curses::UI to do all of its event handling via POE, instead of internal to itself. This allows you to use POE behind the scenes for things like networking clients, without Curses::UI breaking your programs' functionality. I think you duplicated some sentences in the long description. *sigh* Long day, not the first mistake I've made, thanks Ron. It should of course read: This is a subclass for Curses::UI that enables it to work with POE. It is designed to simply slide over Curses::UI. Keeping the API the same and simply forcing Curses::UI to do all of its event handling via POE, instead of internal to itself. This allows you to use POE behind the scenes for things like networking clients, without Curses::UI breaking your programs' functionality. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479233: ITP: r-base-core-ra -- Ra patch for just-in-time compilation of R code
Package: wnpp
Owner: Dirk Eddelbuettel <[EMAIL PROTECTED]>
Severity: wishlist
* Package name: r-base-core-ra
Version : 1.0.9
Upstream Author : Stephen Milborrow
* URL or Web page : http://www.milbo.users.sonic.net/ra
* License : GPL
Description : Ra patch for just-in-time compilation of R code
This is packaged as well. It need's Stephen 'jit' package which entered
Debian unstable earlier today as r-cran-jit. See the URL above for details.
I packaged this as a plain alternative to R with a completely distinct
directory /usr/lib/Ra/ and just two binaries /usr/bin/R and
/usr/bin/Rscript.Ra provided the 'Ra' versions of R and Rscript.
Tentative debian/control below.
Cheers, Dirk
Source: r-base-core-ra
Section: math
Priority: optional
Maintainer: Dirk Eddelbuettel <[EMAIL PROTECTED]>
Standards-Version: 3.7.3
Build-Depends: gcc (>= 4:4.1.0), g++ (>= 4:4.1.0), gfortran (>= 4:4.1.0),
libblas-dev, liblapack-dev (>= 3.1.1), tcl8.4-dev, tk8.4-dev, bison,
groff-base, libncurses5-dev, libreadline5-dev, debhelper (>= 5.0.0), texi2html,
texinfo (>= 4.1-2), libbz2-dev, libpcre3-dev, xpdf-reader, zlib1g-dev,
libpng12-dev, libjpeg62-dev, libx11-dev, libxt-dev, x-dev, libpango1.0-dev,
libcairo2-dev, libtiff4-dev, xvfb, xbase-clients, xfonts-base, r-cran-jit,
r-cran-mgcv
Package: r-base-core-ra
Architecture: any
Depends: ${perl:Depends}, zip, unzip, libpaper-utils, ${shlibs:Depends}
Recommends: r-base-core, r-base-dev, r-cran-jit
Suggests: ess, r-recommended, r-doc-info | r-doc-pdf | r-doc-html, r-mathlib,
r-base-html | r-base-latex
Description: 'ra' variant of GNU R core of statistical computing language and
environment
R is `GNU S' - A language and environment for statistical computing
and graphics. R is similar to the award-winning S system, which was
developed at Bell Laboratories by John Chambers et al. It provides a
wide variety of statistical and graphical techniques (linear and
nonlinear modelling, statistical tests, time series analysis,
classification, clustering, ...).
.
R is designed as a true computer language with control-flow
constructions for iteration and alternation, and it allows users to
add additional functionality by defining new functions. For
computationally intensive tasks, C, C++ and Fortran code can be
linked and called at run time.
.
S is the statistician's Matlab and R is to S what Octave is to Matlab.
.
This package provides a patched version of GNU R with 'just-in-time'
compilation of R code using the 'jit' package (in r-cran-jit). See
http://www.milbo.users.sonic.net/ra for details.
--
Three out of two people have difficulties with fractions.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: building a package two times
Cyril Brulebois <[EMAIL PROTECTED]> writes: > On 03/05/2008, Marco d'Itri wrote: >> DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH) >> ifeq ($(DEB_HOST_ARCH),amd64) >> FLAVORS := std >> else ifeq ($(DEB_HOST_ARCH),ia64) >> FLAVORS := std >> else ifeq ($(DEB_HOST_ARCH),ppc64) >> FLAVORS := std >> else ifeq ($(DEB_HOST_ARCH),s390x) >> FLAVORS := std >> else >> FLAVORS := std lfs >> endif > > Since you have âFLAVORS := stdâ in every case but the last one, why not > using findstring, so as to factorize a bit? > > Mraw, > KiBi. FLAVORS := std ifeq ((findstring $(DEB_HOST_ARCH),amd64 ia64 ppc64 s390x),) FLAVORS += lfs endif Like this? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479238: ITP: res -- OCaml library for automatically resizing contiguous data structure
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli <[EMAIL PROTECTED]> * Package name: res Version : 2.2.5 Upstream Author : Markus Mottl <[EMAIL PROTECTED]> * URL : http://www.ocaml.info/home/ocaml_sources.html * License : LGPL Programming Lang: OCaml Description : OCaml library for automatically resizing contiguous data structure This OCaml library consists of a set of modules which implement automatically resizing (i.e. reallocating) data structures that consume a contiguous part of memory. . This allows appending and removing of elements to/from arrays (both boxed and unboxed), strings (i.e. buffers), bit strings and weak arrays while still maintaining fast constant-time access to elements. . There are also functors that allow the generation of similar modules which use different reallocation strategies. The package is being worked on at git://git.debian.org/git/pkg-ocaml-maint/packages/res.git . It is being packages as a dependency of core (see #479152). -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: latest sid image is broken?
AM> It is a known temporary problem caused by the ... transition, All I know is on the first days of such transitions, my usual # apt-get -o Debug::pkgProblemResolver=true --purge dselect-upgrade barfs up kilometers of broken dep messages, the next day it is fewer, but still several broken deps... I switch to using upgrade instead of dselect-upgrade until the latter stops complaining, which might take a week. My question is why can't this drama be played out behind the scenes? Why can't all the dependency stuff be resolved first before it is sent to sid? Or is that how dependency problems are detected and hunt down? If so, then why can't this be played out offline and fixed instead of sending it to sid for all to share the misery? There should be a check that no dependency inconsistencies are present before each daily propagation of sid; or one is not allowed to touch sid unless the result leaves no dependency inconsistencies. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: latest sid image is broken?
On Sun, 04 May 2008, [EMAIL PROTECTED] wrote: > Why can't all the dependency stuff be resolved first before it is sent > to sid? Unstable is the place where dependencies are resolved before they are sent on to testing. It's not like they're hard to deal with; you just don't upgrade packages whose dependencies are uninstallable. If you need to install packages whose dependencies are not satisfiable in unstable, you use the testing version. Some repository has to be the leading edge of development, and that repository is unstable. Don Armstrong -- I leave the show floor, but not before a pack of caffeinated Jolt gum is thrust at me by a hyperactive girl screaming, "Chew more! Do more!" The American will to consume more and produce more personified in a stick of gum. I grab it. -- Chad Dickerson http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: latest sid image is broken?
Hi, [EMAIL PROTECTED] wrote: > My question is why can't this drama be played out behind the scenes? > > Why can't all the dependency stuff be resolved first before it is sent > to sid? > > Or is that how dependency problems are detected and hunt down? If so, > then why can't this be played out offline and fixed instead of sending > it to sid for all to share the misery? > > There should be a check that no dependency inconsistencies are present > before each daily propagation of sid; or one is not allowed to touch > sid unless the result leaves no dependency inconsistencies. That's exactly what testing is about. Regards, Rene -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: building a package two times
On May 03, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > FLAVORS := std > ifeq ((findstring $(DEB_HOST_ARCH),amd64 ia64 ppc64 s390x),) > FLAVORS += lfs > endif > > Like this? AFAICT this will match also if DEB_HOST_ARCH=s390. Anyway, I hoped for way more substancial critique. Either you all are not trying hard enough or I know much more than I tought about makefiles... :-) -- ciao, Marco signature.asc Description: Digital signature
Has recibido una postal de David
Hola debian-devel@lists.debian.org, Has recibido una postal de David <[EMAIL PROTECTED]> ! Para ver tu postal por favor clickea este link : http://postales.sonico.com/view.php?cid=11622329&[EMAIL PROTECTED]&db=2&t=ecards_sonico&ss=1 Muchas Gracias, http://Postales.Sonico.com Sitios recomendados http://www.TarjetasTelefonicas.com - Ahorra hasta 95% en tus llamadas telefónicas http://www.Sexymetro.com - ¿Crees que eres sexy? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
quiltrc
~/.quiltrc:
for where in ./ ../ ../../ ../../../ ../../../../ ../../../../../; do
if [ -e ${where}debian/rules -a -d ${where}debian/patches ]; then
export QUILT_PATCHES=debian/patches
fi
done
Also recommended:
QUILT_PUSH_ARGS="--color=auto"
QUILT_DIFF_ARGS="--no-timestamps --no-index -p ab --color=auto"
QUILT_REFRESH_ARGS="--no-timestamps --no-index -p ab"
QUILT_DIFF_OPTS='-p'
QUILT_PATCH_OPTS='--unified-reject-files'
--
ciao,
Marco
signature.asc
Description: Digital signature
Re: Bug#479238: ITP: res -- OCaml library for automatically resizing contiguous data structure
Stefano Zacchiroli <[EMAIL PROTECTED]> writes: > Package: wnpp > Severity: wishlist > Owner: Stefano Zacchiroli <[EMAIL PROTECTED]> > > * Package name: res Please change this to a package name that is less generic, and conforms with other OCaml library packages. 'libres-ocaml' would be better. -- \ “The cost of education is trivial compared to the cost of | `\ ignorance.” —Thomas Jefferson | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#479238: ITP: res -- OCaml library for automatically resizing contiguous data structure
On Sun, May 04, 2008 at 12:27:29PM +1000, Ben Finney wrote: > Please change this to a package name that is less generic, and > conforms with other OCaml library packages. 'libres-ocaml' would be > better. This is the source package name, as in all ITPs, not the binary package name. No OCaml package has a source name like libFOO-ocaml, they all have *binaries* called libFOO-ocaml-dev. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -<%>- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
