Re: [arch-general] New Conflict on System Upgrade - license? pear? vi?

[Allan McRae]

David C. Rankin wrote:

On Saturday 20 June 2009 06:55:24 pm Thomas Bächler wrote:
  

David C. Rankin schrieb:


Listmates,

	Here are some strange conflicts found during an attempted system update. 
Thankfully they are limited to the license package, pear and vi:


(269/269) checking for file conflicts   
[#] 100%
error: could not prepare transaction
error: failed to commit transaction (conflicting files) 
licenses: /usr/share/licenses/common/FDL exists in filesystem   
licenses: /usr/share/licenses/common/GPL exists in filesystem   
licenses: /usr/share/licenses/common/GPL2/license.txt exists in filesystem  
licenses: /usr/share/licenses/common/LGPL exists in filesystem  
  
This is a pacman bug where it finds false conflicts when there is a 
symlink to a directory in the old package and a directory in the new one 
(or the other way around, I don't remember).
I thought the package was supposed to be fixed, but apparently it 
wasn't. -Sf licenses.



php: /usr/share/pear/.registry/xml_util.reg exists in filesystem
  

[...]

No idea about php.


vi: /usr/bin/view exists in filesystem  
  
I had this more than once, no idea what causes it, but you can simply rm 
/usr/bin/view and then update.



	I guess these are left overs from the earlier forced kde-unstable install. 
  

I don't think that is the case.


I'll try an uninstall of the packages and then a reinstall and see how it 
goes...
  

That should work, too.





For the license package, I just uninstalled it, and it reinstalled 
without issue. For all the pear packages, pacman said nobody owned them and 
that pear wasn't installed. I just created a temporary directory and moved all 
the conflicting pear packages to the temp directory (with their original 
directory structure in place in case I needed to restore them) and then did the 
system update again and it worked fine.
  


Already done.

man pacman.conf:
  UseDelta
  Download delta files instead of complete packages if possible.
  Requires the xdelta program to be installed.

Re: [arch-general] Presto for pacman?

[David C. Rankin]

On Monday 22 June 2009 03:09:14 am Allan McRae wrote:
> Magnus Therning wrote:
> > Is there something similar to Yum Presto[1] for pacman?
> >
> > Would it be possible to do, or are there limitations in the package
> > format that prevents it?
> >
> > /M
> >
> > [1]: http://fedoraproject.org/wiki/Features/Presto
> >   
> 
> This is already implemented in the unreleased pacman codebase.  Once 
> this gets released we need to figure out how to deal with this from the 
> package distribution side.
> 
> Allan
> 
> 
> 
> 

Excellent,

Two thoughts. (1) delta rpms are great for download size, but 
computationally expensive on the client side for reinstalls or multiple machine 
updates, so (2) if possible, can an option be retained to enable/disable use of 
deltarpms for folks that would like to have full packages?

-- 
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com

Re: [arch-general] New Conflict on System Upgrade - license? pear? vi?

[David C. Rankin]

On Saturday 20 June 2009 06:55:24 pm Thomas Bächler wrote:
> David C. Rankin schrieb:
> > Listmates,
> > 
> > Here are some strange conflicts found during an attempted system 
> > update. 
> > Thankfully they are limited to the license package, pear and vi:
> > 
> > (269/269) checking for file conflicts   
> > [#] 100%
> > error: could not prepare transaction
> > 
> > error: failed to commit transaction (conflicting files) 
> > 
> > licenses: /usr/share/licenses/common/FDL exists in filesystem   
> > 
> > licenses: /usr/share/licenses/common/GPL exists in filesystem   
> > 
> > licenses: /usr/share/licenses/common/GPL2/license.txt exists in filesystem  
> > 
> > licenses: /usr/share/licenses/common/LGPL exists in filesystem  
> > 
> 
> This is a pacman bug where it finds false conflicts when there is a 
> symlink to a directory in the old package and a directory in the new one 
> (or the other way around, I don't remember).
> I thought the package was supposed to be fixed, but apparently it 
> wasn't. -Sf licenses.
> 
> > php: /usr/share/pear/.registry/xml_util.reg exists in filesystem
> > 
> [...]
> 
> No idea about php.
> 
> > vi: /usr/bin/view exists in filesystem  
> > 
> 
> I had this more than once, no idea what causes it, but you can simply rm 
> /usr/bin/view and then update.
> 
> > I guess these are left overs from the earlier forced kde-unstable 
> > install. 
> 
> I don't think that is the case.
> 
> > I'll try an uninstall of the packages and then a reinstall and see how it 
> > goes...
> 
> That should work, too.
> 
> 

For the license package, I just uninstalled it, and it reinstalled 
without issue. For all the pear packages, pacman said nobody owned them and 
that pear wasn't installed. I just created a temporary directory and moved all 
the conflicting pear packages to the temp directory (with their original 
directory structure in place in case I needed to restore them) and then did the 
system update again and it worked fine.




-- 
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com

Re: [arch-general] vi from testing has gone nuts - does not honor virc/~.virc settings

[David C. Rankin]

On Monday 22 June 2009 03:05:29 pm David C. Rankin wrote:
> On Monday 22 June 2009 11:06:37 am David Rosenstrauch wrote:
> > David C. Rankin wrote:
> > > Listmates, Devs:
> > >
> > >   I upgraded to testing to test the new dmraid.
> >
> > Just my personal opinion here, and perhaps the devs will disagree, but
> > personally I wouldn't suggest upgrading your entire box to testing.  If
> > you only want to kick the tires on one package from testing, then
> > probably best to only install that.
> >
> > One of the things I like about Arch is how it keeps me on the cutting
> > edge with very up-to-date versions of all the packages, but still
> > manages to keep my system very stable.  IMO, if you bump everything up
> > to testing, you're going to lose a lot of that wonderful stability.
> >
> > DR
> 
> 
> Thanks DR,
> 
>   I think I will work my way back out of [testing] while leaving dmraid 
> 1.0.15rc intact.
> 
> 

Disabling [testing] in pacman.conf and downgrading vi to 7.2.65-1 solved the 
problem.


-- 
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com

Re: [arch-general] Fwd: Re: dmraid-1.0.0rc15 in testing, need you help on this! (possible Bug on Delete)

[David C. Rankin]

On Monday 22 June 2009 02:56:17 pm Jan de Groot wrote:
> On Mon, 2009-06-22 at 14:48 -0500, David C. Rankin wrote:
> > Huh??? Why wasn't nvidia_ecaejfdip9 deactivated. I have
> > deleted the partition 
> > in cfdisk, tried to activate it (y) and deactivate it (n) and still it
> > is 
> > there. Is this a bug? Or do I need to erase the metadata in some other
> > way??
> 
> You could try to force a re-read on the partition tables of the real
> harddisks at /dev/sda and /dev/sdb using hdparm. After that, try
> re-activating dmraid.
> 
> 

dmsetup remove nvidia_ecaejfdip9

Did the trick. (Thanks to the developer pointing me in the right 
direction. All in all dmraid 1.0.0.rc15-6 seems to be working great on Arch. 
Great job Tobias!

-- 
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com

Re: [arch-general] Holy Cow -- What happened to bash / vi??

[Gerardo Exequiel Pozzi]

David C. Rankin wrote:


>   I get this new message:
>
> [00:08 archangel:/etc] # noc fstab
> bash: /usr/local/bin/noc: /bin/bash: bad interpreter: Text file busy
>
>   

>   Text file busy?? It's a text file, it's not busy, it's either saved or 
> you 
> get what was present the last time it was saved, but it certainly isn't busy.
>
>   


"Text file busy" is not related with text files :)

Text refers to the "text section" of the executable. The text section of an 
executable is where the code resides, in other words the real program.

This message appears when a process is running and you try to overwrite it, for 
example:

[r...@gerardo ~]# lsof -n | grep "sbin/init"
init 1   root  txt   REG8,1 313521079262 /sbin/init 
<<< note the 'txt' at 4th field.
[r...@gerardo ~]# echo 'hola' > /sbin/init
-bash: /sbin/init: Text file busy

But in this case is different, you are open(2) a file in read/write mode 
(O_RDWR), and you tried to execute it execve(2). This is impossible.

Again lsof help to view this:

[djg...@gerardo ~]$ vi coco.sh 

[djg...@gerardo ~]$ lsof -n | grep coco.sh
vi4127 djgera4uW REG8,632 113481 
/home/djgera/coco.sh  see the 'W' in 4th field.
[djg...@gerardo ~]$ ./coco.sh
bash: ./coco.sh: /bin/bash: bad interpreter: Text file busy


Another simple example:

[djg...@gerardo ~]$ cat coco.sh
#!/bin/bash

echo "Hola mundo!"
[djg...@gerardo ~]$ cat coco.c
#include 
#include 
#include 
#include 
#define __USE_GNU
#include 

int main(int argc, char *argv[])
{
int coco;
coco = open("./coco.sh", O_RDWR);
sleep(60);
close(coco);
return(0);
}
[djg...@gerardo ~]$ gcc coco.c -o coco
[djg...@gerardo ~]$ ./coco &
[1] 4234
[djg...@gerardo ~]$ lsof -n | grep coco.sh
coco  4234 djgera3u  REG8,632 113481 
/home/djgera/coco.sh  See the 'u' in 4th field.
[djg...@gerardo ~]$ ./coco.sh
bash: ./coco.sh: /bin/bash: bad interpreter: Text file busy


Good Luck!


(sorry my english)



-- 
Gerardo Exequiel Pozzi ( djgera )
http://www.djgera.com.ar
KeyID: 0x1B8C330D
Key fingerprint = 0CAA D5D4 CD85 4434 A219  76ED 39AB 221B 1B8C 330D

Re: [arch-general] [arch-dev-public] Preparing for libjpeg update

[Grigorios Bouzakis]

On Tue, Jun 23, 2009 at 7:44 AM, Allan McRae wrote:
> And the 2.6 version is old and does not have the arch in the package file
> name either...   Good spotting.  I really should fix that!
>
> Allan

There was some request to remove that some time ago in the flyspray as
the only 2
packages depending on it were bittorrent which is now command line
only and comical
in [community].

-- 
Greg

Re: [arch-general] [arch-dev-public] Preparing for libjpeg update

[Allan McRae]

Gerardo Exequiel Pozzi wrote:

Allan McRae wrote:
  

Hi all,

This weekend should see the release of the first update for libjpeg in
several years.  Everything remains API compatible so this should be
just a simple rebuild...  of 130 packages from [extra].  That is too
many packages for any sane person and double the number of the
readline rebuilds so I will need some help. I will deal with the
packages that are needed as dependencies for many other packages
first. The full list is given below and I will create a TODO list
closer to the time so that we can keep track of what has been done.

Given this is going to be a rather large rebuild, I will hold off
until the readline rebuilds are moved from [testing].  I guess these
can probably move before the weekend anyway.

Allan


Rebuild list:




  
ruby 




129 :) Ruby don't depends on libjpeg
  


No, it is some ruby- package from community.  My script strips 
version numbers off but gets confused by packages in [community] that do 
not have the arch in the package file name...



bah, 130 because there are two versions of wxgtk :P

  


And the 2.6 version is old and does not have the arch in the package 
file name either...   Good spotting.  I really should fix that!


Allan

Re: [arch-general] [arch-dev-public] Preparing for libjpeg update

[Grigorios Bouzakis]

On Tue, Jun 23, 2009 at 7:27 AM, Gerardo Exequiel
Pozzi wrote:
> Allan McRae wrote:
>> Hi all,
>>
>> This weekend should see the release of the first update for libjpeg in
>> several years.  Everything remains API compatible so this should be
>> just a simple rebuild...  of 130 packages from [extra].  That is too
>> many packages for any sane person and double the number of the
>> readline rebuilds so I will need some help. I will deal with the
>> packages that are needed as dependencies for many other packages
>> first. The full list is given below and I will create a TODO list
>> closer to the time so that we can keep track of what has been done.
>>
>> Given this is going to be a rather large rebuild, I will hold off
>> until the readline rebuilds are moved from [testing].  I guess these
>> can probably move before the weekend anyway.
>>
>> Allan
>>
>>
>> Rebuild list:
>>
> 
>> ruby
> 
>
> 129 :) Ruby don't depends on libjpeg
> bah, 130 because there are two versions of wxgtk :P
>
> And 83 in community: http://bugs.archlinux.org/task/15222 (sorted by
> maintainer and pkgname)
>
> Good Luck!

Sounds like quite a party!


-- 
Greg

Re: [arch-general] [arch-dev-public] Preparing for libjpeg update

[Gerardo Exequiel Pozzi]

Allan McRae wrote:
> Hi all,
>
> This weekend should see the release of the first update for libjpeg in
> several years.  Everything remains API compatible so this should be
> just a simple rebuild...  of 130 packages from [extra].  That is too
> many packages for any sane person and double the number of the
> readline rebuilds so I will need some help. I will deal with the
> packages that are needed as dependencies for many other packages
> first. The full list is given below and I will create a TODO list
> closer to the time so that we can keep track of what has been done.
>
> Given this is going to be a rather large rebuild, I will hold off
> until the readline rebuilds are moved from [testing].  I guess these
> can probably move before the weekend anyway.
>
> Allan
>
>
> Rebuild list:
>

> ruby 


129 :) Ruby don't depends on libjpeg
bah, 130 because there are two versions of wxgtk :P

