- Arch-general - lists.archlinux.org

[arch-general] VTs are unusable (too dim) after X starts
by didier gaumet 10 Jul '09

10 Jul '09

Hi all, It is probably trivial and I surely am the dumbest poster of the week, but I can't use my VT's (so dim that it is unusable) after X is started. During the boot process, VT1 is "normal" (i.e. readable). If I boot in a non-graphical mode (init level <5) there is no problem. If I boot in graphical mode (init level 5), the problem is persistent even if I switch to, say, an init level 3. My question: Have you met this problem and how did you solve it? I am not against reading docs and searching google or Archwiki but so far without success. My video card is an OEM ATI 9250, my monitor is an old Delta Electronics 17" CRT, Archlinux (i686) is up-to-date and booted via Grub2 without vga/video parameters (non framebuffer mode), X is used without an xorg.conf and automatically loads the radeon and drm modules. some info: ----------------------------------------------------------------------- $ lspci -vv 00:00.0 Host bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333] Subsystem: VIA Technologies, Inc. Device 0000 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx- Latency: 0 Region 0: Memory at e0000000 (32-bit, prefetchable) [size=256M] Capabilities: <access denied> Kernel driver in use: agpgart-via Kernel modules: via-agp 00:01.0 PCI bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333 AGP] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx- Latency: 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 0000c000-0000cfff Memory behind bridge: dfe00000-dfefffff Prefetchable memory behind bridge: bfc00000-dfcfffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: <access denied> Kernel modules: shpchp [...] 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01) (prog-if 00 [VGA controller]) Subsystem: Micro-Star International Co., Ltd. Device 9522 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 32 (2000ns min), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 16 Region 0: Memory at d0000000 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at c800 [size=256] Region 2: Memory at dfef0000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at dfec0000 [disabled] [size=128K] Capabilities: <access denied> Kernel modules: radeonfb 01:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (Secondary) (rev 01) Subsystem: Micro-Star International Co., Ltd. Device 9523 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 32 (2000ns min), Cache Line Size: 32 bytes Region 0: Memory at c8000000 (32-bit, prefetchable) [size=128M] Region 1: Memory at dfee0000 (32-bit, non-prefetchable) [size=64K] Capabilities: <access denied> ----------------------------------------------------------------------- # Config file for GRUB2 - The GNU GRand Unified Bootloader # /boot/grub/grub.cfg # DEVICE NAME CONVERSIONS # # Linux Grub # ------------------------- # /dev/fd0 (fd0) # /dev/sda (hd0) # /dev/sdb2 (hd1,2) # /dev/sda3 (hd0,3) # # Timeout for menu set timeout=5 # Set default boot entry as Entry 0 set default=0 # didier: modules insmod vbe insmod radeonfb # (0) Arch Linux menuentry "Arch Linux" { set root=(hd0,5) linux /vmlinuz26 root=/dev/sda7 ro initrd /kernel26.img } # (1) Arch Linux fallback menuentry "Arch Linux fallback" { set root=(hd0,5) linux /vmlinuz26 root=/dev/sda7 ro single initrd /kernel26.img } # (2) Memtest86+ menuentry "Memtest86+" { set root=(hd0,5) linux16 /memtest86+/memtest.bin root=/dev/sda7 } # (3) Windows menuentry "Windows" { set root=(hd0,3) chainloader +1 } ----------------------------------------------------------------------- Module Size Used by aes_i586 8100 0 aes_generic 27204 1 aes_i586 radeon 367232 2 drm 154720 3 radeon rfkill_input 6020 0 sco 10952 2 bridge 54040 0 stp 2088 1 bridge llc 5552 2 bridge,stp bnep 10916 2 l2cap 23940 3 bnep ipv6 277908 18 bluetooth 56484 5 sco,bnep,l2cap fuse 61088 2 arc4 1732 2 ecb 2788 2 b43 138720 0 snd_seq_dummy 2696 0 rfkill 10640 3 rfkill_input,b43 snd_seq_oss 31168 0 dvb_usb_cinergyT2 8716 0 usblp 13028 0 snd_seq_midi_event 7012 1 snd_seq_oss snd_seq 53744 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event dvb_usb 16752 1 dvb_usb_cinergyT2 mac80211 182880 1 b43 ueagle_atm 31132 0 usbatm 16004 1 ueagle_atm cfg80211 67332 2 b43,mac80211 dvb_core 86848 1 dvb_usb snd_pcm_oss 40352 0 snd_mixer_oss 17540 2 snd_pcm_oss atm 39924 1 usbatm led_class 3976 1 b43 input_polldev 3628 1 b43 snd_via82xx 24060 1 snd_ac97_codec 106088 1 snd_via82xx i2c_viapro 7384 0 i2c_core 22776 3 drm,dvb_usb,i2c_viapro ac97_bus 1540 1 snd_ac97_codec snd_pcm 73768 3 snd_pcm_oss,snd_via82xx,snd_ac97_codec snd_timer 21068 2 snd_seq,snd_pcm snd_page_alloc 8812 2 snd_via82xx,snd_pcm snd_mpu401_uart 7524 1 snd_via82xx ppdev 7720 0 via_ircc 18968 0 snd_rawmidi 21824 1 snd_mpu401_uart snd_seq_device 6768 4 snd_seq_dummy,snd_seq_oss,snd_seq,snd_rawmidi psmouse 59644 0 ssb 45932 1 b43 lp 9700 0 ns558 4548 0 irda 126744 1 via_ircc analog 10656 0 uhci_hcd 23476 0 ohci_hcd 24116 0 snd 58404 11 snd_seq_oss,snd_seq,snd_pcm_oss,snd_mixer_oss,snd_via82xx,snd_ac97_codec,snd_pcm,snd_timer,snd_mpu401_uart,snd_rawmidi,snd_seq_device serio_raw 5704 0 sg 27896 0 pcspkr 2404 0 8139too 24904 0 crc_ccitt 1700 1 irda soundcore 6784 2 snd via_agp 8324 1 pcmcia 36268 2 b43,ssb parport_pc 36932 1 parport 34476 3 ppdev,lp,parport_pc ehci_hcd 35824 0 gameport 11280 4 snd_via82xx,ns558,analog usbcore 149936 9 dvb_usb_cinergyT2,usblp,dvb_usb,ueagle_atm,usbatm,uhci_hcd,ohci_hcd,ehci_hcd pcmcia_core 35128 3 b43,ssb,pcmcia shpchp 34424 0 pci_hotplug 28964 1 shpchp 8139cp 21476 0 agpgart 32756 2 drm,via_agp mii 4804 2 8139too,8139cp thermal 13888 0 evdev 10176 10 processor 35864 0 fan 4392 0 button 5588 0 battery 10984 0 ac 4360 0 rtc_cmos 11244 0 rtc_core 18048 1 rtc_cmos rtc_lib 2500 1 rtc_core ext3 135340 3 jbd 48856 1 ext3 mbcache 7112 1 ext3 sr_mod 16676 0 cdrom 36032 1 sr_mod sd_mod 27808 6 pata_acpi 4228 0 ata_generic 4680 0 pata_via 9452 5 libata 168428 3 pata_acpi,ata_generic,pata_via floppy 55780 0 scsi_mod 110516 4 sg,sr_mod,sd_mod,libata ----------------------------------------------------------------------- $ grep EE /var/log/Xorg* /var/log/Xorg.0.log:Current Operating System: Linux pc-didier 2.6.30-ARCH #1 SMP PREEMPT Sat Jul 4 11:13:08 UTC 2009 i686 /var/log/Xorg.0.log: (WW) warning, (EE) error, (NI) not implemented, (??) unknown. /var/log/Xorg.0.log:(II) Loading extension MIT-SCREEN-SAVER /var/log/Xorg.0.log:(EE) open /dev/fb0: No such file or directory /var/log/Xorg.0.log.old:Current Operating System: Linux pc-didier 2.6.30-ARCH #1 SMP PREEMPT Sat Jul 4 11:13:08 UTC 2009 i686 /var/log/Xorg.0.log.old: (WW) warning, (EE) error, (NI) not implemented, (??) unknown. /var/log/Xorg.0.log.old:(II) Loading extension MIT-SCREEN-SAVER /var/log/Xorg.0.log.old:(EE) open /dev/fb0: No such file or directory /var/log/Xorg.0.log.old:(EE) XKB: No components provided for device Virtual core keyboard -----------------------------------------------------------------------

