Re: Bug#393411: Source package contains non-free IETF RFC/I-D's
Simon Josefsson <[EMAIL PROTECTED]> writes: > The second problem seems to be generic. The reason I looked at > packages in testing was that they are the packages that are going to > be released, and if I look at what's in unstable, it seems that I > might miss what's going to be in etch (e.g., e2fsprogs seems to be > frozen, and the version in unstable now doesn't seem to be going into > etch). > > Should I look at packages in unstable, and only if the package is > frozen, look at the one in testing, instead? You should check the packages in testing. Then check the packages in unstable. Note what packages fixed the problem in unstable, file an RC bug for the testing version and close it for the unstable version. That then reflects the reality and will keep track of the problem. Note what packages started to be buggy in sid. Hopefully none. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lack of transparency of automatic actions
Hendrik Sattler <[EMAIL PROTECTED]> writes: > Am Montag 16 Oktober 2006 11:34 schrieb Frank Küster: >> Hendrik Sattler <[EMAIL PROTECTED]> wrote: >> >> Even worse, you again have to use KDE or Gnome to take advantage of >> >> network-manager. Why are we leaving CLI users out in the cold? >> > >> > Good question. The concept for a cli like this would need many thoughts, >> > though. A GUI makes that a bit easier. >> >> It's not "(KDE or GNOME) vs. CLI". I usually work under X, but I don't >> use a Desktop Environment. I use some of the GUI tools they offer, but >> it's always unclear to me to what extent this is expected to work at >> all, and which side effects it may have (like creation of stuff called >> "icons" on my desktop background, if I use the wrong WindowManager, or >> "useful" subdirectories below $HOME). > > AFAIK, knetworkmanager only needs a compatible system tray and kwallet (to > store the keys). I didn't try with Xfce or another WM, though. WMaker is > probably a good test candidate. > Normally, they do not create "icons". And it should fail with an explanation if such is not available. There is nthing worse than an application that you start and then it puts itself in an non-existent system tray and sits there unreachable. > But there is always a lack of control applications, that's true. Another > example are passkey agents for current bluez (there is only one for Gnome). > > HS MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sometimes-dependency, linux-image-2.6.18-1-486
Hamish Moffatt <[EMAIL PROTECTED]> writes: > On Mon, Oct 16, 2006 at 04:08:17PM -0500, Clarence Risher wrote: >> of yaird. Should that be filed as a bug against >> linux-image-2.6.18-1-486 even though its not always a dependency? > > Yes. > >> And that leads me to the general question, on the topic of >> sometimes-dependencies. Does debian have any facility to handle such? >> linux-image-2.6.18-1-486 doesnt technically depend on yaird, since it >> can use any mkinitrd script (of which there are many, provided by other >> packages), but when it does pick mkinitrd.yaird then it requires an up >> to date version of yaird. > > Conflicts. The package doesn't depend on yaird, but it does (should) > conflict with insufficient versions. > > > Hamish You can also use Depends: yarid (>= 1.2-3) | initramfs-tools | initrd-toos | foo | bar Any one of them will do but if yarid is used then the version must be new enough. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question regarding maintainer email
On Tue, Oct 17, 2006 at 09:33:04 +1000, Ben Finney wrote: > Bill Allombert <[EMAIL PROTECTED]> writes: > > > Something I have yet to understand is what purposes the bounce [from > > a moderated list] serve in the first place. Moderating is OK, but > > bouncing ? > > I read many mailing lists (this one, for example) without being > subscribed as a member. > > An automated message saying "Your post to the list, unlike many > others, will be delayed until a human acts" tells me that I shouldn't > get anxious at the non-appearance of my message on the list. Without > such a message, many people would believe their message was eaten > somewhere, and post it again and again. However, it is often the case that such mails will never make it to the list, due to lazyness or other reasons for the list admin not to accept the mail manually. I already had this case with an Alioth list that was used as the maintainer address for a Debian package. Regards, Tino -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New cyrus-sasl2 packages
* "Roberto C. Sanchez" <[EMAIL PROTECTED]> [2006-10-16 01:18]: > Mail-Followup-To: ... quite helfpul, if you ask me. :) I'm not sure if you wanted that, but I'm following your wish. > * These packages are still in a state of flux, so please bear with us And they are, as one can see in #393318 - the bug isn't in libetpan nor in etpan-ng. Please keep in mind that filing FTBFS RC bugs because of some package that is "still in a state of flux" is helping at no end ... Especially FTBFS bugs which don't appear in a clean unstable chroot aren't helpful at all. If you still work on the package and don't upload it, there is no problem - and you still can fix the problems appearing within your own package. So long, Alfie -- "This is Linux Country. On a quiet night, you can hear Windows reboot." -- .sig in <[EMAIL PROTECTED]> signature.asc Description: Digital signature
[Help] Please compile clustalw on architectures ia64, mips, mipsel, s390 and m68k
Dear all, Clustal W and Clustal X are the most popular software for multiple alignment of biological sequences. Their source package was NMUed during the lesstif transition, but not built on enough architectures, and was therefore removed from testing. http://packages.qa.debian.org/c/clustalw.html Can some DD help clustalw to get back into Etch as we still have the opportunity ? I just entered the NM queue and therefore can not do this kind of work by myself. Thank you so much in advance! Have a nice day, -- Charles Plessy Debian-Med packaging team Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gdm/Gnome/KDE and device permissions
[Gernot Salzer]
> what is the standard/canonical way of handling device permissions
> in Debian ("etch" in my case) on desktop PCs running a GUI?
As you probably found out from the replies so far, there is no
standard way. :(
Here are some notes I wrote for Debian Edu. You might find it useful.
Local device access
---
The local user should have access to some of the local devices
(sound, cdrom, etc) after logging in on the console or via
kdm/gdm/xdm/etc, but not when logging in from remote via ssh. There
are as far as I know two ways to make this happen. One way is to
add the local user to the groups needed to access these devices, the
other is to change the permissions on these devices to give access
to the local user. The former is done using pam_group, while the
latter is done using pam_devperm. Both have advantages and
weaknesses.
pam_group
-
By updating /etc/pam.d/common-auth and /etc/security/group.conf it is
possible to add the logged in user to the grous needed (audio,
floppy, cdrom, plugdev, video). In addition to getting access to
the devices present during login, it also make sure hotplugged
devices like USB sticks work (group membership in plugdev take care
of this).
The problem with this method is that every member of the groups in
question can create a setgid program to gain access to the devices
also when not logged into the machine. This will make it possible
to record from the microphone, read and from the floppy, cdrom and
usb stick, as well as play unwanted sound on other users computers.
It is also possible to start long-running processes in the
background to keep the access privileges to the devices in question.
--- /etc/pam.d/common-auth.orig 2006-10-17 11:25:40.0 +
+++ /etc/pam.d/common-auth 2006-10-17 11:25:29.0 +
@@ -7,4 +7,5 @@
# (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the
# traditional Unix authentication mechanisms.
#
+auth optionalpam_group.so
auth requiredpam_unix.so nullok_secure
--- /etc/security/group.conf.orig 2006-10-17 11:27:32.0 +
+++ /etc/security/group.conf2006-10-17 11:31:43.0 +
@@ -55,6 +55,8 @@
#xsh; tty* ;*;Al0900-1800;floppy
+*; tty*&!ttyp*; *; Al-2400; audio,cdrom,floppy,plugdev,video
+*; :0; *; Al-2400; audio,cdrom,floppy,plugdev,video
#
# End of group.conf file
pam_devperm
---
By installing libpam-devperm and updating /etc/pam.d/common-sessionn
(and /etc/logindevperm to fix bug #393661 and get access to
/dev/dsp), it is possible to modify the permissions of relevant
devices when a user log in, and reset the permissions when the user
log out. The user of the device is changed to the logged in user,
and the mode is normally set to 0600 granting exclusive access.
The problem with this method is that hotplug devices do not work, as
they are not available when the user is logged in, and the device
ownership is only modified when the user log in. Another problem is
that the user can keep the access privileges for the devices after
he log out by starting long-running processes in the background.
--- /etc/pam.d/common-session.orig 2006-10-17 11:23:21.0 +
+++ /etc/pam.d/common-session 2006-10-17 10:42:08.0 +
@@ -7,3 +7,4 @@
# non-interactive). The default is pam_unix.
#
sessionrequiredpam_unix.so
+sessionrequiredpam_devperm.so
--- /etc/logindevperm.orig 2006-10-17 10:51:58.0 +
+++ /etc/logindevperm 2006-10-17 10:53:08.0 +
@@ -24,7 +24,7 @@
:0 0600 /dev/cdrecorder:/dev/cdrecorder1:/dev/cdrecorder2:/dev/cdrecorder3
:0 0600 /dev/dvd:/dev/dvd1:/dev/dvd2:/dev/dvd3
:0 0600 /dev/zip:/dev/zip1:/dev/zip2:/dev/zip3
-:0 0600 /dev/dsp0:/dev/dsp1:/dev/dsp2:/dev/dsp3
+:0 0600 /dev/dsp:/dev/dsp0:/dev/dsp1:/dev/dsp2:/dev/dsp3
:0 0600 /dev/fd0:/dev/fd0u1440:/dev/fd0h1440:/dev/fd0u720:/dev/fd0h720
:0 0600 /dev/fd1:/dev/fd1u1440:/dev/fd1h1440:/dev/fd1u720:/dev/fd1h720
:0 0600 /dev/sequencer:/dev/sequencer2:/dev/music
Conclusion
--
I recommend using the pam_group mechanism to get a working hotplug
support, and recommend solving the setgid-issue by adding the nosuid
mount flag to the partitions where users can add files (/home/,
/tmp/, /dev/shm/, /var/lock/), and solving the problem with
long-running processes by running some kind of idle-job killer to
kill long-running processes.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sometimes-dependency, linux-image-2.6.18-1-486
On Tue, Oct 17, 2006 at 09:35:49AM +0200, Goswin von Brederlow wrote: > Hamish Moffatt <[EMAIL PROTECTED]> writes: > > On Mon, Oct 16, 2006 at 04:08:17PM -0500, Clarence Risher wrote: > >> And that leads me to the general question, on the topic of > >> sometimes-dependencies. Does debian have any facility to handle such? > >> linux-image-2.6.18-1-486 doesnt technically depend on yaird, since it > >> can use any mkinitrd script (of which there are many, provided by other > >> packages), but when it does pick mkinitrd.yaird then it requires an up > >> to date version of yaird. > > > > Conflicts. The package doesn't depend on yaird, but it does (should) > > conflict with insufficient versions. > > You can also use > Depends: yarid (>= 1.2-3) | initramfs-tools | initrd-toos | foo | bar > > Any one of them will do but if yarid is used then the version must be > new enough. Isn't there the possibility here that you have both yaird (< 1.2-3) and another suitable package installed? The deps would be met, but linux-image-* might choose yaird and build a non-working initramfs. (The initramfs generators don't conflict with each other.) Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gdm/Gnome/KDE and device permissions
Am Dienstag 17 Oktober 2006 13:50 schrieb Petter Reinholdtsen: > By updating /etc/pam.d/common-auth and /etc/security/group.conf it is > possible to add the logged in user to the grous needed (audio, > floppy, cdrom, plugdev, video). In addition to getting access to > the devices present during login, it also make sure hotplugged > devices like USB sticks work (group membership in plugdev take care > of this). Does that work when not using pmount but only hal to mount devices? Can the other side of d-bus messages be aware of such group memberships?: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377689 Unless d-bus started to support this during the last month, setting plugdev via PAM will not always work (only when using pmount). Same probably goes for network-manager and its netdev group. HS pgpAPGGBeibyc.pgp Description: PGP signature
building non-free packages on debian.org machines? (was: [Help] Please compile clustalw on architectures ia64, mips, mipsel, s390 and m68k)
Petter Reinholdtsen <[EMAIL PROTECTED]> wrote: > [Charles Plessy] >> Clustal W and Clustal X are the most popular software for multiple >> alignment of biological sequences. Their source package was NMUed during >> the lesstif transition, but not built on enough architectures, and was >> therefore removed from testing. >> >> http://packages.qa.debian.org/c/clustalw.html > > Ah, the pain with no autobuilders for non-free packages. You will > have to find a developer with access to all of the architectures ia64, > mips, mipsel and s390 (m68k is ignored), and get them to build > binaries of the package. Am I correct that it's not appreciated to build the package on the debian.org machines? Unfortunately, this is kind of unclear in the Machine Usage Policy. The only thing that comes near is , | Avoid running processes that are abusive in CPU or memory. If | necessary the DSA's will reap up such processes without warning. ` Of course in many cases it would be needed to ask the DSA people to install the required build-deps, but before I ask I'd rather know whether it's allowed at all. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: [Help] Please compile clustalw on architectures ia64, mips, mipsel, s390 and m68k
Petter Reinholdtsen <[EMAIL PROTECTED]> wrote: > What about convincing the upstream developers to change the license to > one of the free software licenses? It would solve the problem for > good. Judging from the mail recorded in its copyright file, this isn't likely to happen. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: safe halt/reboot/shutdown
On Mon, 16 Oct 2006 16:50:08 +0200, martin f krafft <[EMAIL PROTECTED]> wrote: >I am sure you've all once typed 'halt' only to notice that >you were in an active SSH session and the machine on the other side >of $BIG_DISTANCE obediently followed your request. I've done it way >too much, so I ended up hacking up > > http://svn.madduck.net/pub/sbin/base/shutdown > >This script, along with symlinks from halt and reboot, lives in >/usr/local/sbin on all my systems -- and thus I would like to see it >in Debian proper. However, I feel that it's too small for a separate >package, and I am not sure sysv-utils is the appropriate place, even >if debconf would ask the user whether s/he wanted that safety net. A more compatible way of doing so would be having an optional configuration file where one could set an option that shutdown won't do anything unless the correct host name was given on the command line. The config file should be optional so that shutdown's behavior is not altered in the default case and shutdown still works even if the config file is not available for any reason such as a broken system. While we are at it, this configuration file should also have an option to completely forbid shutdown -h or halt - a colocated server that switches itself off after shutdown -h won't respond to a reset signal, so remote hands are needed. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
How can the OS autodetect that a user is a newbie and offer help?
Hi all, I believe that since command-line Linux is hard to learn, Debian should offer handholding. (This would benefit both Debian users who are new to the command line and How can the OS autodetect that a user is a newbie and offer help? For example, when a person types newbie commands like "help" or "kde" (which is bound to something already) or the DOS commands "del" or "ren" (which are not), we should point them to more help. (In case anyone here has ever watched a real clueless newbie struggle: What are other commands that 100% clueless newbies often type?) For example, there are various Linux command-line mode tutorials out there. There are also the manuals linked to from debian.org. Plus there are tons of good quick reference cards; I do some tutoring and the one I recommend most often to my clients is "The One Page Linux Manual". There's even an interactive Java-based tutorial on the Web (Google for linux interactive tutorial). There is also our support webpage that points users to the mailing lists and IRC. Finally, for those without cheap web access, there are documents such as debian-reference-en and quick-reference-en, though they're Priority: optional and so unlikely to be installed. What would be a good help text to offer when a user types a command that indicates he/she is a newbie? Also, what package should I file a wishlist against to request that such help be added? Regards, Jason Spiro <[EMAIL PROTECTED]> -- The church is near but the road is icy; the bar is far away but I will walk carefully. -- Russian Proverb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian Installer - Call for testing *this week*
(Please reply to the debian-boot list.) Preparations for Release Candidate 1 of the installer have now really started. All important functional changes are now included in the daily images. In order improve the quality of the release and reduce the number of nasty surprises afterwards, it would be great if we could get some help testing the installer during *this week*. Please make sure you use one of the _daily built_ images available from: http://www.debian.org/devel/debian-installer/ or http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/ and file an installation report with your findings: http://d-i.alioth.debian.org/manual/en.i386/ch05s03.html#submit-bug See this wiki page for a general overview of the planned release, including known issues: http://wiki.debian.org/DebianInstaller/EtchRC1Prep Testing the installer for your favorite architecture(s) === This is the main focus for this call for testing. Please let us know if there are any important issues, especially regressions from previous releases. If you can, try different installation methods. Note that the installer still uses 2.6.17. Main reason is that 2.6.18 is not yet ready to migrate to testing and switching to 2.6.18 would therefore block RC1 of d-i. Depending on the kernel team and RMs, we may still switch to 2.6.18 before RC1, but switching immediately afterwards looks more likely. Other things to test There is a number of other things that could be tested, mostly new functionality that was added recently: - graphical installer, especially whether your mouse and touchpad work correctly - crypto support in partman: the installer now has crypto support both for guided [1] and manual [2] partitioning; thorough tests, including of the actual security of the installed system, very, very welcome - automatic raid partitioning (preseeded only [1]) - 2.6 based installation floppies for i386 - support for non-standard filesystems (i.e. anything other than ext3) - if you speak a language other than English, consider installing in that language; note that one last round of translation updates is still planned, but reports of issues are still appreciated TIA, Frans Pop [1]http://d-i.alioth.debian.org/manual/en.i386/ch06s03.html#di-partition [2]http://d-i.alioth.debian.org/manual/en.i386/ch06s03.html#partman-crypto [3]http://d-i.alioth.debian.org/manual/en.i386/apbs04.html#preseed-partman-raid pgpJWmZuObmyg.pgp Description: PGP signature
Re: safe halt/reboot/shutdown
also sprach Marc Haber <[EMAIL PROTECTED]> [2006.10.17.1453 +0200]: > A more compatible way of doing so would be having an optional > configuration file where one could set an option that shutdown > won't do anything unless the correct host name was given on the > command line. You want to alter /sbin/shutdown itself? > While we are at it, this configuration file should also have an option > to completely forbid shutdown -h or halt - a colocated server that > switches itself off after shutdown -h won't respond to a reset signal, > so remote hands are needed. This is a good idea. I'll see to implementing this in my script, along with the suggested configuration file handling. I do like the extra prompt though... -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems NP: No-Man / Flowermouth (2005 Reissue) signature.asc Description: Digital signature (GPG/PGP)
Re: gdm/Gnome/KDE and device permissions
[Hendrik Sattler] > Does that work when not using pmount but only hal to mount devices? Can the > other side of d-bus messages be aware of such group memberships?: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377689 Thank you for the reference. It seem to me that this problem still exist in the KDE version we use. > Unless d-bus started to support this during the last month, setting > plugdev via PAM will not always work (only when using pmount). Same > probably goes for network-manager and its netdev group. :( Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Help] Please compile clustalw on architectures ia64, mips, mipsel, s390 and m68k
Wouter Verhelst <[EMAIL PROTECTED]> wrote: > On Tue, Oct 17, 2006 at 02:38:49PM +0200, Andreas Tille wrote: [...] >> Just read the mails of these both threads and learn why we have >> not yet autobuilders for non-free. IMHO the main issue is that >> "nobody really _did_ it". > > There are two issues at hand that explain why there is no non-free > autobuilder: > > * Most people who could set up one (because they have the hardware and > the skillz) do not want to [...] > * Packages in main are required to be DFSG-free [...] > Therefore, anyone interested in building non-free > would need to maintain a list of packages that do not have such > problematic restrictions. TTBOMK, this has not happened. This is nothing new, it has already been discussed in the thread Andreas referenced. Something new would be an answer to my question whether it's acceptable to build non-free packages on the Debian machines. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: How can the OS autodetect that a user is a newbie and offer help?
On Tue, Oct 17, 2006 at 01:02:45PM +, Jason Spiro wrote: > Hi all, > > I believe that since command-line Linux is hard to learn, Debian should > offer handholding. (This would benefit both Debian users who are new to > the command line and How can the OS autodetect that a user is a newbie > and offer help? Hmm, I don't think it's "hard to learn", it's just "hard to switch" when you say a "normal user" to switch his OS now. > For example, when a person types newbie commands like "help" or "kde" > (which is bound to something already) or the DOS commands "del" or "ren" > (which are not), we should point them to more help. (In case anyone here > has ever watched a real clueless newbie struggle: What are other > commands that 100% clueless newbies often type?) This is a good idea, we put little shell scripts somewhere and add it to the PATH variable for all members of the group "newbies", something like that at least. Then we could also tell them which manpages to read and point them to some good websites or wikis. > What would be a good help text to offer when a user types a command that > indicates he/she is a newbie? Also, what package should I file a > wishlist against to request that such help be added? We could start together a project which does this shell scripts, I think it's not really a lot of work. Don't file a bug, first we can do a "linuxnewbie" program and someone (maybe myself) will build a debian package one day. For me there's only one point: We have to make sure that advanced users DO NOT get this bothering messages. Regards -- .''`. Mario Iseli <[EMAIL PROTECTED]> : :' :proud user of Debian unstable `. `'` `- Debian - when you have better things to do than fixing a system -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: safe halt/reboot/shutdown
On Tue, 17 Oct 2006 15:12:25 +0200, martin f krafft <[EMAIL PROTECTED]> wrote: >also sprach Marc Haber <[EMAIL PROTECTED]> [2006.10.17.1453 +0200]: >> A more compatible way of doing so would be having an optional >> configuration file where one could set an option that shutdown >> won't do anything unless the correct host name was given on the >> command line. > >You want to alter /sbin/shutdown itself? Yes. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: [Help] Please compile clustalw on architectures ia64, mips, mipsel, s390 and m68k
[Charles Plessy] > Clustal W and Clustal X are the most popular software for multiple > alignment of biological sequences. Their source package was NMUed during > the lesstif transition, but not built on enough architectures, and was > therefore removed from testing. > > http://packages.qa.debian.org/c/clustalw.html Ah, the pain with no autobuilders for non-free packages. You will have to find a developer with access to all of the architectures ia64, mips, mipsel and s390 (m68k is ignored), and get them to build binaries of the package. Or you can ask the ftpmasters to remove the binaries for these archs, but that normally take longer time. I only have i386 machines myself, so I can not help you. What about convincing the upstream developers to change the license to one of the free software licenses? It would solve the problem for good. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Help] Please compile clustalw on architectures ia64, mips, mipsel, s390 and m68k
On Tue, 17 Oct 2006, Petter Reinholdtsen wrote: Ah, the pain with no autobuilders for non-free packages. Exactly. You will have to find a developer with access to all of the architectures ia64, mips, mipsel and s390 (m68k is ignored), and get them to build binaries of the package. In principle this might be every developer via http://db.debian.org/machines.cgi but it is just a pain to do it this way (and does not always work - at least when I tried some months ago I was not able to compile the package I tried). Or you can ask the ftpmasters to remove the binaries for these archs, but that normally take longer time. That would be stupid because we *want* the architectures. What about convincing the upstream developers to change the license to one of the free software licenses? It would solve the problem for good. When I maintained this package I tried and I guess my successors tried as well. Another solution was suggested nearly 5 years ago http://lists.debian.org/debian-devel/2001/11/msg01472.html and if I remember also at other occurences but the search interface for the list archive does not uncover these mails and Google found only this one for a quick glance. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Help] Please compile clustalw on architectures ia64, mips, mipsel, s390 and m68k
On Tue, 17 Oct 2006, Andreas Tille wrote: When I maintained this package I tried and I guess my successors tried as well. Another solution was suggested nearly 5 years ago http://lists.debian.org/debian-devel/2001/11/msg01472.html and if I remember also at other occurences but the search interface Just to reply to my own mail: I blamed the search interface to fast: http://lists.debian.org/debian-devel/2002/11/msg00270.html Just read the mails of these both threads and learn why we have not yet autobuilders for non-free. IMHO the main issue is that "nobody really _did_ it". Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Help] Please compile clustalw on architectures ia64, mips, mipsel, s390 and m68k
On Tue, Oct 17, 2006 at 02:38:49PM +0200, Andreas Tille wrote: > On Tue, 17 Oct 2006, Andreas Tille wrote: > > >When I maintained this package I tried and I guess my successors tried > >as well. Another solution was suggested nearly 5 years ago > > > > http://lists.debian.org/debian-devel/2001/11/msg01472.html > > > >and if I remember also at other occurences but the search interface > > Just to reply to my own mail: I blamed the search interface to > fast: > > http://lists.debian.org/debian-devel/2002/11/msg00270.html > > Just read the mails of these both threads and learn why we have > not yet autobuilders for non-free. IMHO the main issue is that > "nobody really _did_ it". There are two issues at hand that explain why there is no non-free autobuilder: * Most people who could set up one (because they have the hardware and the skillz) do not want to, either because they feel that maintaining buildd machines for main takes up more than enough of their time, or because they oppose to working on non-free as a principle. * Packages in main are required to be DFSG-free; therefore, it cannot be illegal to install or build this package if you live in Europe, are male, do not speak English, or any other silly requirement. The only requirement for a package to appear in Debian is that Debian must be allowed to *distribute* it. A requirement that we are allowed to build or even install it, is not part of the requirement of non-free. While the examples I gave above are obviously silly and over the top, there are actual examples of packages in non-free that have license requirements which would make autobuilding them (or their reverse dependencies) cumbersome, at the very least (though I can't recall which they were). Therefore, anyone interested in building non-free would need to maintain a list of packages that do not have such problematic restrictions. TTBOMK, this has not happened. -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: safe halt/reboot/shutdown
On Tue, 17 Oct 2006, Marc Haber wrote: You want to alter /sbin/shutdown itself? Yes. According to my own experience this would probably be the only clean way. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: safe halt/reboot/shutdown
also sprach Marc Haber <[EMAIL PROTECTED]> [2006.10.17.1556 +0200]: > >You want to alter /sbin/shutdown itself? > > Yes. Go for it. In the mean time I am going to deal with my shell script. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems NP: No-Man / Speak signature.asc Description: Digital signature (GPG/PGP)
Source package contains non-free IETF RFC/I-D's
Some raised a concern with false positives in my reports -- and also tagged all the bugs with etch-ignore. I went through all bug reports manually yesterday (see earlier mail), but I also realized that it would be possible to do this automatically, to provide further assurance that the bugs indicate real and confirmed problems. I've updated my script to do this, view it last on the page: http://wiki.debian.org/NonFreeIETFDocuments The script will run md5sum on the RFC/I-D in source packages, and compare them against a known-real repository (rsync'ed against ftp.rfc-editor.org). The output of the script is very long, so I won't include it here. An URL to it is: http://josefsson.org/bcp78broken/debian-ietf-documents-diff.txt To parse the output yourself, look for lines beginning with 'pkg'. Those denote the start of a new package with potential problems. After that there will be lines such as 'tar xfz...' and two MD5 sums. If the MD5 sums match, it will print MATCH. If the MD5 sums mismatch, it will print MISMATCH. If it can't find a known-good file to compare with, it prints FETCH-FAIL. Some statistics: 74 packages 401 MATCH, i.e., the RFC in the source package is an authentic RFC 79 MISMATCH, i.e., the RFC differ from the authentic RFC 6 FETCH-FAIL Note that this does _not_ mean that there were 79 false positives in my reports. Nothing I did today indicates that there are any more false positives except (possibly) draft-zebra-00.txt that I found manually yesterday. The FETCH-FAIL's are few and easy to analyze: FETCH-FAIL draft-davis-dasl-protocol-00.txt FETCH-FAIL spf-draft-20040209.txt FETCH-FAIL spf-draft-200405.txt FETCH-FAIL rfc.txt FETCH-FAIL rfc.txt FETCH-FAIL draft-zebra-00.txt I can't find the first document anywhere on the Internet, possibly the filename is incorrect, although it looks like a submitted IETF document. spf-* were submitted through the IETF under other names. rfc.txt is a dummy file. draft-zebra-00.txt was the likely false positive I found manually yesterday. The MISMATCH'es are more interesting to analyze, and indicate a variety of reasons. As can be seen in the file, just a few pages down, one reason is that the RFC in the source package differs from the authenticate RFC! E.g., typos has been corrected. Modifying the document is not permitted by the IETF license, so these files do not seem to be legally distributable at all, not even in non-free. Several files differ trivially, such as removed/added initial/terminal newlines, or changing multiple newlines into one newline. At least one file differ due to RCS $Id$ tags. In the DateTime-Format-Mail archive, the files differ substantially because the source package only contains a small excerpt from the RFC, instead of the entire RFC. Some files differ because I can't compare them to the real document, because the IETF used to put a "RIP-notice" that the document has expired using the same filename. The diff output for all of them suggests that these are real IETF documents, though. /Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#393411: Source package contains non-free IETF RFC/I-D's
Goswin von Brederlow <[EMAIL PROTECTED]> writes: > Simon Josefsson <[EMAIL PROTECTED]> writes: > >> The second problem seems to be generic. The reason I looked at >> packages in testing was that they are the packages that are going to >> be released, and if I look at what's in unstable, it seems that I >> might miss what's going to be in etch (e.g., e2fsprogs seems to be >> frozen, and the version in unstable now doesn't seem to be going into >> etch). >> >> Should I look at packages in unstable, and only if the package is >> frozen, look at the one in testing, instead? > > You should check the packages in testing. This is what I'm doing now. > Then check the packages in unstable. I'm doing this step manually now. > Note what packages fixed the problem in unstable, file an RC bug for > the testing version and close it for the unstable version. That then > reflects the reality and will keep track of the problem. Hm, I know how to submit a bug for the version in testing (this is what I've done), but I don't know how to close it for the unstable version. How do I do that? > Note what packages started to be buggy in sid. Hopefully none. Exactly -- I intend to mirror and check unstable for regressions in this area. I submitted a lintian check for this, if something like it can be installed, it would also help avoid this problem in the future. /Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: safe halt/reboot/shutdown
also sprach Andreas Tille <[EMAIL PROTECTED]> [2006.10.17.1600 +0200]:
> According to my own experience this would probably be the only
> clean way.
I fail to see the problem with my shell script: unless it's called
via SSH while connected to a terminal, it does nothing else but call
/sbin/halt.real (or whatever the actual halt command is). No sudo,
no grep, no anything, just plain POSIX shell.
I agree that it would be *nice* to have a policy framework for
shutdown, but it just won't happen before etch. But I want my shell
script in etch.
Thus, unless I get other suggestions, I'll package it up in its own
package, which diverts /sbin/{reboot,halt,shutdown} and puts my
shell script in their place. I'll Enhance whatever init systems
there are and I'll ask them to add Suggests.
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <[EMAIL PROTECTED]>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
always remember you're unique, just like everyone else.
signature.asc
Description: Digital signature (GPG/PGP)
Missing days?
Hi! I have started to wonder a bit about 'missing days' - a thing that is especially importaint now when we are heading for a total freeze. >From http://packages.qa.debian.org/u/udev.html: Too young, only 1 of 10 days old [2006-10-15] Accepted 0.100-2.1 in unstable (low) and here my math works fine. But here: http://packages.qa.debian.org/k/kwin-style-crystal.html Too young, only 1 of 10 days old [2006-10-13] Accepted 1.0.2-1 in unstable (low) But here, my math don't work as expected. Anyone able to enlighten me a bit ? /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Missing days?
On 2006-10-17, Sune Vuorela <[EMAIL PROTECTED]> wrote: > But here: > http://packages.qa.debian.org/k/kwin-style-crystal.html > Too young, only 1 of 10 days old > [2006-10-13] Accepted 1.0.2-1 in unstable (low) hmm... one day has just gone here. now 2 of 10 (But I still miss one day ;) /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Help] Please compile clustalw on architectures ia64, mips, mipsel, s390 and m68k
Le Tue, Oct 17, 2006 at 02:30:59PM +0200, Frank Küster a écrit : > Petter Reinholdtsen <[EMAIL PROTECTED]> wrote: > > > What about convincing the upstream developers to change the license to > > one of the free software licenses? It would solve the problem for > > good. > > Judging from the mail recorded in its copyright file, this isn't likely > to happen. http://packages.debian.org/changelogs/pool/non-free/c/clustalw/clustalw_1.83-1.1/clustalw.copyright Dear all, Eight years have passed since the authors of Clustal gave a special permission to Debian. There could be hope that the non-exclusive licences they sold to companies have expired, removing the reason for which they are reluctant to give Clustal away for free. Indeed, as there are now some "competitors" in the public domain, I see more and more commercial products using them instead of Clustal, so it is predictable that the authors will not get revenues from this program for ever, if they still do. When the Debian-Med project will have some authority in the field of molecular biology and bioinformatics, I think that it will be a good idea to contact the academic authors of non-free software, and ask them if they would like to reconsider their choice. But for this, we need success, and for success we need to listen to our users, and our users still massively use Clustal compared to the free competitors. http://people.debian.org/~igloo/popcon-graphs/index.php?packages=kalign+dialign+probcons+clustalx+clustalw+muscle+t-coffee+poa+amap-align+sigma-align&show_installed=on&want_legend=on&beenhere=1 I do not know how to interpret the popcon data: either some users are swiching from the clustal programs to alternatives, or we are losing some users since clustalw was removed from testing. Already 10 % less... Ouch, it bleeds... In conclusion: by building this non-free package and allowing clustalw to migrate in testing, you will help to increase our user base and promote all the free software we promote together with clustalw: http://wiki.debian.org/SequenceAlignment PS: depending on the answer, debian-science can be a better list than debian-devel. PPS: I would bet that half of the architectures on which clustalw is missing are architectures on which nobody uses Clustal W or Clustal X, but this is another story... Have a nice day, -- Charles Plessy Debian-Med Packaging Team Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How can the OS autodetect that a user is a newbie and offer help?
On 2006-10-17, Mario Iseli <[EMAIL PROTECTED]> wrote: > We could start together a project which does this shell scripts, I think > it's not really a lot of work. Don't file a bug, first we can do a > "linuxnewbie" program and someone (maybe myself) will build a debian > package one day. Has anyone ever done anything similar before? What does policy say about the idea of modifying users' PATH statements? I vaguely remember reading an ITP or something for colorwrapper, a program which colorizes the output of ps, date, dmesg, etc. which I think requires changing the user's path. But I don't remember what ended up happening. What should the help message we display say? > For me there's only one point: > We have to make sure that advanced users DO NOT get this bothering > messages. How? :-) And will it matter, if it only affects commands like 'kde', 'gnome', 'move', 'ren', and 'delete' which currently just say "bash: command not found"? --Jason -- The church is near but the road is icy; the bar is far away but I will walk carefully. -- Russian Proverb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Source package contains non-free IETF RFC/I-D's
Simon Josefsson wrote: > Some raised a concern with false positives in my reports -- and also > tagged all the bugs with etch-ignore. I went through all bug reports > manually yesterday (see earlier mail), but I also realized that it > would be possible to do this automatically, to provide further > assurance that the bugs indicate real and confirmed problems. Note that it was not the only reason to tag them etch-ignore... > I've updated my script to do this, view it last on the page: > http://wiki.debian.org/NonFreeIETFDocuments > > The script will run md5sum on the RFC/I-D in source packages, and > compare them against a known-real repository (rsync'ed against > ftp.rfc-editor.org). > > The output of the script is very long, so I won't include it here. An > URL to it is: > http://josefsson.org/bcp78broken/debian-ietf-documents-diff.txt > > To parse the output yourself, look for lines beginning with 'pkg'. > Those denote the start of a new package with potential problems. > After that there will be lines such as 'tar xfz...' and two MD5 sums. > If the MD5 sums match, it will print MATCH. If the MD5 sums mismatch, > it will print MISMATCH. If it can't find a known-good file to compare > with, it prints FETCH-FAIL. > > Some statistics: > 74 packages > 401 MATCH, i.e., the RFC in the source package is an authentic RFC > 79 MISMATCH, i.e., the RFC differ from the authentic RFC >6 FETCH-FAIL Note that not all authentic RFC documents have the same license, some of them are probably even DFSG compliant... So there can be more than 79 false positives... Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: Missing days?
On Tue, Oct 17, 2006 at 02:34:11PM +, Sune Vuorela wrote: > Hi! > > I have started to wonder a bit about 'missing days' - a thing that is > especially importaint now when we are heading for a total freeze. > > >From http://packages.qa.debian.org/u/udev.html: > Too young, only 1 of 10 days old > [2006-10-15] Accepted 0.100-2.1 in unstable (low) I got: Date: Sun, 15 Oct 2006 10:02:15 -0700 Which is before the dinstall run on the 15th. A few hours later dinstall runs. Yet a few hour later britney runs and sees it for the first time. At that point, it's 0 days old. Than 24 hours later, britney runs again, and it's 1 day old. In about 10 hours, britney will run again, and it will become 2 days old. > But here: > http://packages.qa.debian.org/k/kwin-style-crystal.html > Too young, only 1 of 10 days old > [2006-10-13] Accepted 1.0.2-1 in unstable (low) Date: Fri, 13 Oct 2006 14:48:15 -0700 Which is a few hours after the dinstall run on the 13th. A few hours later when britney runs, it doesn't see it yet. Britney only sees it more than 24h after it was uploaded. So it's 2 days old now. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#393739: ITP: myghtyutils -- Set of utility classes used by Myghty templating
Package: wnpp Severity: wishlist Owner: Oleksandr Moskalenko <[EMAIL PROTECTED]> * Package name: myghtyutils Version : 0.52 Upstream Author : Michael Bayer <[EMAIL PROTECTED]> * URL : http://cheeseshop.python.org/pypi/MyghtyUtils/ * License : MIT Programming Lang: Python Description : Set of utility classes used by Myghty templating Utility classes used by Myghty templating: container - the Containment system providing back-end neutral key/value storage, with support for in-memory, DBM files, flat files, and memcached. buffer - some functions for augmenting file objects . util - various utility functions and objects. synchronizer - provides many reader/single writer synchronization using either thread mutexes or lockfiles. session - provides a Session interface built upon the Container, similar interface to mod_python session. Currently needs a mod_python-like request object, this should be changed to something more generic. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (950, 'unstable'), (500, 'testing'), (10, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-mrb319 Locale: LANG=uk_UA.KOI8-U, LC_CTYPE=uk_UA.KOI8-U (charmap=KOI8-U) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#393756: ITP: beaker -- Simple WSGI middleware that uses the Myghty Container API
Package: wnpp Severity: wishlist Owner: Oleksandr Moskalenko <[EMAIL PROTECTED]> * Package name: beaker Version : 0.6.1 Upstream Author : Julian Krause and Ben Bangart - <[EMAIL PROTECTED]> * URL : http://cheeseshop.python.org/pypi/Beaker/ * License : MIT Programming Lang: Python Description : Simple WSGI middleware that uses the Myghty Container API Simple WSGI middleware that uses the Myghty Container API MyghtyUtils contains a very robust Container API for storing data using various backends. Beaker uses those APIs to implement common web application wrappers, like sessions and caching, in WSGI middleware. Currently the only middleware implemented is that for sessions but more is coming soon. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (950, 'unstable'), (500, 'testing'), (10, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-mrb319 Locale: LANG=uk_UA.KOI8-U, LC_CTYPE=uk_UA.KOI8-U (charmap=KOI8-U) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sometimes-dependency, linux-image-2.6.18-1-486
Hamish Moffatt <[EMAIL PROTECTED]> writes: > On Tue, Oct 17, 2006 at 09:35:49AM +0200, Goswin von Brederlow wrote: >> Hamish Moffatt <[EMAIL PROTECTED]> writes: >> > On Mon, Oct 16, 2006 at 04:08:17PM -0500, Clarence Risher wrote: >> >> And that leads me to the general question, on the topic of >> >> sometimes-dependencies. Does debian have any facility to handle such? >> >> linux-image-2.6.18-1-486 doesnt technically depend on yaird, since it >> >> can use any mkinitrd script (of which there are many, provided by other >> >> packages), but when it does pick mkinitrd.yaird then it requires an up >> >> to date version of yaird. >> > >> > Conflicts. The package doesn't depend on yaird, but it does (should) >> > conflict with insufficient versions. >> >> You can also use >> Depends: yarid (>= 1.2-3) | initramfs-tools | initrd-toos | foo | bar >> >> Any one of them will do but if yarid is used then the version must be >> new enough. > > Isn't there the possibility here that you have both yaird (< 1.2-3) and > another suitable package installed? The deps would be met, but > linux-image-* might choose yaird and build a non-working initramfs. > (The initramfs generators don't conflict with each other.) > > Hamish Then you do actually need Depends: yarid | initramfs-tools | initrd-toos | foo | bar Conflicts: yarid (<= 1.2-3) What happens if you have multiple initrd/initramfs generators installed? Do you get multiple images? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How can the OS autodetect that a user is a newbie and offer help?
Hi, let me respond to the subject. I don't know about the rest of the mail, sorry. Anyway, the usual way to detect a newbie and give help to them seems to be to assume everyone a newbie and give little hints, startup tips, ... till they learn enough to turn them off. For examples see gimp or mc. MfG Goswin PS: One of the hints better be how to turn the hints off. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#393757: ITP: webhelpers -- Library of helper functions to make writing web application templates easier
Package: wnpp Severity: wishlist Owner: Oleksandr Moskalenko <[EMAIL PROTECTED]> * Package name: webhelpers Version : 0.2.1 Upstream Author : Ben Bangert <[EMAIL PROTECTED]> and James Gardner <[EMAIL PROTECTED]> * URL : http://cheeseshop.python.org/pypi/WebHelpers/ * License : BSD Programming Lang: Python Description : Library of helper functions to make writing web application templates easier One of the sub-sections of Web Helpers contains a full port of the template helpers that are provided by Ruby on Rails with slight adaptations on occasion to accommodate for Python. Some of these helpers only require Routes to function. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (950, 'unstable'), (500, 'testing'), (10, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-mrb319 Locale: LANG=uk_UA.KOI8-U, LC_CTYPE=uk_UA.KOI8-U (charmap=KOI8-U) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How can the OS autodetect that a user is a newbie and offer help?
On 2006-10-17, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: [snip] > > Anyway, the usual way to detect a newbie and give help to them seems > to be to assume everyone a newbie and give little hints, startup tips, > ... till they learn enough to turn them off. For examples see gimp or > mc. > > PS: One of the hints better be how to turn the hints off. :) Someone suggested to me off-list that perhaps all we need is to provide a pointer to more newbie help in /etc/issue. Perhaps that would be the easiest to implement, and the easiest for users to disable :-), no? The disadvantage would be that users who have X Window plus KDM already set up, or who SSH into a friend's machine, who need help with linux commands in an xterm wouldn't see the message, but I assume that is a rare case so just editing /etc/issue and /etc/issue.net is fine. Agree? If the issue file were changed, what could go in it? I suggest: * one link to a special webpage which points total newbies to newbie documentation and also gives newbie-level instructions on how to get technical support * also, instructions how to view one offline-viewable Linux *tutorial* which is already installed - preferably a good one, but even the bad old intro(1) manpage if there is no good one. Also, perhaps it'd be possible for the bash "help" command to display those same two things in addition to the terse reference it already displays. What do you think? -- The church is near but the road is icy; the bar is far away but I will walk carefully. -- Russian Proverb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[no subject]
retitle 376431 RFP: openwatcom -- C/C++ compiler/IDE that make efficient, portable code submitter 376431 [EMAIL PROTECTED] severity 376431 wishlist thanks It looks unlikely I will manage to package this. It's too big a package to deal with as my first package ever. Open Watcom is complex; it does not use autoconf; and nobody has ever packaged the Linux port of Open Watcom before. Main issues include: - Open Watcom 1.5 does not seem to build on Linux. 1.4 and the dailies seem to build fine though. - the license (though they don't have to make that many changes to it - see thread on debian-legal) - paths and $WATCOM (Open Watcom expects the $WATCOM variable to be set, which conflicts with policy) - where will the data files go? surely not in /usr/local/watcom, right? - there has been some argument in the past in news://news.openwatcom.org/openwatcom.contributors about how the paths should be arranged. - there'd be a lot of manpages to write. and forget the idea of using help2man, openwatcom help is not in the proper format I think the first thing for whoever wants to package this to do would be to work with the upstream committers to deal with 2 things: the license (my advice: try to get it in non-free first, GPL idea can wait till later) and the path issue. In my opinion, the paths issue should be dealt with later on, in private and not on a public mailing list, so as to avoid starting a flamewar. If someone else decides to try take a stab at it, I'd love to hear your progress and I might be interested in co-maintaining. Also, if someone wants my .diff.gz with a debian/rules, a debian/control, and which modifies wcc, wcc386, and part of wlink to look in other paths, email me. The changes the .diff.gz makes aren't that well-written though. Cheers, Jason change ITP to RFP
Re: sometimes-dependency, linux-image-2.6.18-1-486
On Tue, Oct 17, 2006 at 08:44:16PM +0200, Goswin von Brederlow wrote: > What happens if you have multiple initrd/initramfs generators > installed? Do you get multiple images? No, kernel-package has logic to pick one of them and go with that. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
iptables extensions removed from package
Hello, In the most recent version of iptables, IPMARK and several other extensions were removed [1]. I disagree with this change, and contacted the maintainer about it by filing a bug report [2]. The maintainer declined to put the extensions back into the package, but provided no reason why, other than "I do not have to include any patch-o-matic extensions". A historical version of the README.Debian file included with iptables [3] (it's no longer included in current versions) states that as many extensions as possible will be included in the package. I think this is a great idea. A recent dicussion on the netfilter-devel mailing list [4] discussed the fact that the patch-o-matic system is undergoing/has undergone a change in structure, whereas the actual patches are hosted on third-party sites rather than on netfilter.org. I don't see why this would cause the extensions to be removed from the Debian package. Am I missing something here? Extensions such as IPMARK are stable and used by many in the community. I don't understand why they have been removed from Debian. I would like to see them put back into the mainstream so I don't have to maintain my own separate package. What do you think? Thanks. 1. http://packages.debian.org/changelogs/pool/main/i/iptables/iptables_1.3.5.0debian1-1/changelog 2. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=392998 3. http://www.fifi.org/doc/iptables/README.Debian 4. http://patchwork.netfilter.org/netfilter-devel/patch.pl?id=3456 -- Aaron Dummer [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How can the OS autodetect that a user is a newbie and offer help?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/17/06 08:02, Jason Spiro wrote: > Hi all, > > I believe that since command-line Linux is hard to learn, Debian should > offer handholding. (This would benefit both Debian users who are new to > the command line and How can the OS autodetect that a user is a newbie > and offer help? > [snip] > > What would be a good help text to offer when a user types a command that > indicates he/she is a newbie? Also, what package should I file a > wishlist against to request that such help be added? $ wajig search newbie | sort bookmarks - Debian bookmark collection fdclone - A console-base lightweight file manager linuxfacile - An Italian manual for newbies newbiedoc - Documentation by and for newbies selflinux - A collection of German documents about Linux uim - Simple and flexible input method collection and library - -- Ron Johnson, Jr. Jefferson LA USA Is "common sense" really valid? For example, it is "common sense" to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that "common sense" is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFNVABS9HxQb37XmcRAqeGAKClHXPBKS7IPWC5p/KQ2lPR8aOwwgCgpwBq H3jG6Q1NiKdZvrjQeQyYCto= =SEPk -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How can the OS autodetect that a user is a newbie and offer help?
On Wednesday 18 October 2006 05:41, you wrote: > On 2006-10-17, Goswin von Brederlow > <[EMAIL PROTECTED]> wrote: > [snip] > > > Anyway, the usual way to detect a newbie and give help to them seems > > to be to assume everyone a newbie and give little hints, startup tips, > > ... till they learn enough to turn them off. For examples see gimp or > > mc. > > > > PS: One of the hints better be how to turn the hints off. :) > > Someone suggested to me off-list that perhaps all we need is to provide > a pointer to more newbie help in /etc/issue. Perhaps that would be the > easiest to implement, and the easiest for users to disable :-), no? As already suggested, desktop environments could/should have a help/tips display that's turned on by default for new users. What's really needed is better help for newbies dumped unexpectedly at the command-line because X wasn't installed/properly configured/didn't start. I'd suggest only 1-2 lines of login help in /etc/issue, and command-line help (equal to 1-2 lines of text saying type xxx for help) in /etc/motd. xxx might display a help file/command line guide, or start a basic tutorial, or a special newbie shell environment. At its simplest it could just show a 80x24 page of help text containing basic commands and pointers to more help. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#393411: Source package contains non-free IETF RFC/I-D's
On Tue, Oct 17, 2006 at 03:49:54PM +0200, Simon Josefsson wrote: > > Note what packages fixed the problem in unstable, file an RC bug for > > the testing version and close it for the unstable version. That then > > reflects the reality and will keep track of the problem. > Hm, I know how to submit a bug for the version in testing (this is > what I've done), but I don't know how to close it for the unstable > version. How do I do that? Use a Version: pseudo-header in your mail to [EMAIL PROTECTED] -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Source package contains non-free IETF RFC/I-D's
On 17 okt 2006, at 18.47, Luk Claes wrote: Some statistics: 74 packages 401 MATCH, i.e., the RFC in the source package is an authentic RFC 79 MISMATCH, i.e., the RFC differ from the authentic RFC 6 FETCH-FAIL Note that not all authentic RFC documents have the same license, some of them are probably even DFSG compliant... Can you name one such license that is DFSG-free? RFC's published before 1989 may be in the public domain, since they don't contain a copyright notice, but the RFC editor claim that the new copying conditions apply retroactively. RFC's published after 1989 are protected by copyrights, but as far as I know, none of the RFC licenses are free. The RFC 2026 and the RFC 3978 licenses has been discussed before. That leaves, I believe, only the license specified by RFC 1602, which reads: "Copyright (c) ISOC (year date). Permission is granted to reproduce, distribute, transmit and otherwise communicate to the public any material subject to copyright by ISOC, provided that credit is given to the source. For information concerning required That appears to be non-free. I note that RFC 1602 do seem to give the ISOC the right to release those RFCs under a liberal license: l. Contributor agrees to grant, and does grant to ISOC, a perpetual, non-exclusive, royalty-free, world-wide right and license under any copyrights in the contribution to reproduce, distribute, perform or display publicly and prepare derivative works that are based on or incorporate all or part of the contribution, and to reproduce, distribute and perform or display publicly any such derivative works, in any form and in all languages, and to authorize others to do so. Perhaps talking to ISOC about this would help. So there can be more than 79 false positives... I don't yet see any way for that to hold. /Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: malsync ready for adoption
Le 16.10.2006, à 11:48:41, Daniel Schepler a écrit: > On Sunday 15 October 2006 21:48 pm, Ludovic Rousseau wrote: > > If you are interested you should also adopt libmal. It causes a problem > > on kpilot and I offered the package to the kpilot maintainer without an > > answer from him. See #389353. > > > > If no one adopt it I will request the removal of malsync from unstable. > > Sorry, I missed that message. I'm not interested in maintaining libmal; it's > just an optional add-on to kpilot. If libmal were removed from unstable, I > would most likely just recompile kdepim with the libmal-dev build-dep cut > out. OK. What is preferred for a buggy and unmaintained (upstream) package - removal or - orphaning I can orphan libmal but that will not solve #389353 and the QA will not be able to debug it without access to a PDA and an account on http://www.avantgo.com/ The upsteam maintainer can't test it either so I do not see a fast resolution here. > By the way, where did you get the idea that the submitter of #389353 and the > kpilot maintainer were the same person? I'm not "Peter Robin". :) Oops, sorry. Bye, -- Dr. Ludovic Rousseau[EMAIL PROTECTED] -- Normaliser Unix c'est comme pasteuriser le camembert, L.R. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Source package contains non-free IETF RFC/I-D's
On Tue, Oct 17, 2006 at 11:46:11PM +0200, Simon Josefsson wrote: > >>Some statistics: > >> 74 packages > >> 401 MATCH, i.e., the RFC in the source package is an authentic RFC > >> 79 MISMATCH, i.e., the RFC differ from the authentic RFC > >> 6 FETCH-FAIL > >Note that not all authentic RFC documents have the same license, > >some of them > >are probably even DFSG compliant... > Can you name one such license that is DFSG-free? > RFC's published before 1989 may be in the public domain, since they > don't contain a copyright notice, but the RFC editor claim that the > new copying conditions apply retroactively. I don't see any reason we should honor retroactive claims of copyright. If the RFCs were genuinely placed in the public domain, then this can't be revoked; true "public domain" means that there is no longer a copyright which applies to the work, and therefore no license is needed. If the RFCs were /not/ placed in the public domain, the question then is, who holds the copyright on them? Only if the IETF is the copyright holder should we need to honor their attempts to relicense. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: delay of the full etch freeze
On Thu, Oct 12, 2006 at 10:38:26PM -0700, Thomas Bushnell BSG wrote: > > On Thu, Oct 12, 2006 at 10:22:43PM +0200, Petter Reinholdtsen wrote: > >> [Charles Plessy] > >> > The rationale is that the 8th is "old freeze deadline minus 10 > >> > days", so it was not completely unreasonnable to take this day as > >> > the deadline for having new packages in Etch. > >> I find this completely unreasonable. If someone waited that late in > >> the release process before uploading a package they knew would have to > >> go through NEW, they can not expect the package to make it into Etch. > >> New packages should have had at least a few weeks in unstable to allow > >> problems to be detected before heading for testing. > >> So I would recommend against moving the freeze deadline to allow > >> packages in NEW to enter. > > Yes, this is my official position on the question (dunno about Andi's, I'm > > replying to email off-line at the moment and haven't checked with him, but I > > would guess his position is similar). > > The only packages in NEW that I'm inclined to worry about are those that fix > > release-critical bugs. > Was there a reason this was not said when I asked: > http://lists.debian.org/debian-release/2006/09/msg00315.html That it wasn't release-critical, so was lost under 200 other mails that were. ;) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How can the OS autodetect that a user is a newbie and offer help?
On Tue, Oct 17, 2006 at 01:02:45PM +, Jason Spiro wrote:
> Hi all,
Hi there.
> For example, when a person types newbie commands like "help" or "kde"
> (which is bound to something already) or the DOS commands "del" or "ren"
> (which are not), we should point them to more help. (In case anyone here
> has ever watched a real clueless newbie struggle: What are other
> commands that 100% clueless newbies often type?)
I think 'help' is by far the most common one ('?' might be close too).
Currently 'help' brings bash's help which might not be what a newbie
expected. Some (older?) people might even try pressing F1 and see what
happens [0].
I remember back in 2000 providing a Debian package called 'ayuda' ('help', in
Spanish) developed by members of my local IEEE Student Branch. This package
included just a simple shell script ('ayuda') and a number of text files.
When the script was called it would show up a dialog(1) menu a user could
navigate and use to access the manuals included. Manuals were ordered in
'user', 'admin' and 'programming' topics. The 'user' topic would tell him how
to use shell commands, read e-mail, use a text editor (Joe, Vi or Emacs), and
configure his environment.
It would also tell the users how to use the system's proper documentation
(manpages and info) and it would also point to more documentation (HOWTOs and
locally installed documentation).
The tool was abandoned and, after trying to get some community development, I
removed it from Debian.
I guess it would be nice to have something similar. You cannot replace 'help'
(if using Bash, Bash will answer) but a package could provide a 'helpme'
command [1][2] which did something similar.
Right now such a help program should work both in a console and in an X
display (if it detects one) should point users also to the documentation
available in Desktop environments (if available), to (Debian-specific)
documentation packages (like 'doc-debian' or the 'quick-reference') and to
(Debian-specific) use of dwww/dhelp/doc-central.
> What would be a good help text to offer when a user types a command that
> indicates he/she is a newbie? Also, what package should I file a
> wishlist against to request that such help be added?
Since there is no package providing that tool I would say 'general'. However,
filing bugs vs. general doesn't mean they will get fixed by themselves. I
think that it would be much better if somebody sat down and wrote a "Debian
help" system that provided some Debian-specific things and integrated
properly with both gnome-help and khelpcenter.
Regards
Javier
[0] Many MS-DOS programs (such as Wordperfect, Lotus 1-2-3 and the like)
mapped F1 was always mapped to the 'help' key. This is still true in many
(desktop) environments and applications.
[1] At the very least:
$ cat helpme
#!/bin/sh
echo "Don't panic!"
[2] Bonus points if someone figures a way to l10n that 'help' call, since
non-english spearkers might write something different such as: 'ayuda',
'hilfe', 'aide', 'aiuto', 'ajuda', etc.
signature.asc
Description: Digital signature
Re: How can the OS autodetect that a user is a newbie and offer help?
On Wed, Oct 18, 2006 at 08:36:42AM +1000, Andrew Vaughan wrote: > What's really needed is better help for newbies dumped unexpectedly at the > command-line because X wasn't installed/properly configured/didn't start. What's really needed is to fix our X autoconfiguration mechanisms so that this doesn't happen. One of my target goals is to work on this post-etch, and happily upstream is working hard on it as well. If people want to help with this issue, please follow up to debian-x. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How can the OS autodetect that a user is a newbie and offer help?
On Tue, Oct 17, 2006 at 07:56:00PM -0400, David Nusinow wrote: > On Wed, Oct 18, 2006 at 08:36:42AM +1000, Andrew Vaughan wrote: > > What's really needed is better help for newbies dumped unexpectedly at the > > command-line because X wasn't installed/properly configured/didn't start. > > What's really needed is to fix our X autoconfiguration mechanisms so that > this doesn't happen. One of my target goals is to work on this post-etch, > and happily upstream is working hard on it as well. If people want to help > with this issue, please follow up to debian-x. > IIRC, the majority of the "I ended up at a text prompt, what do I do now?" questions we see on d-u are not X configuration problems. They are newbies who pick all the defaults and up without X on their systems entirely. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: How can the OS autodetect that a user is a newbie and offer help?
On Tue, Oct 17, 2006 at 08:27:46PM -0400, Roberto C. Sanchez wrote: > On Tue, Oct 17, 2006 at 07:56:00PM -0400, David Nusinow wrote: > > On Wed, Oct 18, 2006 at 08:36:42AM +1000, Andrew Vaughan wrote: > > > What's really needed is better help for newbies dumped unexpectedly at > > > the > > > command-line because X wasn't installed/properly configured/didn't start. > > > > What's really needed is to fix our X autoconfiguration mechanisms so that > > this doesn't happen. One of my target goals is to work on this post-etch, > > and happily upstream is working hard on it as well. If people want to help > > with this issue, please follow up to debian-x. > > > > IIRC, the majority of the "I ended up at a text prompt, what do I do > now?" questions we see on d-u are not X configuration problems. They > are newbies who pick all the defaults and up without X on their systems > entirely. This should be fixed for etch, afaik. If you just choose the defaults, you'll end up with a gnome desktop installation and X up and running by default. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Looking for Debian Packaging expert
Hi all, I work for ACCESS, Inc. here in Sunnyvale, California. We are looking for someone who is adept in Debian Packaging. This person would deliver 3 or 4 hourly sessions to our employees just to educate them on benefits of using Debian Packaging and answer any questions that our employees (internal developers) might have. It would not be training sessions but it would be semi technical talks on how to use and deploy Debian packages mechanism and discussing the advantages of using Debian packages for distribution of software internally. Regards, -mahmood
Re: How can the OS autodetect that a user is a newbie and offer help?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/17/06 19:35, David Nusinow wrote: > On Tue, Oct 17, 2006 at 08:27:46PM -0400, Roberto C. Sanchez wrote: >> On Tue, Oct 17, 2006 at 07:56:00PM -0400, David Nusinow wrote: >>> On Wed, Oct 18, 2006 at 08:36:42AM +1000, Andrew Vaughan wrote: [snip] > This should be fixed for etch, afaik. If you just choose the defaults, > you'll end up with a gnome desktop installation and X up and running by > default. A deep well of curmudgeonly geekiness is welling up within me, about to burst forth with an overwhelming NOOO!!! We who used MS-DOS in 1985 were not appreciably smarter than people are now, yet we figured out DIR & COPY & DEL & CD. A HELP command and a set of DOS-friendly aliases (and/or scripts) would/should be adequate. After all, this isn't OpenVMS... - -- Ron Johnson, Jr. Jefferson LA USA Is "common sense" really valid? For example, it is "common sense" to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that "common sense" is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFNYrsS9HxQb37XmcRAoFbAJ9Sopnn7Vaz8IHcgCvY5sLgxJ/wiACdG6NB Fv/zkJDryyt5gsfx+nVCIjM= =fmu8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How can the OS autodetect that a user is a newbie and offer help?
On Tue, 17 Oct 2006 20:02:45 +0700, Jason Spiro <[EMAIL PROTECTED]> wrote: For example, when a person types newbie commands like "help" or "kde" (which is bound to something already) or the DOS commands "del" or "ren" (which are not), we should point them to more help. (In case anyone here has ever watched a real clueless newbie struggle: What are other commands that 100% clueless newbies often type?) Seems to me that the times of DOS have passed. Back in those times, users would be familiar with the command line of one OS and be frustrated with another's. Today's typical user is rather familiar with a GUI and will be frustrated by a different GUI. For example, Windows users are likely to have a hard time looking for the "Start" button in Gnome. In a desktop environment, the user needs to do a special action to run the shell (such as starting the Gnome Terminal). It's somewhat unlikely that the user ends up in the "scary black screen" by accident, and even then he can easily find the familiar close button in the title bar of the window. My point is that today's user only gets a shell when he wants a shell, and users who don't know how to use the shell won't want it. To really help newbies migrate from other OS, it's better to improve the desktop GUIs and make them provide more hints etc. Adding newbie assistance to the shell wouldn't help many users, for the reasons described above. On the other hand, it will annoy advanced users for sure because any "newbie detection" would be an heuristic which inevitably fails from time to time. Even if the hints need only to be disabled once, it will be annoying to do so every time when maintaining a cluster of Debian machines. So, my opinion is: please don't include things like this in default Debian installations. -- Alexey Feldgendler <[EMAIL PROTECTED]> [ICQ: 115226275] http://feldgendler.livejournal.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How can the OS autodetect that a user is a newbie and offer help?
[I have snipped everything except the words I am replying to.]
2006/10/17, Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> wrote:
I think 'help' is by far the most common one ('?' might be close too).
Currently 'help' brings bash's help which might not be what a newbie
expected. Some (older?) people might even try pressing F1 and see what
happens [0].
In xterm my F1 key causes a beep. Perhaps there's a way to remap the
F1 key in bash and/or readline?
I remember back in 2000 providing a Debian package called 'ayuda' ('help', in
Spanish) developed by members of my local IEEE Student Branch. This package
included just a simple shell script ('ayuda') and a number of text files.
When the script was called it would show up a dialog(1) menu a user could
navigate and use to access the manuals included. ...
I guess it would be nice to have something similar.
Interesting idea. But, since a) most people have web access nowadays
and b) people with no web access in a new Linux install can reboot
into Windows if they need web access, therefore I personally wouldn't
want to maintain such a package. Of course, you could get such a
script into Debian yourself (maybe in package debian-goodies or
elsewhere) if you wanted.
> What would be a good help text to offer when a user types a command that
> indicates he/she is a newbie? Also, what package should I file a
> wishlist against to request that such help be added?
Since there is no package providing that tool I would say 'general'. However,
filing bugs vs. general doesn't mean they will get fixed by themselves. I
think that it would be much better if somebody sat down and wrote a "Debian
help" system that provided some Debian-specific things and integrated
properly with both gnome-help and khelpcenter.
Is more Debian-specific help really needed for KDE/Gnome users? IIRC
Synaptic comes with Gnome help files. Also, there are already lots of
HTML-format manuals for Debian.
[2] Bonus points if someone figures a way to l10n that 'help' call, since
non-english spearkers might write something different such as: 'ayuda',
'hilfe', 'aide', 'aiuto', 'ajuda', etc.
I really like that idea.
Cheers,
Jason
--
Jason Spiro: computer consulting with a smile.
I also provide training and spyware removal services for homes and businesses.
Call or email for a FREE 5-minute consultation. Satisfaction guaranteed.
416-781-5938 / Email: [EMAIL PROTECTED] / MSN: [EMAIL PROTECTED]
Bug#393849: ITP: pcopy -- multithreaded (raw) disk copying program
Package: wnpp Severity: wishlist Owner: Anibal Monsalve Salazar <[EMAIL PROTECTED]> * Package name: pcopy Version : 1.5 Upstream Author : Peter Eriksson <[EMAIL PROTECTED]> * URL : http://directory.fsf.org/sysadmin/Backup/pcopy.html * License : GNU General Public License Programming Lang: C Description : multithreaded (raw) disk copying program Tool for large disk to disk copying. pcopy is intended to be used when doing large disk (partition) to disk (partition) copying where dd is just too slow (and error prone). It also displays a progress counter while doing the copying. Aníbal Monsalve Salazar -- http://v7w.com/anibal signature.asc Description: Digital signature
Re: Looking for Debian Packaging expert
On Tue, 17 Oct 2006, Mahmood Sheikh wrote: I work for ACCESS, Inc. here in Sunnyvale, California. We are looking for someone who is adept in Debian Packaging. This person would deliver 3 or 4 hourly sessions to our employees just to educate them on benefits of using Debian Packaging and answer any questions that our employees (internal developers) might have. It would not be training sessions but it would be semi technical talks on how to use and deploy Debian packages mechanism and discussing the advantages of using Debian packages for distribution of software internally. I recently have done something like you are looking for in Max-Planck-Institut für Kognitions- und Neurowissenschaften in Leipzig (Germany) and the material is online at http://people.debian.org/~tille/talks/200609_mpi/index_de.html But it is only in German (if you follow the link to the English translation on this page you will just learn that there is only a German version). But perhaps this material might be helpful as a basis for somebody who wants to do such a workshop at your place. This person should probably start inspecting http://people.debian.org/~tille/packages/mpi-schulung/ which contains the complete sources of the slides (in LaTeX beamer) and a packaging example. Kind regards Andreas. -- http://fam-tille.de
Re: How can the OS autodetect that a user is a newbie and offer help?
On Tue, Oct 17, 2006 at 11:48:33PM -0400, Jason Spiro wrote:
> >I remember back in 2000 providing a Debian package called 'ayuda' ('help',
> >in
> >Spanish) developed by members of my local IEEE Student Branch. This
> >package
> >included just a simple shell script ('ayuda') and a number of text files.
> >When the script was called it would show up a dialog(1) menu a user could
> >navigate and use to access the manuals included. ...
> >I guess it would be nice to have something similar.
>
> Interesting idea. But, since a) most people have web access nowadays
> and b) people with no web access in a new Linux install can reboot
> into Windows if they need web access, therefore I personally wouldn't
> want to maintain such a package. Of course, you could get such a
> script into Debian yourself (maybe in package debian-goodies or
> elsewhere) if you wanted.
If you do a Debian install and, for some reason, don't get X configured you
don't want to tell people "reboot into Windows and look for help". I, for
example, don't have a Windows partition available. As for the script, I
already provided it in Debian (5 years ago) but it was
a) Spanish-specific
b) not supported by a community
All that I'm saying is that it would be great to start a Debian community
project that was not language-specific and supported and get *that* into
Debian.
> >Since there is no package providing that tool I would say 'general'.
> >However,
> >filing bugs vs. general doesn't mean they will get fixed by themselves. I
> >think that it would be much better if somebody sat down and wrote a "Debian
> >help" system that provided some Debian-specific things and integrated
> >properly with both gnome-help and khelpcenter.
>
> Is more Debian-specific help really needed for KDE/Gnome users? IIRC
> Synaptic comes with Gnome help files. Also, there are already lots of
> HTML-format manuals for Debian.
What I'm saying is that users using GNOME's help system or KDE's help system
cannot find a single bit of advice specific to Debian since *our* help system
(dwww/dhelp/doc-central) does not mesh in with theirs. So if a user (in
GNOME) goes to the task bar and selects 'Desktop->Help' he can, at most,
access the local manpages but there is no 'Debian' section there.
Try running 'yelp', look at the topics and try searching for 'Debian'. You'll
see what I mean. This is not GNOME-specific, BTW, IIRC the same happens with
KDE help center. I'm just saying that a Debian-specific help should be added
to both systems (and should provide the same contents).
Regards
Javier
signature.asc
Description: Digital signature
Re: How can the OS autodetect that a user is a newbie and offer help?
Alexey Feldgendler wrote: > In a desktop environment, the user needs to do a special action to run > the shell (such as starting the Gnome Terminal). It's somewhat unlikely > that the user ends up in the "scary black screen" by accident, and even > then he can easily find the familiar close button in the title bar of > the window. My point is that today's user only gets a shell when he > wants a shell, and users who don't know how to use the shell won't want it. If something happens to X then a user can end up in the terminal. Even a faulty application can trash X. Maybe all what is needed is a small script and a warning. Suppose we write a script called "desktop" or "start-desktop" that can start X, Gnome, KDE or whatever is installed on the system - with safe values for e.g. the X config. Sort of like Windows' rescue mode. Then have a message appear when the terminal starts (not the virtual terminals that you can start from your desktop, but the terminal you get when X is dead) that reads something like: "If your desktop accidentally died, type "start-desktop" and hit the return key or type "reboot" to restart your computer." If it can be made so that this message only appears when X is installed but not running on the system, then even better. -- Sander Marechal http://www.gnome-hearts.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