And 83 in community: http://bugs.archlinux.org/task/15222 (sorted by
maintainer and pkgname)

Good Luck!

-- 
Gerardo Exequiel Pozzi ( djgera )
http://www.djgera.com.ar
KeyID: 0x1B8C330D
Key fingerprint = 0CAA D5D4 CD85 4434 A219  76ED 39AB 221B 1B8C 330D

Re: [arch-general] portable player, usb plugging/mounting problems

[Sergey Manucharian]

On Mon, 22 Jun 2009 19:58:28 -0300
"Guilherme M. Nogueira"  wrote:

.
> I have a Sansa e200 portable media player and I'm having problems
> mounting it. It used to work, but I can't recall when (I have been
> listening to the same stuff for over 4 months now).
> I'm using arch i686 with core, extra, community, kdemod-core and
> kdemod-extragear  and updated system.
> 
> The player has two modes, MSC and MTP. I always use it in Mass
> Storage Class mode.
.

Hi Guilherme,

A friend of mine has such a player, and he has problems mounting it in
Windows, but never in Linux :)

Thunar volman easily recognizes it, even if it in MTP mode. You may
want to turn on the "Hold" switch and hold the "Left" button
when inserting it in USB plug - just to check if there is a difference.
Tomorrow I will check the dmesg output with my friend's player and let
you know.

Cheers,
Sergey

[arch-general] portable player, usb plugging/mounting problems

[Guilherme M. Nogueira]

Hello dear Arch users,

I have a Sansa e200 portable media player and I'm having problems mounting
it. It used to work, but I can't recall when (I have been listening to the
same stuff for over 4 months now).
I'm using arch i686 with core, extra, community, kdemod-core and
kdemod-extragear  and updated system.

The player has two modes, MSC and MTP. I always use it in Mass Storage Class
mode.

Thing is, when I plug the device with HAL running I get the following:

$ dmesg:
usb 1-6: new high speed USB device using ehci_hcd and address 13
usb 1-6: configuration #128 chosen from 1 choice
scsi24 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 13
usb-storage: waiting for device to settle before scanning
usb 1-6: reset high speed USB device using ehci_hcd and address 13
scsi25 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 13
usb-storage: waiting for device to settle before scanning

If I stop HAL deamon, I get this:

