Re: iptables and kvm
Good time of the day, Craig. You wrote: > I am running Debian Wheezy, and have installed kvm. When I list my > iptables rules there are a set of default rules defined, and > forwarding is set up for my virtual network. For the life of me I can > not figure out where these rules are defined, and I would like to > make some changes that I want to be permanent. Would anyone mind > enlightening me as where I can find the source of those rules? > > > grep -RIil iptables /etc/* returns nothing. If You want to set Your own rules, You can write it to a file where You want to hold it, then You can put a script w/ execution bit set in /etc/network/if-pre-up.d that will read those files. As soon as the interface comes up, Your rules will come up too (in case it is correct - otherwise the defaults will be used). Sthu. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51021e49.e684980a.513c.0...@mx.google.com
Re: [Followup]: Basic USB Automounter?
- Original Message - > From: sp113438telfort > To: debian-user@lists.debian.org > Cc: "debian-user@lists.debian.org" > Sent: Thursday, January 24, 2013 6:01 PM > Subject: Re: [Followup]: Basic USB Automounter? > > [snip] >> > I missed the first of this. Has anyone mentioned pmount? >> >> >> Yes. And I came across it in my research, too. It's on my list of >> alternative mounting tools for udev rules in case using the standard >> mount command results in the device only being accessable by root. >> Definitely NOT what I want. From what I understand, 'udisks >> --mount' provides the same functionality while being more >> feature-rich. >> >> >> B >> >> >> > The story will get even more problematic when you want to boot your > machine with the USB devices are already connected ... So far, the only "permanent" USB connection is the printer which as yet is not configured, but is recognized at boot. No problem there, so far. Other than that, my USB needs are temporary--flash cards and thumb drives inserted to copy stuff onto or off of, then removed. No external USB hard drives as yet. No need. No other USB paraphernalia either. > Please post a message containing SOLVED when you find out! If or when I encounter such a problem and solve it, I'll surely let the list know. B -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1359093315.19150.yahoomail...@web142305.mail.bf1.yahoo.com
clock source 25 is not valid, cannot use
When I use linux-image-3.2.0-0.bpo.4-rt-amd64, An error of a large quantity of clock source occurs at the boot time when I connect usb-sound-card AS372(chip:CM6620). There is not the problem with the stability of the system, but these errors fill up the log. When I used kernel 2.6.32, this error was not displayed because usb-sound-card did not recognize. I do not know it whether that this error is the problem of the kernel or a problem of alsa. How can I fix it? -- System Information: Debian Release: 6.0.6 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) ** Kernel log: [ 69.568042] 2:4:2: clock source 25 is not valid, cannot use [ 69.570406] 2:4:2: clock source 25 is not valid, cannot use [ 69.570907] 2:4:2: clock source 25 is not valid, cannot use [ 69.571531] 2:4:2: clock source 25 is not valid, cannot use [ 69.572798] 2:4:2: clock source 25 is not valid, cannot use [ 69.573935] 2:4:2: clock source 25 is not valid, cannot use [ 69.576163] 2:4:2: clock source 25 is not valid, cannot use [ 69.576660] 2:4:2: clock source 25 is not valid, cannot use [ 69.577282] 2:4:2: clock source 25 is not valid, cannot use [ 69.578426] 2:4:2: clock source 25 is not valid, cannot use [ 69.579551] 2:4:2: clock source 25 is not valid, cannot use [ 69.582158] 2:4:2: clock source 25 is not valid, cannot use [ 69.582658] 2:4:2: clock source 25 is not valid, cannot use [ 69.583283] 2:4:2: clock source 25 is not valid, cannot use [ 69.584321] 2:4:2: clock source 25 is not valid, cannot use [ 69.585442] 2:4:2: clock source 25 is not valid, cannot use [ 69.587907] 2:4:2: clock source 25 is not valid, cannot use [ 69.588538] 2:4:2: clock source 25 is not valid, cannot use [ 69.589033] 2:4:2: clock source 25 is not valid, cannot use [ 69.590055] 2:4:2: clock source 25 is not valid, cannot use [ 69.591177] 2:4:2: clock source 25 is not valid, cannot use [ 69.593908] 2:4:2: clock source 25 is not valid, cannot use [ 69.594533] 2:4:2: clock source 25 is not valid, cannot use [ 69.595158] 2:4:2: clock source 25 is not valid, cannot use [ 69.596183] 2:4:2: clock source 25 is not valid, cannot use [ 69.597442] 2:4:2: clock source 25 is not valid, cannot use [ 69.600077] 2:4:2: clock source 25 is not valid, cannot use [ 69.600793] 2:4:2: clock source 25 is not valid, cannot use [ 69.601411] 2:4:2: clock source 25 is not valid, cannot use [ 69.602440] 2:4:2: clock source 25 is not valid, cannot use [ 69.603559] 2:4:2: clock source 25 is not valid, cannot use [ 69.626664] 2:4:2: clock source 25 is not valid, cannot use [ 69.627288] 2:4:2: clock source 25 is not valid, cannot use [ 69.627913] 2:4:2: clock source 25 is not valid, cannot use [ 69.629064] 2:4:2: clock source 25 is not valid, cannot use [ 69.630184] 2:4:2: clock source 25 is not valid, cannot use [ 69.632418] 2:4:2: clock source 25 is not valid, cannot use [ 69.632914] 2:4:2: clock source 25 is not valid, cannot use [ 69.633414] 2:4:2: clock source 25 is not valid, cannot use [ 69.634439] 2:4:2: clock source 25 is not valid, cannot use [ 69.635437] 2:4:2: clock source 25 is not valid, cannot use [ 69.638039] 2:4:2: clock source 25 is not valid, cannot use [ 69.638540] 2:4:2: clock source 25 is not valid, cannot use [ 69.639165] 2:4:2: clock source 25 is not valid, cannot use [ 69.640303] 2:4:2: clock source 25 is not valid, cannot use [ 69.641443] 2:4:2: clock source 25 is not valid, cannot use [ 69.644079] 2:4:2: clock source 25 is not valid, cannot use [ 69.644798] 2:4:2: clock source 25 is not valid, cannot use [ 69.645416] 2:4:2: clock source 25 is not valid, cannot use [ 69.646566] 2:4:2: clock source 25 is not valid, cannot use [ 69.647815] 2:4:2: clock source 25 is not valid, cannot use [ 69.650041] 2:4:2: clock source 25 is not valid, cannot use [ 69.650666] 2:4:2: clock source 25 is not valid, cannot use [ 69.651291] 2:4:2: clock source 25 is not valid, cannot use [ 69.652309] 2:4:2: clock source 25 is not valid, cannot use [ 69.653442] 2:4:2: clock source 25 is not valid, cannot use [ 69.655541] 2:4:2: clock source 25 is not valid, cannot use [ 69.656081] 2:4:2: clock source 25 is not valid, cannot use [ 69.656798] 2:4:2: clock source 25 is not valid, cannot use [ 69.657693] 2:4:2: clock source 25 is not valid, cannot use [ 69.658818] 2:4:2: clock source 25 is not valid, cannot use [ 69.661292] 2:4:2: clock source 25 is not valid, cannot use [ 69.661918] 2:4:2: clock source 25 is not valid, cannot use [ 69.662543] 2:4:2: clock source 25 is not valid, cannot use [ 69.663567] 2:4:2: clock source 25 is not valid, cannot use [ 69.664933] 2:4:2: clock source 25 is not valid, cannot use [ 69.667418] 2:4:2: clock source 25 is not valid, cannot use [ 69.668154] 2:4:2: clock source 25 is not valid, cannot use [ 69.668675] 2:4:2: clock source 25 is not valid, cannot use [ 69.669695] 2:4:2: clock source 25
Re: [Followup]: Basic USB Automounter?
On Thu, 24 Jan 2013 13:53:29 -0800 (PST) Patrick Bartek wrote: > > > > > - Original Message - > > From: Mark Allums > > To: debian-user@lists.debian.org > > Cc: > > Sent: Thursday, January 24, 2013 12:18 PM > > Subject: RE: [Followup]: Basic USB Automounter? > > > >> From: Patrick Bartek [mailto:bartek...@yahoo.com] > >> Also, someone suggested usbmount, which I was aware of, but in my > >> reading, it said that it would only mount thumb and external USB > >> hard drives, and not flash cards using a reader. I never tested > >> to see if this > > were > >> true. > > > > In my experience, SD cards are treated like USB drives. On my Eee > > PC, I have run Debian from the SD card slot on a 32GB card. (That > > was quite a while back.) Sometimes, it takes a little sleuthing to > > figure out what /dev node it is. > > A single SD card slot seems to work differently than a USB multicard > reader that accepts 6 different kinds of cards, and all at once, if > you want. I tested one automounter that recognized the reader, but > wouldn't automount any cards when inserted. The cards were never > even recognized unless the card was in the reader when the reader was > plugged in, then it worked. The "problem" seems to be that most of > the automounting solutions I've come across depend on the "mounting" > support files that come with a full Desktop Environment, whether > you're using the desktop or not, to handle the details, the > permissions, etc. My set up has none of that. I want to keep it as > lean as possible for speed while still meeting my requirements and > being easily usable. > > > I missed the first of this. Has anyone mentioned pmount? > > > Yes. And I came across it in my research, too. It's on my list of > alternative mounting tools for udev rules in case using the standard > mount command results in the device only being accessable by root. > Definitely NOT what I want. From what I understand, 'udisks > --mount' provides the same functionality while being more > feature-rich. > > > B > > > The story will get even more problematic when you want to boot your machine with the USB devices are already connected ... Please post a message containing SOLVED when you find out! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130125030133.636be47c@fx4100
Re: [Followup]: Basic USB Automounter?
- Original Message - > From: Mark Allums > To: debian-user@lists.debian.org > Cc: > Sent: Thursday, January 24, 2013 12:18 PM > Subject: RE: [Followup]: Basic USB Automounter? > >> From: Patrick Bartek [mailto:bartek...@yahoo.com] >> Also, someone suggested usbmount, which I was aware of, but in my >> reading, it said that it would only mount thumb and external USB hard >> drives, and not flash cards using a reader. I never tested to see if this > were >> true. > > In my experience, SD cards are treated like USB drives. On my Eee PC, I > have run Debian from the SD card slot on a 32GB card. (That was quite a > while back.) Sometimes, it takes a little sleuthing to figure out what /dev > node it is. A single SD card slot seems to work differently than a USB multicard reader that accepts 6 different kinds of cards, and all at once, if you want. I tested one automounter that recognized the reader, but wouldn't automount any cards when inserted. The cards were never even recognized unless the card was in the reader when the reader was plugged in, then it worked. The "problem" seems to be that most of the automounting solutions I've come across depend on the "mounting" support files that come with a full Desktop Environment, whether you're using the desktop or not, to handle the details, the permissions, etc. My set up has none of that. I want to keep it as lean as possible for speed while still meeting my requirements and being easily usable. > I missed the first of this. Has anyone mentioned pmount? Yes. And I came across it in my research, too. It's on my list of alternative mounting tools for udev rules in case using the standard mount command results in the device only being accessable by root. Definitely NOT what I want. From what I understand, 'udisks --mount' provides the same functionality while being more feature-rich. B -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1359064409.85999.yahoomail...@web142305.mail.bf1.yahoo.com
Re: Samba usershare errors
On 25/01/2013 3:51 AM, "Roger Lynn" wrote: > > Hi, > > I am running the Debian package of Samba 2:3.6.6-4 on an up to date Wheezy > server. I am getting a lot of errors logged similar to this: > > log.sophie-pc:[2013/01/24 08:38:38.848419, 0] > param/loadparm.c:9114(process_usershare_file) > log.sophie-pc: process_usershare_file: stat of > /var/lib/samba/usershares/servic failed. Permission denied > log.sophie-pc:[2013/01/24 08:38:38.849233, 0] > param/loadparm.c:9114(process_usershare_file) > log.sophie-pc: process_usershare_file: stat of > /var/lib/samba/usershares/servic failed. No such file or directory > log.sophie-pc:[2013/01/24 08:38:38.849679, 0] > param/loadparm.c:9114(process_usershare_file) > log.sophie-pc: process_usershare_file: stat of > /var/lib/samba/usershares/servic failed. No such file or directory > > As far as I know usershares are disabled. The clients are running a variety > of recent versions of Windows. It most often seems to happen with PDF files, > but there are others too. > > My smb.conf file looks like this. Several similar share definitions have > been omitted for brevity. > > [global] > workgroup = FUNDAMENTALS > server string = %h server > interfaces = 127.0.0.0/8, bond0 > bind interfaces only = Yes > obey pam restrictions = Yes > pam password change = Yes > unix password sync = Yes > syslog = 0 > log file = /var/log/samba/log.%m > max log size = 1000 > load printers = No > os level = 65 > preferred master = Yes > domain master = Yes > dns proxy = No > wins support = Yes > panic action = /usr/share/samba/panic-action %d > idmap config * : backend = tdb > invalid users = root > [Service] > comment = Service files > path = /srv/smb/service > read only = No > create mask = 0775 > force create mode = 0664 > directory mask = 0770 > force directory mode = 0770 > [Sophie] > comment = Home Directories > path = /home/sophie/share > invalid users = root, manfred > read only = No > create mask = 0775 > force create mode = 0444 > directory mask = 0775 > force directory mode = 0555 > > What might be causing the above errors? > > I am also getting lots of cups errors like this: > [2013/01/24 15:29:32.978276, 0] printing/print_cups.c:110(cups_connect) > Unable to connect to CUPS server localhost:631 - Connection refused > [2013/01/24 15:29:32.978505, 0] printing/print_cups.c:487(cups_async_callback) > failed to retrieve printer list: NT_STATUS_UNSUCCESSFUL > > I presume this is because cups is not installed. Is there any way to stop > Samba from continuously trying access it? > Remove printer section from config. > Thank you, > > Roger > > > -- > To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: http://lists.debian.org/51015e3c.7050...@rilynn.me.uk >
Re: dselect fun
Chris Bannister wrote: On Wed, Jan 23, 2013 at 09:54:17AM +, Darac Marjal wrote: chime in with a reminder that dselect is considered discouraged these days. It's spiritual successor (a TUI interface to apt) is now aptitude. That depends on who you ask. For newbies, I certainly wouldn't recommend dselect, but if they wanted to use it I certainly wouldn't discourage them from doing so. In fact, if they can get their head around dselect, then anything else that is thrown at them will probably seem like a piece of cake. As to the overall Linux market there are at least two distinct classes of "newbies". There is the class who is targeted by the Canonical (cf Microsoft) mentality - Big Brother knows best. There is class who wants the best from his system. "BEST" is not a simple one dimensional parameter. When I was in school a strong emphasis was placed on "first principles". I think Debian could benefit from that outlook. I.E. Use the intuitive/user friendly/simple/simplistic interface(s) when appropriate. But know hat goes on "under the hood". I'll follow the later route. I started my transition from Windows to Linux over two years ago. I could have had a system up in a day. But I don't see how it would have been significantly better/ than (insert your least favorite OS implementation here). I'll continue to pursue the "back to basics" route. I do not wish to discourage pointing newbies to most modern tools. BUT please point them to the fundamentals. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5101a113.9070...@cloud85.net
Re: moving from Kubuntu 10.4 to squeeze
On Jo, 24 ian 13, 10:34:08, Mark Allums wrote: > > Upgrades from release to release are more tricky than Ubuntu. It is > sometimes easiest to just install the new version "clean". I'm not familiar with Ubuntu, but Debian upgrades have always worked fine for me. Kind regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
RE: 32-bit to 64-bit
From: Sven Joachim [mailto:svenj...@gmx.de] > > On 2013-01-24 17:51 +0100, Sven Joachim wrote: > > > On 2013-01-24 16:58 +0100, Kelly Clowers wrote: > > >> On Thu, Jan 24, 2013 at 6:51 AM, Sven Joachim > > wrote: > > >>> I have crossgraded some packages in i386 chroots that way, but in the > > >>> current state of affairs I would definitely _not_ dare to try a full > > >>> crossgrade on my main system with almost 2000 installed packages. > > >> > > >> I bet it is doable. I wish I had a 32 bit system to try it on, I love doing > > >> crazy things with the package manager, like when I combined > > >> significant parts of Ubuntu (X and GTK) into my Debian install, > > >> and later transitioned back to pure Debian. > > > > Okay, I just tried to do a crossgrade in one of those disposable > > chroots. The good news is that dpkg itself can be crossgraded smoothly > > once the necessary amd64 libraries are installed, the bad news is that > > apt gets thoroughly confused by this action: > > > > , > > | # dpkg --version > > | Debian `dpkg' package management program version 1.16.9 (i386). > > | This is free software; see the GNU General Public License version 2 or > > | later for copying conditions. There is NO warranty. > > | root@turtle:/var/cache/apt/archives# apt-cache show base-files:amd64 > > | Package: base-files > > | Version: 7.1 > > | Essential: yes > > | Installed-Size: 414 > > | Maintainer: Santiago Vila > > | Architecture: amd64 > > | Replaces: base, dpkg (<= 1.15.0), miscutils > > | Provides: base > > | Pre-Depends: awk > > | Breaks: initscripts (<< 2.88dsf-13.3), sendfile (<< 2.1b.20080616-5.2~) > > | Description-en: Debian base system miscellaneous files > > | This package contains the basic filesystem hierarchy of a Debian system, > > and > > | several important miscellaneous files, such as /etc/debian_version, > > | /etc/host.conf, /etc/issue, /etc/motd, /etc/profile, and others, > > | and the text of several common licenses in use on Debian systems. > > | Multi-Arch: foreign > > | Description-md5: 6d16337f57b84c4747f56438355b2395 > > | Tag: admin::configuring, role::app-data, suite::debian > > | Section: admin > > | Priority: required > > | Filename: pool/main/b/base-files/base-files_7.1_amd64.deb > > | Size: 71776 > > | MD5sum: dcaeda04f934efba7de05d924f45a850 > > | SHA1: d4c5131596a65dfefa055026ee1c25c2aa95f13e > > | SHA256: > > > 9b89d2a217da3fa2c6366ad44748eaa3613e575e77bbb727a3b02b6a7b80ea7 > > e > > | > > | dpkg -i dpkg_1.16.9_amd64.deb > > | (Reading database ... 9690 files and directories currently installed.) > > | Preparing to replace dpkg 1.16.9 (using dpkg_1.16.9_amd64.deb) ... > > | Unpacking replacement dpkg ... > > | Setting up dpkg (1.16.9) ... > > | # apt-cache show base-files:amd64 > > | N: Unable to locate package base-files > > | E: No packages found > > ` > > > > This also means that my plan to "aptitude download base-files:amd64" > > followed by "dpkg -i base-files*amd64.deb" does not work, so I'll revert > > to the i386 dpkg in that chroot for now. Thanks for going to so much trouble for us. You suggest a chroot. What about a *totally* off-line approach? Unpacking files to their proper places by hand, then updating scripts and config files from outside manually (probably using another script prepared specifically for the purpose.) I would not know the first place to start. But I suspect that there is a market for this. I would suggest that Debian create a 32=>64 bit transition kit for jessie, because this is only going to come up more and more often as 32-bit loses ground to 64-bit in usage. A lot of old-timers, plus a fair number of servers that have been in place for years will be asking this same question. I myself for my personal equipment tend to grab the hard drive out of one old machine and stick it into another new one, and thanks to Debian and Linux, it usually works. But although the hardware is capable of 64-bit (and future hardware only moreso) keeping the exact environment without reinstalling from scratch seems impossible. For most things, that's okay, I will do "Just-In-Time installing", not doing it all at once, but only as the situation that needs something specific presents itself. But for this specific application, well, I have it the way I like it, and it's too much work (and too error-prone, at least for yours-truly) to start over. Thanks. I won't give up. I will keep looking. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/007d01cdfa73$540c07b0$fc241710$@allums.com
RE: [Followup]: Basic USB Automounter?
> From: Patrick Bartek [mailto:bartek...@yahoo.com] > Also, someone suggested usbmount, which I was aware of, but in my > reading, it said that it would only mount thumb and external USB hard > drives, and not flash cards using a reader. I never tested to see if this were > true. In my experience, SD cards are treated like USB drives. On my Eee PC, I have run Debian from the SD card slot on a 32GB card. (That was quite a while back.) Sometimes, it takes a little sleuthing to figure out what /dev node it is. I missed the first of this. Has anyone mentioned pmount? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/007801cdfa6f$f0d076c0$d2716440$@allums.com
Re: Upgrade from stable to testing hosed my server
On 01/24/2013 05:51 PM, Mark Phillips wrote: Peter, Can I access the log if I boot the machine with a live cd of some kind? Mark Hello Mark, read the release notes first and think about what you did wrong. I do not know how you proceed with the upgrade, but yes there are paths like these: /var/log/dpkg.log /var/log/aptitude /var/log/apt/ The quickest solution will be to restore package states using the commands 'dpkg --get-selections' and 'dpkg --set-selections'. Or simply install all the missing ones - once you remember what packages you installed on the system before. Some of these procedures are documented in the release notes - therefore I highly recommend you to read it. You can use the Debian installation CD/DVD and boot into 'rescue mode'. -- Peter -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5101932b.3040...@gmail.com
iptables and kvm
I am running Debian Wheezy, and have installed kvm. When I list my iptables rules there are a set of default rules defined, and forwarding is set up for my virtual network. For the life of me I can not figure out where these rules are defined, and I would like to make some changes that I want to be permanent. Would anyone mind enlightening me as where I can find the source of those rules? grep -RIil iptables /etc/* returns nothing. Thanks, Craig Sent - Gtek Web Mail -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1359054666.32117...@webmail.gtek.biz
Re: 32-bit to 64-bit
On 2013-01-24 17:51 +0100, Sven Joachim wrote: > On 2013-01-24 16:58 +0100, Kelly Clowers wrote: > >> On Thu, Jan 24, 2013 at 6:51 AM, Sven Joachim wrote: >>> >>> I have crossgraded some packages in i386 chroots that way, but in the >>> current state of affairs I would definitely _not_ dare to try a full >>> crossgrade on my main system with almost 2000 installed packages. >> >> I bet it is doable. I wish I had a 32 bit system to try it on, I love doing >> crazy things with the package manager, like when I combined >> significant parts of Ubuntu (X and GTK) into my Debian install, >> and later transitioned back to pure Debian. > > As much as I love doing such crazy things myself, I also need a working > system and so restrict such experiments to chroots which can be thrown > away when things go wrong. Mixing Ubuntu and Debian packages > willy-nilly is a recipe for disaster, as is trying to crossgrade from > i386 to amd64 ATM. Okay, I just tried to do a crossgrade in one of those disposable chroots. The good news is that dpkg itself can be crossgraded smoothly once the necessary amd64 libraries are installed, the bad news is that apt gets thoroughly confused by this action: , | # dpkg --version | Debian `dpkg' package management program version 1.16.9 (i386). | This is free software; see the GNU General Public License version 2 or | later for copying conditions. There is NO warranty. | root@turtle:/var/cache/apt/archives# apt-cache show base-files:amd64 | Package: base-files | Version: 7.1 | Essential: yes | Installed-Size: 414 | Maintainer: Santiago Vila | Architecture: amd64 | Replaces: base, dpkg (<= 1.15.0), miscutils | Provides: base | Pre-Depends: awk | Breaks: initscripts (<< 2.88dsf-13.3), sendfile (<< 2.1b.20080616-5.2~) | Description-en: Debian base system miscellaneous files | This package contains the basic filesystem hierarchy of a Debian system, and | several important miscellaneous files, such as /etc/debian_version, | /etc/host.conf, /etc/issue, /etc/motd, /etc/profile, and others, | and the text of several common licenses in use on Debian systems. | Multi-Arch: foreign | Description-md5: 6d16337f57b84c4747f56438355b2395 | Tag: admin::configuring, role::app-data, suite::debian | Section: admin | Priority: required | Filename: pool/main/b/base-files/base-files_7.1_amd64.deb | Size: 71776 | MD5sum: dcaeda04f934efba7de05d924f45a850 | SHA1: d4c5131596a65dfefa055026ee1c25c2aa95f13e | SHA256: 9b89d2a217da3fa2c6366ad44748eaa3613e575e77bbb727a3b02b6a7b80ea7e | | dpkg -i dpkg_1.16.9_amd64.deb | (Reading database ... 9690 files and directories currently installed.) | Preparing to replace dpkg 1.16.9 (using dpkg_1.16.9_amd64.deb) ... | Unpacking replacement dpkg ... | Setting up dpkg (1.16.9) ... | # apt-cache show base-files:amd64 | N: Unable to locate package base-files | E: No packages found ` This also means that my plan to "aptitude download base-files:amd64" followed by "dpkg -i base-files*amd64.deb" does not work, so I'll revert to the i386 dpkg in that chroot for now. Cheers, Sven -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874ni62yep@turtle.gmx.de
[Followup]: Basic USB Automounter?
First, thanks for all the input and suggestions. Here is the basics of my research into setting up user automounting on a minimal console-only system or X running only a window manager (in my case, Openbox)--no display or sessions manager. I'm running wheezy 64-bit. The "quick and dirty" solution? Udisks, plus udisks-glue. Worked out of the box, but with caveats. 1. Udisks-glue must be run by the user. So, putting /usr/bin/udisks-glue in rc.local, so it runs at start up, won't work as only root will be able to access the device(s). However, devices are automounted. Yes, you can edit the appropriate "permissions" file to give "users" access, but this was too much work. Maybe, later, if the need arises. 2. "Glue" must be run by the user in the current session terminal for the user to be able to access the automounted device. So, if you boot to tty1 as I'm doing, logging in, running "glue", all is fine. However, if you later need X and run startx, automounting won't work as "glue" is running only in tty1, and the X is running in another. You can either run "glue" again in a xterm or, what I did, run it from Openbox's autostart file. I did find a script that forces startx to run X in the login tty, in this case tty1, but didn't test it. I wanted to keep the system as "default" as possible. 3. By default, "glue' doesn't mount the device with its label or device name (/dev/sd-whatever), but with a cryptic name like 585D-F99F. If I understand correctly, this can be changed by editing udisks-glue's configure file, either the global one or a user one. 4. "Glue" is not set up by default to mount CDs or DVDs, but again this can be enabled by editing the config file. Another automount solution is creating a udev rule for it. I found this [1], but haven't tested it yet. Still learning how to write a proper udev rule. This appeals to me more than "glue" as it's a more system "standard" solution. Also, someone suggested usbmount, which I was aware of, but in my reading, it said that it would only mount thumb and external USB hard drives, and not flash cards using a reader. I never tested to see if this were true. I'll let the list know how the udev rule solution goes as a few had need of the automounting on minimal systems. Until later. B [1]: https://soosck.wordpress.com/2011/01/19/improved-udev-rule-arch-linux/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1359052288.857.yahoomail...@web142304.mail.bf1.yahoo.com
OT: pam_unix(dovecot:auth): authentication failure.
Good time of the day. Excuse me for off-topic. Could You please comment this auth. failure: localhost auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=null rhost=91.201.64.249 ? As I understand this - one tried to login to dovecot - but dovecot was closed by firewall from that IP, or it was tried from local side and therefore I have a security issue inside of my system? Thank You for Your time. Sthu. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51016fd9.0781980a.4d78.3...@mx.google.com
Re: moving from Kubuntu 10.4 to squeeze
On Thursday, January 24, 2013 11:54:40 Ralf Mardorf wrote: > -Original Message- > From: Mark Allums > Sent: Thu 1/24/2013 17:34 > > > The most noticeable difference to me has been the lack of drivers. > > Debian does not use http://upstart.ubuntu.com/ . Not an issue. I prefer typing: "/etc/init.d/mysql restart" as an example -- Mike McGinn KD2CNU Ex Uno Plurima No electrons were harmed in sending this message, some were inconvenienced. ** Registered Linux User 377849 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201301241206.10235.mikemcg...@mcginnweb.net
RE: moving from Kubuntu 10.4 to squeeze
-Original Message- From: Mark Allums Sent: Thu 1/24/2013 17:34 > The most noticeable difference to me has been the lack of drivers. Debian does not use http://upstart.ubuntu.com/ .
Re: 32-bit to 64-bit
On 2013-01-24 16:58 +0100, Kelly Clowers wrote: > On Thu, Jan 24, 2013 at 6:51 AM, Sven Joachim wrote: >> >> I have crossgraded some packages in i386 chroots that way, but in the >> current state of affairs I would definitely _not_ dare to try a full >> crossgrade on my main system with almost 2000 installed packages. > > I bet it is doable. I wish I had a 32 bit system to try it on, I love doing > crazy things with the package manager, like when I combined > significant parts of Ubuntu (X and GTK) into my Debian install, > and later transitioned back to pure Debian. As much as I love doing such crazy things myself, I also need a working system and so restrict such experiments to chroots which can be thrown away when things go wrong. Mixing Ubuntu and Debian packages willy-nilly is a recipe for disaster, as is trying to crossgrade from i386 to amd64 ATM. Cheers, Sven -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ip6m34nl@turtle.gmx.de
Samba usershare errors
Hi, I am running the Debian package of Samba 2:3.6.6-4 on an up to date Wheezy server. I am getting a lot of errors logged similar to this: log.sophie-pc:[2013/01/24 08:38:38.848419, 0] param/loadparm.c:9114(process_usershare_file) log.sophie-pc: process_usershare_file: stat of /var/lib/samba/usershares/servic failed. Permission denied log.sophie-pc:[2013/01/24 08:38:38.849233, 0] param/loadparm.c:9114(process_usershare_file) log.sophie-pc: process_usershare_file: stat of /var/lib/samba/usershares/servic failed. No such file or directory log.sophie-pc:[2013/01/24 08:38:38.849679, 0] param/loadparm.c:9114(process_usershare_file) log.sophie-pc: process_usershare_file: stat of /var/lib/samba/usershares/servic failed. No such file or directory As far as I know usershares are disabled. The clients are running a variety of recent versions of Windows. It most often seems to happen with PDF files, but there are others too. My smb.conf file looks like this. Several similar share definitions have been omitted for brevity. [global] workgroup = FUNDAMENTALS server string = %h server interfaces = 127.0.0.0/8, bond0 bind interfaces only = Yes obey pam restrictions = Yes pam password change = Yes unix password sync = Yes syslog = 0 log file = /var/log/samba/log.%m max log size = 1000 load printers = No os level = 65 preferred master = Yes domain master = Yes dns proxy = No wins support = Yes panic action = /usr/share/samba/panic-action %d idmap config * : backend = tdb invalid users = root [Service] comment = Service files path = /srv/smb/service read only = No create mask = 0775 force create mode = 0664 directory mask = 0770 force directory mode = 0770 [Sophie] comment = Home Directories path = /home/sophie/share invalid users = root, manfred read only = No create mask = 0775 force create mode = 0444 directory mask = 0775 force directory mode = 0555 What might be causing the above errors? I am also getting lots of cups errors like this: [2013/01/24 15:29:32.978276, 0] printing/print_cups.c:110(cups_connect) Unable to connect to CUPS server localhost:631 - Connection refused [2013/01/24 15:29:32.978505, 0] printing/print_cups.c:487(cups_async_callback) failed to retrieve printer list: NT_STATUS_UNSUCCESSFUL I presume this is because cups is not installed. Is there any way to stop Samba from continuously trying access it? Thank you, Roger -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51015e3c.7050...@rilynn.me.uk
Re: moving from Kubuntu 10.4 to squeeze
On Thursday, January 24, 2013 11:34:08 Mark Allums wrote: > The most noticeable difference to me has been the lack of drivers. You are > pretty much on your own finding drivers for things. Debian supports older > hardware quite well, but there is usually a long wait for it. > > Upgrades from release to release are more tricky than Ubuntu. It is > sometimes easiest to just install the new version "clean". > > If you run packages from Testing (starting, say 6 months after a release), > go all out in Testing . Mixing distributions leads to heartbreak. Ditto > Sid. IF you run things from Sid, you're better off running a full Sid > system rather than a mixed system with some packages from Testing and some > from Sid. > > The only things to get from Experimental are possibly the latest iceweasel, > or a new kernel. But wait on the latter until the kbuild package is > released, if you are going to need the kernel headers to compile hardware > drivers (the classic example being nvidia-glx kernel module). The headers > depend on linux-kbuild, and the kernel guys often don't get around to > packaging it right away. > > I'm sure there are people with better advice, Keep it coming, guys! Thanks Mark, that is some good info. The only proprietary driver I had to install was for the wireless, which I got from Dell. The laptop uses an Intel graphics chip (I forget which one), but there was a bug with the drivers in one 'buntu version (again I forget, might have been 10.04) which just about drove me nuts until it was fixed. I bought this laptop in early 2009,so it is by no means "new". Mike -- Mike McGinn KD2CNU Ex Uno Plurima No electrons were harmed in sending this message, some were inconvenienced. ** Registered Linux User 377849 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201301241149.59733.mikemcg...@mcginnweb.net
Re: 32-bit to 64-bit
On 2013-01-24 16:58 +0100, Mark Allums wrote: > The third bit is the hard part. I am wondering if I should go from lucid to > precise first, or do the 32/64-bit trick first. Or is there a way to do > both at once? With dpkg from lucid or precise you're out of luck anyway. The former is not multiarch aware at all, the latter does not support crossgrades¹. You need at least dpkg 1.16.2. Cheers, Sven ¹ http://lists.debian.org/debian-dpkg/2011/12/msg00023.html -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obge34yb@turtle.gmx.de
RE: moving from Kubuntu 10.4 to squeeze
> From: Mike McGinn [mailto:mikemcg...@mcginnweb.net] > I have a Dell Inspiron 1545 laptop with 4G of RAM and have been a 'buntu > user > since release 7.04. With each release of the new OS from Kubuntu I have > been > less and less happy with the so called "quality" and I am planning a move to > Debian. As a Kontact user the problems reported with the new versions of > that > particular package are dictating the move to Squeeze. (I subscribe to both > the > kde-pim users and developers mail lists.) > > I have been experimenting with an installation in a virtual machine and I am > getting ready to make the jump. I am happy with what I have experienced in > my > VM and I just want to know if there are any pitfalls I have not foreseen. My > system is backed up every night, so I am not worried about losing anything. The most noticeable difference to me has been the lack of drivers. You are pretty much on your own finding drivers for things. Debian supports older hardware quite well, but there is usually a long wait for it. Upgrades from release to release are more tricky than Ubuntu. It is sometimes easiest to just install the new version "clean". If you run packages from Testing (starting, say 6 months after a release), go all out in Testing . Mixing distributions leads to heartbreak. Ditto Sid. IF you run things from Sid, you're better off running a full Sid system rather than a mixed system with some packages from Testing and some from Sid. The only things to get from Experimental are possibly the latest iceweasel, or a new kernel. But wait on the latter until the kbuild package is released, if you are going to need the kernel headers to compile hardware drivers (the classic example being nvidia-glx kernel module). The headers depend on linux-kbuild, and the kernel guys often don't get around to packaging it right away. I'm sure there are people with better advice, Keep it coming, guys! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/005601cdfa50$a2862380$e7926a80$@allums.com
Re: Upgrade from stable to testing hosed my server
On 01/24/2013 02:30 PM, Mark Phillips wrote: I used aptitude to upgrade a headless server from Debian stable to Debian testing. The upgrade did not generate any error messages, but when I rebooted I could not ssh into the box (connection refused) nor do I get any output on a monitor I attached to the box (no signal). Apache does not appear to be running either on the box (could not connect to the box). I can successfully ping the box. Any suggestions on how to fix this this server would be greatly appreciated! Thanks, Mark Hi Mark, it's very hard to help you right now. Do you have a log of the terminal session on which you performed the upgrade? Always read the upgrade notes first in the future. All of the notes from older stable release notes [1] will help you to perform the upgrade without any major issue. Of course there could be some differences, but none which will lead to unaccessible server. [1] http://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html -- Peter -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51015ffd.1080...@gmail.com
Re: 32-bit to 64-bit
On Thu, Jan 24, 2013 at 7:58 AM, Mark Allums wrote: > > > The third bit is the hard part. I am wondering if I should go from lucid to > precise first, or do the 32/64-bit trick first. Or is there a way to do > both at once? If I package it into a virtual machine instance, first, then I > can snapshot along the way. I can revert the snapshot if I screw it up, and > start over. Also, I can then deploy the newly refurbished system as a > student virtual machine. I want to go back to native-on-bare-metal, there > are ways to do that, too. > > The scenario is relevant for Debian-User because I want to do something > similar with other (Debian) machines and because this is a learning > experience for me, and others reading this list might gain something useful > as well. I would definitely upgrade first, then try to change arch. Does Lucid even have multiarch? Anyway, even if it did, it would be better in Precise. And don't try both at once! In fact break into as many pieces as possible, I would say. And don't try to rely on the apt/aptitude auto-solver. I would just use aptitude in interactive mode and manually resolve issues. Cheers, Kelly Clowers -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAFoWM=-clxhii9gv4z_eupj9glfem_pn62ox7deld76ut_x...@mail.gmail.com
Re: 32-bit to 64-bit
On Thu, Jan 24, 2013 at 6:51 AM, Sven Joachim wrote: > > There are two problems with that: > > - Not all packages have been multiarchified, including some important > packages with many reverse dependencies like perl and python. > Crossgrading those will leave you with many broken packages, at least > temporarily. Cross your fingers that apt will show a way out. > > - Apt does not properly support crossgrades, for a package foo which is > not "Multi-Arch: same" it treats foo:i386 and foo:amd64 as two > different, conflicting packages. This means that it will remove > foo:i386 before installing foo:amd64 which obviously does not work for > Essential packages, so you have to crossgrade those with dpkg alone. > This is quite a hassle since you have to install all necessary > libraries beforehand. > > I have crossgraded some packages in i386 chroots that way, but in the > current state of affairs I would definitely _not_ dare to try a full > crossgrade on my main system with almost 2000 installed packages. I bet it is doable. I wish I had a 32 bit system to try it on, I love doing crazy things with the package manager, like when I combined significant parts of Ubuntu (X and GTK) into my Debian install, and later transitioned back to pure Debian. Cheers, Kelly Clowers -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAFoWM=_v_aSH_Nf5z=8bt0qn1cceman0xl9tr872y2w3efd...@mail.gmail.com
RE: 32-bit to 64-bit
From: Sven Joachim [mailto:svenj...@gmx.de] > On 2013-01-24 14:51 +0100, Mark Allums wrote: > > > Can one do this? Not: Is this easy, but merely: Is this something that is > > feasible? > > > > I have a 32-bit system that I would like to migrate into 64-bitness within > > the same basic framework, within the same "install". That is, can I go from > > > > 32-bit kernel-arch + 32-bit userland => > > 64-bit kernel-arch + 32-bit userland => > > This works just fine (with a few caveats, e.g. virtualbox does _not_ > work with this combination), just install and boot a linux-image-*-amd64 > kernel. I've been running that combination for years. > > > 64-bit kernel-arch + 64-bit userland > > > > within Debian Squeeze or Wheezy, or Bodhi Lucid or Precise? Without a > clean > > install? > > No, this is not really possible, at least not without a high risk of > totally breaking your system. What you _can_ do to minimize downtime is > to run "debootstrap --arch=amd64" in a dedicated filesystem and then > install the same packages as on your i386 system in the chroot (export > the list on i386 with "dpkg --get-selections" and import it on amd64 > with "dpkg --set-selections"), and then copy over your /etc directory > (you need to adapt fstab of course, but no other changes should be > necessary). > > Then you should be able to dual-boot the i386 and amd64 installations, > and you can dispose of the i386 one when you no longer need it. > > > I was thinking that multiarch might help this happen. > > There are two problems with that: > > - Not all packages have been multiarchified, including some important > packages with many reverse dependencies like perl and python. > Crossgrading those will leave you with many broken packages, at least > temporarily. Cross your fingers that apt will show a way out. > > - Apt does not properly support crossgrades, for a package foo which is > not "Multi-Arch: same" it treats foo:i386 and foo:amd64 as two > different, conflicting packages. This means that it will remove > foo:i386 before installing foo:amd64 which obviously does not work for > Essential packages, so you have to crossgrade those with dpkg alone. > This is quite a hassle since you have to install all necessary > libraries beforehand. > > I have crossgraded some packages in i386 chroots that way, but in the > current state of affairs I would definitely _not_ dare to try a full > crossgrade on my main system with almost 2000 installed packages. Let me give you a scenario. I have a lightweight system using Bodhi 1.x. It has a single disk with no swap in a single partition. I can virtualize it easily. Similar virtual machines are used in a classroom situation, thanks to the simplicity of Virtualbox. Bohdi is the choice because it is based on Ubuntu, but uses Enlightenment to help keep it lean enough to download and install in a virtual machine for a class without dedicating a whole machine to something that you only need for that one class. People can do their homework at home. The professor can set up a special environment that allow everyone to use the same thing and minimize frustration. I want to preserve the environment as much as possible, but 1.) resize the disk image and add swap and a separate /boot and /home partition 2.) upgrade Bohdi to 2.2.x 3.) move from 32-bit to 64-bit. The first I can easily do, disks and partitions are child's play, these days (back up your data!). No. 2, I can do, it is a bit tricky, but it is similar to upgrading Ubuntu. To do it, you can install more Ubuntu infrastructure and use the upgrader, do simply do it the Debian Way, with apt-get upgrade, apt-get dist-upgrade, etc. The third bit is the hard part. I am wondering if I should go from lucid to precise first, or do the 32/64-bit trick first. Or is there a way to do both at once? If I package it into a virtual machine instance, first, then I can snapshot along the way. I can revert the snapshot if I screw it up, and start over. Also, I can then deploy the newly refurbished system as a student virtual machine. I want to go back to native-on-bare-metal, there are ways to do that, too. The scenario is relevant for Debian-User because I want to do something similar with other (Debian) machines and because this is a learning experience for me, and others reading this list might gain something useful as well. Mark -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/005501cdfa4b$b5b19de0$2114d9a0$@allums.com
Re: moving from Kubuntu 10.4 to squeeze
Le Jeu 24 janvier 2013 16:05, Mike McGinn a écrit : > I am happy with what I have experienced > in my VM and I just want to know if there are any pitfalls I have not > foreseen. The only one I can see outside of system being configured differently by default is the hardware support. Using a live debian or a dual boot in first times to ensure everything is still working correctly sounds wise. Welcome to Debian :) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/26d6cd333ada7ec65606f234c1b88b98.squir...@www.sud-ouest.org
Re: 32-bit to 64-bit
On 24/01/13 09:51 AM, Sven Joachim wrote: On 2013-01-24 14:51 +0100, Mark Allums wrote: Can one do this? Not: Is this easy, but merely: Is this something that is feasible? I have a 32-bit system that I would like to migrate into 64-bitness within the same basic framework, within the same "install". That is, can I go from 32-bit kernel-arch + 32-bit userland => 64-bit kernel-arch + 32-bit userland => This works just fine (with a few caveats, e.g. virtualbox does _not_ work with this combination), just install and boot a linux-image-*-amd64 kernel. I've been running that combination for years. 64-bit kernel-arch + 64-bit userland within Debian Squeeze or Wheezy, or Bodhi Lucid or Precise? Without a clean install? No, this is not really possible, at least not without a high risk of totally breaking your system. What you _can_ do to minimize downtime is to run "debootstrap --arch=amd64" in a dedicated filesystem and then install the same packages as on your i386 system in the chroot (export the list on i386 with "dpkg --get-selections" and import it on amd64 with "dpkg --set-selections"), and then copy over your /etc directory (you need to adapt fstab of course, but no other changes should be necessary). Then you should be able to dual-boot the i386 and amd64 installations, and you can dispose of the i386 one when you no longer need it. I was thinking that multiarch might help this happen. There are two problems with that: - Not all packages have been multiarchified, including some important packages with many reverse dependencies like perl and python. Crossgrading those will leave you with many broken packages, at least temporarily. Cross your fingers that apt will show a way out. - Apt does not properly support crossgrades, for a package foo which is not "Multi-Arch: same" it treats foo:i386 and foo:amd64 as two different, conflicting packages. This means that it will remove foo:i386 before installing foo:amd64 which obviously does not work for Essential packages, so you have to crossgrade those with dpkg alone. This is quite a hassle since you have to install all necessary libraries beforehand. I have crossgraded some packages in i386 chroots that way, but in the current state of affairs I would definitely _not_ dare to try a full crossgrade on my main system with almost 2000 installed packages. Cheers, Sven You're being a little pessimistic. The conflicting "esssential" packages are handled in the "essentials" part of the upgrade. With a functioning AMD64 base system, you have a safe way to continue the upgrade. Booting from a live CD and chrooting into the new system should let you recover from most disasters. While you may find it necessary to install some packages with dpkg, apt-get with -f can fix any partial installs that need missing packages. You don't need to install all the dependencies manually. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51014e85.2040...@rogers.com
moving from Kubuntu 10.4 to squeeze
I have a Dell Inspiron 1545 laptop with 4G of RAM and have been a 'buntu user since release 7.04. With each release of the new OS from Kubuntu I have been less and less happy with the so called "quality" and I am planning a move to Debian. As a Kontact user the problems reported with the new versions of that particular package are dictating the move to Squeeze. (I subscribe to both the kde-pim users and developers mail lists.) I have been experimenting with an installation in a virtual machine and I am getting ready to make the jump. I am happy with what I have experienced in my VM and I just want to know if there are any pitfalls I have not foreseen. My system is backed up every night, so I am not worried about losing anything. -- Mike McGinn KD2CNU Ex Uno Plurima No electrons were harmed in sending this message, some were inconvenienced. ** Registered Linux User 377849 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201301241005.00329.mikemcg...@mcginnweb.net
Re: [1/2OT] the stat "D"
> > Last night I spent some time to check the "D" stat. > It's kinda of tricky, why my intuition tells me that those jobs run in > foreground, not background, won't have such problem. "In particular, users are asked to run only one background job at a time." from http://www.washington.edu/computing/unix/background.html now I know why there are so many "D" for those background jobs. if I am wrong, please let me know, Thanks, -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51014b10.5040...@gmail.com
Re: 32-bit to 64-bit
On 2013-01-24 14:51 +0100, Mark Allums wrote: > Can one do this? Not: Is this easy, but merely: Is this something that is > feasible? > > I have a 32-bit system that I would like to migrate into 64-bitness within > the same basic framework, within the same "install". That is, can I go from > > 32-bit kernel-arch + 32-bit userland => > 64-bit kernel-arch + 32-bit userland => This works just fine (with a few caveats, e.g. virtualbox does _not_ work with this combination), just install and boot a linux-image-*-amd64 kernel. I've been running that combination for years. > 64-bit kernel-arch + 64-bit userland > > within Debian Squeeze or Wheezy, or Bodhi Lucid or Precise? Without a clean > install? No, this is not really possible, at least not without a high risk of totally breaking your system. What you _can_ do to minimize downtime is to run "debootstrap --arch=amd64" in a dedicated filesystem and then install the same packages as on your i386 system in the chroot (export the list on i386 with "dpkg --get-selections" and import it on amd64 with "dpkg --set-selections"), and then copy over your /etc directory (you need to adapt fstab of course, but no other changes should be necessary). Then you should be able to dual-boot the i386 and amd64 installations, and you can dispose of the i386 one when you no longer need it. > I was thinking that multiarch might help this happen. There are two problems with that: - Not all packages have been multiarchified, including some important packages with many reverse dependencies like perl and python. Crossgrading those will leave you with many broken packages, at least temporarily. Cross your fingers that apt will show a way out. - Apt does not properly support crossgrades, for a package foo which is not "Multi-Arch: same" it treats foo:i386 and foo:amd64 as two different, conflicting packages. This means that it will remove foo:i386 before installing foo:amd64 which obviously does not work for Essential packages, so you have to crossgrade those with dpkg alone. This is quite a hassle since you have to install all necessary libraries beforehand. I have crossgraded some packages in i386 chroots that way, but in the current state of affairs I would definitely _not_ dare to try a full crossgrade on my main system with almost 2000 installed packages. Cheers, Sven -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zjzy3a7v@turtle.gmx.de
Re: 32-bit to 64-bit
On 24/01/13 09:35 AM, Mark Allums wrote: From: Gary Dale [mailto:garyd...@rogers.com] I have a 32-bit system that I would like to migrate into 64-bitness within the same basic framework, within the same "install". That is, can I go from 32-bit kernel-arch + 32-bit userland => 64-bit kernel-arch + 32-bit userland => 64-bit kernel-arch + 64-bit userland within Debian Squeeze or Wheezy, or Bodhi Lucid or Precise? Advice? Yes. You can add the AMD64 architecture then install an AMD64 kernel, reboot into it and you're running a 64bit system. I suspect there is more to it than that, but I've done it in the past and it did give me a bootable 64bit system. From: Darac Marjal [mailto:mailingl...@darac.org.uk] Because this web page could do with more promotion: http://wiki.debian.org/FAQsFromDebianUser?highlight=%28debian-user%29#Are_cr oss-grades_possible.3F Thank you both. Is good to know. Does anyone have any recent, direct experience doing this? What are the pitfalls? You may be running more 32bit software than you would if you had done a clean install. Also, clean installs are generally (as the name suggests) cleaner than upgrades. There may be some unnecessary files hanging around on your hard drive that aren't really needed in the new architecture. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/510149cd.7010...@rogers.com
RE: 32-bit to 64-bit
> From: Gary Dale [mailto:garyd...@rogers.com] > > I have a 32-bit system that I would like to migrate into 64-bitness within > > the same basic framework, within the same "install". That is, can I go from > > > > 32-bit kernel-arch + 32-bit userland => > > 64-bit kernel-arch + 32-bit userland => > > 64-bit kernel-arch + 64-bit userland > > > > within Debian Squeeze or Wheezy, or Bodhi Lucid or Precise? > > > > Advice? > Yes. You can add the AMD64 architecture then install an AMD64 kernel, > reboot into it and you're running a 64bit system. > > I suspect there is more to it than that, but I've done it in the past > and it did give me a bootable 64bit system. > From: Darac Marjal [mailto:mailingl...@darac.org.uk] > Because this web page could do with more promotion: http://wiki.debian.org/FAQsFromDebianUser?highlight=%28debian-user%29#Are_cr oss-grades_possible.3F Thank you both. Is good to know. Does anyone have any recent, direct experience doing this? What are the pitfalls? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/005101cdfa40$10d778e0$32866aa0$@allums.com
Re: 32-bit to 64-bit
On 24/01/13 08:51 AM, Mark Allums wrote: Can one do this? Not: Is this easy, but merely: Is this something that is feasible? I have a 32-bit system that I would like to migrate into 64-bitness within the same basic framework, within the same "install". That is, can I go from 32-bit kernel-arch + 32-bit userland => 64-bit kernel-arch + 32-bit userland => 64-bit kernel-arch + 64-bit userland within Debian Squeeze or Wheezy, or Bodhi Lucid or Precise? Without a clean install? I was thinking that multiarch might help this happen. Advice? Yes. You can add the AMD64 architecture then install an AMD64 kernel, reboot into it and you're running a 64bit system. I suspect there is more to it than that, but I've done it in the past and it did give me a bootable 64bit system. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51014038.40...@rogers.com
Re: 32-bit to 64-bit
On Thu, Jan 24, 2013 at 07:51:19AM -0600, Mark Allums wrote: > Can one do this? Not: Is this easy, but merely: Is this something that is > feasible? > > I have a 32-bit system that I would like to migrate into 64-bitness within > the same basic framework, within the same "install". That is, can I go from > > 32-bit kernel-arch + 32-bit userland => > 64-bit kernel-arch + 32-bit userland => > 64-bit kernel-arch + 64-bit userland > > within Debian Squeeze or Wheezy, or Bodhi Lucid or Precise? Without a clean > install? > > I was thinking that multiarch might help this happen. Because this web page could do with more promotion: http://wiki.debian.org/FAQsFromDebianUser?highlight=%28debian-user%29#Are_cross-grades_possible.3F signature.asc Description: Digital signature
32-bit to 64-bit
Can one do this? Not: Is this easy, but merely: Is this something that is feasible? I have a 32-bit system that I would like to migrate into 64-bitness within the same basic framework, within the same "install". That is, can I go from 32-bit kernel-arch + 32-bit userland => 64-bit kernel-arch + 32-bit userland => 64-bit kernel-arch + 64-bit userland within Debian Squeeze or Wheezy, or Bodhi Lucid or Precise? Without a clean install? I was thinking that multiarch might help this happen. Advice? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/004001cdfa39$e3eb9740$abc2c5c0$@allums.com
Upgrade from stable to testing hosed my server
I used aptitude to upgrade a headless server from Debian stable to Debian testing. The upgrade did not generate any error messages, but when I rebooted I could not ssh into the box (connection refused) nor do I get any output on a monitor I attached to the box (no signal). Apache does not appear to be running either on the box (could not connect to the box). I can successfully ping the box. Any suggestions on how to fix this this server would be greatly appreciated! Thanks, Mark
Re: multiple nic/IP in firewall
On Wed, Jan 23, 2013 at 9:45 PM, Tom Furie wrote: > On Tue, Jan 22, 2013 at 07:54:25PM -0300, Roberto Scattini wrote: > > > ~# route -n > > Kernel IP routing table > > Destination Gateway Genmask Flags Metric RefUse > > Iface > > XX.220.XX.176 0.0.0.0 255.255.255.255 UH0 00 > eth3 > > YY.20.YY.0 0.0.0.0 255.255.255.255 UH0 00 > eth4 > > XX.220.XX.176 0.0.0.0 255.255.255.252 U 0 00 > eth3 > > 192.168.100.0 0.0.0.0 255.255.255.0 U 0 00 > eth2 > > YY.20.YY.0 0.0.0.0 255.255.255.0 U 0 00 > eth4 > > 0.0.0.0 XX.220.XX.177 0.0.0.0 UG0 00 > eth3 > > I just noticed here, that your YY traffic is being routed over your > default gateway, that should probably have a next hop specific to that > network. You also probably want to remove the YY.20.YY.0 host route. > > This might not solve the whole problem, but it will get some of it out > of the way. > > i dont fully understand what nexthop means... previously carlos recommended this line: ip route add default scope global nexthop via XX.220.XX.177 dev eth3 weight 1 nexthop via YY.20.YY.Y dev eth4 weight 1 sadly, i tried but it didnt work. i find iproute docs a little criptic,if someone could explain me what is the meaning of the words "default scope global nexthop" maybe i can get it working... i will continue with my research... -- Roberto Scattini
Re: [1/2OT] the stat "D"
On Thursday 24,January,2013 06:35 PM, Sven Joachim wrote:
> On 2013-01-24 10:34 +0100, lina wrote:
>
>> I have some process if run in background, it always very slow, like:
>>
>> $ ps f | awk '{print $1, $2,$3,$4, $5}'
>>
>> 124201 pts/13 Ss+ 0:00 -bash
>> 29572 pts/116 Ss+ 0:00 -bash
>> 29275 pts/63 Ss+ 0:00 -bash
>> 22080 pts/14 Ss+ 0:00 -bash
>> 11581 pts/2 Ss 0:00 -bash
>> 2920 pts/2 R+ 0:00 \_
>> 2921 pts/2 S+ 0:00 \_
>> 2922 pts/2 S+ 0:00 \_
>> 108014 pts/13 D 3:16 cal_dist
>> 108013 pts/13 D 3:17 cal_dist
>> 108012 pts/13 D 2:57 cal_dist
>> 108011 pts/13 D 3:00 cal_dist
>> 108010 pts/13 D 3:17 cal_dist
>> 108009 pts/13 D 3:18 cal_dist
>> 108008 pts/13 D 3:15 cal_dist
>> 108007 pts/13 D 3:00 cal_dist
>> 108006 pts/13 D 3:15 cal_dist
>> 108005 pts/13 D 3:16 cal_dist
>> 108004 pts/13 D 3:16 cal_dist
>> 108003 pts/13 D 3:16 cal_dist
>> 108002 pts/13 D 3:16 cal_dist
>> 108001 pts/13 D 3:16 cal_dist
>> 108000 pts/13 D 3:16 cal_dist
>> 107999 pts/13 D 3:16 cal_dist
>>
>> I use something like
>>
>> echo"1
>> 2" > idx.txt
>>
>> for i in `seq w 1 1 16`
>
> This is not a valid call of seq, you probably meant `seq -w 1 1 16`
> instead.
Typo here, haha ... thanks,
>
>> do
>>
>> cal_dist -i $i.in -o $i.out < idx.txt &
>>
>> done
>
> I have no idea what cal_dist is or does, but the processes are in state
> "uninterruptible sleep" (that's what D stands for), i.e. they are
> waiting for system calls to complete. Typically the only syscalls that
> take any noticeable time are related to I/O, so most likely the
> processes are waiting for your hard disk to deliver data from the $i.in
> files. Or they are doing lots of fsync(2) calls on the $i.out files
> which can cause a dramatic slowdown on some filesystems.
Last night I spent some time to check the "D" stat.
It's kinda of tricky, why my intuition tells me that those jobs run in
foreground, not background, won't have such problem.
Perhaps that's why I wish to run in foreground, I am not so familiar
with "make j" in this situation, neither familiar with the xargs.
>
> Cheers,
>Sven
>
>
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/510127d0.9000...@gmail.com
Re: Installing flash player into user's home dir. for chromium.
Hello, 2013/1/18 Patrick Bartek > > > From: Sthu Deus > > To: debian-user@lists.debian.org > > >> > > > >> Check if the user home directory has a hidden .moziila/plugins > >> directory. This is one of several defaults that browsers search for > >> plugins. If not, add it, place the flash player plugin in it and see > >> what happens. > > > > I've downloaded the .tar.gz player, finally I got: > > > > ~/.moziila/plugins/libflashplayer.so > > > > But chromium still asks for new version of FlashPlayer. > > > This is a guess: Maybe, Chromium doesn't look there for plugins. Perhaps > there is a way to tell Chromium where to look. I don't know. Check the user > manual or contact the developer directly. I've always put plugins, > regardless of the browser, in /usr/lib/mozilla/plugins for 32-bit systems and > 32-bit plugins, or /usr/lib64/mozilla/plugins for 64-bit systems and 64-bit > plugins. > Chrome has its own version of the Adobe Flash player. On my Fedora17 box it belongs to the google-chrome-stable package: $ locate flash | grep \.so$ | grep -v BAK /opt/google/chrome/PepperFlash/libpepflashplayer.so /usr/lib/flash-plugin/libflashplayer.so /usr/lib/kde4/kcm_adobe_flash_player.so /usr/lib/libreoffice/program/libflashlo.so /usr/lib/mozilla/plugins/libflashplayer.so $ rpm -qf /opt/google/chrome/PepperFlash/libpepflashplayer.so google-chrome-stable-24.0.1312.52-175374.i386 Regards, Roland -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/calk2krwjq_sum9z4bjjb6gsm9t3qevzgaqik0yhecemo05l...@mail.gmail.com
Re: [1/2OT] the stat "D"
On 2013-01-24 10:34 +0100, lina wrote:
> I have some process if run in background, it always very slow, like:
>
> $ ps f | awk '{print $1, $2,$3,$4, $5}'
>
> 124201 pts/13 Ss+ 0:00 -bash
> 29572 pts/116 Ss+ 0:00 -bash
> 29275 pts/63 Ss+ 0:00 -bash
> 22080 pts/14 Ss+ 0:00 -bash
> 11581 pts/2 Ss 0:00 -bash
> 2920 pts/2 R+ 0:00 \_
> 2921 pts/2 S+ 0:00 \_
> 2922 pts/2 S+ 0:00 \_
> 108014 pts/13 D 3:16 cal_dist
> 108013 pts/13 D 3:17 cal_dist
> 108012 pts/13 D 2:57 cal_dist
> 108011 pts/13 D 3:00 cal_dist
> 108010 pts/13 D 3:17 cal_dist
> 108009 pts/13 D 3:18 cal_dist
> 108008 pts/13 D 3:15 cal_dist
> 108007 pts/13 D 3:00 cal_dist
> 108006 pts/13 D 3:15 cal_dist
> 108005 pts/13 D 3:16 cal_dist
> 108004 pts/13 D 3:16 cal_dist
> 108003 pts/13 D 3:16 cal_dist
> 108002 pts/13 D 3:16 cal_dist
> 108001 pts/13 D 3:16 cal_dist
> 108000 pts/13 D 3:16 cal_dist
> 107999 pts/13 D 3:16 cal_dist
>
> I use something like
>
> echo"1
> 2" > idx.txt
>
> for i in `seq w 1 1 16`
This is not a valid call of seq, you probably meant `seq -w 1 1 16`
instead.
> do
>
> cal_dist -i $i.in -o $i.out < idx.txt &
>
> done
I have no idea what cal_dist is or does, but the processes are in state
"uninterruptible sleep" (that's what D stands for), i.e. they are
waiting for system calls to complete. Typically the only syscalls that
take any noticeable time are related to I/O, so most likely the
processes are waiting for your hard disk to deliver data from the $i.in
files. Or they are doing lots of fsync(2) calls on the $i.out files
which can cause a dramatic slowdown on some filesystems.
Cheers,
Sven
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d2wu50nb@turtle.gmx.de
Re: [1/2OT] the stat "D"
On Thursday 24,January,2013 05:34 PM, lina wrote:
> Hi,
>
> I have some process if run in background, it always very slow, like:
>
> $ ps f | awk '{print $1, $2,$3,$4, $5}'
>
> 124201 pts/13 Ss+ 0:00 -bash
> 29572 pts/116 Ss+ 0:00 -bash
> 29275 pts/63 Ss+ 0:00 -bash
> 22080 pts/14 Ss+ 0:00 -bash
> 11581 pts/2 Ss 0:00 -bash
> 2920 pts/2 R+ 0:00 \_
> 2921 pts/2 S+ 0:00 \_
> 2922 pts/2 S+ 0:00 \_
> 108014 pts/13 D 3:16 cal_dist
> 108013 pts/13 D 3:17 cal_dist
> 108012 pts/13 D 2:57 cal_dist
> 108011 pts/13 D 3:00 cal_dist
> 108010 pts/13 D 3:17 cal_dist
> 108009 pts/13 D 3:18 cal_dist
> 108008 pts/13 D 3:15 cal_dist
> 108007 pts/13 D 3:00 cal_dist
> 108006 pts/13 D 3:15 cal_dist
> 108005 pts/13 D 3:16 cal_dist
> 108004 pts/13 D 3:16 cal_dist
> 108003 pts/13 D 3:16 cal_dist
> 108002 pts/13 D 3:16 cal_dist
> 108001 pts/13 D 3:16 cal_dist
> 108000 pts/13 D 3:16 cal_dist
> 107999 pts/13 D 3:16 cal_dist
>
> I use something like
>
> echo"1
> 2" > idx.txt
>
> for i in `seq w 1 1 16`
> do
>
> cal_dist -i $i.in -o $i.out < idx.txt &
>
> done
The xargs alternative is something like:
$ seq -w 1 1 16 | xargs -n 1 -P 8 -I A cal_dist ../../dist_A.out
But there is a problem, I need to select the idx.txt, namely pick "1
2" in prompt during the running of cal_dist, but I am a bit stuck with
this.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5101070c.7020...@gmail.com
Re: [1/2OT] the stat 'D'
> I am new to the xargs, so I don't know how to let it run in background. > The waiting is going to kill me, I mean so slow. > > > Thanks ahead for your suggestions, No idea about what is xargs, but I guess that simply calling your script from a console with a '&' at end of command will be ok, aka "$myscript.sh &" -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/0950073b1f30cbbdeb01eb6542c7a6b0.squir...@www.sud-ouest.org
Re: What happens when you upgrade a package with modified config files?
On Wednesday 23 January 2013 16:58:52 Karl E. Jorgensen wrote: > > But I cannot push this further all by myself. > > Poke the individual Debian maintainers - they're smart people :-) They are also busy people. They will be more likely to move if *their* users are complaining ;-) , or even better, helping. > > [1] http://wiki.debian.org/PackageConfigUpgrade > > Yes - unfortunately the formats of configuration files vary (wildly) > between different software packages, so I doubt that a > one-size-fits-all solution is viable. Perhaps Config::Model should > use a plugin-structure for different config file formats? It's already a pluging structure: to support foobar style format, you'd have to write a Config::Model::Backend::FooBar class. See for instance the OpenSsh backend [1] > I've seen other debian packages migrate config files (cannot remember > which ones off the top of my head), and in those cases the > installation explicitly asked for permission to rewrite the config > file [1]. I think that could be arranged either in the postinst snippet injected by dh_config_model_upgrade or by a specific cme option (or both). > This still leaves the problem with non-trivial upgrades, e.g. where > nearly everything has been refactored between versions, and no > sensible defaults are possible for (some) configuration variables in > the new version. So a 100% automatic migration is probably not > possible. 99% may be possible though. It depends. Agreed. All the best [1] https://github.com/dod38fr/config-model- openssh/tree/master/lib/Config/Model/Backend -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201301241034.14353@debian.org
Re: [1/2OT] the stat "D"
> > I am new to the xargs, so I don't know how to let it run in background. typo, *not* run in background. Thanks, -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51010050.2070...@gmail.com
[1/2OT] the stat "D"
Hi,
I have some process if run in background, it always very slow, like:
$ ps f | awk '{print $1, $2,$3,$4, $5}'
124201 pts/13 Ss+ 0:00 -bash
29572 pts/116 Ss+ 0:00 -bash
29275 pts/63 Ss+ 0:00 -bash
22080 pts/14 Ss+ 0:00 -bash
11581 pts/2 Ss 0:00 -bash
2920 pts/2 R+ 0:00 \_
2921 pts/2 S+ 0:00 \_
2922 pts/2 S+ 0:00 \_
108014 pts/13 D 3:16 cal_dist
108013 pts/13 D 3:17 cal_dist
108012 pts/13 D 2:57 cal_dist
108011 pts/13 D 3:00 cal_dist
108010 pts/13 D 3:17 cal_dist
108009 pts/13 D 3:18 cal_dist
108008 pts/13 D 3:15 cal_dist
108007 pts/13 D 3:00 cal_dist
108006 pts/13 D 3:15 cal_dist
108005 pts/13 D 3:16 cal_dist
108004 pts/13 D 3:16 cal_dist
108003 pts/13 D 3:16 cal_dist
108002 pts/13 D 3:16 cal_dist
108001 pts/13 D 3:16 cal_dist
108000 pts/13 D 3:16 cal_dist
107999 pts/13 D 3:16 cal_dist
I use something like
echo"1
2" > idx.txt
for i in `seq w 1 1 16`
do
cal_dist -i $i.in -o $i.out < idx.txt &
done
I am new to the xargs, so I don't know how to let it run in background.
The waiting is going to kill me, I mean so slow.
Thanks ahead for your suggestions,
Best regards,
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5101000a.8040...@gmail.com
Re: MPD and Last.FM, not connecting or working.
Good time of the day, Morel. Thank You, Morel, for Your time and answer. You wrote: > > though it is a bit hard - as diver > > dependencies of source packages should be satisfied before compiling > > # aptitude build-dep mpd > > This one is quite useful to avoid lack of dependencies when trying to > compile something which is already in Debian's repo. > Of course, if mainstream deps have changed, you will have some > tinkering to do, but I do not think it is highly probable, since > there is no recent major version change. It is great! I will save the trick for some future! Sthu. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5100f777.e17c980a.04b5.f...@mx.google.com
Re: MPD and Last.FM, not connecting or working.
> though it is a bit hard - as diver > dependencies of source packages should be satisfied before compiling # aptitude build-dep mpd This one is quite useful to avoid lack of dependencies when trying to compile something which is already in Debian's repo. Of course, if mainstream deps have changed, you will have some tinkering to do, but I do not think it is highly probable, since there is no recent major version change. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e3ba33b15654d4711eda78b352572e83.squir...@www.sud-ouest.org
