Re: Etch Software RAID Upgrade Trouble Suggested Installer Improvements
On Sat, 06 Jan 2007 08:35:59 +0100, Claus Fischer [EMAIL PROTECTED] wrote: 7. There needs to be a command to copy all data Between cp, tar, rsync friends there are dozens of variations how to copy over the files of a running system to another location, but none is perfect: - leave out lost+found - leave out /proc, /sys, the automatic /dev - copy all real files - copy the /dev on harddisk under the mounted devfs (using mount -bind or so) There is really need for a good program that does it; IMHO that program should be cp. Here's how I do it: mkdir 1 2 mount -o ro /dev/hda1 1 # Despite it's already mounted somewhere mount /dev/hdb1 2 cp -avx --preserve=all 1/* 2 # rsync will do as well umount 2 umount 1 -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: db.debian.org (and related infrastructure) updates
On Sun, 31 Dec 2006 13:16:24 +0100, Amaya [EMAIL PROTECTED] wrote: Currently it is a drop down that allows you to choose: - unspecified - male - female Which in my opinion reflects sex and not gender. I would rather have it as an input field where people can express their gender in the way they want to, as gender has little to do with biological sex, and there's more than two options for it. What other kinds of gender are there? It would be interesting to see some examples. -- 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?
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: apt-findremovable v0.1 (initial release)
On Wed, 04 Oct 2006 18:07:02 +0700, Raphael Hertzog [EMAIL PROTECTED] wrote: Some of us are partial to apt-get and would appreciate apt-findremovable. I would rather appreciate that apt-get and aptitude share the information of which packages have been explicitely installed and which have been automatically installed. Why not just stop using apt-get? aptitude can do everything the same as apt-get and even supports the same command line parameters. -- 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: apt-findremovable v0.1 (initial release)
On Tue, 03 Oct 2006 21:54:09 +0700, Jan Kechel [EMAIL PROTECTED] wrote: deborphan looks simmilar to what you describe. yeah, similar, also it finds only the leaves, while apt-findremovable checks which depends have no other rdepends than the specified one Seems like debfoster does what you need. However, it's considered obsolete now that aptitude takes care of unused packages. -- 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: Time to rethink ifupdown
On Thu, 24 Aug 2006 13:27:26 +0700, Sylvain Le Gall [EMAIL PROTECTED] wrote: What about creating a DBUS interface - it can be integrated in any language that support it, and can be integrated in a GUI application. Introducing dependencies on DBUS into a package essential to system operation doesn't sound like a very good idea to me. -- 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: Time to rethink ifupdown
On Sun, 20 Aug 2006 16:03:49 +0700, Jon Dowland [EMAIL PROTECTED] wrote: I've been wondering for a while if it might not be possible to develop a more up-to-date ifup/down that would a) maintain suitability for non-graphical environments and b) have enough functionality, cross-distro, to be useful as a back-end for NM, as I'm pretty uncomfortable with having all the logic in the same tool as the whizzy interface. What's missing from the current ifupdown which stops it from being useful as a backend for NM? However, ifupdown is Priority: important and Section: base, meaning that it shall be frozen [2] and that redevelopment will have to target etch+1. Of course, redesign of ifupdown is too big a thing to be pushed into etch. I wasn't even thinking of that. -- 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: Time to rethink ifupdown
On Sun, 20 Aug 2006 16:11:16 +0700, David Goodenough [EMAIL PROTECTED] wrote: Obviously if you are configuring a server you do not want others than the administrator setting up the network, but if you are the sole user of a laptop there needs to be a safe way for the user (non-technical) to do this as the user moves from one location to another. One option that has occurred to me is to establish a group which is allowed to edit /etc/network/interfaces. The obvious problem with this is the up and down commands, which allow any program to be run as root. Fortunately there is an answer, which is to use the macro facility that ifupdown has (the one used for wireless-xxx) and then it gets controllable and therefore safe (if used properly). This would need either to abandon up and down all together or to have a switch (presumable in /etc/defaults/ifupdown) which enabled the use of this group and disabled the use of up and down. When a laptop user moves between usual locations, there should be no need to edit /etc/network/interfaces. If you mean adding new locations, there really should be user-friendly tools which do it. -- 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: Time to rethink ifupdown
On Sun, 20 Aug 2006 16:20:26 +0700, martin f krafft [EMAIL PROTECTED] wrote: Please take a look at http://wiki.debian.org/netconf . It would be great if you could help flesh out that page with your excellent arguments and thoughts. Also, if you are interested in working on netconf (which currently noone is), I'd be happy to dedicate some time to it. I would add my thoughts there but currently I know nothing about netconf beyond what's written on that page now. What is the scope of netconf? Is it supposed to supersede ifupdown, supplement it, or be an alternative? Is anything already implemented, or is it only an idea for now? Is there a reason to start developing a new tool instead of enhancing ifupdown? Can I forward your post to the netconf mailing list? Yes, you're welcome. I've just subscribed to that list, BTW. -- 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: Time to rethink ifupdown
On Wed, 23 Aug 2006 22:17:23 +0700, martin f krafft [EMAIL PROTECTED] wrote: I would add my thoughts there but currently I know nothing about netconf beyond what's written on that page now. What is the scope of netconf? Is it supposed to supersede ifupdown, supplement it, or be an alternative? Is anything already implemented, or is it only an idea for now? It's an idea with the final goal to provide most of what ifupdown+guessnet+resolvconf do now, I would personally add ifrename to this list. with better integration with wireless-tools/wpasupplicant and ifplugd, ...but, actually, I think that everything should be integrated by adding files to .d-style directories like resolvconf is integrated into ifupdown, rather than built in like basic configuration of IPv4 interfaces is built into ifupdown. and a proper interface for user interfaces. What do you mean under this? Is there a reason to start developing a new tool instead of enhancing ifupdown? Is there a reason to cling to ifupdown? I guess that there is: there is a substantial amount of code written and tested, and ifupdown is widely accepted. OTOH, Debian never was a conservative distro, so all kind of things can be changed. Yes, you're welcome. I've just subscribed to that list, BTW. Mh, I don't have it anymore, of course. If you still do, please bounce it. Done. -- 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: Time to rethink ifupdown
On Wed, 23 Aug 2006 22:45:52 +0700, martin f krafft [EMAIL PROTECTED] wrote: I would personally add ifrename to this list. I would suggest udev instead. This means you're suggesting a whole new aspect of functionality to be introduced to udev, because udev is currently, AFAIK, only for creating device nodes under /dev/. and a proper interface for user interfaces. What do you mean under this? Like a HAL interface, or a socket, so we can have GNOME/KDE applications easily configure networks on laptops. Why is a socket better than proper UNIX-way command-line interface? (Proper UNIX-way includes producing machine-friendly output.) Is there a reason to cling to ifupdown? I guess that there is: there is a substantial amount of code written and tested, and ifupdown is widely accepted. ifupdown does many things right. But it also needs a brushup. I just prefer to start with a clean slate. You are free to do otherwise, or team up with me. Ah, Free software. :) As for me, I would personally prefer starting a new project like netconf in C or some other imperative language rather than contributing to ifupdown -- I'm not very good with the concept of literal programming. I believe that a good, solid programming style allows to express an algorithm better than paragraphs of prose. (That's just my personal opinion.) -- 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: Time to rethink ifupdown
On Wed, 23 Aug 2006 23:05:31 +0700, martin f krafft [EMAIL PROTECTED] wrote: This means you're suggesting a whole new aspect of functionality to be introduced to udev, because udev is currently, AFAIK, only for creating device nodes under /dev/. cat /etc/udev/rules.d/z25_persistent-net.rules I don't have that (in etch). But I've got the idea. As for me, I would personally prefer starting a new project like netconf in C or some other imperative language rather than contributing to ifupdown -- I'm not very good with the concept of literal programming. I believe that a good, solid programming style allows to express an algorithm better than paragraphs of prose. (That's just my personal opinion.) I want to use Python for netconf and possibly later port it to C++. Definitely *not* C. But that's me, and the above is just talk. If you disagree, use C. No, I just used C as an example. I'm fine with any language as long as you can write something like while (condition) action in it without too much thinking about how this simple thing is done in this language. Python is just OK. -- 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: Debian ISOs
On Thu, 24 Aug 2006 00:38:59 +0700, Bruce Sass [EMAIL PROTECTED] wrote: http and ftp will always work is a really good point... someone mentioned `corporate filtering,' I think bandwidth limiting by ISPs would be a bigger problem. Shouldn't be a deal killer though, just don't use bittorrent as the only method. If only there was some auto-negotiation method like the one HTTP provides for content types: IF the client is able to use bittorrent, THEN use it, ELSE use FTP. -- 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]
Time to rethink ifupdown
the callbacks on connection/disconnection. ifup --notify should accept extra parameters like param=value which are passed to post-up scripts as IF_PARAM=value environment variables. This will allow, e.g., pppd to provide autoconfigured settings like DNS address to the post-up scripts. The /etc/network/interfaces file, in addition to ifaces and mappings, allows a new type of stanza: supervisor. The syntax is simple: a headline supervisor NAME with regular lines like pre-up, up, post-up, pre-down, down, post-down. A supervisor is considered a physical interface in the sense that you can do ifup/ifdown upon it, and that it can correspond to a logical interface at a given moment. However, the connection between a supervisor and a logical interface is not static (as in case of a mapping) but dynamic. A supervisor starts disconnected (not associated with a logical interface) -- this is the same as half-up for tristate interfaces. Here is an example: supervisor wlan0 up waproamd -M -i $IFACE# Start up a waproamd instance down waproamd -k -i $IFACE # Kill a running waproamd # We assume that waproamd is configured to run proper callbacks iface wlan0-home inet dhcp wireless-essid HomeNet iface wlan0-office inet static wireless-essid OfficeNet address 192.168.12.34 gateway 192.168.12.1 The daemon is expected to run the following callbacks: ifup --notify $IFACE=$LOGICAL to associate the supervisor with a logical interface, and ifdown --notify $IFACE to set the supervisor back into the disconnected state. The former first runs the explicit (up) or built-in (like running ifconfig) up actions on the logical interface, then post-up on the logical interface, then post-up on the supervisor. The latter runs pre-down on the supervisor, then pre-up on the logical interface, then the explicit or built-in actions on the logical interface. The pre-up or post-down actions on the logical interface are never run. When running post-up and pre-down actions on the supervisor, the $LOGICAL variable should be available. The details need to be worked out, of course. For now, I'd love to hear your opinion on the idea in general. If the general direction of ifupdown development is accepted, I can offer my help in both detailed design and implementation. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Bug#310048: kicker: sometimes eats 100% CPU after logout from KDE
Package: kicker Version: 4:3.3.2-1 Severity: important Sometimes after I log out from KDE, the kicker remains hanging and starts eating 100% CPU. It doesn't die off even when I log in again, so I have to kill it with SIGKILL. This happens or not happens without obvious reasons, and the probability of hanging seems to be about 50%. I've tried attaching to the hanging kicker process to find out what's it busy with. Using strace has shown that it's not doing any syscalls. Here is what I found out with gdb: 0x4b7b8332 in mallopt () from /lib/tls/i686/cmov/libc.so.6 (gdb) up #1 0x4b7b817e in mallopt () from /lib/tls/i686/cmov/libc.so.6 (gdb) up #2 0x4b7b6ffb in free () from /lib/tls/i686/cmov/libc.so.6 (gdb) up #3 0x45c7eed8 in QImage::freeBits () from /usr/lib/libqt-mt.so.3 (gdb) up #4 0x45c7e6aa in QImage::reset () from /usr/lib/libqt-mt.so.3 (gdb) up #5 0x45c7dfeb in QImage::~QImage () from /usr/lib/libqt-mt.so.3 (gdb) up #6 0xb7b42da2 in TaskBarContainer::sizeHint () from /usr/lib/libtaskbar.so.1 (gdb) up #7 0x4b7701d2 in exit () from /lib/tls/i686/cmov/libc.so.6 (gdb) up #8 0x463b3203 in _kde_IceDefaultIOErrorHandler () from /usr/lib/libDCOP.so.4 (gdb) up #9 0x463b4822 in _kde_IceWrite () from /usr/lib/libDCOP.so.4 (gdb) up #10 0x463b4355 in KDE_IceFlush () from /usr/lib/libDCOP.so.4 (gdb) up #11 0x463ab35c in DCOPClient::callInternal () from /usr/lib/libDCOP.so.4 (gdb) up #12 0x463aaafc in DCOPClient::callInternal () from /usr/lib/libDCOP.so.4 (gdb) up #13 0x463aa5c5 in DCOPClient::call () from /usr/lib/libDCOP.so.4 (gdb) up #14 0x463aa3ea in DCOPClient::call () from /usr/lib/libDCOP.so.4 (gdb) up #15 0x463ac222 in DCOPClient::disconnectDCOPSignal () from /usr/lib/libDCOP.so.4 (gdb) up #16 0x463a008e in DCOPObject::~DCOPObject () from /usr/lib/libDCOP.so.4 (gdb) up #17 0xb79333a6 in KMFactory::~KMFactory () from /usr/lib/libkdeprint.so.4 (gdb) up #18 0xb793673f in KStaticDeleterKMFactory::destructObject () from /usr/lib/libkdeprint.so.4 (gdb) up #19 0x46273825 in KGlobal::deleteStaticDeleters () from /usr/lib/libkdecore.so.4 (gdb) up #20 0x461e13ac in KApplication::~KApplication () from /usr/lib/libkdecore.so.4 (gdb) up #21 0x46282157 in KUniqueApplication::~KUniqueApplication () from /usr/lib/libkdecore.so.4 (gdb) up #22 0x46b513e8 in Kicker::~Kicker () from /usr/lib/libkdeinit_kicker.so (gdb) up #23 0x46b4f441 in kdemain () from /usr/lib/libkdeinit_kicker.so (gdb) up #24 0xb7ff88a6 in kdeinitmain () from /usr/lib/kde3/kicker.so (gdb) up #25 0x0804cd30 in ?? () If you need more debugging information of some kind, or information about my system configuration, just write what info you need, I'll try to collect it. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (900, 'testing'), (800, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.11-1-686 Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R) Versions of packages kicker depends on: ii kdebase-data 4:3.3.2-1 KDE Base (shared data) ii kdelibs4 4:3.3.2-5 KDE core libraries ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libfam0c102 2.7.0-6client library to control the FAM ii libgcc1 1:3.4.3-12 GCC support library ii libice6 6.8.2-5.1 Inter-Client Exchange library ii libidn11 0.5.13-1.0 GNU libidn library, implementation ii libkonq4 4:3.3.2-1 Core libraries for KDE's file mana ii libpng12-01.2.8rel-1 PNG library - runtime ii libqt3c102-mt 3:3.3.4-3 Qt GUI Library (Threaded runtime v ii libsm66.8.2-5.1 X Window System Session Management ii libstdc++51:3.3.5-12 The GNU Standard C++ Library v3 ii libx11-6 6.8.2-5.1 X Window System protocol client li ii libxext6 6.8.2-5.1 X Window System miscellaneous exte ii libxrender1 0.9.0-0ubuntu4 X Rendering Extension client libra ii libxtst6 6.8.2-5.1 X Window System event recording an ii xlibs 6.8.2-5.1 X Window System client libraries m ii zlib1g1:1.2.2-4 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