$ dmesg
usb 1-6: new high speed USB device using ehci_hcd and address 4
usb 1-6: configuration #128 chosen from 1 choice
scsi14 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 4
usb-storage: waiting for device to settle before scanning
scsi 14:0:0:0: Direct-Access SanDisk  Sansa e270PQ: 0 ANSI:
0
sd 14:0:0:0: [sdb] 11780096 512-byte hardware sectors: (6.03 GB/5.61 GiB)
sd 14:0:0:0: [sdb] Write Protect is off
sd 14:0:0:0: [sdb] Mode Sense: 45 00 00 00
sd 14:0:0:0: [sdb] Assuming drive cache: write through
sd 14:0:0:0: [sdb] 11780096 512-byte hardware sectors: (6.03 GB/5.61 GiB)
sd 14:0:0:0: [sdb] Write Protect is off
sd 14:0:0:0: [sdb] Mode Sense: 45 00 00 00
sd 14:0:0:0: [sdb] Assuming drive cache: write through
 sdb: sdb1 sdb2
sd 14:0:0:0: [sdb] Attached SCSI removable disk
sd 14:0:0:0: Attached scsi generic sg2 type 0
scsi 14:0:0:1: Direct-Access SanDisk  Sansa e270PQ: 0 ANSI:
0
sd 14:0:0:1: [sdc] 246016 512-byte hardware sectors: (125 MB/120 MiB)
sd 14:0:0:1: [sdc] Write Protect is off
sd 14:0:0:1: [sdc] Mode Sense: 45 00 00 00
sd 14:0:0:1: [sdc] Assuming drive cache: write through
sd 14:0:0:1: [sdc] 246016 512-byte hardware sectors: (125 MB/120 MiB)
sd 14:0:0:1: [sdc] Write Protect is off
sd 14:0:0:1: [sdc] Mode Sense: 45 00 00 00
sd 14:0:0:1: [sdc] Assuming drive cache: write through
 sdc: sdc1
sd 14:0:0:1: [sdc] Attached SCSI removable disk
sd 14:0:0:1: Attached scsi generic sg3 type 0
usb-storage: device scan complete

The output of lsusb is:
$ lsusb
Bus 001 Device 013: ID 0781:7421 SanDisk Corp. Sansa E200 series


I don't really understand why is this, since I read that HAL just gets
notified of the new device and provides the interface for other apps, but
the kernel and udev are the ones that really do the recognizing and
mounting.

Since in my mind udev is the one that does the job, I tried following a tip
I read in the mainling list archive and created a new udev rule in
/etc/udev/rules.d/sansa.rules with:
UBSYSTEMS=="usb", KERNEL=="sd*",
ATTRS{idProduct}=="7421",ATTRS{idVendor}=="0781", SYMLINK+="sansa",
GROUP="storage"

I ask for you help to understand what is going on here.

Thank you very much,

Guilherme.

-- 
Malformed message exception

Re: [arch-general] Fwd: Re: dmraid-1.0.0rc15 in testing, need you help on this! (possible Bug on Delete)

[Jan de Groot]

On Mon, 2009-06-22 at 14:48 -0500, David C. Rankin wrote:
> Huh??? Why wasn't nvidia_ecaejfdip9 deactivated. I have
> deleted the partition 
> in cfdisk, tried to activate it (y) and deactivate it (n) and still it
> is 
> there. Is this a bug? Or do I need to erase the metadata in some other
> way??

You could try to force a re-read on the partition tables of the real
harddisks at /dev/sda and /dev/sdb using hdparm. After that, try
re-activating dmraid.

Re: [arch-general] vi from testing has gone nuts - does not honor virc/~.virc settings

[David C. Rankin]

On Monday 22 June 2009 11:06:37 am David Rosenstrauch wrote:
> David C. Rankin wrote:
> > Listmates, Devs:
> >
> > I upgraded to testing to test the new dmraid.
>
> Just my personal opinion here, and perhaps the devs will disagree, but
> personally I wouldn't suggest upgrading your entire box to testing.  If
> you only want to kick the tires on one package from testing, then
> probably best to only install that.
>
> One of the things I like about Arch is how it keeps me on the cutting
> edge with very up-to-date versions of all the packages, but still
> manages to keep my system very stable.  IMO, if you bump everything up
> to testing, you're going to lose a lot of that wonderful stability.
>
> DR


Thanks DR,

I think I will work my way back out of [testing] while leaving dmraid 
1.0.15rc intact.

-- 
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com

Re: [arch-general] vi from testing has gone nuts - does not honor virc/~.virc settings

[David C. Rankin]

On Monday 22 June 2009 02:59:08 am Grigorios Bouzakis wrote:

> >
> > Thanks Tobias and Allan,
> >
> >That is just what I needed to know!
>
> The whole point of using testing is.. you should have known that already.
> :)


Well my friend, when Tobias asked for assistance testing dmraid, I 
didn't 
hesitate to help. Sometimes, the best way to learn is to wade into the frigid 
water ;-) Not to mention, some of the rather basic questions or feedback 
regarding changes to vi and readline, and the reference they provide in the 
list archives, may just help another with the same questions at some point in 
the future.

Additionally, from what I glean from the current state of readline, 
there 
isn't anything 'concrete' to know at the present time other than it is 
'changing' and there is quite a bit of debate about what it will ultimately 
look like and why...

-- 
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com

[arch-general] Fwd: Re: dmraid-1.0.0rc15 in testing, need you help on this! (possible Bug on Delete)

[David C. Rankin]

Heinz,

I thought I would forward this one to you just in case there is a bug 
on the 
delete. It is probably just my limited understanding of dmraid, but I thought 
after I deleted the partition in cfdisk and then deactivated the device 
(nvidia_ecaejfdi) node nvidia_ecaejfdip9 should disappear? It is still there. 
How do I get rid of it? This is on Archlinux. Here is a bit more info about my 
setup:

[14:17 archangel:/home/david/archlinux/dmraid] # l /dev/mapper
total 0
drwxr-xr-x  2 root root   0 2009-06-22 13:44 .
drwxr-xr-x 23 root root   0 2009-06-22 13:44 ..
crw-rw  1 root root  10, 60 2009-06-22 01:40 control
brw---  1 root disk 254,  0 2009-06-22 13:48 nvidia_ecaejfdi
brw---  1 root disk 254,  2 2009-06-22 01:40 nvidia_ecaejfdip5
brw---  1 root disk 254,  3 2009-06-22 01:40 nvidia_ecaejfdip6
brw---  1 root disk 254,  4 2009-06-22 01:40 nvidia_ecaejfdip7
brw---  1 root disk 254,  5 2009-06-22 01:40 nvidia_ecaejfdip8
brw---  1 root disk 254, 10 2009-06-22 13:44 nvidia_ecaejfdip9
(I have deleted this in cfdisk) ^^
brw---  1 root disk 254,  1 2009-06-22 01:40 nvidia_fdaacfde
brw---  1 root disk 254,  6 2009-06-22 01:40 nvidia_fdaacfdep5
brw---  1 root disk 254,  7 2009-06-22 01:40 nvidia_fdaacfdep6
brw---  1 root disk 254,  8 2009-06-22 01:40 nvidia_fdaacfdep7
brw---  1 root disk 254,  9 2009-06-22 01:40 nvidia_fdaacfdep8


