Re: Packaging ltp selinux tests
On Tue, 05 May 2009 18:20:15 +0200, Manoj Srivastava sriva...@debian.org wrote: On Mon, May 04 2009, Riku Voipio wrote: On Mon, Apr 06, 2009 at 10:13:39PM -, Jiri Palecek wrote: I'd like to package the selinux tests from the ltp test suite. The tests need a special selinux policy to be loaded and some files to be relabeled. I haven't found any standard way of packaging this, so I made an experimental package (see [1]; it sort of works - not completely, like 10 tests out of 30, but that's not an issue now) and I would like to hear your opinion on these issues: 1. The package loads the policy on postinst configure with semodule -i, is that right? (And did I implement it properly in the scripts?) There were some avc message during package install (semodule was denied access to a terminal with type apt_t), can this be solved? I am not yet comfortable with my security policy changing just because a package is installed. So far, even the policy packages do not install the new policy, letting the security officer audit and manually install policy. OK. Would you be comfortable with a debconf question on the subject, then? Having security policies change automatically seems contrary to the whole idea of buttoning down security, so this change is not likely to happen. As long as it fails gracefully is semodule binary is missing or selinux isn't enabled. 2. The relabeling has to be done manually with fixfiles relabel; is there a way to do it (and should it be done) automatically? The same applies here. Having packages relabel files is one way to potentially allow your security to fly out of the window. How should I convey information about the contexts of the files in the package? 3. The runtime packages depend on selinux-policy-default; should it (alternatively) depend on the other policies too? Would this need a separate policy package? Well, currently, selinux-policy-default is the only one being worked on. 4. Should the policy package be in /usr/share? Which policy package? The .pp file. Regards Jiri Palecek -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: dpkg-shlibdeps question
On Mon, 04 May 2009 19:07:18 +0200, Raphael Hertzog hert...@debian.org wrote: On Fri, 01 May 2009, Jiří Paleček wrote: should almost never happen (except diversion) and the result when it happens is Should I read it as the only legal situation where it returns multiple packages are diversions (the rest are errors) or the majority of situations ... are diversions, ie. does it make sense to return multiple packages in the absence of diversions? dpkg -S can return multiple packages for directories too since they can be shared by many packages but in the case of real files AFAIK it can only happen with diversions. Ok. Thanks. Yes, but I think this is unattainable. Especially when doing transitions, you're not likely to have both packages in sync. I don't see why it would be so difficult. Diverting a file means that you have a drop-in replacement and I don't see why you couldn't provide dependencies that are compatible (even if not exactly the same). Yes, you can make it compatible (although I'm not sure what exactly you mean by compatible). Or maybe even the same, but when things change, it has to be maintained, which doesn't happen automatically. I just wanted to know if it would be OK for dpkg-shlibdeps to use only one package for a library (eg. in case of diversions, use dpkg-divert to find the right one) and fail in case of ambiguity. What is the right one, the non-diverted one ? I'd say so. If the purpose of dpkg-shlibs is to translate shared object dependencies as viewed by ld.so into package dependencies for dpkg, it seems to me the correct package(s) to depend on is the one that provides the binary that was used for the build (let's put aside the situations when no package contains the library used, eg. it was provided by the user who overwrote the file from the package). Regards Jiri Palecek -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: dpkg-shlibdeps question
On Thu, 30 Apr 2009 17:00:12 +0200, Raphael Hertzog hert...@debian.org wrote: On Thu, 30 Apr 2009, Jiří Paleček wrote: Yes, but even then, libGL.so.1 (the one used for building a package) is only mentioned in one symbol file, namely the one from nvidia-glx, isn't it (let's put aside the package doesn't feature a symbol file)? Why should the libgl1-mesa-glx symbol file, if it existed, be taken into account? We could maybe help you if you told us to what part of the code you refer when you say that a single library can be mentioned in two different symbols files ? The code is what it is for many reasons including the fact that dpkg -S can return multiple packages for a single lib file. In practice, it Exactly, that's the thing I'm referring to. should almost never happen (except diversion) and the result when it happens is Should I read it as the only legal situation where it returns multiple packages are diversions (the rest are errors) or the majority of situations ... are diversions, ie. does it make sense to return multiple packages in the absence of diversions? not specified (in the doc at least). In practice you might get a mix of both dependencies and to avoid any problem the packaging of the diverting library should simply stay compatible to the one of the official library (i.e. generate the same dependencies). Yes, but I think this is unattainable. Especially when doing transitions, you're not likely to have both packages in sync. I just wanted to know if it would be OK for dpkg-shlibdeps to use only one package for a library (eg. in case of diversions, use dpkg-divert to find the right one) and fail in case of ambiguity. Regards Jiri Palecek -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: dpkg-shlibdeps question
On Wed, 29 Apr 2009 19:40:12 +0200, Josselin Mouette j...@debian.org wrote: Le mercredi 29 avril 2009 à 18:51 +0200, Jiří Paleček a écrit : I've hacked a little into dpkg-shlibdeps and while doing this, I've found that the code makes allowance for a single library being mentioned in two different symbol files. I'd like to ask if (and when) can such situation actually arise. My first guess would be nvidia-glx and its diversion of libGL.so.1. Yes, but even then, libGL.so.1 (the one used for building a package) is only mentioned in one symbol file, namely the one from nvidia-glx, isn't it (let's put aside the package doesn't feature a symbol file)? Why should the libgl1-mesa-glx symbol file, if it existed, be taken into account? Regards Jiri Palecek -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
dpkg-shlibdeps question
Hello, I've hacked a little into dpkg-shlibdeps and while doing this, I've found that the code makes allowance for a single library being mentioned in two different symbol files. I'd like to ask if (and when) can such situation actually arise. Regards Jiri Palecek -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
swfdec0.6 buildd failure
Hello, I was looking at the swfdec0.6 package and wondered why it is unavailable on almost all architecture. So I looked at the build logs and they (almost) fail in a quite strange way. It seems apt installed a broken set of packages (even though a package set satisfying the build-dependencies was -probably- available). The build thus failed. See http://experimental.debian.net/fetch.php?pkg=swfdec0.6ver=0.6.0-1arch=powerpcstamp=1203904370file=logas=raw Is this a bug in APT? Regards Jiri Palecek -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
RFP: tijmp -- memory profiler for java 6
Package: wnpp Severity: wishlist * Package name: tijmp Version : 0.3-pre1 Upstream Author : Robert Olofsson * URL or Web page : http://www.khelekore.org/jmp/tijmp/ * License : GPL Description : memory profiler for java 6 TIJMP is a memory profiler for Java 6. It is similar to the jmp memory profiler, but unlike it, works with Java 6 (using JVMTI). It is written to be fast and have small memory footprint. The user interface uses swing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391667: RFP: qshaderedit -- shader editor
X-Debbugs-CC: debian-devel@lists.debian.org Package: wnpp Severity: wishlist * Package name: qshaderedit -- shader editor Version : 0.1.2 Upstream Author : Ignacio Castaño, Karl Robillard and Lars Uebernickel * URL or Web page : http://castano.ludicon.com/page.php?page_id=118 * License : GPL Description : A shader editor QShaderEdit is a simple multiplatform shader editor inspired by Apple's OpenGL Shader Builder. It supports ARB programs, GLSL shaders and CgFx effects. Shaders are small programs which run on the GPU during the rendering process. They can be used to implement anything from some special lighting model to raytracing or Voronoi diagram display.
Re: Aptitude question
On Wed, 04 Jan 2006 19:50:14 +0100, Linas Zvirblis [EMAIL PROTECTED] wrote: Jiri Palecek wrote: How does aptitude decide which one to choose? Shouldn't it prefer to do something that won't break other packages? Or should it ask the user for help? As for your problem, you must provide way more information than just it does not work in order to get help. There are at least five different versions of aptitude you could be using on whatever version of Debian you use. Most of us cannot read minds, especially over the Internet. If you had read (at least the written protion of) my mind more carefully, you would realize that I have never said it does not work. I thought it more as a feature request (or idea) than bug report. I was asking about how is aptitude supposed to solve such situations, beacuse it isn't clear if it really should try to guess the correct packages to install. If you don't quite understand the exact situation I'm talking about, I've created a testcase. Download http://www.ms.mff.cuni.cz/~palej3am/testbed.tar.bz2 unpack it, and run APT_CONFIG=path_to_hte_enclosed_apt.conf aptitude Then, try to install A. This will, in my version of aptitude (0.2.15.9-7), breaks package D. However, the constraints are satisfiable by downgrading package B. I was only asking if it will/can/should install dependencies so as no packages are broken, because it could be quite difficult. Also, there could be more solutions to the problem (in my example, removing D also solves the problem -- it is up to the user to decide). Another option would be interactively ask offering the possibilities of satisfiying valuations, or prefering breaking only new packages and leaving old packages alone (i.e. don't even try satisfy the dependency on A, when it leads to breaking a package already installed). Anyway, installing vtk-tcl (that depends on xlibmesa-gl | libgl1 and libglu1-xorg | libglu1) on my box did not break anything. As you had already noted, it greatly depends on the particular system (you don't wanna read my /var/lib/dpkg/available and status, do you?). I thought it more as an illustrative example.
