Re: RFS: multixterm -- drive multiple xterms separately or together
On 3/7/06, gregor herrmann <[EMAIL PROTECTED]> wrote: > On Tue, Mar 07, 2006 at 05:11:29PM +0100, Michelle Konzack wrote: > > (shortening cc:-list) > > > > clusterssh opens xterms with ssh sessions, multixterm opens multiple > > > xterms (with whatever contents). So if you want to control several > > > xterms at the same time that are not ssh sessions multixterm can > > > handle this but clusterssh can't. > > :-/ > > If you find a good argument why controlling multiple xterms > simultanously that contain no ssh sessions might be useful I guess > there's no problem with re-opening the ITP bug and looking for a > sponsor again. System performance tests? Multiple compilations on multiple machines, including the host? installation of multiple chroot environments on the loacl machine? -- Regards, EddyP = "Imagination is more important than knowledge" A.Einstein
Re: Packaging Maven 2 - shipping binaries for bootstrapping.
Hi Philipp, I tried to package Maven 2 last summer and you seem to have gotten as far as I was back then so let me give you a small braindump. You seem to have found some of the depdencies that Maven needs to build itself, but there is a whole lot more of them. You can drop a few of them if you skip all the tests for the inital package. I think I found out that the entire dependency graph of Maven 2 (not sure if this included test dependencies or not) was around 100 artifacts so there's a few packages to build :) On Thu, 2006-03-02 at 10:56 +0100, Philipp Meier wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi debian java folks, hi mentors, > > I'm posting this to mentors, too, because the problem described below is > not only about maven2 but about a general problem with bootstrapping > circularely depending packages. > > More news on packaging maven2. I was able to built some more > dependencies of maven2 as debian packages. Now, I reached a point where > I need a hint: > > Maven-components is built with a custom bootstrapping shellscript which > builds some core components of maven2 and then builds maven2 with the > help of the bootstrapped libraries. Maven-repository-metadata built > during the bootstrapping depends on a modello-test. modello-test itself > depends on maven-artifact. Modello test is a seperate package which > shall be built seperately from maven2. Because maven-repository-metadata > and maven-artifact are built using the bootstrapping script in one build > run there is a circular dependency. Think A -> C, C -> B where A and B > are in the same source package, C is in another. > > I see two ways of breaking this: > > First, ship modello as binary jar file with the first source tarball of > maven2 until maven2 is in the archives and can build modello. The > license of modello allows the binary contribution. The later versions > can be built with the packages from the archives then. AFAIK it's not acceptable to bundle binaries at all. Also is it really possible and feasable to build a package with an earlier version of itself? > Second option: Split maven-components into several packages. This will > be not very easy because of the sophisticated bootstrapping of maven2. > The process buils some bootstrapping code using a shellscript which > build a level 2 bootstrapper which builds the maven core which builds the > maven plugins. Event then, marven-artifact must be shipped as a separate > source package because of the dependencies described above. I think that you most likely will have to build each Maven artifact as it's own debian package as they're independently reusable (and actually reused). My conclusion from the last try was that I would make a big source ball containing all the compile time dependencies of Maven (meaning without everything required to run the tests) and make a bootstrap Maven 2 package from that. This bootstrap package would then in turn be used to build all the dependencies that Maven itself needs (including tests dependencies) and finally it would build the proper Maven 2 package with all the tests enabled. This bootstrap package can quite easily be generated using Maven 2 itself to find all the depdendencies. This was just an initial brain dump, feel free to ask more questions here or on irc (#debian-java on freenode). -- Trygve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libapache2-mod-auth-ldap
On Wed, 2006-03-08 at 16:12 +0100, Torsten Schlabach wrote: > Arnaud, > > >> I'have make this package and you could find it > >> @www.spyroux.be/~arnaud/debian > > As such a good idea, but ... > > >> This package (libapache2-mod-auth-ldap) seems to be missing from the > >> sarge. > > I thought this as well, but it isn't. The mod_ldap and mod_auth_ldap are > part of the package apache2-common. They get installed into > /etc/apache2/mods-available, but they are not available until you make a > symlink to it in /etc/apache2/mods-enabled. oh, I didn't see that :-D [... snip ...] > >> This is my first debian package so, this package could contain some > >> errors. I build it on a sarge and it's running on www.spyroux.be. > > You linked your package to a specific version of apache2. In the > meanwhile a slightly newer version got released, so I was able to instal > your package only with dpkg --force-depends. If might have been better > (though I am not sure about the rules) to make your package depend on > apache2 >= 2.xx rather than apache = 2.xx. That's because you need to recompile the module each time you have a new version of apache2-common. But this problem could come from the conflict between the two versions of the module. > I wonder though what the rule is what modules are part of apache2-common > and which ones are separate Debian packages. I would be tempted to > assume that everything which is part of the tarball that comes from the > Apache httpd project goes into apache2-common while anything that is > made available separately (such as PHP for example) goes into a separate > Debian package, but again, I am not sure. I don't know... Actually, I didn't update the module since a long time because the computer where the module is running "just works" without any problem and because nobody ask me to do it... Regards, Arnaud signature.asc Description: This is a digitally signed message part
Re: libapache2-mod-auth-ldap
On Wed, Mar 08, 2006 at 04:12:26PM +0100, Torsten Schlabach wrote: > Arnaud, > I wonder though what the rule is what modules are part of apache2-common > and which ones are separate Debian packages. I would be tempted to > assume that everything which is part of the tarball that comes from the > Apache httpd project goes into apache2-common while anything that is > made available separately (such as PHP for example) goes into a separate > Debian package, but again, I am not sure. This is the way it should be, unless the apache tarball is "nonpristine", or even incorporates multiple upstream tarballs. If it is pristine, and doesn't include something you'd like it to, file a bug; otherwise, it can be a separate project. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libapache2-mod-auth-ldap
Arnaud, >> I'have make this package and you could find it >> @www.spyroux.be/~arnaud/debian As such a good idea, but ... >> This package (libapache2-mod-auth-ldap) seems to be missing from the >> sarge. I thought this as well, but it isn't. The mod_ldap and mod_auth_ldap are part of the package apache2-common. They get installed into /etc/apache2/mods-available, but they are not available until you make a symlink to it in /etc/apache2/mods-enabled. >> There is a package in the experimental branch (found via >> packages.debian.org) with the name : libapache2-mod-authz-ldap but I >> did'nt try it (it has got an odd version number). This is about something else. Haven't researched this to the end, but I had installed it only to find out it was not what you need to link a .htaccess to your LDAP server. So I put it aside. >> This is my first debian package so, this package could contain some >> errors. I build it on a sarge and it's running on www.spyroux.be. You linked your package to a specific version of apache2. In the meanwhile a slightly newer version got released, so I was able to instal your package only with dpkg --force-depends. If might have been better (though I am not sure about the rules) to make your package depend on apache2 >= 2.xx rather than apache = 2.xx. I wonder though what the rule is what modules are part of apache2-common and which ones are separate Debian packages. I would be tempted to assume that everything which is part of the tarball that comes from the Apache httpd project goes into apache2-common while anything that is made available separately (such as PHP for example) goes into a separate Debian package, but again, I am not sure. Regards, Torsten Regards, Torsten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW queue
On Wed, Mar 08, 2006 at 05:48:45PM +0900, Kai Hendry wrote: > On 2006-03-08T09:00+0100 Miriam Ruiz wrote: > > Is it my imagination or binary-arch doesn't exist either? > > Isn't that what .PHONY is for? No; .PHONY is a list of rules which exist, but do not cause files of that name to be created http://www.gnu.org/software/make/manual/html_mono/make.html#SEC41 Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW queue
Not exactly, AFAIK: http://theory.uwinnipeg.ca/localfiles/infofiles/make/make_33.html A phony target is one that is not really the name of a file. It is just a name for some commands to be executed when you make an explicit request. There are two reasons to use a phony target: to avoid a conflict with a file of the same name, and to improve performance. The phony target will cease to work if anything ever does create a file named `clean' in this directory. Since it has no dependencies, the file `clean' would inevitably be considered up to date, and its commands would not be executed. To avoid this problem, you can explicitly declare the target to be phony, using the special target .PHONY Greetings, Miry --- Kai Hendry <[EMAIL PROTECTED]> escribió: > On 2006-03-08T09:00+0100 Miriam Ruiz wrote: > > Is it my imagination or binary-arch doesn't exist either? > > Isn't that what .PHONY is for? > > sam$ egrep PHONY webpy-0.135/debian/rules > .PHONY: build clean binary-indep binary-arch binary install configure > > Best wishes, > __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW queue
On 2006-03-08T09:00+0100 Miriam Ruiz wrote: > Is it my imagination or binary-arch doesn't exist either? Isn't that what .PHONY is for? sam$ egrep PHONY webpy-0.135/debian/rules .PHONY: build clean binary-indep binary-arch binary install configure Best wishes, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW queue
--- Kai Hendry <[EMAIL PROTECTED]> escribió: > > http://hendry.iki.fi/debian/unstable/webpy_0.135-1.diff.gz > > doesn't have a required 'build' target, which IMO is sufficient reason > > to reject the upload. > > What should it be? 386? I think it refers to this: http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules debian/rules is a makefile script with different rules that must do different things. For what I've read in the mail, it seems that the "build:" target is missing. The build target should perform all the configuration and compilation of the package. debian/rules in your diff only have the following targets for what I can see: clean, install, binary-indep, binary Is it my imagination or binary-arch doesn't exist either? Greetings, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
