ITA: filler - Simple game in Java
Good evening. My name is James Damour, and I would like to adopt the filler package that the Debian QA team has orphaned. I have made my first modifications to the package, and I have uploading them to http://mentors.debian.net. I would appreciate it if a sponsor could review my packaging, and let me know what I should change in order to get it ready for upload to the Debian archive. I've fixed all lintian or linda errors, and the remaining linda warning may be a bug (as a game, filler needs to be rwxr-sr-x and linda is expecting rwxr-xr-x). I expect that I'll get a FTBFS error because I can not specify a compliant Java Development Kit from within the Debian archive (filler requires Swing technology, and I haven't found a VM that will build it, but I'm still looking). Any assistance in this area would be greatly appreciated. -- James Damour (Suvarov454) <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: ITA: filler - Simple game in Java
On Tue, 2004-05-11 at 11:40, Gunnar Wolf wrote: > James Damour dijo [Tue, May 11, 2004 at 08:25:52AM -0400]: > > Good evening. My name is James Damour, and I would like to adopt the > > filler package that the Debian QA team has orphaned. I have made my > > first modifications to the package, and I have uploading them to > > http://mentors.debian.net. > > Hi, > > I cannot offer you to sponsor your package, as I understand no Java, > and any error would probably slip under my nose. Anyway, if you have > the package ready, please retitle bug #232868 to 'ITA: filler - Simple > game in Java' - You can do this by sending the following line as a > mail to [EMAIL PROTECTED]: > > retitle 232868 ITA: filler - Simple game in Java > > I noticed you already replied to that bug report, but when people look > at the WNPP packages, filler still appears as orphaned - do this just > to save other people the effort in opening the report and checking. > Done. > > I would appreciate it if a sponsor could review my packaging, and let me > > know what I should change in order to get it ready for upload to the > > Debian archive. I've fixed all lintian or linda errors, and the > > remaining linda warning may be a bug (as a game, filler needs to be > > rwxr-sr-x and linda is expecting rwxr-xr-x). > > > > I expect that I'll get a FTBFS error because I can not specify a > > compliant Java Development Kit from within the Debian archive (filler > > requires Swing technology, and I haven't found a VM that will build it, > > but I'm still looking). Any assistance in this area would be greatly > > appreciated. > > If your package requires a non-free JDK, then it will enter contrib > (instead of main) and will not be autobuilt, so don't worry, you will > not get the dreaded FTBFS ;-) Just please note somewhere visible > (i.e. in /usr/share/doc/filler/) what JDK did you use to compile it > and where can it be found. Also, double check: Can Filler be used with > any of the existing JVMs in Debian? If not, it would not be useful at > all, and instead of adopting it, you should file for its removal from > the archive. The file, /usr/share/doc/filler/README.Debian mentions both the Blackdown and the Sun VMs. It does not *explicitly* state that these are needed to rebuild the source; do you think that I should update the file to say so? I've tried gij-3.3 and both Kaffe and SableVM from Sid, and neither currently support the Swing APIs used by filler, but I'm very hopeful that they will quite soon. As such, and considering the age of the package (it's been in Debian for over 3 years) I'd prefer to leave the package in Debian, and just have it limp along until FLOSS Java catches up to it. > > Greetings, Thank you for your feedback. -- James Damour (Suvarov454) <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: setgid-wrapper
On Tue, 2004-05-18 at 09:03, Steven Augart wrote: > Dear James, > > James Damour wrote: > > On Mon, 2004-05-17 at 14:29, Steven Augart wrote: > >>Grzegorz B. Prokopski wrote: > >>>As for SGID - if this is java game, so you most probably have a shell > >>>wrapper. S[UG]ID bits do NOT work on shell scripts.[] > >>>What you probably could do is write a small C wrapper, > [...] > >>I was thinking it might make sense to create a program (and package) named > >>setgid-wrapper? [] > [] > >>setregid() to (user's real group, games-group), setreuid() to the user's > >>real id, and execute the real executable. > [] > > > Sadly, I don't think that this would help in my case. The problem with > > filler is that it is a Java application, so it's driver script invokes > > the "java" command; more often than not, "java" is actually another > > script that eventually (perhaps through a chain of several other > > scripts) invokes an ELF. Worse yet, the exact nature of the script > > varies from installation to installation (i.e. it is different for > > Sun/Blackdown Java, Kaffe, SableVM, and GCJ). > > Good point. Fortunately, at least in the case of "filler", it only > requires a small modification of the setgid-wrapper. > > As you probably know, when a shell sees that it is running a setuid or > setgid shell script, it detects this because the euid and ruid or egid > and rgid are different. It "fixes" this by setting the euid to be the > same as the ruid, and/or egid the same as the rgid, effectively > turning off the setuid/setgid bit. Actually, I didn't know that. Thanks for the info! > > But, if the egid and rgid are the same, then the shell script leaves > them alone. (Indeed, unless it's running as root, it has to leave > them alone -- it does not have permission to do anything else.) > > So, instead of setgid-wrapper calling setregid() to (user's real > group, "games"), it will have to call setregid to (games, games) > In this case, this setgid-wrapper concept would work for *all* Java applications. I'm still not sure if it will work for shell driven apps in general, but it sounds reasonable. Security may be a concern, but I believe that a simple, well written setgid-wrapper program, that only runs programs listed in its (root-owned) configuration file should be at least as secure as cron or at. We should be sure to borrow the configuration update logic from cron or at to make sure that we are modifying the file in a way that is both secure, and meets Debian project guidelines. Should I take the first crack at writing setguid-wrapper? Should we pass the concept by Debian Security first? > This will not pose any problems, *except* that any new files the > program creates will have their group set to "games" instead of to the > user's default group. I think that this is actually the desired behavior. > > If you want to include debian-mentors in our correspondence, you > certainly have my permission to send this reply, or quotations from > it, to the list. Roger. Wilco. -- James Damour (Suvarov454) <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: setgid-wrapper
Somehow I managed to miss Bob's and Mike's emails on this subject. I rather wish that I *had* seen it before I spent 16 hours coding up the wrapper ;) Still, I don't think my time was wasted; I learned quite a lot and I think that I have something that can still be salvaged. Still "salvage" seems to describe what is needed. My understanding of the position of Bob and Mike can be summed up as, "in general, shell script's can't be made to use setuid/setgid securely". Basically, the problem comes down that a user can manipulate their PATH to redefining basic commands that are used by the shell scripts (like "ls") in order to elevate their privileges. I'm not willing to give up on the basic idea yet, however, as I still need to run a Java program setgid to "games" to handle a score history file. Similarly, I hope to one day run a Java application server (e.g. Tomcat, JBoss, or Geronimo) setuid to some system id. Therefore I humbly request your comments on how to salvage this idea. Please keep in mind that "/usr/bin/java" is, itself, almost certainly a script. I'll gladly send the package and source to anyone wishing to review my work. I'm not quite ready to have it uploaded to the Debian project (not even Experimental) yet, however. If you don't mind, I'd like more agreement on the basic concepts first. -- James Damour (Suvarov454) <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Executing with root priviliges
On Sat, 5 Jun 2004 22:21:23 +0100, Nick Leverton wrote: > On Sat, Jun 05, 2004 at 08:24:47PM +0200, Eduard Bloch wrote: > > Goswin von Brederlow schrieb am Samstag, den 05. Juni 2004: > > > > > > > So, my question is...is there, or should there be, some virtual > > > > > package or system-wide or user-wide preference for gaining root > > > > > priviliges under X11? What's the best current way to get this > > > > > into the menu system with the least amount of pain for both > > > > > the packager and the user? > > > > There is already the script su-to-root in the current menu package which > > does almost what you want - looking around and choosing a su-like > > program. > > Can you depend on any of the alternatives, with suitable detection ? > That would be good for users in differing environments :) > > Nick I've been working on a similar problem for a package that I've just adopted. It is a game with a "high scores" file that it wants to write to, and Debian Policy (secion 10.9) allows for the file to have an owner of root.games, with the game itself runing setgid to games. Linda even complains if the game is *not* setgid. The problem is, the game is written in Java, so the entry in usr/games is a driver script, and scripts ignore the setuid and setgid modes for security reasons. I didn't get the list of alternatives that you've gotten here, and sudo does not appear to have a mechanism for "keep the current uid, but run under a different gid". I've tried to write a generic "setgid_wrapper" (actually, a setid_wrapper, because I may as well set both the uid and the gid), but there are concerns about YAFuid changing application; and this one isn't written by a professional paranoid like sudo. My question for this thread is, "should I continue to pursue an independent setid_wrapper, which would solve this requirement as well as mine, or should I work with the sudo upstream to get a setgid option added?" Put another way, given that my needs are not met by any of the alternatives presented in this thread, what is the best way (for *all* of Debian) to address them? -- James Damour (Suvarov454) <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: [jdamour@nycap.rr.com: Re: Please help sorting out which sid updates need to make sarge]
On Sun, 2004-08-15 at 11:59, Thomas Viehmann wrote: > Hi. > I'm CC'ing you (James) because I suspect you might not be subscribed to > Correct. > > FTBFS > I cannot find an open bug. If you mean 255831 (which looks like a > legitimate missing build dependency bug, how did you resolve it before > closing the bug), it should be reopened. It was my understanding from the Debian Java policy (http://www.debian.org/doc/packaging-manuals/java-policy/x73.html) that by depending upon the java2-runtime (which is *not* supplied by gcj 3.3), the filler package is correctly identifying a dependency that wasn't satisfied on the system of the user in bug 255831. The fact that there is *NO* package in Debian (main or contrib) that satisfies the dependency is what causes the FTBFS bug. On the other hand, once the Free Java hackers catch up, filler should run without modification. > > > another. Perhaps the package should be dropped from Sarge? > > The best thing is probably to have/file an RC bug and ask on > debian-release to remove the package from sarge referencing the bug number. > I'd be happy to do so, if this is the recommendation of the list. > Kind regards > > Thomas -- James Damour (Suvarov454) <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: [jdamour@nycap.rr.com: Re: Please help sorting out which sid updates need to make sarge]
On Sun, 2004-08-15 at 17:31, Jeroen van Wolffelaar wrote: > On Sun, Aug 15, 2004 at 05:26:21PM -0400, James Damour wrote: > > It was my understanding from the Debian Java policy > > (http://www.debian.org/doc/packaging-manuals/java-policy/x73.html) that > > by depending upon the java2-runtime (which is *not* supplied by gcj > > 3.3), the filler package is correctly identifying a dependency that > > wasn't satisfied on the system of the user in bug 255831. The fact that > > there is *NO* package in Debian (main or contrib) that satisfies the > > dependency is what causes the FTBFS bug. On the other hand, once the > > Free Java hackers catch up, filler should run without modification. > > filler is in contrib, see > http://www.nl.debian.org/doc/debian-policy/ch-archive.html#s-contrib > > packages in contrib are allowed to FTBFS due to missing dependencies in > Debian. You may close any FTBFS bugs on filler caused by missing java2 > packages in Debian referring to the debian policy, it is acceptable > for contrib to FTBFS due to missing dependencies. OK, good to know. > > Your package doesn't propagate to testing at the moment due to missing > depends, but this issue is currently being worked on by Andreas Barth. > I didn't know that. Should I try to contact Andreas and offer to help? > --Jeroen -- James Damour (Suvarov454) <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: [jdamour@nycap.rr.com: Re: Please help sorting out which sid updates need to make sarge]
On Mon, 2004-08-16 at 06:13, Jeroen van Wolffelaar wrote:
> On Mon, Aug 16, 2004 at 09:16:24AM +0200, Thomas Viehmann wrote:
> > Jeroen van Wolffelaar wrote:
> > > packages in contrib are allowed to FTBFS due to missing dependencies in
> > > Debian. You may close any FTBFS bugs on filler caused by missing java2
> > I think this should be missing *build*-dependencies.
> > To me it looks like filler 1.02-2 specifies java-compiler, debhelper as
> > build-dependencies.
>
> Hm, indeed, that's a problem. It should build-depend on j2sdk1.{3,4} or
> whatever instead...
How very, very silly of me not to have seen this before. I'll get a new
version uploaded as soon as I can.
>
> Lintian should also have given you:
> W: filler source: virtual-package-depends-without-real-package-depends
> build-depends-indep: java-compiler
I see that error now, but I don't think I saw it when I first uploaded
it. I remember a similar error on the "depends" line, which may be why
I specified the j2re1.3 | j2re1.4, but I'm pretty sure that the only
lintian error I was getting was that the driver script,
/usr/games/filler was not setgid games (which it can't be... it's a
script).
I've created a new set of package file and made them available at
http://www.damour.info/debian/. Could someone please submit them to the
upload queue for me (as I'm not a Debian Developer)?
Thank you all for your help.
>
> You should build=depend: | to
> give builders a hint which package you want installed. Plus indeed that
> java-compiler isn't a restrictive enough virtual package. On my system,
> java-compiler is provided by:
>
> * j2sdk1.4 1.4.1.01-0.1
> * jdk1.1 1.1.8v3-1
> * j2sdk1.3 1.3.1.02b-2
> * kaffe-pthreads-profile 2:1.1.4.PRE1.1.5-11
> * kaffe-pthreads 2:1.1.4.PRE1.1.5-11
> * kaffe-jthreads 2:1.1.4.PRE1.1.5-11
> * jikes-sablevm 1.1.6-2
> * jikes-kaffe 2:1.1.4.PRE1.1.5-11
> * jikes-gij 1:1.21-2
> * jikes-classpath 2:0.09-2
> * gcj-3.3 1:3.3.4-3
> * gcj 4:3.3.4-2
>
> So, your package should be buildable by _any_ of these. I didn't test
> that though.
>
> If filler isn't buildable by some of these, that is indeed a RC bug. As
> Thomas said, build-depends need to be specified correctly. Depending on
> java2-compiler might be it.
>
> --Jeroen
--
James Damour (Suvarov454) <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
Re: ITA: filler - Simple game in Java
On Tue, 2004-05-11 at 11:40, Gunnar Wolf wrote: > James Damour dijo [Tue, May 11, 2004 at 08:25:52AM -0400]: > > Good evening. My name is James Damour, and I would like to adopt the > > filler package that the Debian QA team has orphaned. I have made my > > first modifications to the package, and I have uploading them to > > http://mentors.debian.net. > > Hi, > > I cannot offer you to sponsor your package, as I understand no Java, > and any error would probably slip under my nose. Anyway, if you have > the package ready, please retitle bug #232868 to 'ITA: filler - Simple > game in Java' - You can do this by sending the following line as a > mail to [EMAIL PROTECTED]: > > retitle 232868 ITA: filler - Simple game in Java > > I noticed you already replied to that bug report, but when people look > at the WNPP packages, filler still appears as orphaned - do this just > to save other people the effort in opening the report and checking. > Done. > > I would appreciate it if a sponsor could review my packaging, and let me > > know what I should change in order to get it ready for upload to the > > Debian archive. I've fixed all lintian or linda errors, and the > > remaining linda warning may be a bug (as a game, filler needs to be > > rwxr-sr-x and linda is expecting rwxr-xr-x). > > > > I expect that I'll get a FTBFS error because I can not specify a > > compliant Java Development Kit from within the Debian archive (filler > > requires Swing technology, and I haven't found a VM that will build it, > > but I'm still looking). Any assistance in this area would be greatly > > appreciated. > > If your package requires a non-free JDK, then it will enter contrib > (instead of main) and will not be autobuilt, so don't worry, you will > not get the dreaded FTBFS ;-) Just please note somewhere visible > (i.e. in /usr/share/doc/filler/) what JDK did you use to compile it > and where can it be found. Also, double check: Can Filler be used with > any of the existing JVMs in Debian? If not, it would not be useful at > all, and instead of adopting it, you should file for its removal from > the archive. The file, /usr/share/doc/filler/README.Debian mentions both the Blackdown and the Sun VMs. It does not *explicitly* state that these are needed to rebuild the source; do you think that I should update the file to say so? I've tried gij-3.3 and both Kaffe and SableVM from Sid, and neither currently support the Swing APIs used by filler, but I'm very hopeful that they will quite soon. As such, and considering the age of the package (it's been in Debian for over 3 years) I'd prefer to leave the package in Debian, and just have it limp along until FLOSS Java catches up to it. > > Greetings, Thank you for your feedback. -- James Damour (Suvarov454) <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
ITA: filler - Simple game in Java
Good evening. My name is James Damour, and I would like to adopt the filler package that the Debian QA team has orphaned. I have made my first modifications to the package, and I have uploading them to http://mentors.debian.net. I would appreciate it if a sponsor could review my packaging, and let me know what I should change in order to get it ready for upload to the Debian archive. I've fixed all lintian or linda errors, and the remaining linda warning may be a bug (as a game, filler needs to be rwxr-sr-x and linda is expecting rwxr-xr-x). I expect that I'll get a FTBFS error because I can not specify a compliant Java Development Kit from within the Debian archive (filler requires Swing technology, and I haven't found a VM that will build it, but I'm still looking). Any assistance in this area would be greatly appreciated. -- James Damour (Suvarov454) <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: setgid-wrapper
On Tue, 2004-05-18 at 09:03, Steven Augart wrote: > Dear James, > > James Damour wrote: > > On Mon, 2004-05-17 at 14:29, Steven Augart wrote: > >>Grzegorz B. Prokopski wrote: > >>>As for SGID - if this is java game, so you most probably have a shell > >>>wrapper. S[UG]ID bits do NOT work on shell scripts.[] > >>>What you probably could do is write a small C wrapper, > [...] > >>I was thinking it might make sense to create a program (and package) named > >>setgid-wrapper? [] > [] > >>setregid() to (user's real group, games-group), setreuid() to the user's > >>real id, and execute the real executable. > [] > > > Sadly, I don't think that this would help in my case. The problem with > > filler is that it is a Java application, so it's driver script invokes > > the "java" command; more often than not, "java" is actually another > > script that eventually (perhaps through a chain of several other > > scripts) invokes an ELF. Worse yet, the exact nature of the script > > varies from installation to installation (i.e. it is different for > > Sun/Blackdown Java, Kaffe, SableVM, and GCJ). > > Good point. Fortunately, at least in the case of "filler", it only > requires a small modification of the setgid-wrapper. > > As you probably know, when a shell sees that it is running a setuid or > setgid shell script, it detects this because the euid and ruid or egid > and rgid are different. It "fixes" this by setting the euid to be the > same as the ruid, and/or egid the same as the rgid, effectively > turning off the setuid/setgid bit. Actually, I didn't know that. Thanks for the info! > > But, if the egid and rgid are the same, then the shell script leaves > them alone. (Indeed, unless it's running as root, it has to leave > them alone -- it does not have permission to do anything else.) > > So, instead of setgid-wrapper calling setregid() to (user's real > group, "games"), it will have to call setregid to (games, games) > In this case, this setgid-wrapper concept would work for *all* Java applications. I'm still not sure if it will work for shell driven apps in general, but it sounds reasonable. Security may be a concern, but I believe that a simple, well written setgid-wrapper program, that only runs programs listed in its (root-owned) configuration file should be at least as secure as cron or at. We should be sure to borrow the configuration update logic from cron or at to make sure that we are modifying the file in a way that is both secure, and meets Debian project guidelines. Should I take the first crack at writing setguid-wrapper? Should we pass the concept by Debian Security first? > This will not pose any problems, *except* that any new files the > program creates will have their group set to "games" instead of to the > user's default group. I think that this is actually the desired behavior. > > If you want to include debian-mentors in our correspondence, you > certainly have my permission to send this reply, or quotations from > it, to the list. Roger. Wilco. -- James Damour (Suvarov454) <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: setgid-wrapper
Somehow I managed to miss Bob's and Mike's emails on this subject. I rather wish that I *had* seen it before I spent 16 hours coding up the wrapper ;) Still, I don't think my time was wasted; I learned quite a lot and I think that I have something that can still be salvaged. Still "salvage" seems to describe what is needed. My understanding of the position of Bob and Mike can be summed up as, "in general, shell script's can't be made to use setuid/setgid securely". Basically, the problem comes down that a user can manipulate their PATH to redefining basic commands that are used by the shell scripts (like "ls") in order to elevate their privileges. I'm not willing to give up on the basic idea yet, however, as I still need to run a Java program setgid to "games" to handle a score history file. Similarly, I hope to one day run a Java application server (e.g. Tomcat, JBoss, or Geronimo) setuid to some system id. Therefore I humbly request your comments on how to salvage this idea. Please keep in mind that "/usr/bin/java" is, itself, almost certainly a script. I'll gladly send the package and source to anyone wishing to review my work. I'm not quite ready to have it uploaded to the Debian project (not even Experimental) yet, however. If you don't mind, I'd like more agreement on the basic concepts first. -- James Damour (Suvarov454) <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Executing with root priviliges
On Sat, 5 Jun 2004 22:21:23 +0100, Nick Leverton wrote: > On Sat, Jun 05, 2004 at 08:24:47PM +0200, Eduard Bloch wrote: > > Goswin von Brederlow schrieb am Samstag, den 05. Juni 2004: > > > > > > > So, my question is...is there, or should there be, some virtual > > > > > package or system-wide or user-wide preference for gaining root > > > > > priviliges under X11? What's the best current way to get this > > > > > into the menu system with the least amount of pain for both > > > > > the packager and the user? > > > > There is already the script su-to-root in the current menu package which > > does almost what you want - looking around and choosing a su-like > > program. > > Can you depend on any of the alternatives, with suitable detection ? > That would be good for users in differing environments :) > > Nick I've been working on a similar problem for a package that I've just adopted. It is a game with a "high scores" file that it wants to write to, and Debian Policy (secion 10.9) allows for the file to have an owner of root.games, with the game itself runing setgid to games. Linda even complains if the game is *not* setgid. The problem is, the game is written in Java, so the entry in usr/games is a driver script, and scripts ignore the setuid and setgid modes for security reasons. I didn't get the list of alternatives that you've gotten here, and sudo does not appear to have a mechanism for "keep the current uid, but run under a different gid". I've tried to write a generic "setgid_wrapper" (actually, a setid_wrapper, because I may as well set both the uid and the gid), but there are concerns about YAFuid changing application; and this one isn't written by a professional paranoid like sudo. My question for this thread is, "should I continue to pursue an independent setid_wrapper, which would solve this requirement as well as mine, or should I work with the sudo upstream to get a setgid option added?" Put another way, given that my needs are not met by any of the alternatives presented in this thread, what is the best way (for *all* of Debian) to address them? -- James Damour (Suvarov454) <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: [jdamour@nycap.rr.com: Re: Please help sorting out which sid updates need to make sarge]
On Sun, 2004-08-15 at 11:59, Thomas Viehmann wrote: > Hi. > I'm CC'ing you (James) because I suspect you might not be subscribed to > Correct. > > FTBFS > I cannot find an open bug. If you mean 255831 (which looks like a > legitimate missing build dependency bug, how did you resolve it before > closing the bug), it should be reopened. It was my understanding from the Debian Java policy (http://www.debian.org/doc/packaging-manuals/java-policy/x73.html) that by depending upon the java2-runtime (which is *not* supplied by gcj 3.3), the filler package is correctly identifying a dependency that wasn't satisfied on the system of the user in bug 255831. The fact that there is *NO* package in Debian (main or contrib) that satisfies the dependency is what causes the FTBFS bug. On the other hand, once the Free Java hackers catch up, filler should run without modification. > > > another. Perhaps the package should be dropped from Sarge? > > The best thing is probably to have/file an RC bug and ask on > debian-release to remove the package from sarge referencing the bug number. > I'd be happy to do so, if this is the recommendation of the list. > Kind regards > > Thomas -- James Damour (Suvarov454) <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: [jdamour@nycap.rr.com: Re: Please help sorting out which sid updates need to make sarge]
On Sun, 2004-08-15 at 17:31, Jeroen van Wolffelaar wrote: > On Sun, Aug 15, 2004 at 05:26:21PM -0400, James Damour wrote: > > It was my understanding from the Debian Java policy > > (http://www.debian.org/doc/packaging-manuals/java-policy/x73.html) that > > by depending upon the java2-runtime (which is *not* supplied by gcj > > 3.3), the filler package is correctly identifying a dependency that > > wasn't satisfied on the system of the user in bug 255831. The fact that > > there is *NO* package in Debian (main or contrib) that satisfies the > > dependency is what causes the FTBFS bug. On the other hand, once the > > Free Java hackers catch up, filler should run without modification. > > filler is in contrib, see > http://www.nl.debian.org/doc/debian-policy/ch-archive.html#s-contrib > > packages in contrib are allowed to FTBFS due to missing dependencies in > Debian. You may close any FTBFS bugs on filler caused by missing java2 > packages in Debian referring to the debian policy, it is acceptable > for contrib to FTBFS due to missing dependencies. OK, good to know. > > Your package doesn't propagate to testing at the moment due to missing > depends, but this issue is currently being worked on by Andreas Barth. > I didn't know that. Should I try to contact Andreas and offer to help? > --Jeroen -- James Damour (Suvarov454) <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: [jdamour@nycap.rr.com: Re: Please help sorting out which sid updates need to make sarge]
On Mon, 2004-08-16 at 06:13, Jeroen van Wolffelaar wrote:
> On Mon, Aug 16, 2004 at 09:16:24AM +0200, Thomas Viehmann wrote:
> > Jeroen van Wolffelaar wrote:
> > > packages in contrib are allowed to FTBFS due to missing dependencies in
> > > Debian. You may close any FTBFS bugs on filler caused by missing java2
> > I think this should be missing *build*-dependencies.
> > To me it looks like filler 1.02-2 specifies java-compiler, debhelper as
> > build-dependencies.
>
> Hm, indeed, that's a problem. It should build-depend on j2sdk1.{3,4} or
> whatever instead...
How very, very silly of me not to have seen this before. I'll get a new
version uploaded as soon as I can.
>
> Lintian should also have given you:
> W: filler source: virtual-package-depends-without-real-package-depends
> build-depends-indep: java-compiler
I see that error now, but I don't think I saw it when I first uploaded
it. I remember a similar error on the "depends" line, which may be why
I specified the j2re1.3 | j2re1.4, but I'm pretty sure that the only
lintian error I was getting was that the driver script,
/usr/games/filler was not setgid games (which it can't be... it's a
script).
I've created a new set of package file and made them available at
http://www.damour.info/debian/. Could someone please submit them to the
upload queue for me (as I'm not a Debian Developer)?
Thank you all for your help.
>
> You should build=depend: | to
> give builders a hint which package you want installed. Plus indeed that
> java-compiler isn't a restrictive enough virtual package. On my system,
> java-compiler is provided by:
>
> * j2sdk1.4 1.4.1.01-0.1
> * jdk1.1 1.1.8v3-1
> * j2sdk1.3 1.3.1.02b-2
> * kaffe-pthreads-profile 2:1.1.4.PRE1.1.5-11
> * kaffe-pthreads 2:1.1.4.PRE1.1.5-11
> * kaffe-jthreads 2:1.1.4.PRE1.1.5-11
> * jikes-sablevm 1.1.6-2
> * jikes-kaffe 2:1.1.4.PRE1.1.5-11
> * jikes-gij 1:1.21-2
> * jikes-classpath 2:0.09-2
> * gcj-3.3 1:3.3.4-3
> * gcj 4:3.3.4-2
>
> So, your package should be buildable by _any_ of these. I didn't test
> that though.
>
> If filler isn't buildable by some of these, that is indeed a RC bug. As
> Thomas said, build-depends need to be specified correctly. Depending on
> java2-compiler might be it.
>
> --Jeroen
--
James Damour (Suvarov454) <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