[14:13 archangel:/home/david/archlinux/dmraid] # dmraid -rd -v -v   
NOTICE: /dev/sdd: asr discovering   
NOTICE: /dev/sdd: ddf1discovering   
NOTICE: /dev/sdd: hpt37x  discovering   
NOTICE: /dev/sdd: hpt45x  discovering   
NOTICE: /dev/sdd: isw discovering   
NOTICE: /dev/sdd: jmicron discovering   
NOTICE: /dev/sdd: lsi discovering   
NOTICE: /dev/sdd: nvidia  discovering   
NOTICE: /dev/sdd: nvidia metadata discovered
NOTICE: /dev/sdd: pdc discovering   
NOTICE: /dev/sdd: sil discovering   
NOTICE: /dev/sdd: via discovering   
NOTICE: /dev/sdc: asr discovering   
NOTICE: /dev/sdc: ddf1discovering   
NOTICE: /dev/sdc: hpt37x  discovering   
NOTICE: /dev/sdc: hpt45x  discovering   
NOTICE: /dev/sdc: isw discovering   
NOTICE: /dev/sdc: jmicron discovering   
NOTICE: /dev/sdc: lsi discovering   
NOTICE: /dev/sdc: nvidia  discovering   
NOTICE: /dev/sdc: nvidia metadata discovered
NOTICE: /dev/sdc: pdc discovering   
NOTICE: /dev/sdc: sil discovering   
NOTICE: /dev/sdc: via discovering   
NOTICE: /dev/sdb: asr discovering   
NOTICE: /dev/sdb: ddf1discovering   
NOTICE: /dev/sdb: hpt37x  discovering   
NOTICE: /dev/sdb: hpt45x  discovering   
NOTICE: /dev/sdb: isw discovering   
NOTICE: /dev/sdb: jmicron discovering   
NOTICE: /dev/sdb: lsi discovering   
NOTICE: /dev/sdb: nvidia  discovering   
NOTICE: /dev/sdb: nvidia metadata discovered
NOTICE: /dev/sdb: pdc discovering   
NOTICE: /dev/sdb: sil discovering   
NOTICE: /dev/sdb: via discovering   
NOTICE: /dev/sda: asr discovering   
NOTICE: /dev/sda: ddf1discovering   
NOTICE: /dev/sda: hpt37x  discovering   
NOTICE: /dev/sda: hpt45x  discovering   
NOTICE: /dev/sda: isw discovering   
NOTICE: /dev/sda: jmicron discovering
NOTICE: /dev/sda: lsi discovering
NOTICE: /dev/sda: nvidia  discovering
NOTICE: /dev/sda: nvidia metadata discovered
NOTICE: /dev/sda: pdc discovering
NOTICE: /dev/sda: sil discovering
NOTICE: /dev/sda: via discovering
INFO: RAID devices discovered:

/dev/sdd: nvi

Re: [arch-general] dmraid-1.0.0rc15 in testing, need you help on this! (possible Bug on Delete)

[David C. Rankin]

On Monday 22 June 2009 03:13:41 am Tobias Powalowski wrote:
> I need to explain this a bit more:
>

>
> Now i cfdisk this device, are the nodes updated then?
> - I mean do i get the /dev/mapper/vidia_fffadgicp1 p2 p3 autimatically or
> do I need to run dmraid -ay for every partition i created?
> - Also what happens if partitions are deleted?
>

ADDING NEW PARTITION (PART9) - 10G IN SIZE:


   cfdisk (util-linux-ng 2.14.2)

  Disk Drive: /dev/mapper/nvidia_ecaejfdi
 Size: 750156372992 bytes, 750.1 GB
   Heads: 255   Sectors per Track: 63   Cylinders: 
91201

 NameFlags  Part Type  FS Type   
[Label] Size (MB)
 
--
 nvidia_ecaejfdi5BootLogical   Linux ext3   
  
20003.85 *
 nvidia_ecaejfdi6Logical   Linux ext3   

123.38
 nvidia_ecaejfdi7Logical   Linux ext3   
  
3.54
 nvidia_ecaejfdi8Logical   Linux swap / Solaris 
   
1998.75
 nvidia_ecaejfdi9Logical   Linux
  
10001.95
 Pri/Log   Free Space   
 
678026.29


(write & quit)

New node NOT created:

[13:39 archangel:~] # l /dev/mapper
total 0
drwxr-xr-x  2 root root   0 2009-06-22 01:40 .
drwxr-xr-x 23 root root   0 2009-06-22 01:41 ..
crw-rw  1 root root  10, 60 2009-06-22 01:40 control
brw---  1 root disk 254,  0 2009-06-22 13:38 nvidia_ecaejfdi
brw---  1 root disk 254,  2 2009-06-22 01:40 nvidia_ecaejfdip5
brw---  1 root disk 254,  3 2009-06-22 01:40 nvidia_ecaejfdip6
brw---  1 root disk 254,  4 2009-06-22 01:40 nvidia_ecaejfdip7
brw---  1 root disk 254,  5 2009-06-22 01:40 nvidia_ecaejfdip8


[13:44 archangel:~] # dmraid -ay nvidia_ecaejfdi
RAID set "nvidia_ecaejfdi" already active
RAID set "nvidia_ecaejfdip5" already active
RAID set "nvidia_ecaejfdip6" already active
RAID set "nvidia_ecaejfdip7" already active
RAID set "nvidia_ecaejfdip8" already active
RAID set "nvidia_ecaejfdip9" was activated

[13:44 archangel:~] # l /dev/mapper
total 0
drwxr-xr-x  2 root root   0 2009-06-22 13:44 .
drwxr-xr-x 23 root root   0 2009-06-22 13:44 ..
crw-rw  1 root root  10, 60 2009-06-22 01:40 control
brw---  1 root disk 254,  0 2009-06-22 13:38 nvidia_ecaejfdi
brw---  1 root disk 254,  2 2009-06-22 01:40 nvidia_ecaejfdip5
brw---  1 root disk 254,  3 2009-06-22 01:40 nvidia_ecaejfdip6
brw---  1 root disk 254,  4 2009-06-22 01:40 nvidia_ecaejfdip7
brw---  1 root disk 254,  5 2009-06-22 01:40 nvidia_ecaejfdip8
brw---  1 root disk 254, 10 2009-06-22 13:44 nvidia_ecaejfdip9


DELETING PARTITION (PART 9) - 10G IN SIZE

   cfdisk (util-linux-ng 2.14.2)

  Disk Drive: /dev/mapper/nvidia_ecaejfdi
 Size: 750156372992 bytes, 750.1 GB
   Heads: 255   Sectors per Track: 63   Cylinders: 
91201

 NameFlags  Part Type  FS Type   
[Label] Size (MB)
 
--
 nvidia_ecaejfdi5BootLogical   Linux ext3   
  
20003.85 *
 nvidia_ecaejfdi6Logical   Linux ext3   

123.38
 nvidia_ecaejfdi7Logical   Linux ext3   
  
3.54
 nvidia_ecaejfdi8Logical   Linux swap / Solaris 
   
1998.75
 Pri/Log   Free Space   
 
688028.23

(write & quit)

Partition NOT removed from /dev/mapper:

[13:48 archangel:~] # l /dev/mapper
total 0
drwxr-xr-x  2 root root   0 2009-06-22 13:44 .
drwxr-xr-x 23 root root   0 2009-06-22 13:44 ..
crw-rw  1 root root  10, 60 2009-06-22 01:40 control
brw---  1 root disk 254,  0 2009-06-22 13:48 nvidia_ecaejfdi
brw---  1 root disk 254,  2 2009-06-22 01:40 nvidia_ecaejfdip5
brw---  1 root disk 254,  3 2009-06-22 01:40 nvidia_ecaejfdip6
brw---  1 root disk 254,  4 2009-06-22 01:40 nvidia_ecaejfdip7
brw---  1 root disk 254,  5 2009-06-22 01:40 nvidia_ecaejfdip8
brw---  1 root disk 254, 10 2009-06-22 13:44 nvidia_ecaejfdip9


[13:59 archangel:~] # dmraid -an nvidia_ecaejfdi

[13:59 archangel:~] # l /dev/mapper
total 0
drwxr-xr-x  2 root root   0 2009-06-22 13:44 .
drwxr-xr-x 23 root root   0 2009-06-22 13:44 .

Re: [arch-general] okular print preview error

[Leonid Grinberg]

Just to bump this discussion -- I too am having this problem. /tmp is
definitely not empty, and there is no DRM in this document (it was
produced by me via pdflatex).

Does anyone know what else might cause this?

--
Thanks,
Leonid Grinberg

Re: [arch-general] vi from testing has gone nuts - does not honor virc/~.virc settings

[Jan de Groot]

On Mon, 2009-06-22 at 12:06 -0400, David Rosenstrauch wrote:
> David C. Rankin wrote:
> > Listmates, Devs:
> > 
> > I upgraded to testing to test the new dmraid.
> 
> Just my personal opinion here, and perhaps the devs will disagree, but 
> personally I wouldn't suggest upgrading your entire box to testing.  If 
> you only want to kick the tires on one package from testing, then 
> probably best to only install that.
> 
> One of the things I like about Arch is how it keeps me on the cutting 
> edge with very up-to-date versions of all the packages, but still 
> manages to keep my system very stable.  IMO, if you bump everything up 
> to testing, you're going to lose a lot of that wonderful stability.
> 
> DR

