Re: Generating ~/.ssh/known_hosts from LDAP
Thanks Matt for your script. Will you add it to debian-goodies ? Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here.
Re: Nice multilingual environment with Debian menu
Osamu Aoki wrote: > 2. command are executed under "sh -c" to enable new environment, Menu documentation is not clear about how command are to be executed. I have made a study of the problem (http://people.debian.org/~ballombe/wmbugs, tes backquote). Part of the problem is that many window-manager documentation are not clear either on this point. There are several way to execute a command: 1) Split on white space and call exec, à la xterm -e command 2) call sh -c 'command' 3) call sh -c 'exec command' 4) call system($command) It is my opinion that the correct way (as far as menu is concerned) is 2). This can be implemented in the menu-method 'supported' section, without needing to patch the window-manager. The problem with 3) is that it break a lot of things, like % sh -c 'exec LANG=jp locale' sh: exec: LANG=jp: not found This is the problem with blackbox. Currently menu.h handle text entries under X11 using x-terminal-emulator -e command, this can be seen as a bug and I will fix it in the next release. Opinion ? Cheers, [Please CC me, thanks] -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here.
Re: RFP: gtybalt -- computer algebra system (CAS) based on GiNaC with optional TeXmacs GUI
On Thu, Jan 20, 2005 at 01:39:04PM -0500, Kevin B. McCarty wrote: > I am planning to package this myself, but I won't have time until mid to > late summer (after my thesis is finished). So if anyone else wants to grab > it in the meantime, they are welcome to. > > The biggest problem is that gTybalt currently depends upon Root, which > is not DFSG-free and has some legal issues, for graphing functionality. > There is apparently movement to fix the Root issues by making it DFSG-free: > http://lists.debian.org/debian-devel/2005/01/msg01166.html > If that doesn't come to anything, gTybalt's upstream intends to rework > the program to use gnuplot or some other freely licensed grapher instead. Avoid gnuplot if you can, the license is GPL-incompatible and not one we should encourage (See bug #100612 for why). > gTybalt also depends upon a few other pieces of open-source code (cint, > nestedsums, NTL) that aren't currently packaged for Debian. I use NTL, but given it is a static-only C++ library I never felt the need to package it. (Also it is heavily tuned at build-time, so a generic build is likely to be slower than a tuned build, and I tend to massage it a bit, so I need to recompile it anyway). Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 4
On Wed, May 10, 2006 at 02:57:22AM +0200, Matthias Klose wrote: > Bill Allombert writes: > > Debian GCC Maintainers > > g++-3.3 > > g++-3.4 > > g++-4.0 > > g++-4.1 > > gcj > > gcj-4.0 > > gcj-4.1 > > java-gcj-compat > > libgcj-dev > > libgcj6-dev > > libgcj7-dev > > libstdc++5-3.3-dev > > libstdc++6-4.0-dev > > libstdc++6-4.1-dev > > libstdc++6-dev > > > > Debian GCC maintainers > > g++-2.95 > > libstdc++2.10-dev > > maybe the corresponding g++-X.Y and libstdc++-Z-X.Z-dev packages could > be solved by merging these packages. Anyway, these binaries are built > from the same source, so we should ot care- Being built from the same source has no effect on apt and dpkg handling of circular dependencies. > I currently do not understand the java-gcj-compat / gcj-4.X relationship. java-gcj-compat is involved in a dependency loop with: antlr gjdoc kaffe kaffe-jthreads kaffe-pthreads libgnucrypto-java libjessie-java graph at http://debian.semistable.com/dot/libjessie-java_unstable.png gcj-4.X circular deps: gcj-4.0 <--> libgcj6-dev gcj <--> libgcj-dev gcj-4.1 <--> libgcj7-dev > > Debian OpenOffice Team > > openoffice.org-common > > openoffice.org-core > > that's just a splitting into arch/indep packages. you sould not warn > about it. apt and dpkg do not handle them any specially, so I don't see why I should. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new tar behavior and --wildcards
On Mon, Jun 26, 2006 at 01:22:12PM -0600, Bdale Garbee wrote: > > Since this seems to have been an intentional behavior change by > upstream to better align with a published standard, I'm uninclined to > fight it, and think our best response is to update our utilities to > include the --wildcards option, with a suitable versioned dependency on > tar. Debian still has to provide an upgrade path for users upgrading from Sarge. We cannot blindly break users scripts. Also, before doing such change we need to audit: 1) all build scripts (i.e. rebuild the whole archive with the new tar) and see how many packages FTBFS. 2) all Sarge maintainer scripts, init script and cron scripts 3) all Etch maintainer scripts, init script and cron scripts 4) all Sarge packages for tar usage to allow for partial upgrade. 5) all Etch packages for tar usage We did something similar with "su" but we did it earlier in the release cycle, and I think we have already lot of work to do to release etch on time. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
