Re: j2sdk build-depends cannot be satisfied?
Hi Correcttion to myself. Sorry. *SNIP* If you change java-runtime to java1-runtime it is perfectly correct. Can everyone agree that this is correct? If not, can someone suggest a line that will satisfy everyone? But you do not need to depend on any of the above except java-common if you _know_ that it works if you compile it to native code for some purpose. The usefulness of that can be discussed. From policy: Java libraries must depend on the needed runtime environment (java1-runtime and/or java2-runtime) but should not depend (only suggest) java-virtual-machine. For more information: http://www.debian.org/doc/packaging-manuals/java-policy/x98.html Regards, // Ola *SNIP* -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: j2sdk build-depends cannot be satisfied?
Stephen Also, WTF is with all the Architecture: all' -java packages Stephen that only depend on java-common? While I guess they're Stephen installable without a java runtime on this system, they're a Stephen completely unusable in that sate. I made this point when Ola discussed the java policy. gcj can compile java bytecode into native code. So Architecture: all java libraries can be used for development purposes without an interpreter. In theory, at least. -- Ian Zimmerman, Oakland, California, U.S.A. I did not vote for Emperor Bush. GPG: 433BA087 9C0F 194F 203A 63F7 B1B8 6E5A 8CA3 27DB 433B A087 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: j2sdk build-depends cannot be satisfied?
Followups set to debian-java where this is a little more on topic. Ian == Ian Zimmerman [EMAIL PROTECTED] writes: Ian gcj can compile java bytecode into native code. So Ian Architecture: all java libraries can be used for development Ian purposes without an interpreter. Yes, and I can statically compile binaries so that the don't depend on lic6 (the provider of /lib/ld-linux.so.2) but that's hardly the normal usage. -- Stephen Sixty percent of all Americans say they flew the flag after Sept. 11, 2001. Last week, less than 40 percent of registered voters cast ballots. Americans who wrap themselves in patriotic colors, yet can't be bothered to exercise the most fundamental right and responsibility in a democracy, betray the country they claim to love. -- Christina Hulbe, Letters to the Editor, The Orgeonian, 10 Nov. 2002 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: j2sdk build-depends cannot be satisfied?
Stephen == Stephen Zander [EMAIL PROTECTED] writes: Stephen Followups set to debian-java where this is a little more Stephen on topic. Excpet that I forgot to actually set the header. Bah. -- Stephen And what do we burn apart from witches?... More witches! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: j2sdk build-depends cannot be satisfied?
Ola == Ola Lundqvist [EMAIL PROTECTED] writes: So, here's my (hopefully) final question. I think I have addressed everyone's concerns with this Depends line: Depends: kaffe | java-virtual-machine, kaffe | java-runtime, java-common Ola If you change java-runtime to java1-runtime it is perfectly Ola correct. java1-runtime java2-runtime should provide a superset of java-virtual-machine and therefore you shouldn't need both. Suggests/ecommends/Depends on java-virtual-machine should only be for those systems tah make *no* use of the java.* classes (the semi-mythical project to make perl emit java bytecode springs to mind). -- Stephen A duck! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: user for getting files
On Fri, 22 Nov 2002 23:06, John H. Robinson, IV wrote: you never want a file owned by nobody. services that do not need any elevated privedges should run as nobody, so if they are compromised, then can do nothing. if you download a file as nobody, then a compromised nobudy-running daemon can then trojan that file. bad. Daemons should not run as nobody, they should run as their own unique UID. A daemon running as nobody can ptrace any other daemon running as nobody and do other interesting things too, unless of course you are running grsec, SE Linux, or some other system for advanced security. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: j2sdk build-depends cannot be satisfied?
Ola == Ola Lundqvist [EMAIL PROTECTED] writes: Ola This looks good if you only need a virtual machine and it Ola works with kaffe. But you most probably need a java1-runtime Ola to run it (not jus kaffe) so you should add that too (if you Ola need the runtime classes). While I understand the need, is java1-runtime an official virtual package name, i.e. discussed on debian-devel prior to it's usage etc? Also, WTF is with all the Architecture: all' -java packages that only depend on java-common? While I guess they're installable without a java runtime on this system, they're a completely unusable in that sate. -- Stephen They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety -- Benjamin Franklin %
Re: j2sdk build-depends cannot be satisfied?
On Thu, Nov 21, 2002 at 11:16:21AM -0600, Kenneth Pronovici wrote: So, here's my (hopefully) final question. I think I have addressed everyone's concerns with this Depends line: Depends: kaffe | java-virtual-machine, kaffe | java-runtime, java-common Can everyone agree that this is correct? If not, can someone suggest a line that will satisfy everyone? Seems fine to me. Friendly, Sven Luther
Re: j2sdk build-depends cannot be satisfied?
Hi On Thu, Nov 21, 2002 at 11:16:21AM -0600, Kenneth Pronovici wrote: Ok... I've gotten a lot of answers on this thread, which I REALLY appreciate. This is what I love about Debian. :-) I just want to take one last pass at my question, to make sure everyone's in agreement. Parts of this thread (which is now a week+ long) have gotten lost along the way :), so to summarize: You really need a email program that can handle threads. Mutt do that. :) 1) My questions are related libnbio2-java 2) libnbio2-java is a JNI Java library, and hence is arch-dependent 3) My original question was why the autobuilder couldn't build it 4) The answer to that question was, because it depends on Blackdown 5) Discussion continued on how I could get it to build with free tools 6) I made it build with free tools (checked with pdebbuild environment) 7) Test code turned out to work with kaffe, but not with gij 8) I posted a recipe for the problem with gij (but did not file a bug, yet) 9) We decided that if it ran with kaffe, that was good enough for now Here is the control file for the package as it currently stands (with the long description removed for brevity): Source: nbio Section: libs Priority: optional Maintainer: Kenneth J. Pronovici [EMAIL PROTECTED] Build-Depends: debhelper ( 4.1.0), fastjar (= 1:3.2.1-0pre6), gcj-3.2 (= 1:3.2.1-0pre6), gcc-3.2 (= 1:3.2.1-0pre6), doxygen Standards-Version: 3.5.7 Package: libnbio2-java Architecture: any Depends: kaffe, java-common Description: NBIO: Nonblocking I/O for Java, Version 2 As I mentioned above, I am fairly confident in the Build-Depends line, since I can build the package in a pdebuild chroot environment. I am just not sure whether my Depends line is correct. In my test enviroment, I have only kaffe and java-common (and no other java-related packages) installed, and my test code works. Some people have suggested that in addition to kaffe, I should list java-virtual-machine and java1-runtime. Others have pointed out that kaffe provides java-virtual-machine and java1-runtime, so I wouldn't really need to list them. Almost correct. Yes kaffe provide it so you do not need to list kaffe if you list java1-runtime and java-virtual-machine. So, here's my (hopefully) final question. I think I have addressed everyone's concerns with this Depends line: Depends: kaffe | java-virtual-machine, kaffe | java-runtime, java-common If you change java-runtime to java1-runtime it is perfectly correct. Can everyone agree that this is correct? If not, can someone suggest a line that will satisfy everyone? But you do not need to depend on any of the above except java-common if you _know_ that it works if you compile it to native code for some purpose. The usefulness of that can be discussed. Regards, Sorry this post got so long... thanks again to all of you for the help. Long but well structurated and clear. Such email is nice to answer. ;) // Ola Sorry this post got so long... thanks again to all of you for the help. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] Personal Homepage: http://www.skyjammer.com/~pronovic/ They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin, Historical Review of Pennsylvania, 1759 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: j2sdk build-depends cannot be satisfied?
Hi Correcttion to myself. Sorry. *SNIP* If you change java-runtime to java1-runtime it is perfectly correct. Can everyone agree that this is correct? If not, can someone suggest a line that will satisfy everyone? But you do not need to depend on any of the above except java-common if you _know_ that it works if you compile it to native code for some purpose. The usefulness of that can be discussed. From policy: Java libraries must depend on the needed runtime environment (java1-runtime and/or java2-runtime) but should not depend (only suggest) java-virtual-machine. For more information: http://www.debian.org/doc/packaging-manuals/java-policy/x98.html Regards, // Ola *SNIP* -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Sponsor required: Film Gimp 0.8a-3
Hey everyone, Could someone please be kind enough to sponsor Film Gimp for me? I've already got 5 packages under my belt and been waiting for DAM approval for 11 months now, so I do know what I'm doing half the time = ). The packages are as Lintian and Linda clean as possible, with the exception of RPATHs, but that has been cleared #debian-devel since they're just GIMP plug-ins. Linda also flags fixincludes, but StevenK suspects it's really a Linda bug. http://www.cse.unsw.edu.au/~alau/debian/ Build-Depends: debhelper ( 3.0.0), libglib1.2-dev, libgtk1.2-dev, libjpeg62-dev, libpng12-dev, libtiff3g-dev, sharutils, zlib1g-dev 4.0KPackages.gz 4.0KSources.gz 44K filmgimp_0.8a-3.diff.gz 4.0Kfilmgimp_0.8a-3.dsc 4.0Kfilmgimp_0.8a-3_i386.changes 1.9Mfilmgimp_0.8a-3_i386.deb 2.5Mfilmgimp_0.8a.orig.tar.gz 80K libfilmgimp-dev_0.8a-3_i386.deb 68K libfilmgimp_0.8a-3_i386.deb Thanks in advance, Andrew Netsnipe Lau - Forwarded message from Andrew Lau [EMAIL PROTECTED] - From: Andrew Lau [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Official Film Gimp 0.8a-3 packages for Debian GNU/Linux Hi everyone, I'm proud to announce that I've finished packaging Film Gimp 0.8a for Debian GNU/Linux. Here are the Debian GNU/Linux release notes: = README.Debian for Film Gimp (23 November 2002) = General Notes: The layout of the 3 Debian GNU/Linux packages for Film Gimp attempt to follow the conventions already established by The Gimp 1.x packages and FHS policy. Plug-ins: /usr/lib/filmgimp/$version/plug-ins/ Brushes, gradients, palettes, patterns scripts: /usr/share/filmgimp/$version/plug-ins/ Headers: Film Gimp normally stores its headers under /usr/include/libgimp/ but to prevent name-space clashes with libgimp1.2-dev, libfilmgimp-dev will install them into /usr/include/filmgimp/ instead. Macros: /usr/share/aclocal/gimp.m4 has been renamed to filmgimp.m4 Upgrade Notes: If you are upgrading from the previous unofficial Film Gimp 0.8a-3 Debian GNU/Linux packages, you will need to remove ~/.filmgimp/ or else it will look for its plug-ins and some data files in the wrong locations Thanks: * Ben Gertzfield [EMAIL PROTECTED] and the other Debian developers who've maintained The Gimp in the past for providing me with much valued inspiration on how best to package Film Gimp. * Robin Rowe [EMAIL PROTECTED] for letting me join their project. = It'll take a few days for it to make it out of the internal queues at http://incoming.debian.org and into unstable. So if you're eager to try/review them in the meantime, please do the following: Add the following line to /etc/apt/sources.list deb http://www.cse.unsw.edu.au/~alau/debian/ ./ And then run # apt-get update # apt-get install filmgimp You may also install the libfilmgimp-dev for the development headers. If you're using Debian GNU/Linux on a non-i386 $ARCHs such as alpha, arm, hppa, ia64, m68k, mips, mipsel, powerpc, s390 sparc, you can also attempt to build the filmgimp debs for your machines using the following: Add the following line to /etc/apt/sources.list deb-src http://www.cse.unsw.edu.au/~alau/debian/ ./ And then run # apt-get update # apt-get build-dep filmgimp # apt-get source filmgimp Within a week or two at most, http://buildd.debian.org will have all those $ARCHs covered (and perhaps reveal some compatibility problems Film Gimp might have). Please comment on anything I could improve for the future releases and any thoughts you may have on the appropriateness of the modifications I've made to your source code in order to produce a Debian policy compliant package. The unified patch is available at http://www.cse/~alau/debian/filmgimp_0.8a-3.diff.gz. I look forward to working again with you guys in future. Yours sincerely, Andrew Netsnipe Lau -- --- * Andrew 'Netsnipe' Lau Computer Science Sturep, UNSW * * apt-get into itDebian GNU/Linux Packager* * netsnipe(+)debianplanet.org\0 alau(+)cse.unsw.edu.au\0 * * GnuPG 1024D/2E8B68BD 0B77 73D0 4F3B F286 63F1 9F4A 9B24 C07D 2E8B 68BD * --- - End forwarded message - -- --- * Andrew 'Netsnipe' Lau Computer Science Sturep, UNSW * * apt-get into itDebian GNU/Linux Packager* *
Re: j2sdk build-depends cannot be satisfied?
From policy: Java libraries must depend on the needed runtime environment (java1-runtime and/or java2-runtime) but should not depend (only suggest) java-virtual-machine. Right. I will use this: Depends: kaffe | java1-runtime, java-common Suggests: java-virtual-machine I think that takes care of it. :-) KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] Personal Homepage: http://www.skyjammer.com/~pronovic/ They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin, Historical Review of Pennsylvania, 1759
Sponsor for gkrellmitime package
Hi all. I'm looking for a sponsor to upload to Debian's repository gkrellmitime package. This is a new package containing an Internet plugin for gkrellm (I posted an ITP bug few months ago). The files can be obtained at: http://www.superiodico.net/debian/upload/ Thank you very much for your help. Thanks and regards. -- Juan Manuel García Molina [EMAIL PROTECTED]
user for getting files
Now that (as upstream) I've released hinfo 1.0, I'm planing on making it my first debian package. One of the things I'd like the debian package to do is download a couple of files (when changed) with wget on a regular basis. Having root do the download is using a sledgehammer on a finishing nail, (it works, but you have to be realy careful to avoid damage), and none of the other standard users seem correct, but is it realy appropriate for a package to create a new user for a weekly download? I'm planning a medium-priority debconf question to enable this, and the actual use will be in a conffile. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html Text is a way we cheat time. -- Patrick Nielsen Hayden
Re: user for getting files
On Fri, Nov 22, 2002 at 11:04:27AM -0800, Blars Blarson wrote: One of the things I'd like the debian package to do is download a couple of files (when changed) with wget on a regular basis. Having root do the download is using a sledgehammer on a finishing nail, (it works, but you have to be realy careful to avoid damage), and none of the other standard users seem correct, but is it realy appropriate for a package to create a new user for a weekly download? I'm planning a medium-priority debconf question to enable this, and the actual use will be in a conffile. I'm far from an expert, but I would have thought that 'nobody' would be appropriate for this. Have nobody download the files to /tmp, and them mv them somewhere else as root (or whatever user). As long as you don't trust the content of those files, this seems safe to me. -- David Roundy http://civet.berkeley.edu/droundy/
Re: j2sdk build-depends cannot be satisfied?
Ola == Ola Lundqvist [EMAIL PROTECTED] writes: So, here's my (hopefully) final question. I think I have addressed everyone's concerns with this Depends line: Depends: kaffe | java-virtual-machine, kaffe | java-runtime, java-common Ola If you change java-runtime to java1-runtime it is perfectly Ola correct. java1-runtime java2-runtime should provide a superset of java-virtual-machine and therefore you shouldn't need both. Suggests/ecommends/Depends on java-virtual-machine should only be for those systems tah make *no* use of the java.* classes (the semi-mythical project to make perl emit java bytecode springs to mind). -- Stephen A duck!
the developer in me
Hello,
if I understood it correctly, this is the place to get started,
right? A short while ago, I wrote a ppp-monitoring program in Perl,
which I consider to be of good value. As far as I'm concerned, I use
it every day. I also know of the pppstatus package but it lacks
some functionality I would need. On the other hand, I don't consider
my program as a replacement for the former one.
However, I was thinking about uploading it to the archive and
sharing it with others. I've also packaged it.
But as far as I know, someone here has to support me, right?
So, please, tell me how to procede, if at all.
andrej
(I have not included it here for I fear that you can -- with
possible good reasons -- reject me even prior to looking at it.)
--
echo ${girl_name} /etc/dumpdates
Re: user for getting files
David Roundy wrote: On Fri, Nov 22, 2002 at 11:04:27AM -0800, Blars Blarson wrote: but is it realy appropriate for a package to create a new user for a weekly download? depending upon what other processes will be using the data, and those that will be starting them, the answer varies from ``maybe'' to ``yes!'' I'm far from an expert, but I would have thought that 'nobody' would be appropriate for this. _no_. you never want a file owned by nobody. services that do not need any elevated privedges should run as nobody, so if they are compromised, then can do nothing. if you download a file as nobody, then a compromised nobudy-running daemon can then trojan that file. bad. As long as you don't trust the content of those files, this seems safe to me. there are other reasons to not trust the file, other than the ownership (dns cache poisoning, dns takeover, trojans on the server), so we can accept this as a truism. -john
Re: j2sdk build-depends cannot be satisfied?
Stephen Also, WTF is with all the Architecture: all' -java packages Stephen that only depend on java-common? While I guess they're Stephen installable without a java runtime on this system, they're a Stephen completely unusable in that sate. I made this point when Ola discussed the java policy. gcj can compile java bytecode into native code. So Architecture: all java libraries can be used for development purposes without an interpreter. In theory, at least. -- Ian Zimmerman, Oakland, California, U.S.A. I did not vote for Emperor Bush. GPG: 433BA087 9C0F 194F 203A 63F7 B1B8 6E5A 8CA3 27DB 433B A087
Re: j2sdk build-depends cannot be satisfied?
Followups set to debian-java where this is a little more on topic. Ian == Ian Zimmerman [EMAIL PROTECTED] writes: Ian gcj can compile java bytecode into native code. So Ian Architecture: all java libraries can be used for development Ian purposes without an interpreter. Yes, and I can statically compile binaries so that the don't depend on lic6 (the provider of /lib/ld-linux.so.2) but that's hardly the normal usage. -- Stephen Sixty percent of all Americans say they flew the flag after Sept. 11, 2001. Last week, less than 40 percent of registered voters cast ballots. Americans who wrap themselves in patriotic colors, yet can't be bothered to exercise the most fundamental right and responsibility in a democracy, betray the country they claim to love. -- Christina Hulbe, Letters to the Editor, The Orgeonian, 10 Nov. 2002
Re: j2sdk build-depends cannot be satisfied?
Stephen == Stephen Zander [EMAIL PROTECTED] writes: Stephen Followups set to debian-java where this is a little more Stephen on topic. Excpet that I forgot to actually set the header. Bah. -- Stephen And what do we burn apart from witches?... More witches!