Using testing to -Syu your system every day, you should be a frequent
reader of arch-dev-public, simple as that. Anything in testing could be
broken, that's why it's testing. We abuse testing for testing out
packages, but also for big todo tasks.
I use testing on my system to do a pacman -Syu daily, but when the
readline rebuilds started to enter testing, I decided to wait a bit
before upgrading.

Re: [arch-general] deps not being properly recognized?

[Aaron Griffin]

On Mon, Jun 22, 2009 at 9:39 AM, Andrei Thorp wrote:
> Excerpts from Allan McRae's message of Sat Jun 20 21:37:11 -0400 2009:
>> Caleb Cushing wrote:
>> > I can't figure out why pacman thinks that deps aren't being fulfilled.
>> >
>> > Targets (1): perl-datetime-0.50-1
>> > 
>> > :: perl-datetime-format-strptime: requires perl-datetime>=0.4304
>> >
>>
>> 50  is not >= 4304
>>
>> Allan
>
> Hmm. That's kind of unfortuante. Chances are, .5x is actually meant to be
>  greater than the .4xxx. Guess the best you can do is force it? :S

Yeah some people do terrible things with version numbers. They are NOT
decimal numbers, they are independent numbers joined by dots.

You can do pacman -Ud to skip dep checks if you're sure the deps are good.

Re: [arch-general] Holy Cow -- What happened to bash / vi??

[Andrei Thorp]

Excerpts from Aaron Griffin's message of Mon Jun 22 12:27:01 -0400 2009:
> On Mon, Jun 22, 2009 at 7:02 AM, Daenyth Blank wrote:
> > On Mon, Jun 22, 2009 at 07:47, Loui Chang wrote:
> >> On Mon 22 Jun 2009 03:09 -0500, David C. Rankin wrote:
> >>> I will downgrade vi. If that is what the future of vi looks like, I
> >>> don't want any part of it. Changes that dramatic ought to be forked.
> >>
> >> You were previously using vim named 'vi'.
> >> The new one is actually a fork of vi called nvi.
> >>
> >>
> >
> > I don't understand why anyone would use any vi. Use vim instead...
> 
> I've always harped on this point. I use "vim". Vim is the name of the
> application that I use. Vim just happens to be largely vi compatible,
> but I still use vim.

Yeah, I'm not a huge fan of running "vi" and expecting vim. Sounds a bit
like running "mozilla" and expecting "firefox" or... something.

-AT
-- 
Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)

Freedom begins when you tell Mrs. Grundy to go fly a kite.

Re: [arch-general] [arch-dev-public] [signoff] + help needed readline rebuilds

[Aaron Griffin]

On Thu, Jun 18, 2009 at 5:28 PM, Gerardo Exequiel
Pozzi wrote:
> Aaron Griffin wrote:
>> There are LOTS of packages in extra and community that need rebuilds.
>> The original output from Allan's script is as follows:
>> abiword-plugins
>> abook
>> afterstep
>> amule
>> bc
>> cdcd
>> clisp
>> ecasound
>> evms
>> fluidsynth
>> freeciv
>> fvwm
>> fvwm-devel
>> genius
>> gftp
>> gnokii
>> gnuchess
>> gnupg
>> gnupg2
>> gnuplot
>> gnutls
>> gphoto2
>> guile
>> gutenprint
>> hugs98
>> jack-audio-connection-kit
>> kdeedu
>> koffice
>> lftp
>> libgda
>> libqalculate
>> librep
>> libxml2
>> lua
>> maxima
>> mono-debugger
>> mysql-clients
>> ntp
>> ocfs2-tools
>> octave
>> pal
>> parted
>> php
>> pilot-link
>> postgresql
>> postgresql-libs
>> python
>> python24
>> r
>> ruby
>> smbclient
>> socat
>> swi-prolog
>> texlive-bin
>> tftp-hpa
>> twinkle
>> uml_utilities
>> unixodbc
>> vice
>> wvstreams
>> xine-ui
>>
> These package don't use readline
>
> maxima
> mono-debugger
> koffice
>
>
> And these are missing in this list:
>
> mysql
> ratpoison
>
> I created a ticket for [community] http://bugs.archlinux.org/task/15165

Updated our internal TODO list for future reference.

Re: [arch-general] Holy Cow -- What happened to bash / vi??

[Aaron Griffin]

On Mon, Jun 22, 2009 at 7:02 AM, Daenyth Blank wrote:
> On Mon, Jun 22, 2009 at 07:47, Loui Chang wrote:
>> On Mon 22 Jun 2009 03:09 -0500, David C. Rankin wrote:
>>> I will downgrade vi. If that is what the future of vi looks like, I
>>> don't want any part of it. Changes that dramatic ought to be forked.
>>
>> You were previously using vim named 'vi'.
>> The new one is actually a fork of vi called nvi.
>>
>>
>
> I don't understand why anyone would use any vi. Use vim instead...

I've always harped on this point. I use "vim". Vim is the name of the
application that I use. Vim just happens to be largely vi compatible,
but I still use vim.

Re: [arch-general] vi from testing has gone nuts - does not honor virc/~.virc settings

[David Rosenstrauch]

David C. Rankin wrote:

Listmates, Devs:

I upgraded to testing to test the new dmraid.


Just my personal opinion here, and perhaps the devs will disagree, but 
personally I wouldn't suggest upgrading your entire box to testing.  If 
you only want to kick the tires on one package from testing, then 
probably best to only install that.


One of the things I like about Arch is how it keeps me on the cutting 
edge with very up-to-date versions of all the packages, but still 
manages to keep my system very stable.  IMO, if you bump everything up 
to testing, you're going to lose a lot of that wonderful stability.


DR

Re: [arch-general] dmraid-1.0.0rc15 in testing, need you help on this!

[David C. Rankin]

On Monday 22 June 2009 03:13:41 am Tobias Powalowski wrote:
> I need to explain this a bit more:
>
> If you start with empty disks, eg. 2 disks
> I put them together in bios of raid controller.
> After booting install media, which runs dmraid -ay during boot process, i
> get something like that:
> /dev/mapper/nvidia_fffadgic
> because no partitions are there.
>

Tobias, that's correct. I put them together in the bios, and then I just 
partition them as normal when the Arch installer ask me what partitions I 
want.

> Now i cfdisk this device, are the nodes updated then?
> - I mean do i get the /dev/mapper/vidia_fffadgicp1 p2 p3 autimatically or
> do I need to run dmraid -ay for every partition i created?

That - I don't know. I know that all the nodes were updated during the 1st 
boot after upgrading to 1.0.15rc, but I haven't looked since. Next time I'm at 
the machine, I'll boot and see. I think you will need to run dmraid -y each 
time, but I will confirm.

> - Also what happens if partitions are deleted?

I haven't tried that yet. Remarkably, cfdisk  doesn't show the 'p' anywhere in 
the partition listing. So it looks like the 'p' is strictly a creature of 
dmraid:

   cfdisk (util-linux-ng 2.14.2)

  Disk Drive: /dev/mapper/nvidia_ecaejfdi
 Size: 750156372992 bytes, 750.1 GB
   Heads: 255   Sectors per Track: 63   Cylinders: 
91201

 NameFlags  Part Type  FS Type   
[Label] Size (MB)
 
--
 nvidia_ecaejfdi5BootLogical   Linux ext3   
  
20003.85 *
 nvidia_ecaejfdi6Logical   Linux ext3   

123.38
 nvidia_ecaejfdi7Logical   Linux ext3   
  
3.54
 nvidia_ecaejfdi8Logical   Linux swap / Solaris 
   
1998.75
 Pri/Log   Free Space   
 
688028.23



>
> Thanks for some enlightment.
> greetings
> tpowa

-- 
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com

Re: [arch-general] vi from testing has gone nuts - does not honor virc/~.virc settings