1 1

[arch-general] [signoff] device-mapper-1.02.33-1 & lvm2-2.02.48-1
by Eric Bélanger 10 Jul '09

10 Jul '09

Hi, I just pushed device-mapper-1.02.33-1 & lvm2-2.02.48-1 in testing. device-mapper-1.02.33-1 : minor upstream update, removed unneeded readline depends (close FS#15205) lvm2-2.02.48-1 : minor upstream update Please test and signoff. Users are encouraged to signoff too as only a few devs use this. Eric

1 0

Re: [arch-general] Mirror not updating
by Lee R. Burton 09 Jul '09

09 Jul '09

Sorry, just saw this email, RIT mirror is now syncing, ... seems a lockfile got stuck. Feel free to give me a call next time for a more rapid response to it. Thanks, Lee Burton lburton(a)mrow.org 301 910 0246 ----- Original Message ----- From: "Gerhard Brauer" <gerhard.brauer(a)web.de> To: arch-general(a)archlinux.org Sent: Thursday, July 9, 2009 10:00:00 AM GMT -05:00 US/Canada Eastern Subject: Re: [arch-general] Mirror not updating Am Donnerstag, den 09.07.2009, 09:27 -0400 schrieb David Rosenstrauch: > Anyone have contact info for the rit.edu mirror? It doesn't appear to > have been updated since June 30. I have contacted on Tuesday all mirror admin from the affected US/CA/EU mirrors, which are not synced and have all the same lastsync time. Only CA mirror http://mirror.twilightlair.net/arch is synced again from this block. I'll write a mail tomorrow again i nothing happens. > > Thanks, > > DR Gerhard "gerbra"

2 1

[arch-general] Are base packages assumed?
by Zé Ninguém 09 Jul '09

09 Jul '09

Hi there. I was wondering if base or base-devel packages should go in a package dependency list or not? What is the current policy about that? I noticed that the instructions to build a clean chroot tell to install base, base-devel and sudo, but does that means the package should be expecting them in a user system? Regards.

6 7

Re: [arch-general] Package release bump?
by Baho Utot 08 Jul '09

08 Jul '09

On Wed, 2009-07-08 at 23:54 +1000, Allan McRae wrote: > Baho Utot wrote: > > On Wed, 2009-07-08 at 23:04 +1000, Allan McRae wrote: > > > >> Baho Utot wrote: > >> > >>> I am following the process for the rebuild of all the package that > >>> depends on libjpeg. > >>> > >>> When rebuilding packages due to another package like libjpeg does the > >>> package release number for the dependent package get bumped? > >>> > >>> > >> If I understand you correctly, you can add a versioned dependency on the > >> updated pkgrel. > >> > >> e.g. imagemagick in [testing] has deps on lcms>=1.18-2 and libwmf>=0.2.8.4-5 > >> > >> Allan > >> > >> > >> > >> > > > > For example: > > > > (from another email for libjpeg > > > > Giovanni Scafora <giovanni(a)archlinux.org> > > Reply-to: Public mailing list for Arch Linux development > > <arch-dev-public(a)archlinux.org> > > To: Public mailing list for Arch Linux development > > <arch-dev-public(a)archlinux.org> > > Subject: Re: [arch-dev-public] WARNING: libjpeg rebuilds are entering > > [testing] - devs get building! > > ) > > > > "I just rebuilt following pkgs for testing x86_64 only: > > > > xmoto > > scribus > > kile > > kdetv > > graphicsmagick > > gimp-ufraw > > hugin > > enblend-enfuse > > kipi-plugins > > stellarium > > tuxpuck > > transcode > > fox > > centerim > > > > > > Do the packages above get the pkgrel bumped because of the change in > > libjpeg > > > > Or does the pkgrel number stay the same? > > > > > > I have a "builder script" that does an abs sync the builds only the > > packages in core/extra/local that have changed. It runs from cron on > > Sunday 1:00am. If I make a new PKGBUILD for a package I need I place it > > into "local" and the script then builds it automatically. I build the > > whole core/extra/local with optimizations for AMD k8. > > > > I then sync all my boxen from my repos. > > > > If the soname changes as in libjpeg and the packages that use libjpeg > > don't change ( the pkgrel stays the same ) then the only package that > > gets built would be libjpeg and none of the ones that depend on it. > > > > I hope that helps to explain my question. > > > > OK, the definitely the pkgrel gets changed. How else would pacman know > to update the package? > > Allan Ok, I was hoping that was the case, otherwise you folks would have busted up my script ;) My script is then go to go -- Never fear Arch Linux is here!

1 0

[arch-general] CTRL-C stops working in bash 4.0
by Damjan Georgievski 08 Jul '09

08 Jul '09

Has anyone noticed that ctrl-c randomly stops working in the new bash? I use rxvt-unicode 9.06-2 and it happens in a terminal where ctrl-c worked while typing bash commands, it will suddenly stop working ie bash will not recognise the key-press. If I start python in the same terminal, it will notice the ctrl-c, so it's not the terminals fault. This started to happen with bash 4.0 -- damjan

9 11

Re: [arch-general] Package release bump?
by Baho Utot 08 Jul '09

08 Jul '09

On Wed, 2009-07-08 at 23:04 +1000, Allan McRae wrote: > Baho Utot wrote: > > I am following the process for the rebuild of all the package that > > depends on libjpeg. > > > > When rebuilding packages due to another package like libjpeg does the > > package release number for the dependent package get bumped? > > > > If I understand you correctly, you can add a versioned dependency on the > updated pkgrel. > > e.g. imagemagick in [testing] has deps on lcms>=1.18-2 and libwmf>=0.2.8.4-5 > > Allan > > > For example: (from another email for libjpeg Giovanni Scafora <giovanni(a)archlinux.org> Reply-to: Public mailing list for Arch Linux development <arch-dev-public(a)archlinux.org> To: Public mailing list for Arch Linux development <arch-dev-public(a)archlinux.org> Subject: Re: [arch-dev-public] WARNING: libjpeg rebuilds are entering [testing] - devs get building! ) "I just rebuilt following pkgs for testing x86_64 only: xmoto scribus kile kdetv graphicsmagick gimp-ufraw hugin enblend-enfuse kipi-plugins stellarium tuxpuck transcode fox centerim Do the packages above get the pkgrel bumped because of the change in libjpeg Or does the pkgrel number stay the same? I have a "builder script" that does an abs sync the builds only the packages in core/extra/local that have changed. It runs from cron on Sunday 1:00am. If I make a new PKGBUILD for a package I need I place it into "local" and the script then builds it automatically. I build the whole core/extra/local with optimizations for AMD k8. I then sync all my boxen from my repos. If the soname changes as in libjpeg and the packages that use libjpeg don't change ( the pkgrel stays the same ) then the only package that gets built would be libjpeg and none of the ones that depend on it. I hope that helps to explain my question.

2 1

[arch-general] Package release bump?
by Baho Utot 08 Jul '09

08 Jul '09

I am following the process for the rebuild of all the package that depends on libjpeg. When rebuilding packages due to another package like libjpeg does the package release number for the dependent package get bumped?

2 1

Re: [arch-general] [arch-dev-public] WARNING: libjpeg rebuilds are entering [testing] - devs get building!
by Gerardo Exequiel Pozzi 08 Jul '09

08 Jul '09

Pierre Schmitz wrote: > On Wednesday 01 July 2009 14:12:05 Allan McRae wrote: > >> Devs, please remember to mark off rebuilt packages from the TODO list as >> you go. >> > > sane-frontends and netpbm do not compile. > > For sane-frontends (same for xsane: http://bugs.archlinux.org/task/15425#comment46571 ) ---------------------------------------------------------------------------------------------------- --- src/gtkglue.c.orig 2009-07-08 02:24:54.000000000 -0300 +++ src/gtkglue.c 2009-07-08 02:25:42.000000000 -0300 @@ -1476,8 +1476,7 @@ || opt->type == SANE_TYPE_GROUP || !dialog->element[i].widget) continue; - if (!(opt->cap & SANE_CAP_ALWAYS_SETTABLE)) - gtk_widget_set_sensitive (dialog->element[i].widget, sensitive); + gtk_widget_set_sensitive (dialog->element[i].widget, sensitive); } } ---------------------------------------------------------------------------------------------------- Thats all folks! -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

1 0

Re: [arch-general] [arch-dev-public] WARNING: libjpeg rebuilds are entering [testing] - devs get building!
by Gerardo Exequiel Pozzi 08 Jul '09

08 Jul '09

Eric Bélanger wrote: > On Wed, Jul 8, 2009 at 1:08 AM, Pierre Schmitz<pierre(a)archlinux.de> wrote: > >> On Wednesday 01 July 2009 14:12:05 Allan McRae wrote: >> >>> Devs, please remember to mark off rebuilt packages from the TODO list as >>> you go. >>> >> sane-frontends and netpbm do not compile. >> >> > > I just commited a patch for netpbm to fix some of the compile > problems. It still needs more patching to compile. The remaining error > is: > > jpeg.c: In function `ReadJPEG': > jpeg.c:473: error: `struct jpeg_decompress_struct' has no member named > `min_DCT_scaled_size' > > This is because min_DCT_scaled_size is no longer defined in libjpeg's > header files. I don't know how to fix it. I wasn't able to find any > patches. It seems that the libjpeg update is too new. > > Reading the libjpeg.h seems that replacing with min_DCT_v_scaled_size is fine. Quote from header: "Therefore, the IDCT output contains v_samp_factor*DCT_v_scaled_size sample rows of a component per iMCU row." buffer_height = cinfo.max_v_samp_factor * cinfo.min_DCT_v_scaled_size; But maybe I wrong. BTW: should be compiled with -fno-strict-aliasing there are some warnings about this, and the code can or not work correctly. -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

1 0