Re: [SoftwareSuspend-devel] 2.1-final for 2.6.8.1
Hi, > > SElinux is not supported by debian. the grsecurity situation isn't > > much different. > For SELinux. the kernel has the code; the archive has the user-space > tools. Believe me, I'm running SELinux on a couple of sarge boxes. Debian SELinux support is incomplete. You need a patched init, for example. rjc has a separate repository for these. You don't want a libselinux dependency from sysvinit for mainstream in Debian was the reasoning. So no way to run SElinux with 100% sarge. And you better take the rules from CVS, too. > I don't see how this is any different to what I propose with > swsusp2. I will package it. If you oppose to have this patch in > stable, please discuss it on debian-devel. [Added CC: to debian-devel] Yes. I claim that it doesn't make any sense to have software-suspend2 patches in Debian stable, because of all the driver issues remaining with 2.6.8.1. I've been running swsusp2 for a long time now, and I'm sponsoring the hibernate script debian packages. Believe me, I have considered doing a patch package. > > It requires the USB modules to be unloaded before suspend. This > > implies you must not compile them statically into the kernel. > > Similar things apply to other drivers. > > I see no problem with this on Debian kernels, which are modular. The patch will not be included in Debian kernels, but will be used by the user to build his own kernel. Which will likely be not pure modular, but maybe just break swsusp. > As soon as Pavel merges swsusp2 into 2.6 ... Which will not be in 2.6.8.1 > > But those who build their own kernel will either go for a more > > recent kernel, or will likely change some options and end up with > > a non-working suspend due to driver problems. and this will > > reflect back badly on both debian and swsusp2. > > Debian assumes that those who compile their own kernels know what > they are doing. I don't see a point in trying to nanny them and > prevent them from screwing up their systems. There are plenty of > other ways to do so too. Heck, just let them get a recent kernel and be much better off! Put the kernel and the swsusp patch into "volatile". Gruß, Erich Schubert -- erich@(mucl.de|debian.org) -- GPG Key ID: 4B3A135C(o_ To understand recursion you first need to understand recursion. //\ Wo befreundete Wege zusammenlaufen, da sieht die ganze Welt für V_/_ eine Stunde wie eine Heimat aus. --- Herrmann Hesse
Re: [SoftwareSuspend-devel] 2.1-final for 2.6.8.1
Hi, The users who will use software-suspend on non-laptops are even less. How many of those are going to run 2.6.8? > > The patch will not be included in Debian kernels, but will be used > > by the user to build his own kernel. Which will likely be not pure > > modular, but maybe just break swsusp. > > This is a problem anyone using the patch will face. And anyone using > any patch faces this problem. No. If the drivers get fixed in newer versions - and some are already, I think - they will not have this problem. At least not to that extend. > Btw: can't the swsusp2 patch force USB module support? I see it with > other kernel options. E.g. switching SCSI from y to m will > automatically force all SCSI drivers to be m as well. There is a dependency from the scsi drivers to the scsi core. You don't have that with swsusp, so I fear it might not be possible. You can only disable building of swsusp - or have an #error statement maybe. But I'm not deep into kconfig, so maybe this is possible. But it is kind of odd, changing options at a completely different place. Well, since apparently it isn't much work for Nigel, have your way. Hmm... I could be evil(tm) and just file an important bug against your package. Being incompatible with usb-built-into-kernel is certainly that severe. Breaks unrelated stuff would be even higher (it completely trashes my firewire apps!) Greetings, Erich Schubert -- erich@(mucl.de|debian.org) -- GPG Key ID: 4B3A135C(o_ To understand recursion you first need to understand recursion. //\ Wo befreundete Wege zusammenlaufen, da sieht die ganze Welt für V_/_ eine Stunde wie eine Heimat aus. --- Herrmann Hesse
Re: Fonts packages maintenance team (second) proposal
Hello Christian, I'd join, but mostly to give up my maintainance of ttf-larabie packages. ;-) (read: a Debian Font Strike force is officially welcomed to adopt my package) > Bring improved maintenance of font-related tools > > The project could also include the maintenance of font-related tools, > such as fontforge or defoma (only with agreement of their respective > maintainers who are highly welcomed in the team). This definitely is needed. Defoma has huge scalability problems. At least it had the last times I tried to "defomize" my font packages. It tooke hours to install these packages due to defoma. best regards, Erich Schubert -- erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C(o_ You know we all became mathematicians for the same reason: //\ we were lazy. --- Max Rosenlicht V_/_ Die Freunde nennen sich aufrichtig. Die Feinde sind es: Daher man ihren Tadel zur Selbsterkenntnis benutzen sollte, als eine bittere Arznei. --- Arthur Schopenhauer signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
DebBugs and Bugzilla synchronization
Hi, I've written a small perl script that queries the debian bug tracking system for bugs forwarded to bugzilla (gnome in my script; it needs to have a XML interface) and makes a list of them and their status in bugzilla. Example output (galeon): http://people.debian.org/~erich/debugzilla-galeon.html This is nice for tracking which of the "forwarded" bugs were closed (fixed, invalid ...) by upstream. The script itself can be found at http://people.debian.org/~erich/debugzilla-html.pl.renamed.txt with the HTML::Template at http://people.debian.org/~erich/debugzilla-html.tmpl it depends on libxml-perl, so it does (currently) not run on master itself or klecker. Just run it on your home machine. ;) This is just a small helper, some real integration of debbugs with bugzilla would be cool, like debbugs subscribing to the upstream bug and automatically tagging the bug "pending" when fixed upstream? Greetings, Erich Schubert -- erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C(o_ To understand recursion you first need to understand recursion. //\ Ein Freund ist ein Geschenk, das man sich selbst macht. V_/_
Re: Have Linux boot with eye-candy
Hi, i have built packages for the bootsplash tools (no package for the patch itself though. just download and apply the diff). They are available on http://people.debian.org/~erich/boot/bootsplash/ and work fine on my notebook as well as my sisters. I didn't get the bootsplash support of swsusp working though; but maybe i just forgot applying that "connector" patch... ;) No AA Text rendering yet (what text to use? that would require modifications to the init scripts... i didn't build this fbtruetype tool yet, but i probably is as easy as the rest) and no animations (packages are built, but i don't have nice animations, i'm no artist. ;) ) Progress bar is working fine if you use the supplied rc.splash (just change it in /etc/inittab) You'll find a theme i built for Debian there, too. It uses a really cool background made by Alexis Younes (ayo), http://www.73lab.com/ -- unfortunately i don't know if it is DFSG-free. using the debian logos it probably isn't. ;) Greetings, Erich Schubert -- erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C(o_ There was never a good war or a bad peace. - Benjamin Franklin //\ Die kürzeste Verbindung zwischen zwei Menschen ist ein Lächeln. V_/_
Re: [RFC] Changing priority of selinux back to optional
Hello Frans, Hello fellow DDs, Yes, the SELinux stuff doesn't seem to have any currently active developers. I haven't heard anything from Manoj in months. I had to stop working on SELinux myself for various reasons; it's not that things didn't work, but it was a mixture of personal reasons (mostly lack of time, and no longer being responsible for the servers I was using SELinux on) but also largely a motivational thing, that I didn't feel people really cared much about it. Most of the time when you'd just mention SELinux, people would basically be scared and run away. This is largely due to FUD efforts by the AppArmor folks, who - incorrectly - framed SELinux as being overly complex. Just recently, at the Google Android Developer Thingy here in Munich, someone (in the informal discussions around dinner) again suggested something along the lines of automatically creating users to separate applications that could easily be squashed using the SELinux stuff. SELinux works the same way uid and gid work, so it just isn't really that complex. All the difficulties lie in writing good restrictive policies; and that doesn't get any easier if you do some uid/gid magic... Anyway, back to the original topic: 1. I agree that SELinux currently is not in shape for a release. The packages are seriously outdated, there have been some major changes in upstream. In particular, the 'targeted' and 'strict' policies have been merged and only differ by having a 'targeted' module installed. AFAIK. 2. At least libselinux is linked by many of the core packages, and the package REALLY should be updated nevertheless. However that might require also updating most of the other packages; I'm not sure about API compability. 3. In my experience, none of the SELinux librarys or applications were particularly hard to package/maintain. All the hard work is in fine-tuning the policy to support all the Debian-specific stuff. Especially when you need the cooperation of other maintainers, such as initscripts: http://bugs.debian.org/390067 cron: http://bugs.debian.org/333837 liblzo1: http://bugs.debian.org/336138 All of which have been open in the range of 1.5-2.5 years. I pushed fixes for some of these issues (e.g. amavis). Usually the best way is to split out a specific part of the init script (such as the part doing the backups of /etc/shadow) into a separate script. This is not a particularly hard change, but you can face a lot of resistance. So in fact, the situation for SELinux-related bugs not in the actual SELinux packages is even worse. So maybe it would be better to actually get some people involved in SELinux again. It's a pity to see the AppArmor FUD work this well. (Albeit AppArmor didn't make it into mainstream kernel or Debian, and I remember having seen some news message last year that Novell stopped development of AppArmor?) The AppArmor WNPP bug has been open for months without any message, too: http://bugs.debian.org/440680 This makes me wonder if we actually have enough developers working on security infrastructure and the core system in general. Actually I have the impression in general (not only with respect to security) that we're losing developer share, but I can't tell you where people are going to instead. Ubuntu didn't recently strike me as being more attractive, and their SELinux and AppArmor stuff is as outdated/stalled as ours. It's mostly Fedora/Gentoo (for SELinux) and SuSE (for AppArmor) that seem to be doing progress here, but probably only because there are a few single persons pushing the stuff for the distributions they use themselves. best regards, Erich Schubert -- erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C(o_ The future is here. It's just not evenly distributed yet. //\ Die Freunde nennen sich aufrichtig. Die Feinde sind es: DaherV_/_ man ihren Tadel zur Selbsterkenntnis benutzen sollte, als eine bittere Arznei. --- Arthur Schopenhauer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] Changing priority of selinux back to optional
Hi everyone, There is no real "SELinux team" anymore that could say yes or no to anything I figure. The SELinux people at Debian were mostly Manoj, RJC and myself. I havn't heard anything from Manoj in months, I'm not able to do any actual SELinux work anymore and while RJC updated his SELinux Demo machine (http://www.coker.com.au/selinux/play.html) at some point, I havn't heard any plans from hin to 'revive' SELinux in Debian, but he is actively advocating SELinux and actively blogging: http://etbe.coker.com.au/tag/selinux/ and he has some somewhat-updated packages in his repository: http://www.coker.com.au/dists/etch/selinux Make sure to talk to him, but other than that I'd suggest you just hijack/NMU the relevant packages. There is an updated policy package I did early this year at http://selinux.alioth.debian.org/experimental/refpolicy/ which is after the strict/targeted merge. It's also using my own packaging, it's not based on Manojs work. He reproduced some of the things I did in Perl, while I'm still using my python+sh code, which in my opinion is superior in some cases I believe (I never tried his packages!). I don't know if his module auto installation still loads one module after the other, or if it's done in one pass like I do. I also introduced some module guessing and upgrading (!) code I don't know if he has yet adopted, so make sure to investigate both packages. Make sure to also investigate the new Ubuntu efforts that Reinhard pointed out. It would be best to join efforts here. Caleb Case is using a tresys email address, that is where refpolicy upstream lives. best regards, Erich Schubert -- erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C (o_ A man doesn't know what he knows until he knows what he doesn't know. //\ Es lohnt sich nicht, die Augen aufzumachen, V_/_ wenn der Kopf im Sand steckt. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: [RFC] Changing priority of selinux back to optional
Thanks, Manoj, for this powerful 'comeback'. Looks like you've updated most of the packages already; at least the non-GUI ones (which are the ones I care most about, I never really got the hang of the UI apps). Don't forget we'll also (AFAIK) need updates to PAM and OpenSSH. These two are very important. We still might want to share efforts with the Ubuntu folks, especially if TreSys is involved there. I know that you don't like CDBS, but I find it rather easy to use, whereas I never got around to dig into your make system (I admit that this might be just because I wasn't willing to spend the half hour or hour of concentration that I would have needed for this). When I was doing backports for sarge (I guess) a long time ago, it felt easier for me to redo them in CDBS than to find out how to remove python-support and do manual python packaging in yours. It would make sense to use a common 'codebase' for the Ubuntu and the Debian stuff, but I'm not sure about the package quality of the Ubuntu packages - at least they lack the usual upstream/diff split. I had a quick look at the libselinux package, and it was using CDBS. It's a very unfortunate situation that you don't use CDBS and many others (just judging from the reports I've seen here, I'm not the only one who said he decided to use CDBS instead) don't get the hang for your build system. This doesn't make it easier to get more people involved. But as long as you are around and updating the packages it's not at all important - you're doing the job, so you get to decide. EOD. P.S. If anyone wants to adopt the "selinux-basics" package, go ahead. best regards, Erich Schubert -- erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C(o_ Which is worse: ignorance or apathy? Who knows? Who cares? //\ Wer keine Zeit mehr mit echten Freunden verbringt, der wird bald V_/_ sein Gleichgewicht verlieren. --- Michael Levine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#416996: ITP: stereo -- Mono (.NET) extension for running multiple applications
Package: wnpp Severity: wishlist Owner: Erich Schubert <[EMAIL PROTECTED]> * Package name: stereo Version : 2.0 beta * URL : http://www.mono-project.com/Stereo * License : LGPL Programming Lang: C# Description : Mono (.NET) extension for running multiple applications Stereo is an extension to the Mono (.NET/C#) platform for running multiple applications at the same time. As you probably know, C# is a language using a bytecode, called CIL: Common Intermediate Language. Using code in an intermediate language has benefits for platform and operating system independence (Java is the most prominent example of this approach), however it also means an overhead when running the applications. Various approaches have been tried to remedy these effects, such as JIT (just in time) compilers translating the bytecode to native code when needed. Applications running based on such bytecodes tend to use more memory than regular applications (for example, they need to keep the compiled code in writeable memory, whereas regular applications can use shared read-only memory for this), and you probably have heard many people complain about the memory usage of Java and .Net applications. Some people even claim the Linux .NET platform is called "Mono" because you can run at most one such application at the same time. That how "stereo" was born: an extensions to run two (or more) applications in the same mono environment, thus reducing the memory overhead significantly, and making it useful for more people. Future versions should even be able to run Python (using IronPython) and eventually Java applications in the stereo runtime. It is also planned to add support for multiple user operation. So eventually, it will be able to replace your whole system. The project will then also change it's name to Multics, to reflect it's unique multi-user capabilities. At least if we get enough funding by Dunc-Tank, who is currently sponsoring all our development efforts. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sid SELinux packages are now working
Hello Manoj, > I think we need to create a tool that can update your policy > setup, taking into account any new packages you might have installed in > the meanwhile and loading new modules as needed. This is the first Like the "update-selinux-policy" command in my packages does? http://svn.debian.org/wsvn/selinux/refpolicy/branches/debian-pkg/debian/utils/update-selinux-policy > An initial approach would be to have this utility be given a > package name on the command line, and it will see if there is a > corresponding selinux modular policy module, and install the policy or > update it as needed (if selinux is enabled, of course). If the module > is already installed, it should do nothing. Actually it might also make sense to update the modules with the latest version in the same run. What my script doesn't do yet is check version numbers. It will just re-run the autodetection and install any module that was already installed or that was automatically detected. So you can't 'blacklist' a policy module, and if you replaced it with a modified custom one, it will also be replaced. Local modifications in separate modules will of course be kept. best regards, Erich Schubert -- erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C(o_ To understand recursion you first need to understand recursion. //\ Denken ist oft schwerer, als man denkt. V_/_ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sid SELinux packages are now working
Hello Manoj, > Hmm. Python. I think I looked at that when I implemented the Well, that script actually is shell. The python script is what I use to do the autodetection magic. > SELinux policy modules and debian packages, which discovers the > relationships between modules and orders the policy load correctly, so > that it can pull in any dependency as required. Yep, I'm generating them on compile time in my packages and storing them in an auxillary file. shipping another 1k file with the package felt nicer to me than computing it on install time. > I was thinking of looking at the module, and updating it if it > was different -- whether or not the version changed. Yes, I am lazy. > md5sum mismatch, refresh module. I don't think this is a good idea. If I have (for whatever reason) to modify a policy module, I'd like to be able to bump the version number a bit to avoid it from being updated. Like bumping it to 2.x; it will be some time until refpolicy uses 2.x version numbers and by then the policy module will be worthless anyway. That way, if we'd e.g. have to do a security update for the policy package, this customized module wouldn't be updated. I don't think there is a big cost in replacing modules with the exact same version (they'll be processed anyway; AFAIK we don't modify the compiled policy, but instead it's assembled again from the .pp files?) At least not if you do all the processing in one step; doing a single semodule -i call of course isn't cheap. So please use the version numbers in the modules. > Hmm. I had not thought about blacklisting modules. I think, if > you have a local module that overrides a refpolicy module, and so you > don't want to have the module changed at all, it should be easy enough > to implement a configuration file which sets a blacklist variable. And it would be a very easy to understand behavior, nicer than the version numbers. But I still wouldn't skip the version checking. best regards, Erich Schubert -- erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C(o_ Reality continues to ruin my life --- Calvin//\ Die kürzeste Verbindung zwischen zwei Menschen ist ein Lächeln. V_/_
Re: [DSE-Dev] Re: Sid SELinux packages are now working
Hi, > OK. Given a .pp file, how _do_ you detect what version it is? For installed modules, we can just use "semodule -l" I havn't tried it, but there is semanage.semanage_module_get_version in the python semanage bindings. I don't know if this only works for installed modules or for packages. But I'd suggest to add an option to "semodule" like --stat or so that we can use to query the version number of a .pp file. That should be doable. best regards, Erich Schubert -- erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C(o_ To be trusted is a greater complement than to be loved. //\ Nur der ist weise, der weiß, dass er es nicht ist. --- Sokrates V_/_
Re: Fixing up SELinux reference policy for Debian
Hi Manoj, Thanks for the work on getting SELinux strict working! Are you using an initrd and/or udev in your UML? > I think we need to create debian specific policy changes to > allow searching /var, /var/lib. and /var/lib/dpkg. We also read file > permissions on files in /var/lib/dpkg; and these need to be added to a > generic user. IMHO that is okay. > After that, I need to start branching out, and adding, say, > apache2 servers to my UML, and checking validity of strict policy. We'd also need people to work on e.g. an exim and a tomcat policy. > Given the magnitude of these changes, I am planning on trying to > do a backport of SELinux packages for Etch, at least, for the current > release, before the kernel requirements diverge too much. I'm with you on that. We really should provide backports to offer powerful SELinux support for etch. There are just too many small issues with etch that break it one place or another. (Such as liblzo breaking openvpn; http://bugs.debian.org/336138 ) We should try to get SELinux *strict* on etch into shape so people can use it on firewalls (including openvpn and IPSec), common mail and web server setups with little effort (well, lets say 'without cgi and complex PHP things' because that is an endless field then). Maybe propose them for a maintainance release even. best regards, Erich Schubert -- erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C(o_ There was never a good war or a bad peace. - Benjamin Franklin //\ Die kürzeste Verbindung zwischen zwei Menschen ist ein Lächeln. V_/_
Re: Sid SELinux packages are now working
Hello Neil, > > > Yep, I'm generating them on compile time in my packages and storing them > > > in an auxillary file. shipping another 1k file with the package felt > > > nicer to me than computing it on install time. > > > > That's fine as long as the dependencies don't change due to local > > modifications. > How would that method cope with a cross-build? Emdebian has already > built some selinux packages from the Debian sources for a rootfs and We're talking about policy package dependencies, not about debian package dependencies. These dependencies mean that the foobar.pp policy package can't be installed unless quux.pp is also installed. If you want to change that for Emdebian, you'll be building a different policy, and then you can just include a different dependency file with that policy. Now refpolicy is already very tight on permissions; I don't think you'll really want to further narrow down permissions for Emdebian (though you e.g. could put perl into a separate domain and then prevent some domains from executing perl... right now, any process that can run /usr/bin/less can also run /usr/bin/perl) best regards, Erich Schubert -- erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C(o_ Reality continues to ruin my life --- Calvin//\ Mathematik: Das Alphabet, mit dessen Hilfe Gott das UniversumV_/_ beschrieben hat. --- Galileo Galilei -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libpkg / libupt / libept gets popcon support
Hi Enrico, Keep up the good work. :-) the name of the new library is still in flux, and maybe it'll end up with the name 'libept' and replacing the libept we have now. I have to admit, that with "libpkg" I'd expect to find something working on the actual packages, whereas your library is working with metadata on the packages, mostly for finding them. Maybe something along libipkg or libinfopkg is more appropriate? best regards, Erich Schubert -- erich@(mucl.de|debian.org) -- GPG Key ID: 4B3A135C(o_ To understand recursion you first need to understand recursion. //\ Wo befreundete Wege zusammenlaufen, da sieht die ganze Welt für V_/_ eine Stunde wie eine Heimat aus. --- Herrmann Hesse
Re: "Semantic" shell? (for lack of better name)
Hello Bryan, I've thought about similar efforts, much were centered about having a generic "command line syntax definition language". Not every application can be squeezed into the input, output scheme. The situation with multiple inputs, single output is common. Neither can every application convert every input to every output, sometimes just particular combinations might be possible (in particular, input format might have to be the same as the output format). Then there are "meta formats", especially compression. For example gzip will convert any file type to the same file type but gzip-compressed (or the other way round using gunzip). So a tool trying to "magically" build chains would need to understand that while gzip can process the "*/*" mime type, it won't convert the file type, whereas 'convert' can convert next to any image file type to next to any other image file type. But for example to convert text/plain to image/gif with convert, you should also specify a font... The debtags efforts do a very minimal approach here: they use 'looser' file types than MIME and they do not differentiate between input, output or whatever-put. There are some benefits from that, including - less information needs to be collected and updated - the information is more likely to be accurate obviously at the cost of the information being less useful. At some point you need to make a cut. At some point I was considering to actually use RDF-like triplets such as "app1 reads image/gif" "app1 writes image/jpeg" etc. but we ended up to going a tuplet-only approach for complexity reasons. Of course things have made progress since. For example, the .desktop files usually include useful information about which MIME types an application supports (unfortunately, many non-GUI-application still do not ship with .desktop files), but the information there also has some kind of "vagueness". So it might well be time to do the next step and collect such meta information on a "reads" "writes" "displays" "prints" and whatever basis. However collecting all this data sounds like a huge task to me. I mentioned before that I was also thinking about a "command line syntax definition language". The reason is that command line programs vary a lot in how parameters are passed. There are certain common standards such as GNU getopt command line syntax (i.e. single letter options with a single dash, long options with a double dash, single letter options can be joined ...), but there are also tons of exceptions (e.g. "java -version" is different from "java -v -e -r -s -i -o -n" and would have been "java --version" in getopt style). A specification of the available options in some meta format ideally would also give an indication of valid file types for file name parameters. But also note about mutually exclusive options. And it is obvious that not all command line can be described this way completely (e.g. to fully validate "perl -e 'perl expression'" you'd need to be able to validate perl syntax ... and "only perl can parse perl". So you'll never know what MIME types that statement accepts ...) A solution covering 90% might still be very nice to have. I believe that a "semantic shell" might need to be based around the command line interface of the applications. best regards, Erich Schubert -- erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C(o_ Reality continues to ruin my life --- Calvin//\ Der Anfang aller Erkenntnis ist das Staunen. --- AristotelesV_/_ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: "Semantic" shell? (for lack of better name)
Hello Bryan, > > At some point I was considering to actually use RDF-like triplets such > > as "app1 reads image/gif" "app1 writes image/jpeg" etc. but we ended up > > to going a tuplet-only approach for complexity reasons. > > we? who? Any working code that I could go poke? The Debtags developers, in particular Enrico and I. But that was at the earlier planning stage, and to a certain extend the current tags can be read as triplet (works-with, uitoolkit can be read as "uses ui toolkit" etc.), but we have a very restricted set of verbs, and the implementation treats verb+object pretty much as a union. A triplet-based approach should probably really be based on RDF and use the existing tools for that instead of reinventing the wheel. > Another response to my email included a link over to > 'open-with-install', a program to query the apt repositories to find a > program to open a certain file with, which is a good step in that > direction. But yes, there is a vagueness involved in .desktop too. This apps data might actually be just derived from the .desktop files. I don't know the details, but that is what comes in mind. In particular since Gnome would only suggest opening the file with the application after installation when it has a matching .desktop file IIRC. > > So it might well be time to do the next step and collect such meta > > information on a "reads" "writes" "displays" "prints" and whatever > > basis. However collecting all this data sounds like a huge task to me. > > Yikes, there are so many of those verbs though - you'd basically be > doing Cyc or WordNet all over again. Each program technically > qualifies as a new verb too, so the usefulness seems to deteriorate. In fact, using data from WordNet etc. is something that immediately comes to mind, especially for not reinventing the wheel. You will need to make a cut somewhere though, the latest when it comes to UI. Probably already for data input. Selecting a subset of WordNet might still be a good idea for data exchange. > "perl -e" accepts a string of text data (I don't think binary data > works). Whether or not the string is valid in terms of perl syntax > (etc.) is another issue entirely, isn't it? Not really. It's just a question of complexity. Many applications have some "file type" parameter. For "convert" IIRC you can prefix the file name with a file type, e.g. "gif:-" to force output in gif format on stdout. So where is the difference in having "gif:" as a prefix of the output parameter (which happens to not just be a plain filename!) or having a full perl program there that does the gif generation? Except that you can cover one with a regexp I guess, and the other not. You have to make compromises somewhere. P.S. autocompletion data files of zsh and bash might be a useful starting point, too, btw. best regards, Erich Schubert -- erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C(o_ Friends are those who reach out for //\ your hand but touch your heart. V_/_ Das größte Hindernis beim Erkennen der Wahrheit ist nicht die Falschheit, sondern die Halbwahrheit. --- L. N. Tolstoi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)
Daniel Burrows wrote: > (e) I've heard about a "debtags" database system that's trying to > find a general solution to the problem of categorizing packages. > I took a look at their library at one point and wasn't able to > figure out how to use it, but if this project is still going > somewhere, supporting it in aptitude would be nice. You can try out debtags either via the web interface at http://debian.vitavonni.de/packagebrowser/ or by installing the "synaptic-debtags" package, which has a debtags view. (In "views", select "tag view") Thanks to mvo and enrico for doing this synaptic integration at debconf. Of course there is still room for improvement, but this is the slickest interface i know. ;-) This to improve in synaptic-debtags: - make the tree less deep, don't make subfolders if only < 10 packages are left etc. - show tag descriptions. - handle "virtual" tags in the tree, such as "ui", which basically is a union of "ui::gtk", "ui::qt", "ui::ncurses" etc. (virtual tags: tags where all packages are in a subgroup) Things to improve with debtags in general: - more tagging. Too many packages are still untagged - inconsistent tagging. New tags were added, so many tagged packages are incompletely tagged. For example many applications don't have a user interface specified. - inconsistent tags. some features have tags, others don't. - structure is becoming to deep IMHO. but if you want to keep the number-of-results low you need such a deep structure. Gruss, Erich Schubert -- erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C(o_ The best things in life are free: Friendship and Love. //\ Die eigentliche Aufgabe eines Freundes ist, dir beizustehen,V_/_ wenn du im Unrecht bist. Jedermann ist auf deiner Seite, wenn du im Recht bist. --- Mark Twain
Build-Dependencys and backports
Hi, there is a common practise with build dependencies that i consider "abuse", although it is described in best-packaging-practises. http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#BINARYCOMPAT "And start recompiling every package that is linked against libfooX against the libfooX-dev, updating the Build-Depends accordingly (to build-depend on a version greater than the newly created libfooX-dev)." This common practise makes package backporting more work. For the packages i backported to woody i often had to drop some "fixed" build dependency and replace it with the old value. IMHO we should use other means to tell the autobuilders which packages they should use for building than build-dependencies. Actually the package does often not build-depend on the version. It have a runtime conflict with packages built with the older version, or it might build-conflict with a particular version of a package. All we would need is to teach autobuilders not to use a certain version of a package any more. At minimum a package maintainer should undo the dependency as soon as all architectures are fixed. Greetings, Erich Schubert -- erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C(o_ To understand recursion you first need to understand recursion. //\ In unseren Freunden suchen wir, was uns fehlt. --- Thornton Wilder V_/_
Re: faster boot
Hi, i have working minit packages (not sure if i uploaded them to ppl.d.o/~erich/boot/ yet) and i've been using them for weeks to init my system. There are a couple of open issues, that is why i didn't upload them. for example current init-scripts are not aware of the monitoring capabilities; when the apache package gets upgraded i should stop apache manually, then upgrade, then stop it via init.d and restart it via minit. I have written some basic scripts which allow for sysvinit backwards compatibility (i.e. rcX.d is processed, but when a minit-version of a script is found the daemon is started supervised instead). But (maybe to me still using a lot of sysvinit scripts and not too much parallel startup yet) i can't say i noticed much speedup during startup. In earlier experiments with minit like a year ago or so i did get a big speedup (but i had been rewriting all my init scripts...) If you want to do it properly, it can get a lot of work. For example i wrote patches for atd and cron to run in foreground (one of which was accepted by the maintainer, no reaction from the other) to allow them to be monitored by minit without hacks. But there are bigger issues. Like mysql, which thinks it must ignore TERM signals. I had to write a wrapper script which catches the signal and calls a mysql shutdown script... I also had packages for simpleinit-msb, which is an enhancement of simpleinit as in the utils-linux source. While it worked fairly well for init, i exchanged mails with the author which said he should better have started from scratch than using the existing simpleinit code. If we want to introduce a new init system into debian, we should prepare a generic init framework (like many distributions already have in place) that allows for - silent/verbose boot and output redirection - fancy display of success/failure (for example with colors) - bootsplash and boot-icons integration - needs, provides as in LSB suggested - status reporting (which services are running?) - disabling of services in a consistent way (some are disabled via /etc/defaults/package, some expect you to edit the init.d script, some suggest removing the links) - hooks for other init systems (for example i'd like the apache init.d script to be aware of my minit, and restart itself via minit) Some distributions try to provide a "check" command for each init script; afaict we don't. I've seen "start-now", "stop-now" commands which override "disabled" services and so on. runit is okay, and it has debian packages already. What i didn't like about runit is the "forest" of processes it creates. The output of pstree is really fancy. ;-) Minit seems to be able to do most of this without using that many processes. Greetings, Erich Schubert -- erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C(o_ A polar bear is a rectangular bear after a coordinate transform. //\ Die kÃrzeste Verbindung zwischen zwei Menschen ist ein LÃcheln. V_/_
Re: Re: faster boot
Hi, Please CC: me on replies, i'm not subscribed to debian-devel. -rwxr-xr-x1 root root 5588 2003-09-15 17:41 /sbin/minit -r-x--1 root root 5588 2003-09-24 10:31 /sbin/runit-init -r-x--1 root root 8628 2003-09-24 10:31 /sbin/runit -rwxr-xr-x1 root root 12724 2003-09-24 10:31 /usr/bin/runsv minit is already really small. All it does is running processes and restarting them when they die. There seems to be little difference between what i can do with minit and with multiple runsv. And yes, i do know about shared memory. I admit that runsvdir has some nice features - like something similar to runlevels, but way easier to understand. Just change the symlink to the new runlevel and it will terminate services not in the new runlevel, while starting new services. Nice! But i don't see why i need that many processes: âârunsvdirââârunsvâââsshd â â ââsvlogd â âârunsvâââgdmâââgdmâââXFree86 â â ââgnome-sessionâââssh-agent â ââ4*[runsvâââgetty] â âârunsvâââmasterâââpickup â âââqmgr â âârunsvâââsvlogd â â ââusbmgr â âârunsvâââcupsd â â ââsvlogd â âârunsvâââfamd â â ââsvlogd â âârunsvâââapacheâââ5*[apache] â âârunsvââârunâââmysqld_safeâââmysqldâââmysqldâââ2*[... â ââ4*[runsvâââsocklog] â â ââsvlogd] â âârunsv â âârunsvââârpc.statd â â ââsvlogd â âârunsvââârunââârpc.mountd â âârunsvâââsleep â âârunsvâââatd â âârunsvâââcron Greetings, Erich Schubert -- erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C (o_ There was never a good war or a bad peace. - Benjamin Franklin //\ Die StÃrke eines Menschen kann man daran messen, V_/_ wie er mit seinen SchwÃchen fertig wird!
Bug#144046: general: Sections are not finely grained
> > I think it would be better to drop the sections altogether and use a > > keyword-based system someone suggested a few months ago. The advantages i suggested this a few months ago. unfortunately i havn't reworked my proposal yet, nor did i make a proof of concept especially for my new enhancements. (a kind of proof-of-concept can be seen in aptitude, as well as on http://people.debian.org/~erich/packagebrowser/ which basically has the algorithms required for the first stage. (second stage will need a useful amount of "tags" added to packages) > > - ultimate fine-grainedness (?) indeed. like selecting gpl licenced apps only, gtk apps only etc. > > - no dillemas about where to put packages which fit in more than > >section (like x11 net-related programs) correct. > Users need a hierachical layout in order to find software. Keyword correct, but the keywords don't need to be hierarchically themselves. You just have to give the user a way to browse the keywords hierarchically. (that way different users can even have different trees, which is a pro against hardwired hierarchies) > by themselves are not that much useful since they would be only appropiate > to the language used. Several disadvantages: > 1.- more difficult to translate than sections Don't think so. I think they'll be much simpler, as you don't have to say which mail tools go in there and which not, these keyword-tags are much simpler than the categories. > 2.- are not organised hierarchicaly (sp?) external hierarchies have always been included in my concept. > 3.- difficult to represent graphically in a package-administration gui > (sections are easily represented as trees). you can represent this as tree easily. Have a look at the url i posted above. Packages (and even sub-trees) appear multiple times. For example Programming -> IDE -> VI Editors -> VI Editors -> IDE -> VI are all the same. Definitely a pro with such flexible tree hierarchies. > If you want to have a keyword-based system I would suggest you > take a look at dpkg-iasearch (yes, not documented, but it's a proof of As i understand this works by kind of indexing the descriptions. Which is by-design inferior to hand-tuned keywords imho. what i'm planning to add to my proposal is the use of weighted keywords. Such as "progress 0.8" and "licence:free 1.0", so i could select only apps that are considered to be quite useable by the maintainer and dfsg-free. unfortunately this will lead to further bloat of the packages files. :-( The most difficult part will be an intuitive user interface. But i think that a user interface doesn't need to implement all features directly. (for example these weights could be in some extended selection menu only, and influence only the sorting by default) Gruss, Erich Schubert -- erich@(mucl.de|debian.org)--GPG Key ID: 4B3A135C A polar bear is a rectangular bear after a coordinate transform. Die kürzeste Verbindung zwischen zwei Menschen ist ein Lächeln. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upcoming bug mass-filing re. non-free TrueType fonts in main
> Now would be a really good time for people to email authors of decent > TrueType freeware fonts to see if they can be convinced to put their fonts > under a DFSG-free license if anyone is interested in doing that. For the author of ttf-larabie-*, i tried that when i made these packages. The licence we got does NOT fulfill all DFSG requirements, but is already very liberate. I don't think we'll get further than that. So please don't press him, unless you maybe pay him to release his fonts (or some of the most useful ones at least, like Blue Highway) under the GPL ;) Greetings, Erich -- erich@(mucl.de|debian.org)--GPG Key ID: 4B3A135C There are only 10 types of people in the world: Those who understand binary and those who don't
debian-security-announce and bugtraq
it seems like people still don't get that bugtraq is subscribed to debian-security-announce... And bugtraq seems unable to add some Footer to the posts that clarifies this... Couldn't we - unsubscribe bugtraq from our list - send out security-announces to bugtraq separately? Gruss, Erich Schubert P.S. Or wasn't this recent mail from branden another try to unsubscribe from our postings to bugtraq? I don't remember much recent complaints... maybe that issue is already settled. -- erich@(mucl.de|debian.org)--GPG Key ID: 4B3A135C There are only 10 types of people in the world: Those who understand binary and those who don't Ein Freund ist ein Geschenk, das man sich selbst macht. "Wissen ist Macht" - wenn man das richtige daraus macht.
Re: HELP - Screen is flooded with DHCP messages.
> IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:04:76:de:b9:53:08:00 SRC=0.0.0.0 > DST=255,255,255,255 LEN=328 TOS=0x10 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=68 > DPT=67 LEN=308 > on all machines. Configure your firewall correctly. That message is a DHCP request. Just don't log DHCP requests. DHCP requests need to be send as broadcasts... Greetings, Erich -- erich@(mucl.de|debian.org)--GPG Key ID: 4B3A135C A man doesn't know what he knows until he knows what he doesn't know. Glück gleicht durch Höhe aus, was ihm an Länge fehlt. "Wissen ist Macht" - wenn man das richtige daraus macht.
Re: How to transition to G++ 3.2 wthout any breakage
I certainly prefer NOT doing any ugly stuff with dpkg. "apt-get dist-upgrade" will uninstall packages that havn't been updated to the new c++ yet, which certainly is worth a bug report on these packages... That is exactly the PRO of a good dependency management... Instead of hacking some ugly stuff into dpkg, which is likely to break more stuff, and adding a wrapper to _hundrets_ of applications certainly is ugly... hacking the dynamic linker certainly is better than that... ANY such hack is more likely do break than the dependency system (which will just keep a few packages in an "uninstallable" state for sid, people could always get the latest package from sarge...) No, IMHO the best way should rely only on the Dependency system. I'm fine with adding a char or other tag to the package, too - lot's of package names (and especially the affected library names) are already quite cryptic... another char doesn't matter there... The change from libpng2 -> libpng3 with gtk2 was FINE, imho. It worked like a charm... I waited until the list of packages which would be deinstalled by that move contained and switched then... i lost just two or three apps i had installed, so what... (mostly i lost mozilla-snapshot and galeon-snapshot which i built myself ;) And if that gcc -> 3.2 move takes a month - well, i can live a months with the software versions i have installed right now. I don't need the bleeding edge for any price. The dependencies should help me know the price i had to pay... ;) But people will need to learn the difference between apt-get upgrade and apt-get dist-upgrade... i guess we'll get dozens of these bug reports while doing the move... BUT: What about preparing for future instances of this problem? Could we maybe have all new libs in /usr/lib/libc6/gcc3.2/ so if this occurs again, it will easier be solved? (hmm... i don't like these paths, either... but some stuff like this should probably be done...) Well, i'm not a dynamic linking insider, these are just my ideas. There are others much more competent around. Gruss, Erich Schubert -- erich@(mucl.de|debian.org)--GPG Key ID: 4B3A135C A man doesn't know what he knows until he knows what he doesn't know. Die kürzeste Verbindung zwischen zwei Menschen ist ein Lächeln. Mathematik: Das Alphabet, mit dessen Hilfe Gott das Universum beschrieben hat.
Re: How to transition to G++ 3.2 wthout any breakage
> > hacking the dynamic linker certainly is better than that... > This only allows to avoid creating wrappers but doesn't avoid the > problem that two libraries can't have the same filename. > Something (dpkg) must move one of them. No. The maintainer must, by uploading a new version of the old library, and using proper Conflicts. That way other packages can depend on the moved versions properly. > Aren't the G++ 3.2 packages going to be moved into sarge? Even if you do > so when the transition is complete, there will still be non-Debian G++ > v2 packages installed on users' machines. No, they are not, as long as there are dependency problems, and as long as we keep a bug "G++ 3.2 transition incomplete" open... There are -nice- and -tested- methods to do such things. > The change from libpng2 to libpng3 is a total disaster like this one. No, the transition worked fine. The disaster is not the way Debian gtk2 migrated, but the library itself. > What I especially don't like is the concept that GTK+, that doesn't use > any png structure in its interface, can dictate what a program using it > does with libpng. The gtk engines that use png's do depend on png. That goes this far that even statically linked GTK apps sometimes don't work - because they try to load a gtk theme with different libraries. (see mldonkey faq, p.e.) > This concept is inherently totally absurd and broken and _anything_ is > better than allowing something as stupid as this. And I'm surprised that > this isn't obvious and that this transition was not stopped by anyone. The transition worked fine, so i don't blame the people who did it. It was a minor disaster on a FreeBSD box i regularly use It worked like a charm because they used package depedencies, instead of any ugly hacks. > Anyway, putting v3 packages in a separate directory still requires to > modify /etc/ld.so.conf and create wrappers for v2 packages. Why do v2 packages need to be modified, if v3 libraries are in a different directory??? > And we still have the problem of external packages that don't obey the > rule of the gcc-3.2 directory. Depending on what other distributions do. If they follow this concept, too, everyone will be fine. If they don't they'll have to solve the whole issue, too... People won't be happy if their applications work on SuSE 9 but not on SuSE 8 or whatever. Gruss, Erich Schubert -- erich@(mucl.de|debian.org)--GPG Key ID: 4B3A135C Go away or i'll replace you with a very small shell script. Es ist besser, geliebt und verloren zu haben, als niemals geliebt zu haben. Humor sollte immmer dabeisein, auch bei Problemen.
Re: How to transition to G++ 3.2 wthout any breakage
> > No. The maintainer must, by uploading a new version of the old library, > > and using proper Conflicts. That way other packages can depend on the > > moved versions properly. > And it is not possible to install both a v2 ABI and a v3 ABI version of > the library. Sure it is. One of the packages has to install the files in a different directory - that is NOT different from moving the files via a dpkg hack. BUT you can assure via the dependencies that these paths are used. > > > Aren't the G++ 3.2 packages going to be moved into sarge? Even if you do > > > so when the transition is complete, there will still be non-Debian G++ > > > v2 packages installed on users' machines. > > > > No, they are not, as long as there are dependency problems, and as long > > as we keep a bug "G++ 3.2 transition incomplete" open... > > There are -nice- and -tested- methods to do such things. > That works as long as user only install Debian packages, but obviously > doesn't work for non-Debian ones. If they use proper dependencies it works just fine. They can't be installed unless they fit to the system. That is the ONLY correct thing. If they install stuff by hand, your automatic wrapper generation and library moving will not help either. If you want to fix alienated rpm's - do that in alien. > > No, the transition worked fine. The disaster is not the way Debian gtk2 > > migrated, but the library itself. > No, it is in the fact the neither the library authors nor Debian fixed > the problem. Which is completely separte from the correct way to package these things, and that is what we are talking about... the libpng issues cannot be solved by a dpkg hack! They did not solve the libpng problem (which is not to be solved by debian, but by upstream and all distributions _together_) but they set the dependencies correctly, so packages don't break. Without a hack. Which is great. > > > Anyway, putting v3 packages in a separate directory still requires to > > > modify /etc/ld.so.conf and create wrappers for v2 packages. > > > > Why do v2 packages need to be modified, if v3 libraries are in a > > different directory??? > Because v2 binaries need to load libraries from the v2 dir and v3 ones > from the v3 dir. > Either the v2 binaries or the v3 ones must be wrapped to obtain this > behavior or the dynamic loader must be modified. We don't have any v3 binaries yet. So where is the problem? The maintainers could include proper wrappers for them. that is better than doing some automatic wrappers... You could even use alternatives to switch from default-is-v2 to default-is-v3 and remove all wrappers at once, when you modified your library paths... No hack needed for that either. > But by modifying dpkg packages can be made to work regardless of the > place where they put libraries. Don't take stuff unnecessarily out of control of maintainers. Many apps use wrappers already, why force them to use another wrapper. You'll break LOTs of things. For example mozilla does use some wrapper to set LD_LIBRARY_PATH correctly... your automatic wrapper generation will maybe not work, and if it does it's definitely inferior to having the maintainer do a proper wrapper himself... Gruss, Erich Schubert -- erich@(mucl.de|debian.org)--GPG Key ID: 4B3A135C A polar bear is a rectangular bear after a coordinate transform. Wer nicht zuweilen zuviel empfindet, der empfindet immer zuwenig. Mathematik: Das Alphabet, mit dessen Hilfe Gott das Universum beschrieben hat.
Re: Why am I receiving still mails from this list?
> I try to unsubscribe from this list for about a week now. I just got the > message that I am no member of the list anymore, but still get the > mails. I tried to unsubscribe again, but I got the message, that this is > not possible because I am no member. > Why do I still get the mails? We are not magicians, quote some headers so we can find out... Probably you subscribed with a different address than the one you unsubscribed? Greetings, Erich -- erich@(mucl.de|debian.org)--GPG Key ID: 4B3A135C Go away or i'll replace you with a very small shell script. Mancher findet sein Herz nicht eher, als bis er seinen Kopf verliert. Der Wissende weiß, dass er glauben muß.
Re: Why am I receiving still mails from this list?
> Received: from sphinx.rz.tu-clausthal.de > Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com > Received: from fwd04.sul.t-online.de > Received: from bombadil.xmldesign.de ([EMAIL PROTECTED]) that obviously is the copy of the mail i sent to you directly. it never used a debian server. me, t-online, tu-clausthal. Greetings, Erich -- erich@(mucl.de|debian.org)--GPG Key ID: 4B3A135C There are only 10 types of people in the world: Those who understand binary and those who don't Die kürzeste Verbindung zwischen zwei Menschen ist ein Lächeln. Der Wissende weiß, dass er glauben muß.
Re: More GPL fonts
> I will be packaging a number of truetype fonts for inclusion in debian > somehow, but the details are not fully worked out yet. I'll take a > look at these for to include in that package, or in a package of just > your fonts. When packaging many fonts with defoma, could you please tell me if you experience the same major slowdowns i get (with certain defoma-dependant packages installed)? Please check out my defoma-enabled ttf-larabie packages on http://people.debian.org/~erich/ttf-larabie/ the -uncommon took some minutes to install here... defoma using all CPU. See #143818... I think it is some broken font... havn't had time to find out which of these > 100 ttfs... Still defoma isn't stopped at one font, it just gets very very slow. Greetings, Erich -- erich@(mucl.de|debian.org)--GPG Key ID: 4B3A135C A man doesn't know what he knows until he knows what he doesn't know. Liebe ist eine schwere Geisteskrankheit (Platon) "Wissen ist Macht" - wenn man das richtige daraus macht.
Re: What's up with testing??
> Can anyone advise why packages aren't getting though into testing? > > + Depends: hpoj glibc Dependencies. glibc is holding them back. Greetings, Erich
Sharp SPAM [marketing@sharpsystems.com: Special Price Offer for Select Sharp Systems Products]
It appears that Sharp Systems systematically spammed writers to the Debian-Laptop list, which certainly is an abuse of the debian lists. (they did not spam the list, so they don't directly violate the anti-spam rules of debian though) The spam arrived 12. Aug 2002. I was spammed shortly after posting there about LCD screens, and a few other posters confirmed my assumption that this resulted to that spam. The SPAM contained correct headers and was properly addressed, mailserver was gatekeeperil2.sharpsec.com, which is registered to sharp as well. It even refers to a probably correct Sharp Freecall number (although i do not live in the USA, so i can't call it) I did NOT request any information from Sharp, especially not about LCD screens (why should i buy an LCD screen in the States, where i have to pay shipment to Europe, when i've got a 1600x1200 LCD in my non-Sharp fine notebook?) It's a shame that a compaby i though once as a major player relies on such dodgy - and in many countries ILLEGAL - methods of annoying potential customers. Guess i'll drop them into my filter list, or wait for them to spam me again, then sue them. Greetings, Erich Well, i hope this public complaint and discredit, which most probably be kept in the archives on the net for a long time will make them stop doing such inpolite things and reconsider their marketing strategies... I also now decided that I won't spend my money on a "Sharp Zaurus". (I didn't really intend to buy any PDA anyway). - Forwarded message from Sharp Systems Marketing <[EMAIL PROTECTED]> - Organisation: Sharp Systems of America From: "Sharp Systems Marketing" <[EMAIL PROTECTED]> To: "Erich Schubert" <[EMAIL PROTECTED]> Subject: Special Price Offer for Select Sharp Systems Products Erich Schubert, Sharp Systems of America is offering its award-winning products at a special price to select customers and companies! Come to www.sharpsystems.com and look at our award winning line of notebook PCs and LCD monitors. >From now until September 30, 2002 you are entitled to receive a $100 rebate >when purchasing any of the following products from Sharp Place: Actius MV10W, >Actius UM30W or LL-T1820B LCD monitor. Simply order your product from www.sharpplace.com, and send a copy of this offer along with your on-line receipt from Sharp Place to: Sharp Systems, 5901 Bolsa Ave, Huntington Beach, CA 92647 For more info, check out our website, or call us at (800) BE-SHARP. *if you prefer not to receive mailings in the future, please send an email to [EMAIL PROTECTED] - End forwarded message - -- erich@(mucl.de|debian.org)--GPG Key ID: 4B3A135C A polar bear is a rectangular bear after a coordinate transform. Ein Freund ist ein Geschenk, das man sich selbst macht. Humor sollte immmer dabeisein, auch bei Problemen.
Re: DMA, ide-scsi, devfs by default
BTW: i also remember having read that certain hardware doesn't work with ide-scsi, so enabling ide-scsi for all IDE hardware is a bad choice. (i think one of the boot-floppies people tried using ide-scsi by default, and got some problem reports) And additional drawback IMHO is the following: devfs is really nice, and it's nice to see /dev/cdroms/cdrom0 - but with ide-scsi i also get /dev/cdroms/cdrom1 ... 6 for different "luns" of my ide writer... i havn't yet understood why they are created... it's kind of unintuitive to have 7 nodes for my cd writer and 1 for my cd+dvd player... ) We also should watch what 2.5 will bring... now it seems like the IDE redesign was reverted, but maybe it will come again or yet another different approach. Maybe these kernels will be DMA-Enabled by default. I think there is an option to enable DMA by default for certain chipsets already - probably the ones where it is safe... I like devfs very much, btw - but there were race conditions and such stuff in there before, so the current state of devfs should be checked. But if it is reliable i would recommend using it. It makes lot of things much easier and probably is much more intuitive for beginners as well. (just thinking of /dev/discs/disc0/part1 and /dev/cdroms/cdrom0 ) Greetings, Erich -- erich@(mucl.de|debian.org)--GPG Key ID: 4B3A135C The best things in life are free: Friendship and Love. Die kürzeste Verbindung zwischen zwei Menschen ist ein Lächeln. Humor sollte immmer dabeisein, auch bei Problemen.
Re: can a non developper become a debian maintainer ?
> well. I can also compile, install, and manage non packaged software, > and occasionnaly find and correct some small or obvious bugs. But I > couldn't really develop anything big, or tackle real big bugs (but > then these are more upstream's task than debian's). Well, actually i'm not too great a developer either (except for maybe Perl stuff, i'm doing quite weird stuff there ;) - but if you know enough to fix small bugs and install non-packaged stuff, this is easily enough to package software and become a maintainer. Even co-maintaining "big" stuff like galeon (well, actually only big dependencies) isn't too hard, even when doing smaller fixes and addons. So probably just try doing the usual NM process, i guess it will be fine ;) And for bigger bugs you always should ask upstream anyway, they probably know already a fix or are able to find a nicer one. You're not alone ;) Greetings, Erich
Re: Why a package is removed or kept back?
> Why is it removing the qt3 dev packages? I checked gdk-imlib-dev, > libpng2-dev and libgnome-dev for conflicts with the qt3 dev libraries, > but I don't see any mentioned. So why are they being removed on this > install? it doesn't make sense to me. Without having looked at the dependencies: Maybe gnome depends on libpng2-dev, which conflicts with libpng-dev, which is required for libqt3-dev ? Check the dependencies of libqt3-dev, too! Greetings, Erich
Should we customize apps for a common "debian-look"?
Redhat seems to be going to use a common look for their desktops (GNOME as well as KDE) in their new beta featuring a new icon set. Check out the screenshots at http://www.gnomedesktop.org/article.php?sid=616&mode=&order=0 I like them and i think they are impressive... It's one of the things Apple proved: desktop and apps that look smooth do make their users feel comfortable with them ;) Apart from the question if KDE and GNOME2 should be made to look similar (KDE developers were pretty angry at RedHats step), should we try to make a "Debian" look default? (Provided that someone does Debian Themes...) This look doesn't need to be shared from GNOME2 to KDE (although i don't see the reason not to do so...) but it could make Debian become some "Brand" that looks like quality, too ;) Actually one of the reasons some people didn't like Gnome 1.4 was the default configuration... This "Distribution Theme" could also take a look at default configurations... The other way would be to leave this to upstream... GNOME2 is already pushing on having a standard GNOME2-look (which i like very much) and just distribute Defaults as-is from upstream... (although it should be easily possible to have a separate debian-common-look package or something like that...) Maybe someone could give a good reason to do so or not to do so... It could be as simple things as using the debian color as default for highlights instead of the usual default-blue for highlights many themes use... I don't have a real opinion, but i do thing that looks begin to matter for linux apps and desktops... Greetings, Erich
Re: Should we customize apps for a common "debian-look"?
> No, seriously, it would be less confusing for novice users. More > experienced ones already know how to change themes and perhaps make > everything look consistent, but it's a considerable ammount of work. Especially since KDE asks at the beginning which style they want to use anyway... If we add a Debian Theme that is the default selection, users accustomed to KDE could always select the KDE default look at the first login... (But i HATE that druid of KDE... why do i have to select the language and keyboard again? my admin already configured these...) > are things which are visibly different. If they like the KDE XP-like > eye candy, then get someone to make a matching engine for GTK+. > Personally it makes me puke... I have this prejudice that a desktop > that I'm going to be looking at 8 hours a day has to make a very well > reasoned use of color and contrast. Yep, the only useable KDE Themes i know are the "light" ones ;) I prefer Gnome2 for the very same reasons, that it hasn't got much eye candy (except icons with nice shadows ;) > > It could be as simple things as using the debian color > > that reddish tone? Please no; it's a very nice color, but I don't > think people want to look at it for more than 5 seconds at a time. Yep, it's a major drawback we don't have a discrete color - well, ok, that SuSE Green would be even uglier, but i remember having seen KDE Themes using that very color ;) Thats why i considered it for highlight uses only. Marking text with that ugly color is ok imho ;) Any better suggestion? I'd like to use dark red, but red is... redhat? Well, their screenshots doesn't suggest they use it for themes though... * Maybe we should put out a call for Artwork? Greetings, Erich
Re: Should we customize apps for a common "debian-look"?
> Provided we *ONLY* muck with things like colors, icons, and root images this > should be fine. Actually changing code like RH did to remove the About box > would not be good. I never look at about boxes anyway, so why remove them? ;) This has nothing to do with common look, and all Interface Guidelines include an about box in the Help menu. I didn't follow the discussion why KDE is angry about RedHat, if it was for the removal of about boxes i think KDE is right to be angry... Greetings, Erich
existing debian themes
On themes.freshmeat.net there are a few Debian themes, some nice backgrounds etc. For example this one could go for a futuristic aqua-like look (GnuBubbles for GTK2 for example?) http://themes.freshmeat.net/screenshots/28071/ And sunshineinabag.co.uk already has a Debian GDM2 login screen http://sunshineinabag.co.uk/ which (when one replace the ridiculous apples ;) could be a nice default for gdm2 (when it gets packaged, i can't await it ;) The "Debian color" should be used for HighLight only, that is for the active window bar, marked text and hover effects maybe. IMHO. Greetings, Erich
Re: Should we customize apps for a common "debian-look"?
> Because some admins, unlike the rest of us, thinks users want's to have > software in their local language and use local keyboard layout, then we > indeed want's to have our software in english and us keyboard layout > with local as an switchable option, right? Which means *everbody* needs to answer these questions once at their first login, instead of just changing them in the control center, like all other options, when we actually DO disagree with our admins preferences? There is no NEED to force the user to confirm these settings, as they can be changed at any time in the control center. Language is indeed quite special, but i prefer there the gnome way - selecting a different language in the login manager is nicer. Because i don't have to select my language... Greetings, Erich
Re: Where are tasks now and how are they handled? (Woody sucks because there is no Task: Spanish)
> One simple question: how are tasks managed? what policy is there for > creation/addition of packages to it? See debian-policy... Excerpt from the changelog: * we no longer have task packages, instead, we define tasks using a special field in the control file (and these should be added only after discussion on the mailing lists) closes: Bug#97755 -- erich@(mucl.de|debian.org)--GPG Key ID: 4B3A135C To understand recursion you first need to understand recursion. Ein Freund ist ein Geschenk, das man sich selbst macht. Für jedes Problem gibt es eine Lösung, die einfach, klar und falsch ist.
Re: Where are tasks now and how are they handled?
> Then the policy document is wrong? Shouldn't it be bugged? I guess the policy document describes how this is to be done _now_. (That is after woody ;) Whereas the override file was they way this was handled for woody. Maybe ask on debian-policy on this issue? Greetings, Erich -- erich@(mucl.de|debian.org)--GPG Key ID: 4B3A135C A polar bear is a rectangular bear after a coordinate transform. Ein Freund ist ein Geschenk, das man sich selbst macht. Humor sollte immmer dabeisein, auch bei Problemen.
Packagebrowser big update
Hello, I just updated my "packagebrowser" to a completely rewritten version. http://debian.vitavonni.de/packagebrowser/ I converted the groups data from "aptitude" to a keyword-oriented system; this system is much more flexible. Unfortunately the UI is quite slow (especially at the top level, i definitely need to add caching there... maybe a fastcgi version. it takes up to 3 seconds for a request while the machine is idle!!!) currently. So i hope the server won't be brought to its knees... You can currently: - browse the categorized packages - add /and remove/ tags to packages The UI is of course still unfinished and has a lot of open issues (not the smallest being the too long list of possible keywords) But i guess this gives a preview of the direction we are steering, and i believe that this is to become a really nice system. On the long run i'd like to port this to the menu system, maybe specialized file managers (integration of a similar system in the gnome file dialog would be amazing!) and a new "apropos" system. Enrico Zini has kept his fast C++ library very generic, so it should be easy to include this in other applications. Thanks go to Enrico Zini for writing lots of code, and showing that we are ready for a keyword based approach, writing a prototype, great ideas (automagical hierarchies) and packaging his first helper applications. Thanks go to Hervé Eychenne for many suggestions, helpful discussion and beta testing. Greetings, Erich
simpleinit and other init procedures
Hello, I have working "simpleinit-msb" and "minit" packages on my system. (simpleinit-msb is an extended simpleinit, see http://www.winterdrache.de/linux/newboot/) and "minit" has nice monitoring capabilities and is similar to daemontools, but GPL (http://www.fefe.de/minit/) The initscripts for the packages need a lot of fiddling, but i think i have a reasonable example set ready. I'd like to have support for linux-progress-patch, too, if you design a complete new init system. (I'm interested in that, too... i had intended to work at this in DebCamp, but i probably won't come to DebConf now. ) Greetings, Erich Schubert -- erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C (o_ Go away or i'll replace you with a very small shell script. //\ Jemanden zu lieben heißt glücklich zu sein, ihn glücklich zu sehen. V_/_
Re: Announcing Debian Package Tags
Hello, Of course we always intended to have "Tags:" lines added to package description files. But to actually get the system working we needed data and application prototypes. Guess we've got part of that now. ;) On the long run: - packages should include the tags in their control file (so custom packages / private repositories can be tagged as well) - the allowed tags list should be fixed and rarely changed. (only after discussion on -devel etc. almost like policy changes) - policy should require that tags are added - there are guidelines what the tags mean, which "kinds" of tags need to be added (application-type etc.) - lintian checks the tags for validity - menu system uses tags (per-installed-binary, not per-package) - there is tag-apropos (same data as above) - sourceforge and fresmeat switch from trove to our tags ;) - HTML and XML stop using the term "tag" to avoid confusion ;) - the whole world uses tags! *gg* Greetings, Erich Schubert -- erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C (o_ Go away or i'll replace you with a very small shell script. //\ Jemanden zu lieben heißt glücklich zu sein, ihn glücklich zu sehen. V_/_
Re: Announcing Debian Package Tags
> > - policy should require that tags are added > > This is going to be problematic. I think it would be better to have an > override system where missing tags can be added by a central authority, > rather than trying to force all maintainers to add tags or be NMUed. Of course. they can be overriden the same way the section "gnome" was overridden for these packages. So no uploads would be required, but the packages can just be updated with their next uploads. Maybe some will stay in the override file for a long time even. I should also look at the localized-apt announced yesterday. This might be nice to integrate. After all not everybody uses tag information, so maybe we could keep those separate (i guess it's ~150kb gzipped) > Speaking of adding tags, I've categorized a bunch of packages through the > CGI interface, and while I appreciate its simplicity, it isn't very > efficient for categorizing large numbers of packages. I would be willing to > put together some simple command line tools to accelerate the process, if > you have not done this already. Well, i have the basic tools there, i can do mass changes even matching on package description or long description. Basically anything i can SELECT from the DB and process in perl ;) I planned to add a "upload" facility, where you can upload a package: +tag, -tag style diff file (or what ever diff format enricos tools have) but i havn't had time to do so yet. However when you send me such things i will hurry to do these changes. The interface is lacking another big point: it doesn't yet automatically add "implicit" tags - the tags "below" one tag in the tree structure - so right now you have to add "devel" as well as "devel::lang::perl" if you want to have the system work properly. Yesterday i introduced another improvement: the interface doesn't form subcategories that contain more than 80% of the matching packages. That is, when you select "devel::lang::perl" but not "devel" it won't provide you with the selection "devel" only, but provide a reasonable list of useful choices. ;) Still the system is way to slow and i fear slashdot... Greetings, Erich
Re: Quake 2 sources GPL'd
> The code simply won't load levels, as it stands, unless it has loaded > the game data. Even if that protection feature was disabled (trivial, > certainly) it still wouldn't work: all such free levels require some > stuff from the commercial data, the weapons, the models, the textures, > etc. Are you aware of all those "Total Conversion" Projects, which aim to replace all this commercial data? There have been hundreds of such projects, some of which might have made it... Sure, most of them will have died by now; but maybe one or two will really have been able to become a "true total conversion" as JC stated... at least they will now have more incentive to do so. Maybe this one might be quite ready: http://www.planetquake.com/stand/ BTW: The source has some drawbacks right now i fear: As far as i could see it does not include the glx driver (which is the only way to use all those nvidia graphics cards) but depends on an old mesa version and svgalib. It looks like it's the source of 3.19; whereas 3.20 is current; so there are probably some known bugs in it? So maybe it's most interesing as source tarball for developers. Greetings, Erich
Quake2/GPL: At least source should go into main
At least the Source _is_ useful for novice programmers that are interested in 3d game programming. So at least the source should go into "main". Maybe there is no complete free dataset available right now; but there should be enough "free" models and textures to make a one-room game with this engine which is completely free... I plead for titling this package "quake2-engine", so there is no need for any data files... I consider this discussion somehow ridiculous. The software is free; If gimp didn't include any free brushes, would it have to go into contrib too??? Greetings, Erich
Re: Quake2/GPL: At least source should go into main
> > At least the Source _is_ useful for novice programmers that are > > interested in 3d game programming. > > How does Quake differ from any other projects in contrib in this way? Software in contrib needs non-free software to run. But the source of quake2 certainly is useful without the commercial game data. > Contrib consists of free things where the source is available and > therefore can be used as education for interested programmers. The > only reason that it isn't in main is that it is unuseable without > extra stuff that can't be placed in main. which is not true for the quake2 engine, which is certainly a nice thing to study for programmers. But you didn't understand completely what i was talking about; i was considering not packaging the quake2 engine as binary, but packaging the _source_ for developers to look at. Greetings, Erich
Re: Quake2/GPL: At least source should go into main
> I wonder how many people in either of these threads have actually downloaded > this source and looked at it? i have. I even got it to compile... and i think it'll need quite some work to get useful... it has inline asm gcc doesn't like; the ref_glx driver is missing; it currently requires svgalib and glide (or an old mesa, i'm not sure) to compile (and probably will run on glide and software only right now) Greetings, Erich
RFC: Categories instead of Section - reworked
i reworked my proposal and ask for comments again. Greetings, Erich GNU Trove Categories for Debian Packages Preface: Dselect has been the bug-a-boo scaring novice users from installing Debian. Tasksel, aptitude, console-apt and gnome-apt have already improved the situation a lot. But actually woody is suffering even more from a literally big problem: Debian is getting too big. Experienced users will rely to "apt-cache search", but what will novice users do? They do not even know what software choice they do have with Debian. ** What Debian needs is an easy way to browse packages. ** This topic _has_ been discussed multiple times in the last few years. But I see the need to come to a solution, and i'd be happy if we could at least get the basics into woody. I reworked a previous proposal by me, and reduced it to GNU Trove Categories which should be easier to understand, manage and write understandable frontends for ;) Current Situation: -- Debian has about 8000 Packages (from tausq's Package list, including non-free) They used to be divided into sections such as "web", "mail", "net", "electonics", "admin", "x11", but they became very unevenly balanced. For example "electonics" has less than 30 Packages, x11 contains all the kde and gnome applications which makes up for > 500 Packages. In Woody, this separation was mostly removed with the package pool. Furthermore lots of programs would fit into more than one section (for example an x11 mail reader, x11 games etc.) Aptitude has some experimental Package Browser included which is a really nice thing. Unfortunately the categorization is included in the aptitude package and can only be changed by updating aptitude (currently). Freshmeat and Sourceforge have a common software map based on GNU Trove. Goal: - Debian software packages should be categorized in a system based upon GNU Trove; so people familar with freshmeat and sourceforge will quickly find the software they are looking for. GNU Trove is expected to be a good way to categorize software; it might need some Debian specific modifications though (such as data-packages split off from the original software) Proposition: Instead of the "Section" I propose using a "GNU-Trove" field, containing multiple values from a central category list. There is need for - a commitee for accepting necessary modifications of GNU Trove - translators - frontends (preferrably inclusion into aptitude, deity, gnome-apt etc.) Frontends should allow browsing and filtering like freshmeat does. (like displaying packages with an OSI-Approved licence only etc.) Benefits: --- - Easier browsing of package lists, especially for newbies - Same categories as freshmeat.net and sourceforge.net Drawbacks: -- - Every Package needs to be updated sometime (or overridden in the archive) - Debian Policy Change - Slower Frontends (more filtering of package lists) Implementation: --- - get the GNU Trove list and convert it into some Packages-similar data format - Add "GNU-Trove:" field to packages - Write Frontends Transition: --- - Frontends should be kept in unstable until a good amount of packages has GNU-Trove categories - two releases after Sections are no longer required by any tool, "Sections" can be dropped - That's it, Erich Schubert pgpMBwBb2cf1N.pgp Description: PGP signature
Bug#126317: ITP: robotournament -- Game where players program their robots against each other
Package: wnpp Version: N/A; reported 2001-12-24 Severity: wishlist * Package name: robotournament Version : x.y.z Upstream Author : Name <[EMAIL PROTECTED]> * URL : http://www.some.org/ * License : (GPL, LGPL, BSD, MIT/X, etc.) Description : Game where players program their robots against each other This is less a corewars-like but Robo-Rally like game. - Multiple Game Types: Death Match, Rally, and Capture The Flag - Multi-Player through TCP/IP - Six weapons including the BFG - Map Editor - Wide variety of board elements - Integrated chat - Computer controlled robots for Rally and Death Match games need to check if this is distributable due to possible copyright conflicts with the makers of the "Robo-Rally" board game. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux marvin 2.4.17-rc1 #1 Don Dez 20 16:17:43 CET 2001 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: Quake 2 sources GPL'd
> No, it doesn't apply, because quake2 is an engine for a game, not an > interpreter for a language. Actually the quake2 engine IS. It's a runtime environment (you might call it interpreter) for the graphics files and the gamei386.so (or whatever it was called) These graphics files and the gamei386.so can be exchanged to make a very different game out of the same engine. The gamei386.so for the original quake2 is GPL, too, but not necessary (as this is, i think, the only part that really depends on the commercial data files!!!) So the engine IS free; the original quake2 rules should go into contrib. Think of python running a compiled python script (?) or java running a "java program". Greetings, Erich
Re: RFC: Categories instead of Section - reworked
> > - Frontends should be kept in unstable until a good amount of > > packages has GNU-Trove categories > > I don't understand this comment. Do you think frontends won't be able > to handle packages that don't have Trove categories? well, people might be confused if such a frontend comes into woody, but only a few packages do have this tag. That's why i'd like this to be kept in unstable until it's useful for end users. Greetings, Erich P.S. I just recieved a dump of freshmeat's categories from scoop, thanks. So maybe in a few days i'll publish a first draft of the categories.
Re: Bug#126317: ITP: robotournament -- Game where players program their robots against each other
> Seriously, for who want to test the game it might be downloaded from > http://robotournament.sourceforge.net, the latest tarball is at: or just check the bug report, http://bugs.debian.org/126317 where i added the correct url... or get the debian package from http://www.fachschaften.uni-muenchen.de/~erich/debian/ (i did the package first, then sent the ITP, because it was just a few minutes of work for this tcl script... that's probably why i forgot to fill out those fields, because i had filled them just a few minutes before...) Greetings, Erich
libpng transition - how about a libpng-inconsistency package
what about making a package called "libpng-inconsistency", which versioned-conflicts with those packages not yet recompiled; libqt, libgd, imlib etc. then only have to depend on this one package, so the conflicts list of them doesn't get too big ;) This would allow us to delay the upgrade of libqt etc. until those applications are recompiled. Maybe it's best to just call for a big recompilation and try to get that done within a few days. After all, unstable may be unstable ;) Greetings, Erich
Re: apt-get reinstall all
> I was just thinking that it would be great to have something in apt-get > that get 'reinstall' or 'repaire' all packages installed on the system. > I don't think I am the only one who rm *'s a wrong dir sometimes, ;) > I think it's now real hard to reinstall every package installed ... well, if you rm'ed /usr/share p.e. just run apt-get --reinstall install `dpkg -S /usr/share | sed -e 's/,//g' -e 's/:.*$//'` if you want to reinstall all installed software, i'd try something like apt-get --reinstall `dpkg --get-selections | grep install | grep -v deinstall | cut -d' ' -f1` Shell scripting is great ;) Greetings, Erich
Re: gnumeric and guppi in sid
> I am just wondering if guppi has every worked properly in sid. well, it does right now. at least for me and on this machine running sid. i think it was the first time i tried, though ;) i usually don't need a spreadsheet, and i usually prefer gnuplot... Greetings, Erich P.S. No, Branden, plase ;) Jack isn't an agent of evil again just because it doesn't work for him, and he doesn't use the bugtracking, nor debian-user but debian-devel.
Re: Appropriate? mutt/mailx requires mail-transport-agent
> I'm working on a diskless workstation configuration where I don't want > mailers running on each machine, though users may have access to the > mail spool through nfs. Is it appropriate for apt-get to coerce exim > to be installed when I only need a reader? Is this a problem about > finding the smtp agent? If you really do not need an smtp agent (note that you might want to get errors mailed to the admin etc.) - just use equiv to create a dummy package providing mail-transport-agent. It's good to enforce such things for most people; if someone really knows that he doesn't need any mailer (there are very small smtp daemons available!) - he'll find out how to "fake" this dependency. See "equiv" package; note that you don't need to install equiv on the client, but just use equiv to create a custom dummy package, and install that empty dummy instead of exim. Greetings, Erich
Request for gs-fonts-virtual package
We really should add some gs-fonts-virtual package, gs is depending upon. LOTs of People (even some Debian Developers) wonder why their printer does not work, just because they forgot to install some gs fonts. So i'd suggest gs depending upon some fonts. If a really experienced user knows that he doesn't need the gsfonts package, he could always make a printer-builtin-fonts package. I'm not sure which package do provide fonts for gs, maybe there is no need for such a virtual package, but gs could just directly depend on the package gsfonts. and we should just add a gsfonts-minimum package or something like that and have gs Depend on gsfonts | gsfonts-minimum Greetings, Erich pgppBvKNBJYhB.pgp Description: PGP signature
Re: Problems with libsdl1.2-dev 1.2.2-3.3 and OpenGL?
> in some way. When I try to compile any program using SDL and OpenGL, the > window/screen shows the last image, from the OpenGL program which was > previous run. My first guess would be that your GL Driver is somehow broken. Memory protection should make it impossible for the next program to read the display of the previous program. If your GL Driver fails to initialize it's video memory, this can easily happen. Which GL Driver do you use? Mesa? Or that buggy memory-eating nvidia driver i'm running (well, geforce2go didn't run with the nv driver, and sometimes armagetron is just fun ;) If you are running the nvidia driver, do try software GL. If it works there, it's probably not SDLs fault. Greetings, Erich
Re: ITP: rootkit - a Ro0Tk1t 4 Deb1an boxxxen
I felt oblieged to announce this package on slashdot ;) http://slashdot.org/developers/02/04/01/162223.shtml?tid=90 We got quite some positive feedback ;) "It's about time. As usual, Debian shows the great leadership that we have all come to expect from the project. The addition of a r00tk1t is yet another brilliant aid to remote administration, and well worth waiting for. RedHat and other so-called "commercial" distributions will, one can only hope, wake up soon and attempt to emulate Debian's ground-breaking innovation in this area, in order to gain market share in the vastly untapped script kiddie market." "Thats the best first april joke i heard today :) the best part is that teh rootkit is fully removeable through dpkg :)" Hey, someone could check the webserver logs how many people did search for the rootkit package via packages.debian.org ;) The link for searching was even posted on slashdot, so some people thought this announcement was serious ;) (well, it was not filed against wnpp, so it was not a real ITP ;) Congrats, Simon. Greetings, Erich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Fix for these slapd bugs is in DELAYED/4-day
Fix for these two grave bugs (my changes are in .config and .postinst)
is in incoming/DELAYED/4-day
I also added a german translation of the debconf templates as
debian/slapd.templates.de
I just noticed there might be another "db_go" missing near
"conf_exists" at the second change, so feel free to upload another fix
;)
I also do not know if this is maybe "debconf abuse" ;)
Greetings,
Erich
Here's the diff with the important changes (dropped some minor changes
like added paranteses or additional checks and a debconf warning that
hopefully will never be seen by anybody...):
--- debian/slapd.config.origTue Apr 2 23:38:50 2002
+++ debian/slapd.config Tue Apr 2 22:20:05 2002
@@ -37,6 +37,7 @@
beginblock;
$ok=(input("medium", "slapd/ldif_file"))[0];
input("medium", "slapd/internal/admin");
+ input("medium", "slapd/internal/dn");
endblock;
go;
$file=get("slapd/ldif_file");
--- debian/slapd.postinst.postinst Tue Apr 2 23:38:50 2002
+++ debian/slapd.postinst Tue Apr 2 22:43:10 2002
@@ -29,14 +29,14 @@
. /usr/share/debconf/confmodule
if [ -f /etc/ldap/slapd.conf ] ; then
- db_get slapd_conf_exists || true
+ db_input critical slapd_conf_exists || true
exit 0
fi
+# These three values are asked always (needed for conf-file)
db_get slapd/internal/dn ; dn="$RET"
db_get slapd/internal/admin ; admin="$RET"
db_get slapd/fill_method ; method="$RET"
-db_get slapd/internal/adminpw ; password="$RET"
top=$(echo $dn | sed 's/,.*//')
key=$(echo $top | sed 's/=.*//')
@@ -53,7 +53,8 @@
elif [ "$key" = "cn" ] ; then
class="organizationalRole"
else
- db_get slapd/unknown_class || true
+ db_input critical slapd/unknown_class || true
+ db_go
exit 1
fi
@@ -66,6 +67,7 @@
if [ "$method" = "ldif" ] ; then
db_get slapd/ldif_file ; ldif="$RET"
else
+ db_get slapd/internal/adminpw ; password="$RET"
ldif="$tmp"
cat < "$ldif"
dn: $dn
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Uploaded Skipstone NMU to DELAYED/4-days
I uploaded skipstone_0.8.1-0.1 to DELAYED/4-days This upload is a complete redo of the package. Please review my changes and upload a Maintainer Upload 0.8.1-1 if you disagree with my changes. Important changes: * should build on ia64 now * works with mozilla 0.9.9 This will close a grave woody bug, when mozilla 0.9.9 and skipstone 0.8.1 enter woody; and some serious policy violation. I removed lot's of outdated things in the packaging, such as the non-working debconf functions (they were displayed on installation of <= 0.5 only...) and i don't think they are necessary any more (18 months ago...). Packaging should be much cleaner now. skipstone (0.8.1-0.1) unstable; urgency=high * Non Maintainer Upload * New upstream version, compatible with mozilla 0.9.9 (Closes: #140844) * Redid the build process, dpatch-style now. * Conflicts with different Mozilla versions (Closes: #139435) * use gcc-3.0 on ia64 (Closes: #136250) * remove -g from CFLAGS (Closes: #115786) * removed debconf: didn't work anyway; change was 18 month ago, thus need no translations any more (Closes: #137684, #136395) * removed depends on mozilla-mailnews (Closes: #135593) * remove "..." from "Exit..." menu entry (Closes: #108867) * corrected spelling in description. (Closes: #125361) * File->Save is Ctrl+S now (Closes: #88059) * no more lintian overrides -- Erich Schubert <[EMAIL PROTECTED]> Fri, 5 Apr 2002 15:19:14 +0200 Greetings, Erich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Defoma Problems
I maintain the ttf-larabie-* packages, a set of 350 almost-free fonts (free as in free beer that is ;) - in 450 ttf files. I'd like to support defoma, but the defoma utilities for generating the defoma hint files are unuseable for me. 1. it takes ages: i have to confirm about 20 dialogs for each font. Makes 9000 dialogs i have to fill out and confirm... I havn't found a way to specify certain defaults, either... for example i want all Fonts to use the "LarabieFonts" Registry. Second i do not want to be shown the confirmation that the font uses "iso-8859-1" as default encoding... 2. i don't know enough about fonts to classify them. Is this font now Roman, is it Semilight, is it NoSerif? For most fonts i tried classifying i did not succeed really. It was difficul enough to split them into three useful packages... I tried mailing the defoma maintainer a few month's ago; i did not recieve a reply. Can someone point me to some useful scripts for generating defoma hints? Greetings, Erich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rsyncable GZIP (was Re: Package metadata server)
> Some questions that need to be asked: > Howmany of our mirrors are rsyncable? How much load can the servers handle? How much more load does rsync do than a fast http server like tux? I think the proposed way of providing diff's for certain "common" versions is much nicer. Sending a request for Packages-diff-mymd5sum.gz and fetching that file is certainly faster and does cause much less load on the server than rsync. It actually will even require less data to be transferred. When the file doesn't exist i can always fallback to fetching the whole file or maybe rsync then... Keeping 14 daily diffs probably does take just a few megs on the server. Providing rsync will probably need as much main memory... But we HAD this discussion already a few days ago... Greetings, Erich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Defoma Problems
> It's interesting how strongly these fonts are a recommendation of free > fonts. Misnamed glyphs need to be moved, those previously mentioned > blank glyphs need to go away, and many new characters could be created > with little work (Berylium has the c, h, g, j, s, u, circumflex and > breve glyphs needed for Esperanto. all that needs to be done is that > they are combined. I believe Welsh, and I'm sure many other languages, > would be equally simple). Actually these changes are allowed by the licence i got from the author. He doesn't allow changing the name or any of the main characters; he explicitely allowed to add new chars by adding circumflexes etc. to old characters. Removing empty characters alltogether is probably ok, too ;) Well, i fear nobody cares enough for non-free fonts to do that... Greetings, Erich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [2002-04-06] Release Status Update
> > galeon logtrend-httpagent rie > > Is there anything I can do to get galeon included in woody? Since there > are no outstanding RC bugs, I assume there are dependency problems. Galeon was unfortunately removed to a RC bug that did apply to a version in sid, not in woody, that i had not tagged fast enough... Thus galeon was removed. I think galeon is in a pretty good shape now again; most problems people are having with it come from mozilla and apply there, too. I'm adding a galeon-nautilus package right now btw. Built from the same source (i begin to like autoconf ;) this is the same as the galeon package, but with nautilus-view enabled. Greetings, Erich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New Packages (i18n version of APT)
I REALLY REALLY would like to see translated apt in woody. And i cannot understand why apt-i18n is not installed so we could test it. Adding apt-i18n to unstable will not break anything, but interested developers can test this before adding it to real apt. I've been thinking about calling to sign a petiton to get this in for woody. I don't care if this delays woody until June... ;) Greetings, Erich pgprFCoMzPgfC.pgp Description: PGP signature
Re: [2002-04-06] Release Status Update
> IIRC galeon is not moved to woody just because it depends on mozilla > which has an RC bug. Since mozilla is not removed but will be fixed > before the release (at least that's how I understood Anthony's mail) I > wonder if galeon then can make it back in. Or did you just removev > galeon 1.0.3 and 1.2.0 (which depends on mozilla) is not affected at > all? Galeon 1.0.3 (depending on mozilla 0.9.8) was removed because I did not tag the serious bug reports against galeon 1.2.0 "+ sid". Galeon 1.2.0 needs mozilla 0.9.9 and can thus not enter testing right now (and i've been changing some packaging things lately, so there have been a few recent uploads anyway) So when mozilla 0.9.9 is fixed, both moz 0.9.9 and galeon 1.2.0 will hopefully be allowed into woody by aj. Time will tell ;) Greetings, Erich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [2002-04-06] Release Status Update
> As much as I like to have woody released soon, I'm quite confused > because I don't understand why masqmail has to go: This is "had had to go". AJ mailed "over the past few weeks". note the plural. Greetings, Erich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian's problems, Debian's future
> Scheme Disk space Bandwidth > --- > Checksums (bwidth optimal)26K 81K > diffs (4 days)32K 331K > diffs (9 days)71K 66K > diffs (20 days) 159K 27K What diff options do you use? As the diffs are expected to be applied to the correct version, they probably shouldn't contain the old data, but the new data only. Greetings, Erich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#142456: ITP: enigma -- A game where you control a marble with the mouse
Package: wnpp Version: N/A; reported 2002-04-12 Severity: wishlist * Package name: enigma Version : 0.38a Upstream Author : Daniel Heck <[EMAIL PROTECTED]> * URL : http://www.freesoftware.fsf.org/enigma/ * License : GPL Description : A game where you control a marble with the mouse Enigma is a puzzle game similar to Oxyd on the Atari ST or Rock'n'Roll on the Amiga and good old Marble Madness. In Enigma, your objective is to locate and uncover matching pairs of Oxyd stones. Simple as it sounds, this task is made more difficult by the fact that Oxyd stones tend to be hidden, inaccessible or protected by unexpected traps. Overcoming these obstacles often requires al lot of dexterity and wit (and can be quite addicting). YES. This game is a clone of OXYD on the Atari. It just has six levels yet, and mouse control is nice, but not as smooth as in Oxyd yet. VERY promising though. I loved Oxyd... -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux marvin.xmldesign.de 2.4.19-pre6acpi0404 #1 Mon Apr 8 00:26:54 CEST 2002 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian Animation ;)
I've been digging in my old PovRay stuff, and i played with an animation i started a few years ago. The result is quite nice i think (but some weird rendering bugs occur here, like the Comet's tail disappearing during the first fly-through) http://www.fachschaften.uni-muenchen.de/~erich/debian/woody.avi Well, any suggestions? ;) Gruss, Erich Schubert -- erich@(mucl.de|debian.org)--GPG Key ID: 4B3A135C A polar bear is a rectangular bear after a coordinate transform. Die kürzeste Verbindung zwischen zwei Menschen ist ein Lächeln. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Animation ;)
> It looks a bit like a potato though... not quite right for the woody > release? What about woody riding it? How long did it take to render? If you make me a woody model for povray? Just a few spheres? ;) That would be no problem... The wood texture of the comet isn't too visible after the compression ;) I was thinking about having the comet the form of the debian swirl. But i'll need to find some converter to create this... > I really should start doing PovRay animations rather than just pictures You'll need to be good at math's to make smooth animations ;) Gruss, Erich Schubert BTW: What is the best free video codec? MPEG-2 ? OpenDivX? After all the movie should be playable with software contained in woody, no non-US stuff that might have patent problems... -- erich@(mucl.de|debian.org)--GPG Key ID: 4B3A135C A polar bear is a rectangular bear after a coordinate transform. Die kürzeste Verbindung zwischen zwei Menschen ist ein Lächeln. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Refactoring the Debtags web interface
Hi, > > Why not use the DDs and DMs keyrings? just make them sign a given random > token and submit it. Debtags used to have a very liberal contribution policy - anonymous - and that helped a lot getting the intial data in. It has always been a goal to make contributing to Debtags as easy as possible, not as secure as possible (especially at the benefit of what?). Thus I like the idea of people authenticating using alioth, OpenID and similar. best regards, Erich Schubert
Re: [Soc-coordination] Google Summer of Code 2009: Debian's Shortlist
Hello Lists, > We did talk a lot about this issue among reviewing mentors. FYI, we > eventually rejected two other DD proposals and only kept this one. One of the two dropped DD proposals is mine. I've been involved as GSoC Mentor 2 years ago and GSoC Admin for Debian the last two years .I've even been involved in reviewing this years submissions until I decided to instead submit an own proposal. ... so how does that fit to your conspiracy theory? best regards, Erich Schubert -- erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C(o_ Which is worse: ignorance or apathy? Who knows? Who cares? //\ Eine Stadt ist einem erst wirklich vertraut wenn man FreundeV_/_ in ihr hat. --- Antoine de Saint-Exupéry -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debtags localisation and font tags proposal
Hello all, Please don't forget that one of the design goals of DebTags was the KISS principle. > (iso639::sr && iso15924::Latn && iso15924::Cyrl && ! rfc4647::sr-Latn-SR) this definitely doesn't qualify as KISS, in particular since this would probably only apply to a single for within a package, and a package may contain multiple fonts. IMHO we should still try to keep Debtags at a "human readable" complexity level (that is without deeper understanding of logics). If for some particular use there is need for more detailed specifications, these should probably be done in a different system such as RDF. Some examples easily expressable in RDF but not in current Debtags are: -- imagemagick reads TrueType imagemagick reads PNG imagemagick writes PNG -- that could be used to infer that maybe imagemagick can render a truetype font into a PNG bitmap, but not the other way round. RDF can also express things such as (note that I'm not bothering to use a well-defined syntax) --- imagemagick converts (_ from JPEG, _ to PNG) --- It does make sense to collect certain information in a more complex format - in particular if the information can somewhat be automatically obtained, e.g. a script could test packages for having translated man pages etc. - and then derive certain tags from this automatically. But I wouldn't push too much semantics and logic into Debtags. This is not meant to be an objection against the culture:: tag reorganization. I do see the point, and all the variants have their use. For example, an application such as "taxbird" clearly is relevant to the german country as such, maybe even for english-speaking users (if it has such a translation). So here the distinction by traditional locales doesn't make much sense. The application is irrelevant for people from switzerland, even when they are using de_CH locale (or de_DE, for that matter). For quite some time, the german translation of Firefox was going by the name de_AT, and while it was primarily made with an austrian background, it was still the most appropriate translation for german users. One thing we should make a distinction here is: - "Support" for languages/cultures/locales - e.g. the availability of translations - "Limited use" to specific cultures/languages/coutries/locales - e.g. the taxbird restriction for German tax declations So e.g. "gnome-panel" has 'support' for 'German' (in particular 'de_DE'), but that doesn't mean it's of no use for a locale it doesn't have translations for (yet) Whereas "taxbird" might have 'support' for 'English' (probably what should be 'en_DE' ...), but is of no use to people not having to do a German tax declaration. A package manager user should be able to specify something like "I speak only English and rudimentary German, but since I'm currently living in Germany, I need full cultural support for German culture, too. Don't bother to install German language packs for applications that have English translations, but please install culturally relevant packages even when they are only available in German.". best regards, Erich Schubert -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Preventing government subversion in Debian, verification of binary package uploads
Hello all, Prism, NSA, Guardian etc. - I assume all of you have been following these reports, and otherwise you definitely should start reading the news. One thing that apparently has been happening a lot these days are secret court orders in the U.S. For example Google apparently was forced to install some NSA devices, and given some compensation for this. But they are not allowed to talk about it. I am wondering how we can prevent a similar thing to happen to Debian. We're big, so we are probably an interesting target for them. There are quite a few developers in the U.S. and UK that could probably be served such a secret court order and be forced to modify their packages. For example, upload a new kernel that has a built-in backdoor for the NSA. Now given that we have open source, there is a good chance that a "sourceful" modification will not go undetected. But we also have binary package uploads. And build daemons can't really fix this either, because their admins might then be given such an order. The last years, we've seen a lot of effort put into automatic building of packages. Current CPU power should be enough to compile any package multiple times. What I'd like to see is that for all packages (at least for all security relevant packages, including kernel, SSH, GPG, OpenSSL) every package is compiled multiple times, and checksums to verify that none of the build systems were compromised. If we can setup our build infrastructure in a way that we have a dozen of build systems all over the globe (in particular, I'd like to see Switzerland and Norway on this list, who seem to be rather "free" these days compared to other countries) and that they will actually produce the *same binary* then we probably have higher security here. But in the end, such as "verification-only build daemon" could be run everywhere. It can be hosted in China or Russia or the U.S. because it only serves the purpose of raising a flag when a build is suspicious. There will probably be a number of challenges. From different library header versions, compiler versions to CPU architecture differences, race conditions and the use of randomization in the build process, a lot of parameters could cause different binary signatures. But if we can at least get the essential packages safe this way, it would be a good thing. And it's not just about having the software secure: Also, if the individual developer cannot make an undetected change to binary files, it reduces the risk for those that are in the U.S., China, the UK or that visit any of these countries, of being served such a court order the first place. So to some extend, this also protects the developers. And last but not least, all of this might already have been done and I just missed it. I know a lot of archive rebuilds have been done before. And the binary-package attack vector is not new. In fact, it is just a variation of the malicious compiler attack. But that one was mostly discussed with respect to viruses and hackers. The secret court order seems to be a much higher risk these days. You may want to read "Reflections on Trusting Trust" by Ken Thompson and this post and the references within: https://www.schneier.com/blog/archives/2006/01/countering_trus.html Even in 2006 we mostly thought we need this to protect ourselves from hackers. But it looks like we may need to do something like this to protect ourselves from our government agencies, these days. So at some point, I'd like to see Debian binaries verified by diverse double compilation, using a number of different compilers and different people in very different countries. Regards, Erich -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAGKbab_dsgHqc0pw5C_S_dae6xkO=4dguvjeqea7z0ggjh9...@mail.gmail.com
Re: Call for projects and mentors for Google Summer of Code 2012
Hello Ana, Can you drop me from the soc-coordination list admin/moderator list? I cannot find the list admin password anymore. I've been rather passive the last years with respect to GSoC. Mostly helping a bit with voting and reviewing the applications. I'll probably help with that again, but since I havn't been reading the soc-coordination list for some time, it doesn't seem to make much sense to remain a moderator for it (in particular while not finding the password anymore - I searched for it in my archives at least twice just to remove myself) ;-) Thank you, Erich -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAGKbab8gihB5LX=jbmsxg7ki9v2nnlhqai5nbhrc0own7zu...@mail.gmail.com
Bug#638230: ITP: elki -- ELKI Data mining algorithm development framework
Package: wnpp Severity: wishlist Owner: Erich Schubert * Package name: elki Version : 0.4.0~beta1 Upstream Author : ELKI Development Team * URL : http://elki.dbs.ifi.lmu.de/ * License : AGPLv3+ Programming Lang: Java Description : ELKI Data mining algorithm development framework ELKI is a development framework for data mining algorithms written in Java. It includes a large variety of popular data mining algorithms, distance functions and index structures. Its focus is particularly on clustering and outlier detection methods, in contrast to many other data mining toolkits that focus on classification. This package also includes the source code, since this software is meant for the development of such algorithms, not so much for end users. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110817212159.13338.79811.reportbug@localhost.localdomain