[Jan Spakula]

Excerpts from Loui Chang's message of Mo Jun 22 16:41:41 +0200 2009:
> > Is there a way for him to try the new 'dmraid' without going the whole
> > way and migrating to [testing].  This would also be useful for him
> > (and me) to know.
> 
> Pretty simple. Enable testing, install dmraid, disable testing.
> Then your testing is limited to those packages only.

While this works fine most of the time, when you run into problems and ask
about it here or on the forums, the first thing that people tell you is: "you
should either use [testing] all the way or not at all, since any particular
package in [testing] might crucially depend in some other packages in
[testing], and they don't get updated when you only update one particular
package."

Anyway, I still think it's a good idea to search the MLs and forums before
asking for help here. Big chances are someone has already noticed/the change
was announced in the dev ML.

Re: [arch-general] dmraid-1.0.0rc15 in testing, need you help on this!

[David C. Rankin]

On Monday 22 June 2009 03:16:15 am Tobias Powalowski wrote:
> Just forgot one question, is /dev/sda also shown in /dev tree if dmraid is
> used?
> thanks
> greetings
> tpowa

They are all there:

[09:53 archangel:~] # l /dev/sd*
brw-rw 1 root disk 8,  0 2009-06-22 01:40 /dev/sda
brw-rw 1 root disk 8,  1 2009-06-22 01:40 /dev/sda1
brw-rw 1 root disk 8,  5 2009-06-22 01:40 /dev/sda5
brw-rw 1 root disk 8,  6 2009-06-22 01:40 /dev/sda6
brw-rw 1 root disk 8,  7 2009-06-22 01:40 /dev/sda7
brw-rw 1 root disk 8,  8 2009-06-22 01:40 /dev/sda8
brw-rw 1 root disk 8, 16 2009-06-22 01:40 /dev/sdb
brw-rw 1 root disk 8, 17 2009-06-22 01:40 /dev/sdb1
brw-rw 1 root disk 8, 21 2009-06-22 01:40 /dev/sdb5
brw-rw 1 root disk 8, 22 2009-06-22 01:40 /dev/sdb6
brw-rw 1 root disk 8, 23 2009-06-22 01:40 /dev/sdb7
brw-rw 1 root disk 8, 24 2009-06-22 01:40 /dev/sdb8
brw-rw 1 root disk 8, 32 2009-06-22 01:40 /dev/sdc
brw-rw 1 root disk 8, 33 2009-06-22 01:40 /dev/sdc1
brw-rw 1 root disk 8, 37 2009-06-22 01:40 /dev/sdc5
brw-rw 1 root disk 8, 38 2009-06-22 01:40 /dev/sdc6
brw-rw 1 root disk 8, 39 2009-06-22 01:40 /dev/sdc7
brw-rw 1 root disk 8, 40 2009-06-22 01:40 /dev/sdc8
brw-rw 1 root disk 8, 48 2009-06-22 01:40 /dev/sdd
brw-rw 1 root disk 8, 49 2009-06-22 01:40 /dev/sdd1
brw-rw 1 root disk 8, 53 2009-06-22 01:40 /dev/sdd5
brw-rw 1 root disk 8, 54 2009-06-22 01:40 /dev/sdd6
brw-rw 1 root disk 8, 55 2009-06-22 01:40 /dev/sdd7
brw-rw 1 root disk 8, 56 2009-06-22 01:40 /dev/sdd8


-- 
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com

Re: [arch-general] vi from testing has gone nuts - does not honor virc/~.virc settings

[Loui Chang]

On Mon 22 Jun 2009 14:12 +0100, Scot Becker wrote:
> > Very true. You should keep up with development if you're going to be
> > running [testing] and be prepared to struggle through any issues.
> > Problems shouldn't come as a total surprise anyways.
> 
> Sure.  But 'struggling though any issues" doesn't mean he has to do it
> without our help, no? I'm new here, but I'm not sure I agree with
> Gridorios sentiments exactly.  David should indeed "expect issues"
> (and issues exactly of this kind, and worse) if he goes to [testing],
> but he's still invited to solicit help, and those who think he's
> beyond his depth, or who can make better use of their time
> contributing elsewhere, needn't bother themselves to respond.

Sure, but you shouldn't complain about what happens to you if you jump
into a river full of pirahnas, without first educating yourself about
them (and how to protect yourself).

> Is there a way for him to try the new 'dmraid' without going the whole
> way and migrating to [testing].  This would also be useful for him
> (and me) to know.

Pretty simple. Enable testing, install dmraid, disable testing.
Then your testing is limited to those packages only.

Don't --sync --sysupgrade on testing.

Re: [arch-general] deps not being properly recognized?

[Andrei Thorp]

Excerpts from Allan McRae's message of Sat Jun 20 21:37:11 -0400 2009:
> Caleb Cushing wrote:
> > I can't figure out why pacman thinks that deps aren't being fulfilled.
> >
> > Targets (1): perl-datetime-0.50-1
> > 
> > :: perl-datetime-format-strptime: requires perl-datetime>=0.4304
> >   
> 
> 50  is not >= 4304
> 
> Allan

Hmm. That's kind of unfortuante. Chances are, .5x is actually meant to be
 greater than the .4xxx. Guess the best you can do is force it? :S

-AT
-- 
Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)

C:\> WIN
Bad command or filename

C:\> LOSE
Loading Microsoft Windows ...

Re: [arch-general] vi from testing has gone nuts - does not honor virc/~.virc settings

[Scot Becker]

> Very true. You should keep up with development if you're going to be
> running [testing] and be prepared to struggle through any issues.
> Problems shouldn't come as a total surprise anyways.

Sure.  But 'struggling though any issues" doesn't mean he has to do it
without our help, no? I'm new here, but I'm not sure I agree with
Gridorios sentiments exactly.  David should indeed "expect issues"
(and issues exactly of this kind, and worse) if he goes to [testing],
but he's still invited to solicit help, and those who think he's
beyond his depth, or who can make better use of their time
contributing elsewhere, needn't bother themselves to respond.

Is there a way for him to try the new 'dmraid' without going the whole
way and migrating to [testing].  This would also be useful for him
(and me) to know.

Thanks,

Scot

Re: [arch-general] Holy Cow -- What happened to bash / vi??

[Dieter Plaetinck]

On Mon, 22 Jun 2009 08:02:43 -0400
Daenyth Blank  wrote:

> On Mon, Jun 22, 2009 at 07:47, Loui Chang wrote:
> > On Mon 22 Jun 2009 03:09 -0500, David C. Rankin wrote:
> >> I will downgrade vi. If that is what the future of vi looks like, I
> >> don't want any part of it. Changes that dramatic ought to be
> >> forked.
> >
> > You were previously using vim named 'vi'.
> > The new one is actually a fork of vi called nvi.
> >
> >
> 
> I don't understand why anyone would use any vi. Use vim instead...

One of the things I've learned from maintaining stuff: never
underestimate the diversity of requirements/values people have.
If you look at the suckless community for instance, you'll find many of
them who consider vim bloatware.

Dieter

Re: [arch-general] Holy Cow -- What happened to bash / vi??

[Daenyth Blank]

On Mon, Jun 22, 2009 at 07:47, Loui Chang wrote:
> On Mon 22 Jun 2009 03:09 -0500, David C. Rankin wrote:
>> I will downgrade vi. If that is what the future of vi looks like, I
>> don't want any part of it. Changes that dramatic ought to be forked.
>
> You were previously using vim named 'vi'.
> The new one is actually a fork of vi called nvi.
>
>

I don't understand why anyone would use any vi. Use vim instead...

Re: [arch-general] vi from testing has gone nuts - does not honor virc/~.virc settings

[Loui Chang]

On Mon 22 Jun 2009 10:59 +0300, Grigorios Bouzakis wrote:
> The whole point of using testing is.. you should have known that already. :)

Very true. You should keep up with development if you're going to be
running [testing] and be prepared to struggle through any issues.
Problems shouldn't come as a total surprise anyways.

It seems pretty heavy right now with readline rebuilds, bash 4.0, and vi.

