Re: Future releases of Debian
On Sat, Jul 26, 2003 at 12:10:01AM -0400, Nathanael Nerode wrote: > debconf (important) depends on liblocale-gettext-perl (standard). > Presumably liblocale-gettext-perl should become important. > Or debconf could be replaced in 'important' with cdebconf, of course. Ouch... > db2: > This is pretty old... who still uses it, anyway? More specifically, No shortage of them (apt-cache showpkg libdb2). Whether they could all be built using libdb3 I don't know. I'll have another look at my cyrus packages at some stage. > kdebindings: > Orphaned package managed by QA. Should be NMUed, adopted, or removed. WTF does this package even do? If someone could provide a patch, or tell me what to do (if it just needs a reupload) I'll do it, but I've never developed for KDE, so I'm stumped. > kxmleditor: > Grave bug to this effect for 155 days. Package should probably be > hijacked or removed. Or it could be NMUed, of course. There's an ITA on this from Mike Hommey <[EMAIL PROTECTED]>. > open-amulet: > Looks pretty abandoned. Package should probably be hijacked or > removed (or forcibly orphaned, or whatever...) > tcl-sql: > Serious bug to this effect for 89 days -- with patch. Should > probably be NMUed. > xerces: > Normal bug to this effect for 31 days -- with patch. Should probably > be NMUed. I'll ping the maintainers of these. Forcible orphan might be a reasonable option. > can't tell whether it needs anything else. Sparc seems to be taking a > while; s390, m68k, and arm seem to need some serious work. > > Good luck finding more people to work on those last three. If someone wants to donate an S390 to me I'll happily take it to work on d-i; I'll even pay the power bills myself. How's that for selfless sacrifice? - Matt
Re: Future releases of Debian
>db2: > This is pretty old... who still uses it, anyway? More specifically, > does anyone use libdb2++, and if so, are they only things which > aren't supposed to be transitioned? OK, this is an odd list: Package: libdb2++ Reverse Depends: libdb4.1++,libdb2++ 2:2.7.7-3 libdb4.0++c102,libdb2++ 2:2.7.7-3 libdb3++c102,libdb2++ 2:2.7.7-3 libdb2++-dev,libdb2++ 2:2.7.7.0-8 animals,libdb2++ 2:2.7.7-4 What exactly is going on here? It appears that apart from 'animals', the only things depending on libdb2++ (the C++ interface to libdb2) are *future* versions of the C++ interface to libdb. Why are they depending on it? This seems odd to me. -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Re: [custom] Some issues for custom debian distributions
It's really good news that someone is writing on this. Since Debian is somewhat hard to install and configure for unexperienced user, but otherwise Debian is The Best :), I guess many people are doing custom Debain installation tools. > - Preconfigure the packages we install > > Using two different approaches: (1) Load answers into the debconf > database before the packages are installed using some home-make > scripts, and (2) rewrite/replace configuration files using > cfengine at the end of the installation if the package is unable > to configure what we want using debconf. I'm fairly satisfied > with this solution, but am not sure if the method used to feed > the debconf database is the best available. I believe the best > option would be to extend all the packages we use to make it > possible to configure everything we need using debconf answers. I'm not sure that everything can be done this way. E.g. in a "distribution" (better to say - custom installation CD) I maintain here I expect users to use kppp to connect to their ISPs. To make this work by default, I have to comment out whole contents of /etc/ppp/options during the last stage of the installation. I don't think that pppd maintainer will agree that such thing should be provided by debconf. Another thing is replacing "#!/bin/sh" by "#!/bin/bash --login" in /etc/kde3/kdm/Xsession (and other dm's Xsession files). This is the only way I know to make login shell startup files evaluated during X logins. This issue is known for ages, but it seems that people who make decisions don't thing it is necessary. So this isn't likely to be fixed with debconf questions. > - Automatic X configuration > > Using home-brewed script filling the debconf database, and then > call dexconf from the xfree86 package to generate the > configuration file. The HW detection info is fetched from > various packages (discover, kudzu, detect, etc). Could you give an URL to such script? I need one badly. Unfortunatly, discover/mdetect/read-edid based dexconf is far from perfect, especcialy in detecting capabilities of the monitor. And hadrware detection is not what I am an expert in :(. > - CD building > > Using a heavily patched version of debian-cd to create the CDs. > Most of the patches is to include the d-i boot floppies. This > should now be possible with the standard version of debian-cd, > but no one in Skolelinux have taken the time to update our copy > of the scripts. The thing I really don't like in debian-cd is the requirement to have a local mirror. I prefer to use apt-get (+apt-proxy) to fetch packages while building CD. I have a (currently ugly) script to do so; if anyone is interested I can (try to) clean it up and make it available. > - Configure default language for all users > > Using a custom script to rewrite config files to modify the > default language/locale. Seems that feeding correct value to debconf for "locales" package fixes this. At least for me. Currently I install "locales" and "console-cyrrillic" (with all dependencies) very early - I modified debootstrap to do so. Default values to debconf database also are written by modified debootstrap. So I have russian properly set up already when base-config runs. > There are probably others, but this should be a good starting point. > Are these issues common to other custom distros? Main problems I current have are related to hardware detection and configuration. Users want to configure their X display easily (resolution, frequency, etc). E.g. from KDE control center. They complain that other distros let them to do so. I am not familar with distros other than Debian so I don't know what to do. Also users want all their hardware to be detected and configured automatically. Well, discover does something, but again, users complain that XXX is not detected/configured/working properly, while everything is ok with other distros. Maybe there are better tools? Please share your experiense.
Re: Future releases of Debian
On Sat, Jul 26, 2003 at 02:45:56AM -0400, Nathanael Nerode wrote: > > >db2: > > This is pretty old... who still uses it, anyway? More specifically, > > does anyone use libdb2++, and if so, are they only things which > > aren't supposed to be transitioned? > > OK, this is an odd list: > Package: libdb2++ > > Reverse Depends: > libdb4.1++,libdb2++ 2:2.7.7-3 > libdb4.0++c102,libdb2++ 2:2.7.7-3 > libdb3++c102,libdb2++ 2:2.7.7-3 > libdb2++-dev,libdb2++ 2:2.7.7.0-8 > animals,libdb2++ 2:2.7.7-4 > > What exactly is going on here? It appears that apart from 'animals', > the only things depending on libdb2++ (the C++ interface to libdb2) are > *future* versions of the C++ interface to libdb. Why are they depending > on it? This seems odd to me. These "dependencies" are versioned conflicts with older versions of libdb2++. > Nathanael Nerode cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#202930: ITP: openoffice.org-dictionaries -- MySpell dictionaries from OpenOffice.org
Package: wnpp Version: unavailable; reported 2003-07-26 Severity: wishlist * Package name: openoffice.org-dictionaries [*] Version : 20030617 Upstream Author : David Bartlett <[EMAIL PROTECTED]> Gianluca Turconi <[EMAIL PROTECTED]> Davide Prina <[EMAIL PROTECTED]> * URL : OOo's source (>= 1.1beta) -> www.openoffice.org * License : GPL / LGPL / SISSL Description : MySpell dictionary for [I] OpenOffice.org hyphenation pattern for English (GB) [II] [I] This is the dictionary for use with the myspell spellchecker which is currently used within OpenOffice.org and the mozilla spellchecker. [II] This is the English (GB) hyphenation pattern for use with OpenOffice.org [*] This is the source package name; we strongly search for a better name. The current one resulted from the idea that this stuff comes from the "dictionaries" module in OOo's CVS and source. Suggestions welcome :) The binary packages would be: - myspell-en-us --| - myspell-en-gb |-- [I] - myspell-it--| - openoffice.org-hyphenation-en-gb [II] -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux frodo 2.4.21-rene #2 Fre Jun 27 15:46:02 CEST 2003 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 pgpsrLCilQdJA.pgp Description: PGP signature
Re: Future releases of Debian
On Sat, Jul 26, 2003 at 12:10:01AM -0400, Nathanael Nerode wrote: > dselect (required) depends on libstdc++5, libgcc1 (both important) > Upgrade priority of the latter two, or downgrade dselect. Alternately... is the difference between "required" and "important" really useful? We already have the "Essential" flag to indicate which packages are really required. We could just fold these levels into one to simplify things. Richard Braakman
Re: [custom] Some issues for custom debian distributions
Quoting Tore Anderson ([EMAIL PROTECTED]): > well), as I've seen far too many packages which ask Debconf questions > way out of proportion, carelessly ignore policy 11.7.3 (cf. the "manage > with Debconf madness" thread), etc. So even though it is possible to I hope you didn't forgot to file bugs for this For sure, there *is* a real debconf madness. During the debconf translation work we often find packages which make a huge abuse of debconf questions, asking for everything to be configured, or showing useless silly notes. Maintainers also often misuse priorities. You will event find packages which have only "high" priority questions. These deserve bug reports. The "switch to po-debconf" current work offers us a good opportunity for reviewing the use of debconf questions. When I submit a patch for po-debconf switch, I sometimes have to suggest removing some templates...or lower thepriority of others. Having a lot of debconf questions is not bad by itself. However, the majority should then be marked of "low" priority as long as they are notes to users and/or Choices with reasonable defaults.
Re: Future releases of Debian
On Sat, Jul 26, 2003 at 02:45:56AM -0400, Nathanael Nerode wrote: > >db2: > > This is pretty old... who still uses it, anyway? More specifically, > > does anyone use libdb2++, and if so, are they only things which > > aren't supposed to be transitioned? > > OK, this is an odd list: > Package: libdb2++ > > Reverse Depends: > libdb4.1++,libdb2++ 2:2.7.7-3 > libdb4.0++c102,libdb2++ 2:2.7.7-3 > libdb3++c102,libdb2++ 2:2.7.7-3 > libdb2++-dev,libdb2++ 2:2.7.7.0-8 > animals,libdb2++ 2:2.7.7-4 > > What exactly is going on here? It appears that apart from 'animals', And, quite honestly, animals should probably disappear. When all of a maintainer's packages were NMU'd into stable, and they haven't moved since, it's time to say goodbye. - Matt
Bug#202940: ITP: pyduali -- pyduali, An arabic spell checker
Package: wnpp Version: N/A; reported 2003-07-26 Severity: wishlist * Package name: pyduali Version : 0.1.1 Upstream Author : Mohammed Elzubeir <[EMAIL PROTECTED]> * URL : http://www.arabeyes.org/project.php?proj=Duali * License : BSD Description : pyduali, An arabic spell checker Duali is an Arabic spellchecker that is open source and can run across multiple platforms. It is currently being developed under the Linux environment. Due to the lack of Arabic spellchecking capabilities on many different platforms and lack of information on how one can go about developing such a useful tool, the Duali project was bo -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux debian 2.4.21-splash #1 Sat Jul 19 03:15:10 EEST 2003 i686 Locale: LANG=en_US, LC_CTYPE=en_US
Re: Future releases of Debian
Richard Braakman <[EMAIL PROTECTED]> wrote:
>
> Alternately... is the difference between "required" and "important"
> really useful? We already have the "Essential" flag to indicate
> which packages are really required. We could just fold these
> levels into one to simplify things.
Required could be used to mark those packages which should be essential
but can't, e.g., libc6 or mawk.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Future releases of Debian
On Sat, Jul 26, 2003 at 07:10:06PM +1000, Matthew Palmer wrote: > On Sat, Jul 26, 2003 at 02:45:56AM -0400, Nathanael Nerode wrote: > > What exactly is going on here? It appears that apart from 'animals', > > And, quite honestly, animals should probably disappear. When all of a > maintainer's packages were NMU'd into stable, and they haven't moved since, > it's time to say goodbye. animals is orphaned (#202174), although the maintainer seems to be under some kind of strange impression that he actually maintains the package (see the same bug). -- Colin Watson [EMAIL PROTECTED]
Re: Future releases of Debian
On Sat, Jul 26, 2003 at 11:39:38AM +0100, Colin Watson wrote: > On Sat, Jul 26, 2003 at 07:10:06PM +1000, Matthew Palmer wrote: > > And, quite honestly, animals should probably disappear. When all of a > > maintainer's packages were NMU'd into stable, and they haven't moved since, > > it's time to say goodbye. > > animals is orphaned (#202174), although the maintainer seems to be under > some kind of strange impression that he actually maintains the package > (see the same bug). I read that little exchange when investigating newly orphaned packages, then checked qa.debian.org/[EMAIL PROTECTED], and laughed. For anyone wondering: having your name in the Maintainer field doesn't make you the maintainer. Maintaining the package makes you the maintainer. - Matt
Re: proposal: per-user temporary directories on by default?
On Fri, Jul 25, 2003 at 08:44:17AM -0500, Steve Greenland wrote: > Or, for all I care, we can default to /tmp/u/username. Just don't bother > me about it. If you default to ~/tmp/ or ~/.temp/ or something like this, you get the hashing for free, and you only need quota on the home partition. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Who wants cgoban?
One of the packages I "maintain" is cgoban. I packaged it ages ago when I was a fanatical Go player. Nowadays I only get Go fever about one week per year, and it's hard to make time for this package when I'm uninspired about the game. I'd like to give it to someone who actually uses it. cgoban - Complete Go board This program presents a graphical Go board on which you can play. It doesn't play against you, you need another program (like gnugo) to do that. It's primarily designed to play on two Internet Go servers, IGS and NNGS. The author of cgoban is friendly and responsive, but he considers cgoban to be obsolete. He's working on cgoban2, which is written in Java and is a client for a different set of Go servers (KGS), so it's not a replacement for cgoban. There is now a sourceforge project for maintaining cgoban1, as one bugreporter rudely pointed out. Packaging that version would be a productive way to take over this package :) If you want it, please let me know, and (to avoid collisions) wait for me to confirm before you actually make an upload. Richard Braakman
Killing off hextype
hextype - Hexdump according to DOS Debug output format I realize that this little program has a certain fan base, and I used to be part of that fan base, but I really think the time has come to retire it. These days the program "hd" (in bsdmainutils) provides all the same convenience. I find myself using hd instead of hextype (even though I maintain hextype!) because it has two advantages: - It's more flexible. If I want to adjust something about the output, or if I want to see only a specific part of a file, then I can just give it some options. With hextype there's only one exact format and I have to be happy with that. - It will condense repeated identical lines. This is hugely convenient when looking at tarfiles, filesystem dumps, and other things with large blocks of zeroes. The sole advantage of hextype is that it's smaller and faster, but I've never had a reason to care about that. Normally I would just file for hextype's removal after coming to these conclusions, but as I said earlier, I know that this program has a fan base :) So if you use hextype, and want to keep it in the archive, then please contact me and I'll happily accept your offer to maintain it... (If you're in the new maintainer queue, I'll also sponsor your uploads as long as you don't make a mess of them.) If I hear nothing about it in a week or two, then I'll assume that everyone hates hextype and I'll ask for it to be removed. Thanks, Richard Braakman
KDE Developers Conference ("Kastle")
http://events.kde.org/info/kastle/ |KDE Contributor Conference 2003 - "Kastle" |22-30 August, 2003 |Nové Hrady, Czech Republic Which Debian KDE folks will be there? I think this event would be great for Debian KDE people to interact with upstream. -- Martin Michlmayr [EMAIL PROTECTED]
NMU version number and native packages
Hi, I've a little question about version number and NMU on debian native packages. What's the standard way to modify this number ? * On one side the developer's reference says: "If there is no debian-revision component in the version number then one should be created, starting at `0.1'." So adding -0.1 to the number * On other side some people on #d-d says that the standard way is to add .1 to the number. So, what's the best way to process ? Cheers, seb128
Re: proposal: per-user temporary directories on by default?
Bernd Eckenfels <[EMAIL PROTECTED]> wrote: > On Fri, Jul 25, 2003 at 08:44:17AM -0500, Steve Greenland wrote: >> Or, for all I care, we can default to /tmp/u/username. Just don't bother >> me about it. > If you default to ~/tmp/ or ~/.temp/ or something like this, you get the > hashing for free, and you only need quota on the home partition. It was pointed out already that this is not necessarily a good idea, e.g. when /home is on NFS. Additionally you cannot run tmpreaper on ~/tmp/ without starting a big information campain, "everthing under ~/ was always sacred." cu andreas -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
Re: KDE Developers Conference ("Kastle")
On Samstag, 26. Juli 2003 15:01, Martin Michlmayr - Debian Project Leader wrote: > http://events.kde.org/info/kastle/ > > |KDE Contributor Conference 2003 - "Kastle" > |22-30 August, 2003 > |Nové Hrady, Czech Republic > > Which Debian KDE folks will be there? I think this event would be > great for Debian KDE people to interact with upstream. I guess I'm the only one - although not officially a Debian Folk (yet) due to the long timeline of becoming a Debian project member. Sucks but that's Debian's rules :) Simon Hausmann from KDE will also be there I guess, he's building the alpha packages for my woody builds on KDE releases. Ralf > > -- > Martin Michlmayr > [EMAIL PROTECTED] -- We're not a company, we just produce better code at less costs. Ralf Nolden [EMAIL PROTECTED] The K Desktop Environment The KDevelop Project http://www.kde.org http://www.kdevelop.org pgpgTkM8chuB6.pgp Description: signature
Re: NMU version number and native packages
The 'standard process' that I know of is this: > * On other side some people on #d-d says that the standard way is to add > .1 to the number. > Thus, a package with a version number '1.5' will be versioned '1.5.1' Then, an exception follows that if the previous upload was a NMU, in which case the last number is increased. (i.e. after 1.5.1, 1.5.2 is used). In that respect, developers-reference's statement of 'Adding 0.1' is not quite precisely documenting the current practice. Binary-only NMUs add a '0.1', which result in 1.5.0.1. Binary-only NMU after a NMU will result in 1.5.1.1. regards, junichi
Re: Who wants cgoban?
On Sat, Jul 26, 2003 at 02:59:59PM +0200, Martin Godisch wrote: > On Sat, Jul 26, 2003 at 14:59:50 +0300, Richard Braakman wrote: > > > One of the packages I "maintain" is cgoban. I packaged it ages ago when > > I was a fanatical Go player. Nowadays I only get Go fever about one week > > per year, and it's hard to make time for this package when I'm uninspired > > about the game. I'd like to give it to someone who actually uses it. > > I'm using it and I'd be glad to adopt it. Okay! Please make an upload within two weeks :) (I adopted the two-week rule after unsuccessfully giving away maelstrom and xconq a couple of times...) Richard Braakman
Re: Future releases of Debian
John Hasler <[EMAIL PROTECTED]> writes: > Bob Hilliard wrote: >> A true newbie would be one who has never used a computer before. To such >> a person, a CLI is much more intuitive than any GUI. > > Colin Walters writes: >> And your research supporting this is...? > > No research, but I've had a couple of experiences that tend to confirm it. > It's irrelevant, though, because people who have never used Windows or Mac > are getting scarce. John answered before I got to it, but he said essentially what I would have. 1 Regards, Bob -- _ |_) _ |_Robert D. Hilliard<[EMAIL PROTECTED]> |_) (_) |_) 1294 S.W. Seagull Way <[EMAIL PROTECTED]> Palm City, FL 34990 USA GPG Key ID: 390D6559
Re: [debian-devel] Future releases of Debian
>--[Halil Demirezen]--<[EMAIL PROTECTED]> > For example, I came accross a segfault with micq. However, I could not find > the reason for this bug. Why i pointed out this is that there may be a > probable > bug there. If you're the one who found the unreproducible segfault, then filing a bug report won't help. Considering that the Debian project neither fixes the Copyright violation of Debian's packaging nor fixes the trivial to fix bug that will give you the scroll of death (both things of the type that are supposed to be fixed), and considering that that version is quite outdated, the only way to use mICQ is to add "http://www.micq.org/deb (un)stable main" to your /etc/apt/sources.list. -- 100 DM = 51 ¤ 13 ¢. 100 ¤ = 195 DM 58 pf. mailto:[EMAIL PROTECTED] http://www.ruediger-kuhlmann.de/
Bug#202907: language tasks pull in reams of huge packages
On Fri, Jul 25, 2003 at 02:50:52PM -0400, Joey Hess wrote: > Package: tasksel, general > Version: 1.25 > Severity: normal > > If you pick the Spanish language task in tasksel, you will get mozilla > and openoffice installed, which is often not the desired effect. This is That not only happens with the spanish task, the same happens with the danish task. BTW. (..) > > Solutions include: > > - Make the -ll packages only recommend the main packages, as the kde > ones do. Unfortunately, this cannot be done easily for mozilla, at least, since translations for a version will not work (and will probably break) other versions. Also, it depends on mozilla being available to register the locale. > - Put the -ll packages in the tasks that install OOo and mozilla. > But this is quite hard to maintain in tasksel. Maybe tasksel could have two different set of tasks: language tasks and "purpose" tasks (for a lack of a better word) and have tasksel decide the appropiate packages based on crossing both types. That way you could have language-tasks packages with no specific purpose or for all purposes (like 'util-linux-locales') but some other packages would be installed only if you selected a combination of tasks. For example: if you selected task 'Spanish' and 'Desktop' you get both kde's and gnome locales and documentation. If you select 'danish' and 'office' then you get 'openoffice.org-l10n-da' > - Stop this translation splitting nonsense. The problem (at least in the mozilla case) is that translations are not provided within upstream sources, they are provided by different teams, for different mozilla versions and are never integrated into the core itself. It's crap, I know, but that should be fixed upstream. In any case, I've removed the mentioned packages from the CVS until we decide what is best and how to do it. Regards Javi pgpKl6KsMwSi0.pgp Description: PGP signature
Bug#202907: language tasks pull in reams of huge packages
Javier Fernández-Sanguino Peña wrote: > Unfortunately, this cannot be done easily for mozilla, at least, since > translations for a version will not work (and will probably break) other > versions. Also, it depends on mozilla being available to register the > locale. They could probably conflict and recommend to get the right version of mozilla, and then mozilla would have to deal with registering languages installed before it. > > - Put the -ll packages in the tasks that install OOo and mozilla. > > But this is quite hard to maintain in tasksel. > > Maybe tasksel could have two different set of tasks: language tasks and > "purpose" tasks (for a lack of a better word) and have tasksel decide the > appropiate packages based on crossing both types. That way you could have > language-tasks packages with no specific purpose or for all purposes > (like 'util-linux-locales') but some other packages would be installed only > if you selected a combination of tasks. > > For example: if you selected task 'Spanish' and 'Desktop' you get both > kde's and gnome locales and documentation. If you select 'danish' and > 'office' then you get 'openoffice.org-l10n-da' Doing this would probably involve multiplying the number of language tasks by the number of other tasks. Yeilding tasks like desktop-spanish, etc. This would quickly become hard to maintain, I'd think. > In any case, I've removed the mentioned packages from the CVS until we > decide what is best and how to do it. Actually I would rather we keep them in until we reach a resolution. I'd rather tasksel err on the side of too big rather than on the side of too little and confusing, as a general rule. Another option that's not much better is moving all the mozilla and OOo translation packages from the language tasks to the main tasks. -- see shy jo pgpsqmJXFQEPZ.pgp Description: PGP signature
Re: proposal: per-user temporary directories on by default?
On Fri, Jul 25, 2003 at 11:11:04PM -0400, Matt Zimmerman wrote: > mkstemp(3) mkstemp returns a file descriptor, how... [reads the manpage again]... oh. %-) > mkdtemp(3) I see. Sigh. I guess it's hopeless to expect that everyone will write their programs properly. Oh well. I give in. Use libpam-tmpdir. -- Dwayne C. Litzenberger <[EMAIL PROTECTED]> The attachment is an OpenPGP (PGP/MIME) signature, which can be used to verify the authenticity of this message. See the message headers for more information. pgpLWKfjKP603.pgp Description: PGP signature
Re: unicode
On Friday 25 July 2003 18:57, Colin Watson wrote: > Oh, konsole? No idea, as I don't use KDE. I saw your mentions of font > problems elsewhere in this thread. Have you tried, say, uxterm with a > known-good UTF-8 font? I use > '-misc-fixed-medium-r-normal--15-140-75-75-c-*-iso10646-1' on my work > machine. > > Have you seen bug #191985? Ok, uxterm is much better. Thanks for pointing that bug report out - but I think the switching to unicode mode thing doesn't work for me. Thanks & greets -- vbi -- Conscience doth make cowards of us all. -- Shakespeare pgpGIBDF0Cdow.pgp Description: signature
Re: Future releases of Debian
On Saturday 26 July 2003 01:08, John Hasler wrote: > No research, but I've had a couple of experiences that tend to confirm it. > It's irrelevant, though, because people who have never used Windows or Mac > are getting scarce. In the industrialized world. But there's 3 billion people who have never seen a computer. And I think it would be cool if the first computer they came across would run a Free OS... Just my ¤.02 -- vbi -- featured link: http://fortytwo.ch/gpg/subkeys pgp20W1dFpDGK.pgp Description: signature
Re: [custom] Some issues for custom debian distributions
Nikita V. Youshchenko wrote: > E.g. in a "distribution" (better to say - custom installation CD) I maintain > here I expect users to use kppp to connect to their ISPs. To make this work > by default, I have to comment out whole contents of /etc/ppp/options during > the last stage of the installation. I don't think that pppd maintainer will > agree that such thing should be provided by debconf. > > Another thing is replacing "#!/bin/sh" by "#!/bin/bash --login" in > /etc/kde3/kdm/Xsession (and other dm's Xsession files). This is the only > way I know to make login shell startup files evaluated during X logins. > This issue is known for ages, but it seems that people who make decisions > don't thing it is necessary. So this isn't likely to be fixed with debconf > questions. This is the kind of thing that dropping a script in /usr/lib/base-config can help you with. > The thing I really don't like in debian-cd is the requirement to have a > local mirror. I prefer to use apt-get (+apt-proxy) to fetch packages while > building CD. I have a (currently ugly) script to do so; if anyone is > interested I can (try to) clean it up and make it available. I would much rather see debian-cd work that way. > Seems that feeding correct value to debconf for "locales" package fixes > this. At least for me. > > Currently I install "locales" and "console-cyrrillic" (with all > dependencies) very early - I modified debootstrap to do so. Default values > to debconf database also are written by modified debootstrap. So I have > russian properly set up already when base-config runs. base-config 1.41 and above modify /etc/locale.gen and run locale-gen to set up the installation locale before it goes interactive. If this doesn't work I would appreciate bug reports and patches in this area. -- see shy jo pgpU6Z4s3VoEd.pgp Description: PGP signature
Re: [custom] Some issues for custom debian distributions
Nikita V. Youshchenko <[EMAIL PROTECTED]> wrote: [...] > Another thing is replacing "#!/bin/sh" by "#!/bin/bash --login" in > /etc/kde3/kdm/Xsession (and other dm's Xsession files). This is the only > way I know to make login shell startup files evaluated during X logins. > This issue is known for ages, but it seems that people who make decisions > don't thing it is necessary. So this isn't likely to be fixed with debconf > questions. [...] cat < /etc/X11/Xsession.d/60local_userenvironment if [ -r /etc/profile ] ;then . /etc/profile fi if [ -r $HOME/.profile ] ; then . $HOME/.profile fi EOF This'll work for all display-managers that use the (Debian-)standard /etc/X11/Xsession.d/. Introducing an ~/.environment which would be evaluated by pam_env would really be nice. cu andreas
Re: Future releases of Debian
On Sat, Jul 26, 2003 at 03:32:33PM +1000, Matthew Palmer wrote: > If someone wants to donate an S390 to me I'll happily take it to work on > d-i; I'll even pay the power bills myself. How's that for selfless > sacrifice? On a reasonably fast machine, Hercules is pretty usable for small-to-medium-sized projects. -- - mdz
Re: update-alternatives priorities for editors
Adam Heath wrote: > /usr/bin/vi should be an alternative for vi-compatible editors. > > /usr/bin/vi should then be an alternative that is hooked into /usr/bin/editor. But, but, but... How does it work if /usr/bin/vi is an alternative hooked into /usr/bin/editor? What package would own that hook? Just speaking academically since I am really not proposing we change this, would there need to be an vi-editor meta package just for the second level of indirection? And a similar emacs-editor meta package for emacs. And so on for each editor? I think this is too much. > Same for emacs. Agreed on the basis of symmetry. (And I am an emacs user.) But from a pragmatic standpoint I think editor should be something for the untrained masses. Bob pgpIjAoK8ozzd.pgp Description: PGP signature
Bug#202980: ITP: ots -- Open Text Summarizer
Package: wnpp Version: unavailable; reported 2003-07-27 Severity: wishlist * Package name: ots Version : 0.3.0+cvs.2003.07.27-1 Upstream Author : Nadav Rotem <[EMAIL PROTECTED]> * URL : http://libots.sourceforge.net/ * License : GPL Description : Open Text Summarizer OTS reads a text and decides which sentences are important and which are not. Then it creates a short summary or will highlight the main idea in the text (the output can be HTML). OTS is m17n'd and works with UTF-8 encoding. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux shangri-la 2.4.21 #1 2003年 7月 25日 金曜日 00:07:43 JST i686 Locale: LANG=ja_JP.eucJP, LC_CTYPE=ja_JP.eucJP
logging out a ssh-user
Hi! I have to log out a user who is logged in via ssh. The information that he is not allowed to login comes from the utmp-file like the pid to kill. If he's logged in via telnet, I can do the job by killing that pid. That does not work with ssh: For some reason, all what I get out of utmp is the pid of the listening sshd which I can't kill if I don't want to disable ssh-logins. I solved it by adding 2 to that pid to reach the child-ssh, checking if it is "sshd" and owned by the user who is to be logged out. If that all is ok, I kill that pid. Well, it works, but is that reliable and secure? Will this also work after the maximum of PID is reached? The package I am talking about is timeoutd. (No bug for that) Dennis
Re: [custom] Some issues for custom debian distributions
On Sat, Jul 26, 2003 at 05:51:35PM +0200, Andreas Metzler wrote: > cat < /etc/X11/Xsession.d/60local_userenvironment > if [ -r /etc/profile ] ;then > . /etc/profile > fi > if [ -r $HOME/.profile ] ; then > . $HOME/.profile > fi > EOF > > This'll work for all display-managers that use the (Debian-)standard > /etc/X11/Xsession.d/. That's a very interesting approach! I did not know this was possible when I sent additional information to #147091. Maybe that's something that language-env (or user-XX) should do upon installation to set the proper locale for X environments also. > > Introducing an ~/.environment which would be evaluated by pam_env would > really be nice. Isn't /etc/environment read too? Because that is what base-config modifies IIRC. Regards Javi pgpq6IktvNwKh.pgp Description: PGP signature
Bug#202907: language tasks pull in reams of huge packages
> They could probably conflict and recommend to get the right version of > mozilla, and then mozilla would have to deal with registering languages > installed before it. Will try, thanks for the tip. > > For example: if you selected task 'Spanish' and 'Desktop' you get both > > kde's and gnome locales and documentation. If you select 'danish' and > > 'office' then you get 'openoffice.org-l10n-da' > > Doing this would probably involve multiplying the number of language > tasks by the number of other tasks. Yeilding tasks like desktop-spanish, > etc. This would quickly become hard to maintain, I'd think. No, I meant that the tasksel definition could be expanded to have packages defined in the tasks that are only installed if another task is selected. Not duplicating tasks merging both but having one say to tasksel: "this package should only be installed if task X has also been selected". > Actually I would rather we keep them in until we reach a resolution. I'd > rather tasksel err on the side of too big rather than on the side of too > little and confusing, as a general rule. > I have removed it both because of over-bloating and because of mozilla-locale-es being broken at the moment. I have also re-added 'user-es' which was missing from the spanish task (but the CVS logs do not indicate if this was done on purpose or it was a mistake) > Another option that's not much better is moving all the mozilla and OOo > translation packages from the language tasks to the main tasks. Agreed. Regards Javi pgpBE3GWl3Bb7.pgp Description: PGP signature
Re: [custom] Some issues for custom debian distributions
Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> wrote: [...] >> Introducing an ~/.environment which would be evaluated by pam_env would >> really be nice. > Isn't /etc/environment read too? Because that is what base-config modifies > IIRC. Yes or no ;-) Currently pam_env does read /etc/environment but it does not read ~/.environment. cu andreas
Re: logging out a ssh-user
On Saturday 26 July 2003 19:55, Dennis Stampfer wrote: > I have to log out a user who is logged in via ssh. The information that > he is not allowed to login comes from the utmp-file like the pid to > kill. Not sure if that helps, but 'slay' might be the proper tool for it. Uli
Bug#203004: ITP: superkaramba -- A program based on karamba improving the eyecandy of KDE
Package: wnpp Version: unavailable; reported 2003-07-27 Severity: wishlist * Package name: superkaramba Version : 0.29 Upstream Authors: Adam Geitgey <[EMAIL PROTECTED]>, Hans Karlsson <[EMAIL PROTECTED]> * URL : http://netdragon.sourceforge.net/ * License : GPL Description : A program based on karamba improving the eyecandy of KDE SuperKaramba is a tool based on karamba that allows anyone to easily create and run little interactive widgets on a KDE desktop. Widgets are defined in a simple text file and can be augmented with Python code to make them interactive. Here are just some examples of the things that can be done: * Display system information such as CPU Usage, MP3 playing, etc. * Create cool custom toolbars that work any way imaginable. * Create little games or virtual pets that live on your desktop. * Display information from the internet, such as weather and * headlines. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux uranus 2.4.20 #6 Fri May 30 16:01:55 CEST 2003 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] -- Jean-Michel Kelbert pgpoBR4CTIwqn.pgp Description: PGP signature
Re: [custom] Some issues for custom debian distributions
On Sat, Jul 26, 2003 at 09:24:55PM +0200, Andreas Metzler wrote: > Javier Fern?ndez-Sanguino Pe?a <[EMAIL PROTECTED]> wrote: [somebody broke attributions here] > >> Introducing an ~/.environment which would be evaluated by pam_env would > >> really be nice. > > > Isn't /etc/environment read too? Because that is what base-config modifies > > IIRC. > > Yes or no ;-) Currently pam_env does read /etc/environment but it does > not read ~/.environment. Yow. Guess I'd better get round to renaming my ~/.environment (which is a shell script, definitely not something suitable for reading by pam_env) sometime soon then ... -- Colin Watson [EMAIL PROTECTED]
Re: [custom] Some issues for custom debian distributions
Andreas Metzler wrote: > Nikita V. Youshchenko <[EMAIL PROTECTED]> wrote: > [...] > > Another thing is replacing "#!/bin/sh" by "#!/bin/bash --login" in > > /etc/kde3/kdm/Xsession (and other dm's Xsession files). This is the only > > way I know to make login shell startup files evaluated during X logins. > > This issue is known for ages, but it seems that people who make decisions > > don't thing it is necessary. So this isn't likely to be fixed with debconf > > questions. That is one of the FAQs on the KDE site. http://www.kde.org/documentation/faq/configure.html#id2913380 9.7. KDE (kdm) does not read my .bash_profile!". The login managersxdm and kdm do not run a login shell, so .profile, .bash_profile, etc. are not sourced. When the user logs in, xdm runs Xstartup as root and then Xsession as user. So the normal practice is to add statements in Xsession to source the user profile. Please edit your Xsession and .xsession files This leads one to suggest what Andreas suggested: > cat < /etc/X11/Xsession.d/60local_userenvironment > if [ -r /etc/profile ] ;then > . /etc/profile > fi > if [ -r $HOME/.profile ] ; then > . $HOME/.profile > fi > EOF > > This'll work for all display-managers that use the (Debian-)standard > /etc/X11/Xsession.d/. I originally went down this path as well. I thought the same thing and implemented the same solution. (I put it in 95user_env so that it was very late in the process.) But there are some problems with doing this. 1. The Xsession is currently run in 'set -e' mode and any non-zero return value from a command will stop the shell process. Running in 'set -e' mode is not a normal mode for running a .profile. Many users will execute commands which will have a non-zero return code. This is not an error. This is just by normal script operation. The effect is that the user cannot log in. 2. Many users will source /etc/bash_completion in their startup file. That should be fine if they are running bash. But the Xsession scripts are running as /bin/sh and it will not be happy parsing bash_completion. The effect is that the user cannot log in. 3. Many users do not use .profile but instead use .bash_profile, .zprofile, .login, etc. Which means that suddenly Xsession needs to know about not only the filename of every viable shell but also the syntax of every viable shell. The effect is that some users do not get their startup environment set up while others do. After having gone through the experience of implementing this and having many users suddenly unable to log in I have new appreciation for the problems the KDE developers face. If they pull in the user's environment then problems there will prevent users from being able to log in. The user won't be happy, even if it is their fault, and the KDE developers will get a bug report even though it is not their problem. (Yes I know the user can either console login or failsafe login and fix their problem. But assumes the user knows it is their problem. It also assumes that the user wants to add workarounds to their startup files to control functionality between KDE login and other logins. I know I don't want to do that myself.) I did not originally agree with the KDE decision not to source the user environment. I was dismayed to see that I was not getting my environment. But I now agree with their choice not to load the user files by default. Because without loading other files then a user can select KDE from the login manager and log in and any problems in that path are solely a KDE problem. If KDE works then they are in. But as soon as you open it up to loading user files you are opening yourself up to an unbounded list of perfectly valid user configurations which cause problems, such as sourcing bash_completion, which will prevent the user from logging in. Is there no hope? Yes there is hope. I think there is a middle ground. The answer I am happy with and have implemented is providing a user $HOME/.xsession. Here is what I use. #!/bin/sh PATH=$HOME/bin:$PATH:. exec x-session-manager That is all of the fixup I need but it does provide the hook to do any customization that is desired. Actually, I personally put /usr/sbin and /sbin in the PATH too. But I don't default users to that. If someone knows they can do it easily enough. Additionally since I use fvwm I start it instead of kde. #!/bin/sh PATH=$PATH:/usr/sbin:/sbin PATH=$HOME/bin:$PATH:. exec fvwm With this in place I should give a clarification of the login manager process. Let me give a typical example. The menu selection will allow the user to choose default, failsafe, kde. Picking default gets you the $HOME/.xsession file if one exists. In the example above I get my selection fvwm. If a user picks kde then the login manager does NOT run the users's $HOME/.xsession file and instead just starts up KDE in the way that it does now withou
Re: proposal: per-user temporary directories on by default?
On Sat, Jul 26, 2003 at 02:52:48PM +0200, Andreas Metzler wrote: > It was pointed out already that this is not necessarily a good idea, > e.g. when /home is on NFS. Additionally you cannot run tmpreaper on > ~/tmp/ without starting a big information campain, "everthing under ~/ > was always sacred." I put all my "important files without a better spot" under ~/tmp. Actually maybe running tmpreaper on this directory would be a good idea ;-), although I don't dare risk it. The fact remains though that I use /tmp/bam and /home/bam/tmp for different purposes. The point about /home being NFS is an important one, some programs don't function properly with /tmp being NFS. (then again, some programs debian/stable don't cope with NFS on /home either, but thats a topic for another thread, most noteably Gnome IIRC). -- Brian May <[EMAIL PROTECTED]>
Re: [custom] Some issues for custom debian distributions
> Nikita V. Youshchenko <[EMAIL PROTECTED]> wrote: > [...] >> Another thing is replacing "#!/bin/sh" by "#!/bin/bash --login" in >> /etc/kde3/kdm/Xsession (and other dm's Xsession files). This is the only >> way I know to make login shell startup files evaluated during X logins. >> This issue is known for ages, but it seems that people who make decisions >> don't thing it is necessary. So this isn't likely to be fixed with >> debconf questions. > [...] > > cat < /etc/X11/Xsession.d/60local_userenvironment > if [ -r /etc/profile ] ;then > . /etc/profile > fi > if [ -r $HOME/.profile ] ; then > . $HOME/.profile > fi > EOF > > This'll work for all display-managers that use the (Debian-)standard > /etc/X11/Xsession.d/. Sterictly saying, this is broken. /etc/profile, ~/.profile and other login shell rc files should be read by logic shells only, so if a user types "startx" on the console, they should not be read.