Re: [arch-general] Holy Cow -- What happened to bash / vi??

[Loui Chang]

On Mon 22 Jun 2009 03:09 -0500, David C. Rankin wrote:
> I will downgrade vi. If that is what the future of vi looks like, I
> don't want any part of it. Changes that dramatic ought to be forked.

You were previously using vim named 'vi'.
The new one is actually a fork of vi called nvi.

Re: [arch-general] dmraid-1.0.0rc15 in testing, need you help on this!

[Jan de Groot]

On Mon, 2009-06-22 at 10:16 +0200, Tobias Powalowski wrote:
> Just forgot one question, is /dev/sda also shown in /dev tree if dmraid is 
> used?
> thanks
> greetings
> tpowa

That looks logical to me. dmraid is just RAID using the devicemapper/lvm
subsystem. When I use LVM on a machine, I will get devicenodes
for /dev/sda and such. dmraid can't work without devicenodes for these
devices, as it has to be managed by userspace tools.

Re: [arch-general] Presto for pacman?

[Magnus Therning]

On Mon, Jun 22, 2009 at 9:09 AM, Allan McRae wrote:
> Magnus Therning wrote:
>>
>> Is there something similar to Yum Presto[1] for pacman?
>>
>> Would it be possible to do, or are there limitations in the package
>> format that prevents it?
>>
>> /M
>>
>> [1]: http://fedoraproject.org/wiki/Features/Presto
>>
>
> This is already implemented in the unreleased pacman codebase.  Once this
> gets released we need to figure out how to deal with this from the package
> distribution side.

Cool!  Hopefully that'll mean smaller go-ooo downloads at some point
in the future :-)

/M

-- 
Magnus Therning(OpenPGP: 0xAB4DFBA4)
magnus＠therning．org  Jabber: magnus＠therning．org
http://therning.org/magnus identi.ca|twitter: magthe

Re: [arch-general] dmraid-1.0.0rc15 in testing, need you help on this!

[Tobias Powalowski]

Just forgot one question, is /dev/sda also shown in /dev tree if dmraid is 
used?
thanks
greetings
tpowa
-- 
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tp...@archlinux.org


signature.asc
Description: This is a digitally signed message part.

Re: [arch-general] dmraid-1.0.0rc15 in testing, need you help on this!

[Tobias Powalowski]

I need to explain this a bit more:

If you start with empty disks, eg. 2 disks
I put them together in bios of raid controller.
After booting install media, which runs dmraid -ay during boot process, i get 
something like that:
/dev/mapper/nvidia_fffadgic
because no partitions are there.

Now i cfdisk this device, are the nodes updated then?
- I mean do i get the /dev/mapper/vidia_fffadgicp1 p2 p3 autimatically or do I 
  need to run dmraid -ay for every partition i created?
- Also what happens if partitions are deleted?

Thanks for some enlightment.
greetings
tpowa
-- 
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tp...@archlinux.org


signature.asc
Description: This is a digitally signed message part.

Re: [arch-general] Holy Cow -- What happened to bash / vi??

[David C. Rankin]

On Monday 22 June 2009 12:42:18 am Grigorios Bouzakis wrote:
> On Mon, Jun 22, 2009 at 8:26 AM, David C. Rankin <
>
> drankina...@suddenlinkmail.com> wrote:
> > Listmates,
> >
> >I updated to [testing] and now I am having strange behavior from
> > ...
>
> Any partiular reason you did that?

yes, testing dmraid 1.0.15rc
>
> Its likely BOTH vi and bash are to blame as both are entirely different
> from the ones in extra.

I will downgrade vi. If that is what the future of vi looks like, I don't want 
any part of it. Changes that dramatic ought to be forked.


-- 
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com

Re: [arch-general] Presto for pacman?

[Allan McRae]

Magnus Therning wrote:

Is there something similar to Yum Presto[1] for pacman?

Would it be possible to do, or are there limitations in the package
format that prevents it?

/M

[1]: http://fedoraproject.org/wiki/Features/Presto
  


This is already implemented in the unreleased pacman codebase.  Once 
this gets released we need to figure out how to deal with this from the 
package distribution side.


Allan

[arch-general] Presto for pacman?

[Magnus Therning]

Is there something similar to Yum Presto[1] for pacman?

Would it be possible to do, or are there limitations in the package
format that prevents it?

/M

[1]: http://fedoraproject.org/wiki/Features/Presto

-- 
Magnus Therning(OpenPGP: 0xAB4DFBA4)
magnus＠therning．org  Jabber: magnus＠therning．org
http://therning.org/magnus identi.ca|twitter: magthe

Re: [arch-general] vi from testing has gone nuts - does not honor virc/~.virc settings

[Grigorios Bouzakis]

On Mon, Jun 22, 2009 at 10:55 AM, David C.
Rankin wrote:
> On Monday 22 June 2009 02:36:26 am Allan McRae wrote:
>> David C. Rankin wrote:
>> > Listmates, Devs:
>> >
>> >     I upgraded to testing to test the new dmraid. As part of the upgrade, 
>> > vi
>> > was changed in a BIG way. (I could hardly use the thing and I have been
>> > using it for 20 years) The screen flashes when you double-escape, in
>> > insert mode if you move to colum 1 things go nuts, insert mode is changed
>> > into some kind of vampire. None of the normal key mappings work, and I
>> > can't get my beloved vi back by restoring the virc from the virc.pacnew -
>> > GGR :-(
>> >
>> >     How do I make my vi return to normal? What's the trick? If restoring 
>> > the
>> > virc and changing the settings has no effect (I even logged out and back)
>> > Wher are the magic settings now?
>> >
>> >     And... if the version I have can't be made to behave like my normal
>> > vi/vim again, "Then what is the proper way to downgrade vi so I can get
>> > my friend back?
>>
>> The new "vi" is "nvi" which I agree is crap  So you probably want to
>> uninstall vi, install vim and symlink /usr/bin/vim to /usr/bin/vi.
>> Probably have to change your config to /etc/vimrc but I am not sure
>> about that.
>>
>> Allan
>
> Thanks Tobias and Allan,
>
>        That is just what I needed to know!

The whole point of using testing is.. you should have known that already. :)



-- 
Greg

Re: [arch-general] vi from testing has gone nuts - does not honor virc/~.virc settings

[David C. Rankin]

On Monday 22 June 2009 02:36:26 am Allan McRae wrote:
> David C. Rankin wrote:
> > Listmates, Devs:
> >
> > I upgraded to testing to test the new dmraid. As part of the upgrade, vi
> > was changed in a BIG way. (I could hardly use the thing and I have been
> > using it for 20 years) The screen flashes when you double-escape, in
> > insert mode if you move to colum 1 things go nuts, insert mode is changed
> > into some kind of vampire. None of the normal key mappings work, and I
> > can't get my beloved vi back by restoring the virc from the virc.pacnew -
> > GGR :-(
> >
> > How do I make my vi return to normal? What's the trick? If restoring the
> > virc and changing the settings has no effect (I even logged out and back)
> > Wher are the magic settings now?
> >
> > And... if the version I have can't be made to behave like my normal
> > vi/vim again, "Then what is the proper way to downgrade vi so I can get
> > my friend back?
>
> The new "vi" is "nvi" which I agree is crap  So you probably want to
> uninstall vi, install vim and symlink /usr/bin/vim to /usr/bin/vi.
> Probably have to change your config to /etc/vimrc but I am not sure
> about that.
>
> Allan

Thanks Tobias and Allan,

That is just what I needed to know!


-- 
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com

Re: [arch-general] dmraid-1.0.0rc15 in testing, need you help on this!

[David C. Rankin]

On Monday 22 June 2009 02:14:15 am Tobias Powalowski wrote:
> > So I guess I will have to edit all the scripts to put an extra 'p' in
> > them as well. (Really kind of a pain, but if this new scheme is going to
> > be the standard, I can do it, ...but if this is just a 'proposed' change,
> > then I would rather not.
> >
> > So is this Official? If so I don't mind changing them around and I know
> > SuSE will eventually catch up. I've cc'ed Heinz Mauelshagen (the dev at
> > Redhat to see if he thinks this is permanent. This does present a problem
> > for Linux dual boot boxes. What was the reason to the change anyway?
> >
> > Tobias, let me know if you want me to run any more test. (I don't have
> > anything to rebuild right now or I would try the -R command which is an
> > EXCELLENT addition to dmraid. Kuddos to the brainchild behind that.
>
> Hi,
> since i didn't have changed the source code of dmraid i think it is an
> official change, i guess it follows the kernel name scheme here.
>
> I try to add some more dmraid specific stuff to archboot setup routine.
> Reading through this wiki:
> http://wiki.archlinux.org/index.php/Installing_with_Fake-RAID
>
> - Is it really enough to call dmraid -ay after you partitioned your
> raidset? Isn't this updated automatically?

I'm no dmraid expert, but I can tell you that any time you remove and 
recreate your dmpartitions, you will get a NEW set of partition labels. If you 
look at the wiki, you will see my old Arch partitions on this same machine 
were:

nvidia_fffadgic
nvidia_fffadgic5
nvidia_fffadgic6
nvidia_fffadgic7
nvidia_fffadgic8

After a drive failure and no -R (rebuild) option yet (in the community 
release), I had to delete my existing array, partition my new replacement disk 
to match the good disk, and then use 'dd' to copy all the partitions from 
'good drive' -> 'new drive' and then add both disks to a new dmraid in the 
bios. When I did that, I ended up with:

nvidia_ecaejfdi
nvidia_ecaejfdi5
nvidia_ecaejfdi6
nvidia_ecaejfdi7
nvidia_ecaejfdi8

The naming was entirely automatic. I don't know if it was handled in 
the bios 
or in Arch, but I do know, I didn't to it. Now with the new dmraid 1.0.15rc, I 
have and the new p, I have:

nvidia_ecaejfdi
nvidia_ecaejfdip5
nvidia_ecaejfdip6
nvidia_ecaejfdip7
nvidia_ecaejfdip8


>
> - There are some mentions that you need to dmsetup remove_all before, which
> I think is not correct.

I agree with you, no need to even tough dmsetup. All I did was add the 'p's in 
../grub/menu.lst and change fstab like the warning said and it is all OK.

>
> - Installing grub do i need this C H S hack?
>   Is grub failing if i just install it on (hd0)?

I don't think it would (maybe) My /boot/grub device map seems to handle that 
correlation:

[02:47 archangel:~] # cat /boot/grub/device.map
(hd0) /dev/mapper/nvidia_fdaacfde
(hd1) /dev/mapper/nvidia_ecaejfdi
(fd0) /dev/fd0

It is just mapping the labels to (hd0), etc. so nothing jumps out at me saying 
you can't

>
> - How about lilo? Is lilo working without any modification?

I don't think I have worked with lilo since Mandrake 7.4 (air) release on an 
old 386 machine from floppy discs (Maybe it was on a CD)

>
> Sorry for asking so many questions, but without the hardware some things
> are really difficult to guess.
> Thanks for your help on this.
> greetings
> tpowa

Thank you for you help. I'm just really glad to have the --rebuild 
capability 
now. I really like dmraid and I have it on 5-6 setups - never a single loss of 
data in the past 4-5 years since I have been using it. Great work!


-- 
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com

Re: [arch-general] vi from testing has gone nuts - does not honor virc/~.virc settings

[Allan McRae]

David C. Rankin wrote:

Listmates, Devs:

	I upgraded to testing to test the new dmraid. As part of the upgrade, vi was 
changed in a BIG way. (I could hardly use the thing and I have been using it 
for 20 years) The screen flashes when you double-escape, in insert mode if you 
move to colum 1 things go nuts, insert mode is changed into some kind of 
vampire. None of the normal key mappings work, and I can't get my beloved vi 
back by restoring the virc from the virc.pacnew - GGR :-(


	How do I make my vi return to normal? What's the trick? If restoring the virc 
and changing the settings has no effect (I even logged out and back) Wher are 
the magic settings now?


	And... if the version I have can't be made to behave like my normal vi/vim 
again, "Then what is the proper way to downgrade vi so I can get my friend 
back?
  


The new "vi" is "nvi" which I agree is crap  So you probably want to 
uninstall vi, install vim and symlink /usr/bin/vim to /usr/bin/vi. 
Probably have to change your config to /etc/vimrc but I am not sure 
about that.


Allan

Re: [arch-general] vi from testing has gone nuts - does not honor virc/~.virc settings

[Tobias Powalowski]

Am Montag 22 Juni 2009 schrieb David C. Rankin:
> Listmates, Devs:
>
>   I upgraded to testing to test the new dmraid. As part of the upgrade, vi
> was changed in a BIG way. (I could hardly use the thing and I have been
> using it for 20 years) The screen flashes when you double-escape, in insert
> mode if you move to colum 1 things go nuts, insert mode is changed into
> some kind of vampire. None of the normal key mappings work, and I can't get
> my beloved vi back by restoring the virc from the virc.pacnew - GGR :-(
>
>   How do I make my vi return to normal? What's the trick? If restoring the
> virc and changing the settings has no effect (I even logged out and back)
> Wher are the magic settings now?
>
>   And... if the version I have can't be made to behave like my normal 
> vi/vim
> again, "Then what is the proper way to downgrade vi so I can get my friend
> back?
when using testing, install vim instead
greetings
tpowa
-- 
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tp...@archlinux.org


signature.asc
Description: This is a digitally signed message part.

[arch-general] vi from testing has gone nuts - does not honor virc/~.virc settings

[David C. Rankin]

Listmates, Devs:

I upgraded to testing to test the new dmraid. As part of the upgrade, 
vi was 
changed in a BIG way. (I could hardly use the thing and I have been using it 
for 20 years) The screen flashes when you double-escape, in insert mode if you 
move to colum 1 things go nuts, insert mode is changed into some kind of 
vampire. None of the normal key mappings work, and I can't get my beloved vi 
back by restoring the virc from the virc.pacnew - GGR :-(

How do I make my vi return to normal? What's the trick? If restoring 
the virc 
and changing the settings has no effect (I even logged out and back) Wher are 
the magic settings now?

And... if the version I have can't be made to behave like my normal 
vi/vim 
again, "Then what is the proper way to downgrade vi so I can get my friend 
back?


-- 
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com

Re: [arch-general] dmraid-1.0.0rc15 in testing, need you help on this!

[Tobias Powalowski]

>   So I guess I will have to edit all the scripts to put an extra 'p' in 
> them
> as well. (Really kind of a pain, but if this new scheme is going to be the
> standard, I can do it, ...but if this is just a 'proposed' change, then I
> would rather not.
>
>   So is this Official? If so I don't mind changing them around and I know
> SuSE will eventually catch up. I've cc'ed Heinz Mauelshagen (the dev at
> Redhat to see if he thinks this is permanent. This does present a problem
> for Linux dual boot boxes. What was the reason to the change anyway?
>
>   Tobias, let me know if you want me to run any more test. (I don't have
> anything to rebuild right now or I would try the -R command which is an
> EXCELLENT addition to dmraid. Kuddos to the brainchild behind that.
Hi, 
since i didn't have changed the source code of dmraid i think it is an 
official change, i guess it follows the kernel name scheme here.

I try to add some more dmraid specific stuff to archboot setup routine.
Reading through this wiki:
http://wiki.archlinux.org/index.php/Installing_with_Fake-RAID

- Is it really enough to call dmraid -ay after you partitioned your raidset?
  Isn't this updated automatically?

- There are some mentions that you need to dmsetup remove_all before, which I
  think is not correct.

- Installing grub do i need this C H S hack? 
  Is grub failing if i just install it on (hd0)?

- How about lilo? Is lilo working without any modification?

Sorry for asking so many questions, but without the hardware some things are 
really difficult to guess.
Thanks for your help on this.
greetings
tpowa
-- 
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tp...@archlinux.org


signature.asc
Description: This is a digitally signed message part.