Re: [arch-general] Problems with install Iso

[Gerhard Brauer]

Am Mittwoch, den 19.08.2009, 19:05 +1000 schrieb richard terry:

> with the /arch/setup program I tried auto to do the whole drive (it was a
> brand new seagate 500gig HDD) > no action, just sat there.
> 
> I tried using CFDISK > create partitions > then the setting the mount points
> didn't recognise any partitions were there. After a couple of reboots and
> retries it did recognise the partition was there, but wouldn't let me
> allocate mount points. On one occasion it allowed me to allocated mount
> points but then just died.

First: best way is to open a bugreport
(http://bugs.archlinux.org/index.php?project=6) so that this isn't lost
in ML threads.

Myself never noticed such during my/our tests. AIF uses the normal tools
for partitioning and making filesystems.

So you could try 2 things:
a) Try using the normal tools to see if there is a problem with 2.6.30
kernel or the tools.
Make (with fdisk or cfdisk) to partitions on the HD.
Format these partitions afterwards (a reboot is not neeeded), for ex:
mkfs.ext2 /dev/sda1
mkfs.ext3 /dev/sda2
mount these partitions to /mnt
mount /dev/sda1 /mnt
mkdir /mnt/test
mount /dev/sda2 /mnt/test
Would this test work?

b) Start aif in debug mode and give us the log file.
Instead using /arch/setup start it with:
aif -p interactive -d -l
Best to go on with auto prepare. When you got stucked with above errors
you could look at the output on tty7. And please give us the
logfile /var/log/aif/aif.log after you could step further.


> Regards
> 
> Richard

Gerhard

Re: [arch-general] arch-release

[Gerhard Brauer]

Am Mittwoch, den 26.08.2009, 09:56 +0200 schrieb Jan de Groot:

> As Arch is a rolling release system, we decided to remove the file. But
> as tools use this file to identify Arch systems, we decided to keep the
> file, but make it empty.
> 
> 2009.08 won't be 2009.08 as soon as you run pacman -Syu ;)

To far this we could maybe add a function to pacman, so that after every
-Syu the unixtime gets written to this file.
This would give us:
* IMHO the highest version/release number a software/distribution ever
  have.
* The individual content of this file then represent the nature of a
  rolling release.

Ok, just kidding ;-)

Gerhard

Re: [arch-general] arch-release

[Gerhard Brauer]

Am Mittwoch, den 26.08.2009, 10:45 +0200 schrieb Jan de Groot:
> On Wed, 2009-08-26 at 10:40 +0200, Gerhard Brauer wrote:
> > 
> > To far this we could maybe add a function to pacman, so that after every
> > -Syu the unixtime gets written to this file.
> > This would give us:
> > * IMHO the highest version/release number a software/distribution ever
> >   have.
> > * The individual content of this file then represent the nature of a
> >   rolling release.
> > 
> > Ok, just kidding ;-)
> 
> And within 28 years it will overflow so we have a negative version
> number :P

I'm sure we will find a solution until this happens.
Maybe we make 2037 our first "Release", so we would have an offset to
add... ;-)

Gerhard

Re: [arch-general] arch-release

[Gerhard Brauer]

Am Mittwoch, den 26.08.2009, 10:52 +0200 schrieb Dieter Plaetinck: 
> 
> maybe we should put the output of `pacman -Q | sha1sum` in /etc/arch-release. 
> git style! :P

Neat!

Or the percentage of our roadmap to world domination (BTW: i always
missed this in Roadmap on Flyspray)

> Dieter

Gerhard

[arch-general] [kernel26 >= .30 + e100] Slow ethernet

[Gerhard Brauer]

Hi,

since 2.6.30.x (i could not exactly say if also with the latest
2.6.29.x) stock kernels i have a terrible slow ethernet transfer rate on
my old Thinkpad T22 (Intel EtherExpress PRO/100 SP, module e100).

Normal transfer rate ex. to a mirror is for me ~700Kb/s but i got only
~80-90 Kb/s. And a bunch of RX overruns and frame errors.

I could solve it by following workarounds:
a) Disable ACPI (acpi=off), but this is the ugliest workaround.

b) When i generate CPU-Load (ex: dd if=/dev/zero of=/dev/null) the
transfer rate goes immediately up to normal and the RX error rate
increasing stops. Stopping the dd the rate goes down again. So i thought
it could be a timer/IRQ problem.
I tried different acpi= and pci= kernel parameters without success. Also
tried to isolate the Ethernet device to a non-shared IRQ.

c) Current working solution is if i use nohz=off as kernel param.
But testing with an 2.6.28 kernel i have installed on this TP there is
CONFIG_NO_HZ=y also set (diff is only that this kernel has
CONFIG_HZ=1000 and 2.6.30/31 CONFIG_HZ=300, but AFAIK if bootet with
NOHZ these settings are ignored (tickless)).

So there must be a signifikant change in >= 2.6.30 (tested 2.6.31 from
testing also). Anyone has an idea to solve it without nohz parameter? I
also could report it to LKML if this seems a bug (for me it is).

Regards
Gerhard

Re: [arch-general] Xorg 1.9 - This traing is going to hell.

[Gerhard Brauer]

On Thu, Sep 30, 2010 at 07:51:23PM +0400, Fess wrote:
> Well, i think, i should say some words.
> But some of you will say that i'm "out of line".
> So, i'll just dicribe details of the update.

I also have problems with XOrg 1.9 on my old Thinkpad T22 (savage
video chip). With the new version i could not switch between X and
tty consoles without a freeze of the system (only SysReq works). I
got small red lines on top of the screen if i switch from tty back
to X and then it freezes. No matter if i user framebuffer (vga=) or
not (savage driver don't uses KVM)
More badly was that also a resume from mem or disk suspend doesn't
work anymore, also a freeze.

Switching back to XOrg 1.8 (downgrade also the depended packages)
works fine again.
I think for myself this was the last XServer upgrade i will have
tried on this laptop.

[OT/Ranting on]
Last 1-2 years i'm realy getting more and more annoyed about the
quality of software developement on core things. I'm not saying this
is our/ArchLinux problem (ok, maybe 5% of bad packaging or similar).
IMHO the quality of upstream developers or developement processes are the
reason. I notice more and more "little" things with side-effects
which get broken from minor to minor upgrade, and i waste my time to
see which package may be the reason.
But every week  new "features" and concepts which will probably
break something on core/base functionality. Meanwhile mostly IMHO at
older hardware and often things which work fine in earlier software
versions. The problems related to XServer were so many last year(s),
since it becomes XOrg, i could not remember such behavior on the
"good old" xfree86 days. In the past one could say: If you have
older hardware and something works fine then this was "rock solid"
in the feature. But i have last 1,2 years (kernel and X related) so
many issues with tty/X switches, Fn-Keys which works and not, mouse
wheels and trackpoint failures, suspend/resume failures...

IMHO there are more and more "young developers", fresh from
university/school, who work on core things. Those have good ideas of
"features", they're hacking times faster than i could speak, but the
quality/stability of the core things is a pain. Ok, next developer.
His/her new ideas are primary, old failures won't got fixed (and
something other is broken). I'm not a developer, i have big respect
on all, but more and more things pisses me of on my linux
workstations the last years... (Maybe the reason for some things are
the compilers, too good on optimazing on "older" code... XOrg 1.9
savage driver is ~5k smaller than 1.8, maybe TTY/X switching was
optimized to /dev/null )

- Kernel update on my T22 to 2.6.35 floods my log with drive not
ready/media errors of my swap partion (only the swap partition!)
New mkswap doesn't solve it. I'm too old to think that the surface
of my harddisk got broken the last 15min before the kernel upgrade.
So switched back to old kernel - same problem (swap is activated,
but log flood about media errors). Doing mkswap again under 2.6.33
(the last working version for others reasons), reboot anbd all is
fine again. Also a dd if=/dev/zero to the swap partition shows no
drive/media errors. But why on 2.6.35? WTF?

- 2.6.33 ist the last working version on which after a
suspend/resume my wireless device re-connects failure-less to a
access point(ath5k).

- 2.6.33, an older version of pm-utils and an older version of XOrg
was the last state where i could switch from X to tty (and back) and
when i could use the TTY's also after a resume. Before the above
mentioned new problems with XOrg 1.9 the switch to TTY was still
broken after suspend/resume.

- Fn-Keys for Suspend or toggle of X-backlight are broken since
weeks. I have to test every time new features bitmap of
thinkpad-acpi module on different kernel/pm-utils versions to enable
them working again...

- Since ~2.6.28 the bandwith of my ethernet device(e100) is reduced to 10%
of the maximum. Only if i use nohz=off as kernel param or if i
produce cpu load (100%) my bandwith goes up again. Last month i
found the "reason": it happens only if i have the speedstep-smi module
loaded! With ee100pro module i never have had such thing, also an
earlier 2.6.28 patchlevel works fine IIR... This is such an
interesting bug so i think i will report it to LKML...

These are some of the core things (for me, i don't care if my mpd is
broken) that makes me angry... ;-)
[OT/Ranting off]

Regards
Gerhard (still alive)

[arch-general] [rc.d/network] Integrate wpa_supplicant as wireless framework?

[Gerhard Brauer]

Hi,

our current default wireless framework in base /e/rc.d/network
script is iwconfig (Open/WEP only). I like to integrate
wpa_supplicant as easy as we could use iwconfig ATM.

iwconfig is a useless framework in most user environments in these
days (most AP's have a stronger encryption than WEP'), but it is a
"easy" tool.

Two possibilities:
a) Throw away iwconfig(wireless-tools package) from rc.d/network and
use wap_supplicant only. wpa_supplicant could of course do all the
things iwconfig is for.

b) Let the user decide wihich wireless framework. This could be done
by seperate /e/conf.d/wireless from wireless_tools and add therin
config options for each iwconfig and wpa_supplicant.
Ex.:

#wlan_eth0="iw|eth0 mode managed essid default"
#wlan_wlan0="wpas|"

#WLAN_INTERFACES=(eth0 wlan0)
-
So /e/rc.d/network->wi_up() has to be modified to honor also
wpa_supplicant.

For both ways /e/wpa_supplicant.conf should get modified to a
cleaner default config (Most comments and examples). We should
provide a config file with activated entries for OPEN wlan and WEP
connections (User has to modify WEP essid and key), and also a
deactivated entry for common WPA2/PSK wlan(User has to modify and
activate this for his/her needs).

The advantage of using wpa_supplicant at least in addition to
iwconfig is IMHO the easy and straightforward integration in our
network settings (r.conf and conf.d/wireless). No need for extra
packages like Netcfg, wicd, networkmanager to associate to WPA
infrastructure (but could be used by users if they want their
"funcionality"").

What do you think about?

Regards
Gerhard "gerbra"

Re: [arch-general] [rc.d/network] Integrate wpa_supplicant as wireless framework?

[Gerhard Brauer]

On Tue, Nov 09, 2010 at 10:42:16PM +0100, Thomas Bächler wrote:
> Am 09.11.2010 14:55, schrieb Gerhard Brauer:
> > Hi,
> 
> Hi Gerhard, it is nice to hear from you after such a long time :)
Yeah, no more R.I.P (rest in pieces), or:
"Auferstanden aus Ruinen..." ;-)

> 
> > our current default wireless framework in base /e/rc.d/network
> > script is iwconfig (Open/WEP only). I like to integrate
> > wpa_supplicant as easy as we could use iwconfig ATM.
> 
> All existing features should be ported to netcfg, and new features will
> only be added there. Again, lack of time prevents me from doing that too
> - but it's the plan.

Ok, i'm fine with. Have used netcfg last before ~2 years or so, it
is currently much better.
I will have a deeper look next weeks (on the bridging part, maybe i
could add VPN support on that easy way...)

> Back to the topic of wireless: netcfg's net-auto-wireless mode is my
> favorite and works perfectly for me.

Yes, also together with net-auto-wired it works fine. I'm only not
sure if i use network-profile seperate configs or better go with
wireless-wpa-config ("static" /e/wpa_supplicant.conf) cause i often
use wpa_gui with option to update the config.

Also i will use different "actions" based on different DHCP server's
and/or MAC addresses found by the active devices. But this seams
also possible (without more work than one need for ifplugd as single
tool...)

Regards
Gerhard

Re: [arch-general] [arch-dev-public] consolekit dependencies?

[Gerhard Brauer]

Sorry for maybe double-posting, fist sent with wrong from-address
;-)

On Sat, Oct 13, 2012 at 04:34:04PM +0200, Tom Gundersen wrote:
> On Sat, Oct 13, 2012 at 11:42 AM, Thomas Bächler  wrote:
> > Most (all?) of our login manager still depend on consolekit. However,
> > since consolekit support will be stripped from polkit when
> > gnome-unstable goes to testing (soon?), registering consolekit sessions
> > on login has no effect whatsoever.
> >
> > Should we rebuild our login managers to remove the consolekit dependencies?
> >
> > I rebuilt kdebase-workspace locally yesterday, and polkit seems to work
> > just fine. kde itself does not use consolekit, except through polkit.
> 
> Doing this makes sense to me. However, to make things clear-cut, it
> would be best if we could entirely remove consolekit from our repos
> and put up an announcement. That way people will not be confused as to
> why things stop working if they are not using logind.

This makes me a little nervous…
What are the way for people which ex. use fluxbox via
ck-launch-session and thunar as a filemanager (for
dbus/polkit/udisks things) AND NOT systemd-logind ?

Will there be a way to use dbus/polkit-releated actions without
systemd?

I got more and more confused about the speed and amount of changes
currently ;-)

> Cheers,
> 
> Tom

Regards
Gerhard
 

[arch-general] Change kernel version or module dir at bootprompt?

[Gerhard Brauer]

Hello,

i've searched a while and found nothing. And AFAIK there isnt't an
chance to do this. But maybe one of you know a trick, a magic...

Is it possible to change either the kernel version (what uname -r says)
or the location of the kernel modul dir at boottime?

I think about an easy solution to backup an arch kernel with it's
modules.
But since the kernel version is fix and releated to the module dir one
could not simply copy /lib/modules/foo.bar to ex.
/lib/modules/foo.bar-backup.

Anyone knows a trick?

Thanks
Gerhard

-- 
Virus gefunden - Bundestrojaner_BT32/W
Dieser Schaedling steht auf dem Boden
der freiheitlich-demokratischen Grundordnung.
Sie haben folgende Moeglichkeiten:
Mit Nein die Abwehr abzuwenden oder mit
jeder anderen Taste die Installation fortzusetzen.

[arch-general] firefox-i18n

[Gerhard Brauer]

Hello,

thanks for fixing firefox (#8780).

Could someone of the DEVs also build a fixed package of firefox-i18n
(#8786)?

Bye
Gerhard

-- 
HAL is running Windows...

Re: [arch-general] Change kernel version or module dir at bootprompt?

[Gerhard Brauer]

Gruesse!
* Xavier <[EMAIL PROTECTED]> schrieb am [01.12.07 11:11]:

Oh, i miss Jame's mail, so in answer you.

> On Sat, Dec 01, 2007 at 05:05:46PM +1100, James Rayner wrote:
> > the kernel version is also embedded into the individual modules, so you'd
> > have to modify the kernel and every module. You might be able to do some
> > ugly sed trickery, but I really discourage it -- you're asking for
> > trouble.. and it probably won't work.

Are you sure? Ay, yes is see: 2.6.23-ARCH SMP preempt mod_unload 686
Ok, this is a "neutral" entry, but changing KERN_VER is not possible, i
agree.

> > Why would you want to do something like this anyway?

As others say: for a quick backup before a kernel-update.
For myself i have a own "rescue" kernel on all important machines. But
the only way to have such is to build a whole kernel.
I thought about an less time expensive method.

First thougt myself was for ex. add a VAR to pacman.conf BackupKernel =
yes|no and then add something like pre-install/update to
kernel26.install file.

> But it's still a problem. There was a request for a fallback kernel, but it
> was apparently rejected :
> http://bugs.archlinux.org/task/7926

I must read this.

After James comment about the vermagic entries i mentioned about a
"hack" in initrd-hooks to bypass this problem.
Ex: we have /lib/modules/kernel26-ARCH which is real 2.6.23.8-1.
One woul like to test the new kernel from testing.
At the moment testing-kernel overwrites the stock arch kernel.

But if (maybe a script):
- Backup kernel and initrd-iamge
- copy /lib/modules/kernel26-ARCH to a backup in /lib/modules
- Have a bootloader entry for backup kernel with a parameter
useoldkernel=yes

Then a hook in initrd.img check useoldkernel and do:
- mv /lib/modules/kernel26-ARCH to something similar
- do a symlink or mv from backup module dir to
/lib/modules/kernel26-ARCH.

I don't know if this could be done in the initrd-image. But if, we have
AFAIK no problem with vermagic in the "new" module dir.

You see, i puzzle a little round that "problem" ;-)

Bye
Gerhard

-- 
Don't drink and root!

Re: [arch-general] firefox-i18n

[Gerhard Brauer]

Gruesse!
* Thomas Bächler <[EMAIL PROTECTED]> schrieb am [01.12.07 16:00]:
> Gerhard Brauer schrieb:
> > Hello,
> > 
> > thanks for fixing firefox (#8780).
> > 
> > Could someone of the DEVs also build a fixed package of firefox-i18n
> > (#8786)?
> > 
> > Bye
> > Gerhard
> 
> http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/i18n/firefox-i18n/PKGBUILD.diff?r1=1.12&r2=1.13&cvsroot=Extra
> I am really confused about that, alex seems to have changed the path
> when updating it.

Yeah, the problem in 1.13 is:
install -D -m 644 chrome.manifest
${startdir}/pkg/usr/opt/mozilla/lib/firefox-${pkgver}/chrome/${lang}.manifest
|| return 1

It's the /usr/opt/mozilla path, should be /opt/mozilla


Bye
Gerhard

-- 
Schlagt den Raab!

Re: [arch-general] Change kernel version or module dir at?bootprompt?

[Gerhard Brauer]

Gruesse!
* Tobias Powalowski <[EMAIL PROTECTED]> schrieb am [02.12.07 10:20]:
> 
> Why you jsut don't use the installation ISO kernel and initrd?
> you get everything to rescue from it and it includes everything.
> no hacks at all only enter it in your grub.
> you can also boot into your existing system with it.

Sometimes the machine isn't easy to reach. At home one could put the CD
into drive, but i think also about machines where one must drive ~100 Km
Or machines (Webserver, etc) managed by hosters...

> greetings
> tpowa

Bye
Gerhard

-- 
Kernel panic: Could not determine whether
bit was one, zero or sqrt(1/PI)...
(J.K. in d-u-g)

Re: [arch-general] Change kernel version or module dir?at?bootprompt?

[Gerhard Brauer]

Gruesse!
* Tobias Powalowski <[EMAIL PROTECTED]> schrieb am [02.12.07 16:06]:
> 
> i meant that you install the kernel from the ISO in combination with the 
> initrd.
> that it is available on the disk and not that you need to boot the cd itself.

At the risk that i misunderstand this, but:
At the moment i could do this, Kernel on ISO is 2.6.22. But when 2.6.23
reaches the ISO, we have the same problem as now: a collision between
uname -r/lib/modules from ISO to stock kernel.

Or am i think completly stupid?

> greetings
> tpowa

Bye
Gerhard

-- 
A: Weil es die Lesbarkeit des Textes verschlechtert.
Q: Warum ist TOFU so schlimm?
A: TOFU
F: Was ist das groesste Aergerniss im Usenet?

Re: [arch-general] Change kernel version or module?dir?at?bootprompt?

[Gerhard Brauer]

Gruesse!
* Pierre Schmitz <[EMAIL PROTECTED]> schrieb am [02.12.07 19:49]:
> Am Sonntag, 2. Dezember 2007 19:41:21 schrieb Gerhard Brauer:
> > At the moment i could do this, Kernel on ISO is 2.6.22. But when 2.6.23
> > reaches the ISO, we have the same problem as now: a collision between
> > uname -r/lib/modules from ISO to stock kernel.
> 
> no, because all modules are within the initrd.

Hello my Massa("Meister"),

*that* sounds simple, *that* seems to be KISS...

I think, we have a knew theme for wiki.archlinux.de ;-)

Bye
Gerhard

-- 
Virus gefunden - Bundestrojaner_BT32/W
Dieser Schaedling steht auf dem Boden
der freiheitlich-demokratischen Grundordnung.
Sie haben folgende Moeglichkeiten:
Mit Nein die Abwehr abzuwenden oder mit
jeder anderen Taste die Installation fortzusetzen.

Re: [arch-general] firefox-i18n

[Gerhard Brauer]

Gruesse!
* Thomas Bächler <[EMAIL PROTECTED]> schrieb am [01.12.07 16:00]:
> Gerhard Brauer schrieb:
> > 
> > Could someone of the DEVs also build a fixed package of firefox-i18n
> > (#8786)?
> 
> I am really confused about that, alex seems to have changed the path
> when updating it.

Sorry, it's me again ;-)
At the risk that i'm bothersome, but is it so complex to build a fixed
language package for FF?

Some users have build meanwhile their own fixed package.
In my opinion this was *our* bug, selfmade ;-)

What is the impression if we don't fix it as quick as the fault
happened?

Bye
Gerhard

-- 
archlinux.de

[arch-general] FTP-ISO 2007.08-2 Bug (wrong PATH for root)

[Gerhard Brauer]

Hello,

a user of archlinux.de have point me to problems with his install from
current ftp-iso. Many commands (reboot, adduser) were not found.

I've tested it here and see that after the installation root has a silly
PATH. There is for ex. /usr/gnu/bin but not /sbin or /usr/sbin.

At the moment i try a second install to be sure that i've make no
mistake. I searched for a bugreport, but found nothing.

I'll write one if i can be sure of this wrong path, ok ?

Bye
Gerhard
archlinux.de

-- 
It's nice to be important...
but it's more important to be nice.

Re: [arch-general] FTP-ISO 2007.08-2 Bug (wrong PATH for root)

[Gerhard Brauer]

Gruesse!
* Dan McGee <[EMAIL PROTECTED]> schrieb am [04.12.07 02:04]:
> On Dec 3, 2007 6:41 PM, Gerhard Brauer <[EMAIL PROTECTED]> wrote:
> >
> > I've tested it here and see that after the installation root has a silly
> > PATH. There is for ex. /usr/gnu/bin but not /sbin or /usr/sbin.
> >
> 
> See <http://archlinux.org/pipermail/arch-dev-public/2007-December/003548.html>

Thank you, Dan.
Next time i'll read also the sign offs in dev-public ;-)

Bye
Gerhard

> -Dan

-- 
Never use a running system...

[arch-general] Kernel OOPS with AVM fwlanusb

[Gerhard Brauer]

Hello,

i have a AVM wlan usb stick for testing, usb id 057C:6201.
I try the avm linux driver with kernel 2.6.23.12-2. Build and modprobe
is ok, inserting the stick gaves after a long period of waiting the
wlan0 device.
iwpriv wlan0 work, iwconfig stopped with a segfault and a oops.

I'm not a kernel guru or developer, but maybe could someone say (without a
full dump or so) what the reason for this trap?
(Yeah, i know the short answer: tainted by fwlanusb ;-)
If @tpowa reads this:
if see strcopy in trap, could this be something similar we have had with
avm fritz card and the objcopy-Patches?
Thank you for having a look at this!
Legend: 14:33:10 after modprobe and wlan0 ready
14:33:45 iwconfig

-
Dec 22 14:33:10 tux1 fwlanusb: Config manager successully created and
started.
Dec 22 14:33:45 tux1 BUG: unable to handle kernel NULL pointer
dereference at virtual address 
Dec 22 14:33:45 tux1 printing eip:
Dec 22 14:33:45 tux1 f8d9c38e
Dec 22 14:33:45 tux1 *pde = 
Dec 22 14:33:45 tux1 Oops:  [#1]
Dec 22 14:33:45 tux1 PREEMPT SMP
Dec 22 14:33:45 tux1 Modules linked in: fwlanusb(P) usb_storage ide_core
appletalk ipx p8022 psnap llc p8023 nvidia(P) ipv6 usblp usbhid hid
ff_memless ppdev tsdev lp pcspkr container parport_pc parport rtc_cmos
rtc_core rtc_lib ppp_generic psmouse serio_raw i2c_i801 i2c_core
ehci_hcd intel_agp agpgart uhci_hcd shpchp pci_hotplug sg evdev thermal
processor fan button battery ac smsc47m1 snd_seq_oss snd_seq_midi_event
snd_seq snd_seq_device snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_pcm
snd_timer snd_page_alloc snd_mixer_oss snd soundcore ac97_bus slhc
eepro100 e100 mii usbcore ext3 jbd mbcache sr_mod cdrom sd_mod ata_piix
ata_generic libata
Dec 22 14:33:45 tux1 CPU:0
Dec 22 14:33:45 tux1 EIP:0060:[]Tainted: PVLI
Dec 22 14:33:45 tux1 EFLAGS: 00210282   (2.6.23-ARCH #1)
Dec 22 14:33:45 tux1 EIP is at strcpy+0xd/0x1b [fwlanusb]
Dec 22 14:33:45 tux1 eax: f1cc1f44   ebx: ffa1   ecx: f1cc1f44
edx: f8de351e
Dec 22 14:33:45 tux1 esi:    edi: c035b984   ebp: c038602c
esp: f1cc1e54
Dec 22 14:33:45 tux1 ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
Dec 22 14:33:45 tux1 Process iwconfig (pid: 7769, ti=f1cc
task=f1cc2a80 task.ti=f1cc)
Dec 22 14:33:45 tux1 Stack: c0419500 f1cc1f44 8b01 f8ddf95c c035b984
 f1e8a000 c015e356
Dec 22 14:33:45 tux1 c041950c c0419500 00200246 c04195c0 c04195c0
f1cc1f34 c0360d8a 8b01
Dec 22 14:33:45 tux1 ffa1 f8825400 f1e8a000 c04195cc 
  f1e8a000
Dec 22 14:33:45 tux1 Call Trace:
Dec 22 14:33:45 tux1 [] fwlanusb_get_name+0xc/0x10 [fwlanusb]
Dec 22 14:33:45 tux1 [] ioctl_standard_call+0x64/0x370
Dec 22 14:33:45 tux1 [] filemap_fault+0x206/0x490
Dec 22 14:33:45 tux1 [] __mutex_lock_slowpath+0x16a/0x2d0
Dec 22 14:33:45 tux1 [] e100_do_ioctl+0x0/0x30 [e100]
Dec 22 14:33:45 tux1 [] wext_handle_ioctl+0x3b6/0x450
Dec 22 14:33:45 tux1 [] fwlanusb_get_name+0x0/0x10 [fwlanusb]
Dec 22 14:33:45 tux1 [] fwlanusb_get_name+0x0/0x10 [fwlanusb]
Dec 22 14:33:45 tux1 [] pty_write+0x47/0x60
Dec 22 14:33:45 tux1 [] dev_ioctl+0x341/0x350
Dec 22 14:33:45 tux1 [] __wake_up+0x3e/0x60
Dec 22 14:33:45 tux1 [] sock_ioctl+0x0/0x210
Dec 22 14:33:45 tux1 [] do_ioctl+0x2b/0x90
Dec 22 14:33:45 tux1 [] vfs_ioctl+0x22e/0x2b0
Dec 22 14:33:45 tux1 [] sys_ioctl+0x5d/0x70
Dec 22 14:33:45 tux1 [] sysenter_past_esp+0x6b/0xa1
Dec 22 14:33:45 tux1 [] schedule+0x4a0/0x5e0
Dec 22 14:33:45 tux1 ===
Dec 22 14:33:45 tux1 Code: c3 8b 4c 24 08 8b 54 24 0c 8b 44 24 10 89 4c
24 04 89 54 24 08 89 44 24 0c e9 b6 ff ff ff 57 56 83 ec 04 8b 74 24 14
8b 7c 24 10  aa 84 c0 75 fa 8b 44 24 10 59 5e 5f c3 57 56 83 ec 04
8b 74
Dec 22 14:33:45 tux1 EIP: [] strcpy+0xd/0x1b [fwlanusb] SS:ESP
0068:f1cc1e54
---

Bye
Gerhard

-- 
Dont't drink and root!

Re: [arch-general] Kernel OOPS with AVM fwlanusb

[Gerhard Brauer]

Gruesse!
* Gerhard Brauer <[EMAIL PROTECTED]> schrieb am [22.12.07 15:05]:
> If @tpowa reads this:
> if see strcopy in trap, could this be something similar we have had with
> avm fritz card and the objcopy-Patches?
> Thank you for having a look at this!

Ok, i solved it. It was the same issue as with fcpci.
Patching *.lib.o with objcopy result in an working module.

Run's stable with wpa_supplicant (much better than with ndiswrapper).
I'll make a PKGBUILD for AUR soon.

Bye
Gerhard

-- 
Schlagt den Raab!

[arch-general] Mirror out of sync [tu.chemnitz.de]

[Gerhard Brauer]

Hello,

One german mirror, tu.chemnitz.de, is not synced since 12.12.2007.

Bye
Gerhard

-- 
Bundestrojaner - wir sind die Guten!
Nur echt mit 52 Verfassungsbruechen!

Re: [arch-general] Mirror out of sync [tu.chemnitz.de]

[Gerhard Brauer]

Gruesse!
* Roman Kyrylych <[EMAIL PROTECTED]> schrieb am [09.01.08 13:42]:
> 2008/1/6, Gerhard Brauer <[EMAIL PROTECTED]>:
> > Hello,
> >
> > One german mirror, tu.chemnitz.de, is not synced since 12.12.2007.
> >
> 
> Actually, since 14-Dec-2007 (date of extra.db.tar.gz).
> Does anyone know how to contact the mirror admin?

This mirror is another time out of date.
core.db.tar.gz is from 14.01.2008.

Could/Should we users "mailbombing" ftpmaster?
If these problems with this german mirror are not fixable i would prefer
to cancel this mirror.
And i would prefer to change the default /etc/pacman.d/mirrorlist to
have *this* mirror not at the first position for Germany.
Hosteurope is good (ok, at the moment no connect) and archlinuxppc AFAIK
also.
# - Germany
Server = ftp://ftp.hosteurope.de/mirror/ftp.archlinux.org/$repo/os/i686
Server = ftp://ftp.archlinuxppc.org/i686/$repo/os/i686
Server = ftp://ftp.hosteurope.de/mirror/ftp.archlinux.org/$repo/os/i686

Gerhard

-- 
Kuenstliche Intelligenz ist der Feind
der natuerlichen Dummheit.

[arch-general] Searching reference server for mirror checking

[Gerhard Brauer]

Hello,

i'm working on a script to check the sync status of the mirrors.
Actually i use ftp.archlinux.org as a reference but Pierre Schmitz point
to me that this is also only a mirror which must not be in sync.

So is there a server (ftp or http) from where i could get the mtime,
size and the repository db file as a reference?
Pierre told me that he could run this script on his server, but for
testing and bugfixing ;-) i need a reliable source. At the moment it
seems i got too many false positives...

  Gerhard

-- 
Never use a running system...

Re: [arch-general] Searching reference server for mirror checking

[Gerhard Brauer]

Gruesse!
* eliott <[EMAIL PROTECTED]> schrieb am [27.01.08 23:22]:
> On 1/27/08, Gerhard Brauer <[EMAIL PROTECTED]> wrote:
> >
> > So is there a server (ftp or http) from where i could get the mtime,
> > size and the repository db file as a reference?
> 
> no. there is not a publicly accessible location of the repo db file
> other than mirror servers.
> ftp.archlinux.org is the best candidate. the two servers (round robin
> dns for ftp.archlinux.org) synchronize approximately every hour.

Thank you. Then i must see if there are realy so many mirrors out of
sync or if i have beasty little things in my script ;-)
Maybe something with the UTC times on the mirrors...

 Gerhard

-- 
Ich bin nicht die Signatur,
ich putz' hier nur!

Re: [arch-general] Searching reference server for mirror checking

[Gerhard Brauer]

Hello!

Ok, i'am 99% ready with the script (mostly output and "internally
cleaning"). I put the output as txt attachement in this mail.

Short:
Overall Status
--
Mirrors tested. : 49
Mirrors with connection problems... : 2
Mirror with data collection problems: 5

Mirrors OUT of sync : 25

Legend for txt file:
size means *.db.tar.gz size reported by either FTP or HTTP mirror
mtime also taken from protocols, converted to UTC if needed
md5sum after doenlaod db file.

Some mirrors seams to have the correct file size, but mtime and/or
md5sum differs. I've checked some of them and there seams to bee
slightly corrupted files on there.

Next i will version pumping on the script (it's a ruby script) from now
0.1 to 1.0 ;-) and then we could see if this is something usefull for
us.

 Gerhard

-- 
Ein Registry-Cleaner ist fuer Win-User
der Bulldozer des kleinen Mannes.
Mirror check on: Mon Jan 28 16:01:42 +0100 2008
 Mon Jan 28 15:01:42 UTC 2008
Connecting to main server...
Connecting ftp.archlinux.org (FTP)... OK
References:

community-x86_64  :   342274 Mon Jan 28 10:01:02 UTC 2008 
0e9985317bf30dc4269ba036c669f169
extra-i686:   318137 Mon Jan 28 06:30:32 UTC 2008 
d4ed2eff69461c639a0e25849ba365e0
core-x86_64   :23699 Mon Jan 28 10:35:37 UTC 2008 
c672afac0f9fd193f54deb7d04280084
extra-x86_64  :   310961 Mon Jan 28 06:32:16 UTC 2008 
51f93864b8f139825c0f7684f7d30374
core-i686 :23686 Mon Jan 28 10:35:07 UTC 2008 
97377a75342afae58bdbafb94b6781d7
community-i686:   347717 Mon Jan 28 08:01:00 UTC 2008 
bbee172a7111e991183f6546ffa45409

Going on with the mirrors...
Connecting ftp.archlinux.org (FTP)... OK
Connecting ftp.nethat.com (FTP)... NOK
Connecting locke.suu.edu (FTP)... OK
Connecting mirrors.unixheads.org (FTP)... OK
Connecting ftp-linux.cc.gatech.edu (FTP)... OK
Connecting mirror.cs.vt.edu (FTP)... OK
Connecting mirrors.easynews.com (HTTP)... OK
Connecting ftp.ibiblio.org (FTP)... OK
Connecting holmes.umflint.edu (HTTP)... OK
Connecting archlinux.c3sl.ufpr.br (HTTP)... OK
Connecting archlinux.c3sl.ufpr.br (FTP)... OK
Connecting gd.tuwien.ac.at (FTP)... OK
Connecting ftp.belnet.be (FTP)... OK
Connecting ftp.sh.cvut.cz (FTP)... OK
Connecting ftp.estpak.ee (FTP)... OK
Connecting ftp.sixnix.net (FTP)... OK
Connecting mir1.archlinuxfr.org (FTP)... OK
Connecting mir2.archlinuxfr.org (FTP)... OK
Connecting distrib-coffee.ipsl.jussieu.fr (FTP)... OK
Connecting mir.archlinux.fr (HTTP)... OK
Connecting ftp.free.fr (FTP)... OK
Connecting ftp.tu-chemnitz.de (FTP)... OK
Connecting ftp.hosteurope.de (FTP)... OK
Connecting ftp.archlinuxppc.org (FTP)... NOK
Connecting www.mirrorservice.org (HTTP)... OK
Connecting ftp.ntua.gr (FTP)... OK
Connecting ftp.mfa.kfki.hu (FTP)... OK
Connecting ftp.heanet.ie (FTP)... OK
Connecting mi.mirror.garr.it (FTP)... OK
Connecting ftp.nluug.nl (FTP)... OK
Connecting ftp.surfnet.nl (FTP)... OK
Connecting ftp.icm.edu.pl (FTP)... OK
Connecting mirror.icis.pcz.pl (FTP)... OK
Connecting piotrkosoft.net (HTTP)... OK
Connecting ftp.piotrkosoft.net (FTP)... OK
Connecting cesium.di.uminho.pt (FTP)... OK
Connecting ftp.iasi.roedu.net (FTP)... OK
Connecting archlinux.org.ru (FTP)... OK
Connecting mirror.yandex.ru (FTP)... OK
Connecting archlinux.freeside.ru (HTTP)... OK
Connecting ftp.ds.hj.se (FTP)... OK
Connecting ftp.gigabit.nu (FTP)... OK
Connecting archlinux.puzzle.ch (FTP)... OK
Connecting server.elsistech.com (HTTP)... OK
Connecting hell.org.ua (FTP)... OK
Connecting ftp.linux.kiev.ua (FTP)... OK
Connecting mirror.isoc.org.il (HTTP)... OK
Connecting mirror.pacific.net.au (FTP)... OK
Connecting mirror.aarnet.edu.au (FTP)... OK

Mirrors with net problems: 2

ftp.nethat.com (Login error: 530 Login incorrect.)
ftp.archlinuxppc.org (Connection error: No route to host - connect(2)Login 
error: undefined method `login' for nil:NilClass)

Mirrors with repo data collect problems: 5

mir1.archlinuxfr.org
---
  community-x86_64()
  extra-i686()
  core-x86_64()
  extra-x86_64()
  core-i686()
  community-i686(Download error: 421 Timeout.)
ftp.heanet.ie
---
  community-x86_64(Size error: 550 
mirrors/ftp.archlinux.org/community/os/x86_64/community.db.tar.gz: not a plain 
file.Mtime error: 550 
mirrors/ftp.archlinux.org/community/os/x86_64/community.db.tar.gz: No such file 
or directoryDownload error: 550 
mirrors/ftp.archlinux.org/community/os/x86_64/community.db.tar.gz: No such file 
or directory.)
  extra-i686(Size error: 550 
mirrors/ftp.archlinux.org/extra/os/i686/extra.db.tar.gz: not a plain file.Mtime 
error: 550 mirrors/ftp.archlinux.org/extra/os/i686/extra.db.tar.gz: No such 
file or directoryDownload error: 550 
mirrors/ftp.archlinux.org/extra/os/i686/extra.db.tar.gz: No such file or 
directory.)
  core-x86_64(Size error: 550 
mirrors

Re: [arch-general] Searching reference server for mirror checking

[Gerhard Brauer]

Hello!
* eliott <[EMAIL PROTECTED]> schrieb am [28.01.08 17:19]:
> 
> I think it would be a very nice thing to have someone run
> periodically, and maybe send reports to the dev team

I think we on archlinux.de could do this. I'll talk with Pierre next
time about that.

Another question , i assume that that you could say "something about
mirroring":
I also talked with Pierre about some more mirrors for germany. I have a
list with some potential candidates. Our question is: what is the right
way to get them as ArchLinux mirrors? We could contact their ftpmaster,
but when they say: yes, we've waited for you ;-) whom must i/we contact
on archlinux.org for rsync and so far?
Is there a "FAQ" or some document anywhere?

Thank's & a nice day
 Gerhard

-- 
Neulich auf dem Maennerklo:
Linke Reihe, bitte hinten anstellen, jeder nur ein Kreuz...

Re: [arch-general] Mirror out of sync [tu.chemnitz.de]

[Gerhard Brauer]

Hello!
* eliott <[EMAIL PROTECTED]> schrieb am [25.01.08 17:56]:
> 
> Please file a ticket on the bugtracker, so we can address the issue.

Ok, i filed some bugreports for the most conspicuous mirrors i checked.
#9390-9394 in pacman flyspray section.

  Gerhard

-- 
rm -rf DOESN'T mean:
read mail -really fast

Re: [arch-general] [mirror] mirror sync and reachability issues

[Gerhard Brauer]

Hello!
* Dan McGee <[EMAIL PROTECTED]> schrieb am [02.02.08 17:29]:
> 
> 9439 sticks out as rather big as it is two of our mirrors in the
> Netherlands, so I'd appreciate any feedback on that one. 

The Netherlands are back & rock'n roll

Pierre and i have put a status site on archlinux.de where you could
check the mirror status.

http://users.archlinux.de/~gerbra/mirrorcheck.html

The output is still a little over-the-top and the reasons not straight
forward.
Next time i will report only out-of-sync-Mirros when the db-files on the
mirrors are older than 1 day. And mark sites older than 2 days red.
But i think itmakes more sens than the 99th pacman gui ;-) and i'm only
a hobby hacker...

At the moment i run the script by hand. When ready and fixed i think
running it 2times a day is ok.

> -Dan

Gerhard

-- 
OOP? Frueher haben wir die Fehler selbst
programmiert, heute werden sie vererbt.

Re: [arch-general] Mirror out of sync?

[Gerhard Brauer]

Gruesse!
* David Rosenstrauch <[EMAIL PROTECTED]> schrieb am [14.02.08 23:30]:
> Pierre Schmitz wrote:
>
>> Just for reference: http://bugs.archlinux.org/task/9561
>
> Anyone know why they're out of sync, BTW?

I've got only one response on my mails, and this mirror is already back.
At the moment there seems to be many problems with US mirrors:
5 of 8 mirrors are out of sync or otherwise bad:
http://bugs.archlinux.org/task/9561
http://bugs.archlinux.org/task/9611

Offline/out of sync
ftp://mirror.cs.vt.edu/pub/ArchLinux
ftp://locke.suu.edu/linux/dist/archlinux
ftp://mirrors.unixheads.org/archlinux
ftp://ftp-linux.cc.gatech.edu/pub/linux/distributions/archlinux

Could any of the arch admins say if the last 3 mirrors from bug #9561
try to sync (if they sync from our rsync server)?

Or anyone here with a contact "the short way" to one of the mirror
admins?

> DR

Gerhard (www.archlinux.de)

-- 
Puenktlich zur Diskussion um den Bundes-Trojaner
erscheint auch das passende Betriebssystem dazu.

Re: [arch-general] [signoff] madwifi/madwifi-utils 0.9.4

[Gerhard Brauer]

On Tue, Mar 11, 2008 at 07:38:20AM +0100, Tobias Powalowski wrote:
> Hi
> small bump of madwifi drivers
> please signoff both arches
> also users can signoff, no respond from any dev

Could give a user signoff for i686

> greetings
> tpowa

-Gerhard


-- 
MSCI = M$cro Soft Certificated Installer

Re: [arch-general] [signoff] madwifi/madwifi-utils 0.9.4.3382

[Gerhard Brauer]

On Thu, Mar 13, 2008 at 06:36:57PM +0100, Tobias Powalowski wrote:
> Hi
> bump of madwifi drivers, back to trunk version
> please signoff both arches
> also users can signoff, no respond from any dev

user signoff for i686

Tobias: i could also signoff pcmciautils 014-4 for i686. Do some base
tests, seems fine.

> greetings
> tpowa

Gerhard

-- 
Never use a running system...

Re: [arch-general] [signoff] pcmciautils

[Gerhard Brauer]

On Wed, Mar 12, 2008 at 12:27:59PM +0100, Tobias Powalowski wrote:
> Hi
> fixed udev rules file to use load-modules.sh instead of plain modprobe.
> signoff for both arches, please

Sorry, don't have seen this mail...
Could do a user signoff for i686
Do some base tests and overall my card works fine.

> greetings
> tpowa

-- 
DSSP - Deutschland sucht den Super Papst
Casting mit Fliege

Re: [arch-general] [signoff] madwifi/madwifi-utils 0.9.4.3382

[Gerhard Brauer]

On Mon, Mar 17, 2008 at 07:29:15PM +0100, Tobias Powalowski wrote:
> Hi
> bump of madwifi drivers, back to trunk version
> please signoff both arches
> also users can signoff, no respond from any dev
> 
> bump at least anyone?

Again:
user signoff for i686
 
> greetings
> tpowa

Gerhard

-- 
Wir sind Bundes-Trojaner!
Widerstand ist zwecklos!
Wir werden Ihre terroristischen
Daten den unseren hinzufuegen.

[arch-general] Grub and GPT partition labels

[Gerhard Brauer]

Hello,

are there any plans to prepare our grub with support for GPT partition
labels? The grub version from current install ISO could not be installed
on such a prepared harddisk:
Filesystem type unknown, partition type 0xee

Good old lilo on the other side works like a charm ;-)

There must be patches for grub to provide this (???)

My question result from a discussion where someone would like to install
on an >7TB Array and says: it doesn't work, but on Debian, SuSe.
And he doesn't provide further infos... ;-)

But i've done some tests in an VM and don't see problems in kernel or
tools. Only the grub problem.

The discussion is only in german:
https://forum.archlinux.de/?page=Postings;id=20;thread=8205

Regards
Gerhard

-- 
www.archlinux.de

Re: [arch-general] Grub and GPT partition labels

[Gerhard Brauer]

On Mon, Mar 17, 2008 at 09:18:48PM +0100, Gerhard Brauer wrote:
> 
> There must be patches for grub to provide this (???)

Ok, i've filed 2 feature request to maybe solve these problem.
#9864, #9865

Gerhard

-- 
Try rm -rf (_R_ead _M_ail _R_ealy _F_ast)

Re: [arch-general] Grub and GPT partition labels

[Gerhard Brauer]

On Tue, Mar 18, 2008 at 11:00:33AM -0500, Aaron Griffin wrote:
> On Tue, Mar 18, 2008 at 5:09 AM, Gerhard Brauer <[EMAIL PROTECTED]> wrote:
> >
> >  Ok, i've filed 2 feature request to maybe solve these problem.
> >  #9864, #9865
> 
> But, it looks like we already have a new grub package. sigh

(Sorry for not so good english) ;-)

I saw your answers and discussions also in arch-devel. I agree to keep
stable things stable, but also life goes on.
Grub's great benefit over lilo is its flexibility, but therefor grub
must known any partition scheme and filesystem where it should find the
kernels. GPT/EFI is meanwhile a standard (i doesn't thought on the Mac
users by my request), we support it also in our kernels.

I also agree that not most of the users cry "hurray" when gpt is
supported but devices/arrays where one needs partitions beyond 2TB is
not so far "feature dreams" as for ~10 years. Buy a bunch of SATA-HDs
and a HW-Raid-Controller and you're "in buisiness".
But for those who needs this we could provide a installation procedure
without an error ("I coudn't install Arch, grub throws an error").

Looking over other distributions i see no harm when using grub with a
gpt-patch. And it's "only" in testing, test it.

If you devs say: no, we dont't want to apply this; no problem, it was a
feature request. I assume that someone who benefits at the moment from
this patch also has the expirience to solve it an other way:
* use Lilo if want a bootloader straight after installation
* use a external boot medium for the first boot and then build grub from
abs with the patch or from AUR, it's done in 5 minutes.

But if 99% of our users never see anything good (or bad!) with a so
patched grub - and the 1% users benefit from it - then i would like to
see it in Arch.

Gerhard


-- 
Never use a running system...

Re: [arch-general] [arch-dev-public] [signoff] cryptsetup 1.0.6-1

[Gerhard Brauer]

On Sat, Mar 15, 2008 at 11:31:22AM +0100, Thomas Bächler wrote:
> New version with some bugs fixed. Please sign off (tested by me on x86_64).

I have tested it on my luks encrypted laptop and on some loop device
container which are also luks encrypted. I could boot my laptop ;-) and
tested adding/deleting passphase keys.

If this is enough i could give a user signoff for i686.

(Sorry for crossposting but i thought i couldn't post directly on
arch-devel).

Gerhard

-- 
Ein Registry-Cleaner ist fuer Win-User
der Bulldozer des kleinen Mannes.

[arch-general] Current FTP/HTTP install broken

[Gerhard Brauer]

Hello,

at the moment it seems that doing installation by ftp/http source is
broken for the current ISOs 2007.08-2.

We got several posts on archlinux.de and i see also on archlinux.org:
http://bbs.archlinux.org/viewtopic.php?pid=345662

Also some new comments in old bugreport:
http://bugs.archlinux.org/task/8898

Problems seems some missing filelists in some packages (ex. glibc) and
that there are 3 /mnt/.CHANGELOG files conflicting in glibc, initscripts
and perl.
These stops the installation of all/most base packages and so if user go
further in install/configuration all config files are empty.

Will these be fixed before the new ISO go official?

Bye
Gerhard

-- 
DSSP - Deutschland sucht den Super Papst
Casting mit Fliege

Re: [arch-general] Current FTP/HTTP install broken

[Gerhard Brauer]

On Mon, Mar 24, 2008 at 08:33:38AM +0100, Tobias Powalowski wrote:
> Am Montag, 24. März 2008 schrieb Dan McGee:
> > On Sun, Mar 23, 2008 at 7:23 PM, Gerhard Brauer <[EMAIL PROTECTED]> 
> wrote:
> > >  Problems seems some missing filelists in some packages (ex. glibc) and
> > >  that there are 3 /mnt/.CHANGELOG files conflicting in glibc, initscripts
> > >  and perl.
> > >  These stops the installation of all/most base packages and so if user go
> > >  further in install/configuration all config files are empty.
> >
> > We don't use filelists anymore in packages. The new ISO will use a
> > much more recent version of pacman so this won't be an issue.

Are the missing filelists in packages the "stopper"? I did some
ftp-installs last 2 weeks and never looked on the output after base
packages install. I assume the real stoppers are the conflicting
CHANGELOG files, right?

> Please use the TEST Isos i posted before, ftp install is broken since a long 
> time.

Slightly broken ;-) but the base installation lead to a finished
install. But the user reports about the new RC-ISOs are positive for
ftp/http install method, so this current problem is a puppy in the sky
after release.

> greetings
> tpowa

Regards
Gerhard (i.still_tired << coffee)

-- 
Linux ist wenn es trotzdem geht...

Re: [arch-general] Current FTP/HTTP install broken

[Gerhard Brauer]

On Mon, Mar 24, 2008 at 11:25:27AM +0100, Xavier wrote:
>
> Ah well, I answered Dan privately because I found this confusing, but I 
> should have answered here probably :)

Thanks for explanation.

Maybe we should future place a hint on download page for the ftp iso
when we run in a similar situation? So that the users download the core
iso instead of ftp.

The new rc-ISO's works fine (Tatat). Hey Tobias, when could we await
the next release? No, not the "current next" - the "next next" ;-)
duck and away

Regards
Gerhard

-- 
www.archlinux.de

Re: [arch-general] ArchISO FTP Installer - Testers Needed

[Gerhard Brauer]

On Wed, Mar 26, 2008 at 03:53:52AM -0500, Simo Leone wrote:
> Hey everyone,

I've tested it on varios machines, Scenic, Thinkpad, IBMs, VirtualBox

> **I need feedback on the following regarding ISO bootup**
> - Did the grub loader work as expected?
Yes

> - Did it pick up and load the module for your network hardware?
Yes, all ethernet cards i use
Also madwifi, usable with wpa_supplicant

> - Did it pick up and load the modules for your disk controllers?
Yes

> - Any kernel panics, freezes, that sort of ugly stuff.
No, nothing during boot or work on console.

> Please keep in mind that this is not intended to be production quality
> at this point, and it's a very early version, so there are still a lot
> of sharp edges that need to be smoothed out.

What i've noticed:
- km is missing to select other keyboard layout
- using the installer i never could mount the cd when saying:
  Select packages->Mount the cdrom...->Available CD drives
  My cdroms are shown (sr0: Vendor|Model but trying to select gives:
  failed to mount /dev/sr0
  Nothing about this in any log, dmesg
- Installer doesn't have any output on an tty for logging
- Installer log in /var ??

But maybe these are things which are generally "broken" in this state.
If you mostly interested in grub/kernel then i would say: OK

I've also done a quick test in a VM with RAM set to 64MB. No problem
booting the kernel and start the installer.

> -Simo

Regards
Gerhard

-- 
Puenktlich zur Diskussion um den Bundes-Trojaner
erscheint auch das passende Betriebssystem dazu.

Re: [arch-general] Current FTP/HTTP install broken

[Gerhard Brauer]

On Fri, Mar 28, 2008 at 01:18:09PM +0200, Ioannis Lazaridis wrote:
> pacman -Sy pacman or download latest (2008-03) iso.

Sorry, the email you replied stuck somewhere on my email provider, so it
reached the list very late ;-)

Gerhard


-- 
Ich bin nicht die Signatur,
ich putz' hier nur!

[arch-general] Installation: after first reboot ext3 superblock mount time in future

[Gerhard Brauer]

Hello,

i've noticed this meanwhile quiet often after many installations.
Currently after a test with 2008.03-0.3, but also with older ISOs:

After install and first reboot i got such fsck notice during rc:

,
| /dev/sda3: Superblock last mount time is in the future. FIXED
| /dev/sda3 has gone 49710 days without being checked, check forced.
`

Here¹ you could download a screenshot from such a situation where also a
reboot is required after fsck.
Cause this is the *first* reboot after installation users will get a bad
impression about Arch.

First i thought this comes from vmware, but i also get it in virtualbox
and i've seen this also during real installations.

I have a suspicion: During (c)fdisk and formatting the disks current locale
and timezone is set to US values (don't know at the moment the initial
settings presented in rc.conf).
During configuration i set my locale and timezone always to de_DE.utf8
and Europe/Berlin. And when first reboot is made that from umounting /
there is a time difference that could cause such and flag it on ext3
partition?
Or with the order in rc scripts?

Maybe also that the hwclock is changed during/after installation...

Have others also seen such? 

¹ http://users.archlinux.de/~gerbra/screen.png

-- 
Don't drink and root!

Re: [arch-general] Installation: after first reboot ext3 superblock mount time in future

[Gerhard Brauer]

On Sat, Mar 29, 2008 at 03:16:00PM +0200, Grigorios Bouzakis wrote:
> 
> This only appears if you set the  HARDWWARECLOCK to UTC as far as i can
> tell.

Most times in virtual machines i leave it to localtime.
But the hwclock of a vm comes from the host system (here it's set to
UTC).

> Even though i dont have Widnows installed localtime works better for me,
> no such issues and plus the clock uses the correct time. UTC is 2 hours
> ahead.

Yes, windows have it's own goal with the clock: all mine, don't care
about other's ;-)

If i remember it, i will try next installations with tzdate set before
fdisk. Maybe this could solve it.

Perhaps we could set tzdate/TIMEZONE in the installer before
(c)fdisk'ing, maybe in km or as a own menu option if this is the reason.

> Greg

Regards
Gerhard

-- 
Linux ist wenn es trotzdem geht...

Re: [arch-general] Installation: after first reboot ext3 superblock mount time in future

[Gerhard Brauer]

On Sat, Mar 29, 2008 at 09:59:13AM -0500, Dan McGee wrote:
> On Sat, Mar 29, 2008 at 8:12 AM, Gerhard Brauer <[EMAIL PROTECTED]> wrote:
>
> >  Cause this is the *first* reboot after installation users will get a bad
> >  impression about Arch.
> 
> Oh noes! We couldn't ever have a bad impression! We might lose a user!
> 
Not me ;-) This needs even more sarcasm ;-)

If i was a car seller i have no problem to say: " Hey, the car you have
buyed is the best, ever, last car you buyed in your life. Ok, first time
a day you must start it twice and ignore this little red lamp... But
when it is started, oh man, you would love this care".
*I* love Arch.

> Feel free to submit a patch against the installer (it is all in GIT on
> projects.archlinux.org), 

No, cause i'm doesn't know the technical background araound this
"problem". Therefor i ask.
And if i submit patches: you'll don't like them cause you must repair
faster than i could patch something ;-)

> but justifying this problem by saying it gives a bad impression is not
> something that is going to make devs jump out and fix it- 
That wasn't my intention, only my opinion. Extorting is useless ;-)

Maybe a little more technical discussion from those who care?

> -Dan

Regards
Gerhard

-- 
www.archlinux.de

Re: [arch-general] Installation: after first reboot ext3 superblock mount time in future

[Gerhard Brauer]

On Sat, Mar 29, 2008 at 04:53:38PM +0100, Gerhard Brauer wrote:
> 
> Maybe a little more technical discussion from those who care?

Ok, i've done another test (at the moment i could reproduce it in
virtualbox):

I've started the installation on 18:01 localtime (here CET).
,
| inside the VM:
| date
| Sat Mar 29 18:01:23 UTC 2008
| hwclock
| same time as above date
`

After creating and formatting the disk i have on sda3(=/):
,[ dumpe2fs -h /dev/sda3 ]
| Filesystem created:   Sat Mar 29 18:06:04 2008
| Last mount time:  Sat Mar 29 18:06:13 2008
| Last write time:  Sat Mar 29 18:06:13 2008
| Mount count:  1
| Maximum mount count:  30
| Last checked: Sat Mar 29 18:06:04 2008
| Check interval:   15552000 (6 months)
| Next check after: Thu Sep 25 18:06:04 2008
`

Then i go over configure system, also set the Timezone to Europe/Berlin
but leave the HARDWARECLOCK to localtime.
Doing this current time in virtual machine is:
Sat Mar 29 18:42:23 CET 2008
(only timezone gets changed, not the time itself)

And here i think it "happend":
,[ dumpe2fs -h /dev/sda3 ]
| Filesystem created:   Sat Mar 29 19:06:04 2008
| Last mount time:  Sat Mar 29 19:06:13 2008
| Last write time:  Sat Mar 29 19:06:13 2008
| Mount count:  1
| Maximum mount count:  30
| Last checked: Sat Mar 29 19:06:04 2008
| Check interval:   15552000 (6 months)
| Next check after: Thu Sep 25 20:06:04 2008
`
sda3 is still mounted, but the creation time is in the future. The same
what fsck found fault with on the next(first) boot.

I think the error is to change timezone during install but leave the
time itself unchanged. Or something like that, i'm not sure ;-)
But i think to ask the user before install:
What is your clock set (UTC/localtime)
and then *set* the clock (maybe also hwclock) before mkfs could solve
this creation times conflicts.

Regards
Gerhard

-- 
Heute ist das Morgen wovor du gestern Angst hattest...

Re: [arch-general] Current FTP/HTTP install broken

[Gerhard Brauer]

On Sat, Mar 29, 2008 at 06:43:11PM +0100, Philippe Miron wrote:
> 
> I just re-install Arch with a 2007 CD, I tried to use the FTP installation
> and I couldn't get the package list from any server. (and my internet
> connection was working..)  I read the thread pretty face (maybe I miss the
> bug report) but I want to know if this is a known issue?

Yes, ftp installation from 2007 CD is broken. You could use the current
(2007) core-ISOs when you do a "install from CD".

Or you use the new ISO's currently in test from here:
ftp://ftp.archlinux.org/other/rc-iso/2008.03/
With them a ftp/http install is possible.

> Thank you.

Gerhard

-- 
Ich bin nicht die Signatur,
ich putz' hier nur!

Re: [arch-general] Installation: after first reboot ext3 superblock mount time in future

[Gerhard Brauer]

Hello,

i've done a bit more testing.
First i think it's not a bug in any package. It's only a mismatch
between clock set on install machine and the timezone which is later set
during config.

1. I guess there is absolut no problem on machines where the hardware
clock is set to UTC by default.

2. If the clock is set to localtime there is a mismatch directly after
booting the kernel. The time is read from bios and then the timezone is
UTC per default what is a wrong time. Ex.
My localtime is 13:46 (= machines hardwareclock) but this time is
CEST(UTC+2)
So date on the machine itself shows:
Sun Mar 30 13:46 UTC 2008 but it must be
Sun Mar 30 11:46 UTC 2008 or
Sun Mar 30 13:46 CEST 2008 

Solutions:
a) set the time by hand (KISS, maybe put a hint on installation guide?)
date -s "13:46 CEST" result in:
Sun Mar 30 11:46 UTC 2008
which is the now correct UTC time.
b) put tzdata package on ISO, so the user could use tzselect. Hint could
also be given in instalation guide. Or we make it more comfortable
(handholding the user) and put this as a menu in installer("Set your
timezone"). The $TZ env var could then also used by the installer to
initial set TIMEZONE in rc.conf as we do it with KEYMAP. As a side
effect we could reduce a lot of postings in forums where users not set
this correctly. But that need perhaps discussion, i feel it a little bit
to handholding.

Personally i will use a) in the future.
As a solution which maybe should be discussed i would prefer b), tzdata
on ISO and a entry in installer menu.

What do you think? Other ideas?

Regards
Gerhard

-- 
Ist Ihnen mutt zu kompliziert? Ihr Mailprogramm zu "fett"?
Sie moegen keine man pages?
Versuchen Sie: rm -rf (ReadMail -Realy Fast)

Re: [arch-general] Installation: after first reboot ext3?superblock mount time in future

[Gerhard Brauer]

On Sun, Mar 30, 2008 at 01:40:10PM +0200, Arvid Ephraim Picciani wrote:
> i vote for putting a) in the instalation guide so new users dont get scared 
> by 
> this (imo) non issue.
You're right, it's not an real issue. Only a little annoying if you
forget to set it correctly. I've last test something with a ~1.9TB
partition and run in this fsck after first boot. CTRL+C was my friend
;-)

> wasnt there noted in the guide that you have to link your timezone
> somewhere?
Yes, in the chapter where to set the values in rc.conf. But at this time
it's already to late, TZ (or time) must be set before starting the
installer (or at top of installer). We *must* have a constant, correct
time during install, especially after fdisk/1.mount and remount during
configuring.

tzselect has the advantage that user could do it interactiv. With this
(another idea) we could handle this like km:
put a hint /etc/motd:
,
| Timezone:
|   - to set your time(zone) correctly during installlation, type tzselect
|   on console.
`

> best regards/Mit freundlichen Grüßen
> Arvid Ephraim Picciani

Regards
Gerhard

-- 
Dont't drink and root!

Re: [arch-general] Installation: after first reboot ext3 superblock mount time in future

[Gerhard Brauer]

On Sun, Mar 30, 2008 at 05:17:18PM +0300, Roman Kyrylych wrote:
> 2008/3/30, Gerhard Brauer <[EMAIL PROTECTED]>:
> 
> Aha, it seems now I've got it.

;-) Yes, english isn't my mother language. I think, someone who reads
my mails guess: Oh, a six year old child on list ;-)

> I didn't know (or forgot) about tzselect (*facepalm*) - thanks for
> pointing me that.

Meanwhile (i wrote on other mail) i would prefer to handle it like km.
Maybe it could be combined with the km hint in /etc/motd. So you must
not "hurt" the installer, but it is on a place where every user should
notice it.

PS: I've tested always with the last RC-ISO. Don't know if tzselect is
available on the archiso that Aaron published last time. But i think
cause it's a live cd there are more tools available.

Regards
Gerhard

-- 
rm -rf bedeutet NICHT:
read mail -really fast

Re: [arch-general] Installation: after first reboot ext3 superblock mount time in future

[Gerhard Brauer]

On Sun, Mar 30, 2008 at 07:58:21PM +0200, Gerhard Brauer wrote:
> 
tzdata/tzselect on ISOs:
> Meanwhile (i wrote on other mail) i would prefer to handle it like km.
> Maybe it could be combined with the km hint in /etc/motd. So you must
> not "hurt" the installer, but it is on a place where every user should
> notice it.

I think i'll make a feature request in next 3-4 days if we got nothing
new in this discussion.
We should not change something only while I and some others have
discussed it.

Gerhard

-- 
Wir sind Bundes-Trojaner!
Widerstand ist zwecklos!
Wir werden Ihre terroristischen
Daten den unseren hinzufuegen.

Re: [arch-general] 2008.04-RC Images are out

[Gerhard Brauer]

On Tue, Apr 15, 2008 at 02:04:37AM -0500, Simo Leone wrote:
> Crosspostingissocool
> http://www.archlinux.org/news/389/
> 
> Enjoy.

Is there a bugreport for collect things for this RC (planned)
Or should we/i report things here in this thread? I've found some minor
things belong to locale/keymap/timezones (yes ;-)

Regards
Gerhard

-- 
rm -rf DOESN'T mean:
read mail -really fast

[arch-general] Closing bugreports too fast?

[Gerhard Brauer]

Hello,

i thought about a "trap" in which myself are also fallen sometimes:
I look at the bugtracker to see if someone filed already a bugreport for
a problem. But i don't find it cause it is already fixed and thereby
marked as closed. And without using advandced search functions all
searches are only done on open bugreports.

As an example the problem yesterday with kdelibs:
In forum thread someone says: i write a bugreport (without posting the
number ;-) It was #10312
tpowa provided a fixed package in a nice short time, quickly, and then
closed the report (fixed). But users in the forum have had problems to
find this report cause it was closed.
If i look at the history of the report i see: Aaron reopened it, then we
have user request for closing an Jan closed it finally again.

On such reports (the maintainer knows that many users would/could have
the problem, sometimes only during different mirror syncing) i would
suggest **not** to close such a report too fast.
Ok, it is fixed from developer side (and maybe available on
ftp.archlinux.org) but users could run in the problem probably later or
tommorrow.

I see no problem with reports where the reporter says: ok, it worked,
you could close it. And where the maintainer knows: it was maybe a local
or a problem on a minor package.
But in situations like above it would be helpfully if the report wasn't
closed (as well it was fixed on developer side), but maybe in a status
like: fixed, scheduled for closing. But the report is "open" and so
found on searching.
I don't know if the bugtracker have such a function to closed it
automatically for ex. after 6 days. On the other hand the maintainer
must do this (it's additional work, but i think it's worth).

Regards
Gerhard

-- 
Don't drink and root!

Re: [arch-general] Closing bugreports too fast?

[Gerhard Brauer]

On Wed, Apr 30, 2008 at 12:26:43PM +0300, Grigorios Bouzakis wrote:
> On 4/30/08, Gerhard Brauer <[EMAIL PROTECTED]> wrote:
> 
> I would never have thought that closing bug reports too fast would be a
> problem to someone. IMHO you are making this seem like an issue when it
> really isnt.

It's not - more - an issue for me, I've learned my lesson ;-) (That is,
was Xavier mentioned in his answer).
But i know 3 other tasks were the user must be pointed: Look directly to
#12345, the problem you ask about is already fixed (and closed).

It doesn't sound very logical to me that one must search in closed
reports to find a solution(or report) for a problem which is real actual
for him. Specially when after doing a pacman -Syu with no harm later his
KDE is broken. I don't speak from outdated mirrors or when users don't
read pacman outputs. I speak from situations were user make everything
right.
Maybe i have an other point of view on some things (i am more from the
service side, not developer side). I will provide enviroments where
users could easily find all necassary informations, so i could say: It's
the only problem that you doesn't read/noticed them.

For example i/we handle the kdelibs problem on archlinux.de: I noticed
that there would be a problem for everyone. So i make a "urgent" post in
forum and a notice on the start site. Most of our mirrors at this time
have had the old package, not the faulty. But i knewed that we could get
many users with problems when the infomation could not be found (and
what to to: skip the update and later either downgrade or get the fixed
package). That all was done cause i'm lazy, i don't want to have 20
users with a broken KDE shouting loudly in forum.
Today (after mirror syncing) i removed the warning from the main site
and after next 2 days i flag the forum warning about kdelibs as "fixed".

I don't request a general paradigm change on flyspray, only a little
thinking from developers that user problems arent't fixed when you do a
:wq or C-x C-s ;-)

> Just make a duplicate bug report. Noone will mock you for making
> it.Lets not overcomplicate things when there is no need. 

That sounds more complicated (more work) to me rather than wait 1 or 2
days before closing a report ;-)

> Greg

Regards
Gerhard

-- 
OOP? Frueher haben wir die Fehler selbst
programmiert, heute werden sie vererbt.

Re: [arch-general] ClamAV should be update to 0.93

[Gerhard Brauer]

On Sun, May 04, 2008 at 01:05:31PM +0200, Alessio Bolognino wrote:
> If you want to help someway, you could update the package, test it and
> send the sources (PKGBUILD and other stuff) to the maintainer or maybe
> even in this mailing list.

Here is my PKGBUILD for 0.93. I have tested it on two servers.
clamav restart must be done with caution cause sometimes the old
incremental daily content isn't regognized, so a freshclam must be done.
So restart or stop/start twice worked for me.

Regards
Gerhard

-- 
OOP? Frueher haben wir die Fehler selbst
programmiert, heute werden sie vererbt.
# $Id: PKGBUILD 356 2008-04-18 22:56:27Z aaron $
# Maintainer: Dale Blount <[EMAIL PROTECTED]>
# Contributor: Gregor Ibic <[EMAIL PROTECTED]>

pkgname=clamav
pkgver=0.93
pkgrel=1
pkgdesc="Anti-virus toolkit for Unix."
arch=(i686 x86_64)
depends=('bzip2' 'zlib' 'gmp' 'curl>=7.16.2' 'perl')
options=(!libtool)
install="$pkgname.install"
license=(GPL)
backup=(etc/clamav/clamav.conf etc/clamav/clamd.conf etc/clamav/freshclam.conf 
etc/conf.d/clamav)
url="http://www.clamav.net";
source=(http://easynews.dl.sourceforge.net/sourceforge/$pkgname/$pkgname-$pkgver.tar.gz
clamav
clamav.confd
clamav.logrotate)

build() {
cd $startdir/src/$pkgname-$pkgver
./configure --prefix=/usr --sysconfdir=/etc/clamav \
--with-dbdir=/var/lib/clamav --disable-clamav
# will add clamav user with clamav.install
make || return 1
make DESTDIR=$startdir/pkg install || return 1

# make sure conf files get installed, cause make install
# doesn't do that if clamav is already installed upon building.
for i in clamd freshclam; do
install -D -m644 etc/$i.conf $startdir/pkg/etc/clamav/$i.conf
done

install -D -m644 $startdir/src/clamav.confd 
$startdir/pkg/etc/conf.d/clamav
install -D -m755 $startdir/src/clamav $startdir/pkg/etc/rc.d/clamav
install -D -m644 $startdir/src/clamav.logrotate 
$startdir/pkg/etc/logrotate.d/clamav

# create log dirs/files & fix conf files.
mkdir -p $startdir/pkg/var/log/clamav/
mkdir -p $startdir/pkg/var/run/clamav/
chown 64.root $startdir/pkg/var/log/clamav/
chown 64.root $startdir/pkg/var/run/clamav/

sed -i -e "s:\#LogFile /tmp/clamd.log:LogFile 
/var/log/clamav/clamd.log:" \
-e "s:\#PidFile /var/run/clamd.pid:PidFile 
/var/run/clamav/clamd.pid:" \
-e "s:\#User clamav:User clamav:" \
-e "s:\#LogTime:LogTime:" \
-e "s:\#TemporaryDirectory /var/tmp:TemporaryDirectory /tmp:" \
-e "s:\LocalSocket /tmp/clamd.socket:LocalSocket 
/var/lib/clamav/clamd.sock:" \
$startdir/pkg/etc/clamav/clamd.conf || return 1

sed -i -e "s:\#UpdateLogFile /var/log/freshclam.log:UpdateLogFile 
/var/log/clamav/freshclam.log:" \
-e "s:\#NotifyClamd /path/to/clamd.conf$:NotifyClamd 
/etc/clamav/clamd.conf:" \
$startdir/pkg/etc/clamav/freshclam.conf || return 1

# fix perms on virus database directory and un-distribute databases to 
require freshclam
rm $startdir/pkg/var/lib/clamav/*.cvd
chown 64:64 -R $startdir/pkg/var/lib/clamav/

# install clamdwatch
cd $startdir/src/$pkgname-$pkgver/contrib/clamdwatch
tar zxf clamdwatch.tar.gz
sed -i -e 's@/var/run/clamd.ctl@/var/lib/clamav/clamd.sock@' \
   -e 's@/var/lock/subsys/clamd@/var/run/clamav/clamd.pid@' \
   -e '[EMAIL PROTECTED]( "/tmp/clamdwatch-" 
);@mkstemp( "/tmp/clamdwatch-" );\nchmod 0644, "$tempFile";@' 
clamdwatch || return 1

install -D -m755 clamdwatch $startdir/pkg/usr/sbin/clamdwatch.pl || 
return 1
}

md5sums=('72ed6f4706858e72f24dda8a591df0da'
 '338db2f3fbca9d5747ba635d576d8739'
 'f1fd8e736f808da0487928274f585851'
 'a7a4d527ba80ec9d4811e2264e9fab9e')

Re: [arch-general] ClamAV should be update to 0.93

[Gerhard Brauer]

On Sun, May 04, 2008 at 03:14:24PM +0200, solsTiCe d'Hiver wrote:
> when i try to use your PKGBUILD, i got this error

Sorry, but the attached PKGBUILD is only a replacement for the one in
the complete clamav makepkg-tarball.

Get the complete clamav directory from abs (/var/abs/extra/clamav/) and
replace the PKGBUILD there with mine.
Or do simply change: pkgver=0.92 to pkgver=0.93 in current PKGBUILD
(yes, that's all)
do a: makepkg -g >> PKGBUILD and then a: makepkg

Sorry for confusing the world ;-)
Yes: a simple needed change and a rebuild could be sooo strong ;-)

Maybe we have a Dev with 10 minutes time for changing and rebuilding...

Gerhard

-- 
DSSP - Deutschland sucht den Super Papst
Casting mit Fliege

Re: [arch-general] ClamAV should be update to 0.93

[Gerhard Brauer]

Hello,

as attachement the **complete** clamav dir 0.93 for makepkg.
Tested on i686

Gerhard

-- 
Bundestrojaner - wir sind die Guten!
Nur echt mit 52 Verfassungsbruechen!

Re: [arch-general] ClamAV should be update to 0.93

[Gerhard Brauer]

Hello,

as attachement the **complete** clamav dir 0.93 for makepkg.
Tested on i686

//Edit: forgot the attachement, grrr ;-)

Gerhard

-- 
Bundestrojaner - wir sind die Guten!
Nur echt mit 52 Verfassungsbruechen!


clamav.tar.gz
Description: Binary data

[arch-general] Mirror: please remove locke.suu.edu

[Gerhard Brauer]

Hello,

mirror is down since March 30.
Could someone assign the ticket #9678 to Dale or Eliott to kick this
mirror?

Regards
Gerhard

-- 
Don't drink and root!

Re: [arch-general] Mirror: please remove locke.suu.edu

[Gerhard Brauer]

On Tue, May 13, 2008 at 07:59:42AM -0500, Aaron Griffin wrote:
> On Tue, May 13, 2008 at 7:48 AM, Gerhard Brauer <[EMAIL PROTECTED]> wrote:
> >  Could someone assign the ticket #9678 to Dale or Eliott to kick this
> >  mirror?
> 
> Why not just, you know, comment on the bug? It sends all of us email
> when you do.

Wrote my mail earlier than Dale assigned to you ;-)

If i remember i have a 4th email address, the staff center on their
campus.
I could write another mail to Chris (guy mentioned in report), maybe he
hasn't received my email. Or mail bombing on all addresses ;-)

PS: i have many email contacts from mirror admins. If you, Dale or
Eliott would like to compare with your contacts i could sent a
mirrorlist file in XML with the data.

Regards
Gerhard

-- 
Die NASA brauchte 12 Jahre um einen Kugelschreiber zu entwickeln, der
kopfueber, in der Schwerelosigkeit und unter Wasser schreiben kann.
Die Russen benutzten einfach einen Bleistift...

[arch-general] AUR Tarball format (makepkg --source)

[Gerhard Brauer]

Hello,

is it possible to upload a package to AUR which is build with:
makepkg --source ?
I think not (package naming and no package subdir in tarball), but this
were be a nice feature ;-)

Regards
Gerhard

-- 
rm -rf DOESN'T mean:
read mail -really fast

Re: [arch-general] AUR Tarball format (makepkg --source)

[Gerhard Brauer]

On Wed, Jun 25, 2008 at 06:24:00PM +0800, Callan Barrett wrote:
> On Wed, Jun 25, 2008 at 6:13 PM, Gerhard Brauer <[EMAIL PROTECTED]> wrote:
> >
> > is it possible to upload a package to AUR which is build with:
> > makepkg --source ?
> > I think not (package naming and no package subdir in tarball), but this
> > were be a nice feature ;-)
> 
> It is possible already. Try it out.

Yiippiieeeh. Yes, it works.

Gerhard

-- 
Linux ist wenn es trotzdem geht...

[arch-general] Could not upload nxcomp package to AUR

[Gerhard Brauer]

Hello,

another question:

I try to upload a package named nxcomp to AUR (Section lib), but it's
revoked:
You are not allowed to overwrite the nxcomp package.

But i don't found such a package in AUR nor with pacman -Ss nxcomp.


Any hints?

Regards
Gerhard

-- 
MSCI = M$cro Soft Certificated Installer

Re: [arch-general] Could not upload nxcomp package to AUR

[Gerhard Brauer]

On Wed, Jun 25, 2008 at 08:05:24PM +0800, Callan Barrett wrote:
> On Wed, Jun 25, 2008 at 7:43 PM, Gerhard Brauer <[EMAIL PROTECTED]> wrote:
> > I try to upload a package named nxcomp to AUR (Section lib), but it's
> > revoked:
> > You are not allowed to overwrite the nxcomp package.
> > But i don't found such a package in AUR nor with pacman -Ss nxcomp.
> 
> http://bugs.archlinux.org/task/8672
> 
> This is fixed in the testing branch of the AUR, hold tight and you'll
> be able to upload in the next release (which shouldn't be too long).

Thanks. But is there a way to upload or put it on an other way? I've
upload currently some packages which depends on nxcomp.

I attach the tarball in this mail.

Regards
Gerhard

-- 
OOP? Frueher haben wir die Fehler selbst
programmiert, heute werden sie vererbt.


nxcomp-3.2.0-1.src.tar.gz
Description: Binary data

Re: [arch-general] Need to mount 2nd SATA drive

[Gerhard Brauer]

On Sat, Jun 28, 2008 at 08:56:53AM -0700, Allie Daneman wrote:
> I can't figure out how to mount my 2nd SATA drive...my primary disk is 
> mounted by uuid in my current fstab but disk 2 doesn't seem like it's
> being found correctly. Can anyone help out...how do I figure out the
> uuid of my 2nd drive ?

Use: blkid
That's a real friend...


Gerhard

-- 
HAL is running Windows...

Re: [arch-general] community/mc-utf8 to extra/mc

[Gerhard Brauer]

On Wed, Jul 02, 2008 at 10:01:09PM +1000, Allan McRae wrote:
> Sergej Pupykin wrote:
>>
>> I see that mc with utf8 support is in extra now, so I delete mc-utf8
>> from community and ask someone who can do it:
>>
>> please reassign http://bugs.archlinux.org/task/10376 to the new maintainer.
>
> Do you know if this bug is valid for the new mc in extra.  If so I will  
> move/reassign it.

Yes it also under mc 4.6.1-5. But this is a very minor thing, and i
noticed that this only occurs whit german locale (ok, i don't tested
others). But with LANG=C this doesn't happend. So it's maybe a (german)
locale issue (false translation character in .po ?).

> Allan

Gerhard

-- 
Kernel panic: Could not determine whether
bit was one, zero or sqrt(1/PI)...
(J.K. in d-u-g)

Re: [arch-general] [arch-dev-public] [signoff] kernel26 2.6.26-1 and related module packages

[Gerhard Brauer]

On Mon, Jul 21, 2008 at 10:56:15PM +0200, Thomas Bächler wrote:
> - madwifi is broken. Do we still need it? AFAIK, all chipsets should now  
> be supported by ath5k by now. Can a madwifi user please look at this  
> (Aaron, Dan?)

My card doesn't work with ath5k, i've tested module from 2.6.25 and now
2.6.26 from testing.

,[ lspci ]
| Atheros Communications, Inc. AR5212/AR5213 Multiprotocol MAC/baseband 
processor (rev 01)
`
It's a PCMCIA card.
Vendor: TP-Link TL-WN610G

I cannot see any networks during scanning (iwlist).

,[ log after insert card ]
| Jul 23 00:50:37 tuxlap pccard: CardBus card inserted into slot 1
| Jul 23 00:50:37 tuxlap ath5k_pci :06:00.0: enabling device ( -> 0002)
| Jul 23 00:50:37 tuxlap ACPI: PCI Interrupt :06:00.0[A] -> Link[LNKB] -> 
GSI 11 (level, low) -> IRQ 11
| Jul 23 00:50:37 tuxlap ath5k_pci :06:00.0: registered as 'phy1'
| Jul 23 00:50:37 tuxlap phy1: Selected rate control algorithm 'pid'
| Jul 23 00:50:37 tuxlap ath5k phy1: Atheros AR2414 chip found (MAC: 0x79, PHY: 
0x45)
`

ifconfig wlan0 up (works after ~5 tries)
iwlist wlan0 scan
shows no networks (no problem with madwifi)
During iwlist scan log is flooded with:

,[ /var/log/everything.log ]
| Jul 23 00:51:54 tuxlap ath5k phy1: noise floor calibration timeout (2432MHz)
| Jul 23 00:51:54 tuxlap ath5k phy1: ath5k_chan_set: unable to reset channel 
(2432 Mhz)
| Jul 23 00:51:54 tuxlap wlan0: failed to set freq to 2432 MHz for scan
| Jul 23 00:51:54 tuxlap ath5k phy1: noise floor calibration timeout (2437MHz)
| Jul 23 00:51:54 tuxlap ath5k phy1: ath5k_chan_set: unable to reset channel 
(2437 Mhz)
| Jul 23 00:51:54 tuxlap wlan0: failed to set freq to 2437 MHz for scan
| Jul 23 00:51:54 tuxlap wlan0: failed to set freq to 2442 MHz for scan
| Jul 23 00:51:54 tuxlap wlan0: failed to set freq to 2447 MHz for scan
| Jul 23 00:51:54 tuxlap wlan0: failed to set freq to 2452 MHz for scan
| Jul 23 00:51:55 tuxlap wlan0: failed to set freq to 2457 MHz for scan
| Jul 23 00:51:55 tuxlap wlan0: failed to set freq to 2462 MHz for scan
| Jul 23 00:51:55 tuxlap wlan0: failed to restore operational channel after scan
| Jul 23 00:51:59 tuxlap __ratelimit: 12 messages suppressed
| Jul 23 00:51:59 tuxlap ath5k phy1: noise floor calibration timeout (2412MHz)
| Jul 23 00:52:07 tuxlap ath5k phy1: noise floor calibration timeout (2417MHz)
| Jul 23 00:52:07 tuxlap wlan0: failed to set freq to 2417 MHz for scan
| ... and so on
`

Same log messages if trying wpa_supplicant

Providing further packages for madwifi seems difficult with >=2.6.26, or see
you any chance?
Should i file a bugreport (arch or madwifi or LKML)?

Searching a little with "ath5k_chan_set: unable to reset channel" i saw more
users which maybe similar problems, ex.
http://madwifi.org/ticket/808 (Little confusing...)
and this in our forum could be similar:
http://bbs.archlinux.org/viewtopic.php?id=52049

Regards
Gerhard

-- 
Kernel panic: Could not determine whether
bit was one, zero or sqrt(1/PI)...
(J.K. in d-u-g)

Re: [arch-general] [arch-dev-public] [signoff] kernel26 2.6.26-1 and related module packages

[Gerhard Brauer]

On Tue, Jul 22, 2008 at 08:32:42PM -0400, Scott wrote:
> On Wed, Jul 23, 2008 at 01:36:14AM +0200, Gerhard Brauer wrote:
> > My card doesn't work with ath5k, i've tested module from 2.6.25 and now
> > 2.6.26 from testing.
> > 
> > ,[ lspci ]
> > | Atheros Communications, Inc. AR5212/AR5213 Multiprotocol MAC/baseband 
> > processor (rev 01)
> > `
> 
> 
> The AR5007EG card still doesn't work with the standard ath5k or MadWifi.
> That 5212 sometimes turns out to need the same driver.
> 
> I have a page on it, (though your card sounds like another card) more
> Fedora specific but also works for Arch at
> http://home.nyc.rr.com/computertaijutsu/rhwireless.html#5007

Thanks for the info, but i have no problems with arch stock-kernels and
madwifi. Works like a charm.
Only the new ath5k foss module doesn't work - would be for me a stopper
not to upgrade to 2.6.26.

I've found the homepage:
http://wireless.kernel.org/en/users/Drivers/ath5k
Seems there is a lot of work to do ;-) I don't understand currently why
madwifi (broken?) is gone and this young project replace it.

At the moment i check out their testing git, i found some commits that
sound like my problem...maybe...

Regards
Gerhard

-- 
OOP? Frueher haben wir die Fehler selbst
programmiert, heute werden sie vererbt.

Re: [arch-general] [arch-dev-public] [signoff] kernel26 2.6.26-1 and related module packages

[Gerhard Brauer]

On Wed, Jul 23, 2008 at 01:36:14AM +0200, Gerhard Brauer wrote:
> 
> Providing further packages for madwifi seems difficult with >=2.6.26, or see
> you any chance?

Ok, i found a solution/patch for madwifi, this works now under 2.6.26.

With ath5k i compiled latest wireless-compat and git version, first
gives me same errors as above, git version a kernel trap.
I will deal this on ath5k-ML or bugtracker.

Regards
Gerhard

-- 
Kernel panic: Could not determine whether
bit was one, zero or sqrt(1/PI)...
(J.K. in d-u-g)

Re: [arch-general] Sending files to printer question

[Gerhard Brauer]

On Tue, Aug 12, 2008 at 08:58:43AM +1000, richard terry wrote:
> 
> I wondered if there was a command line utility to do the conversion.

You could combine some nice tools
Look at the tools:
html2text and htmldoc
First is an "simple" text parser without formatting.
htmldoc is a complex tool which renders html files to ps, pdf (or html).
With htmldoc you could render complex webpages with many options.

The solution for your problem could a piping party..

wget downloads the html code and pipded it to htmldoc. htmldoc produces
ps or pdf which you pipe to your printer.

One quick example could be (one line):
,
| wget -O - pages.html http://aur.archlinux.org/index.php | htmldoc --webpage 
-t ps - | lp
`
The many single - in the commands are important, this is stdin and stdout

For more options and useful settings look at man htmldoc.

> Richard

Gerhard

-- 
Never use a running system...

Re: [arch-general] Sending files to printer question

[Gerhard Brauer]

On Tue, Aug 12, 2008 at 01:40:30AM +0200, Gerhard Brauer wrote:

One mistake:
> ,
> | wget -O - http://aur.archlinux.org/index.php | htmldoc --webpage -t ps - | 
> lp
> `
 
Gerhard
 
-- 
Ich: Wenn du wuesstest, was ich denke...
Sie : Was waere dann?
Ich: Viel Erde ueber dir...

[arch-general] Rebuild davfs2 from extra please

[Gerhard Brauer]

Hello,

davfs2 from extra is outdated. PKGBUILD must also be modified.
Currently davfs2 is broken.

I attached a PKGBUILD in bugreport:
http://bugs.archlinux.org/task/11285

Gerhard

-- 
Die NASA brauchte 12 Jahre um einen Kugelschreiber zu entwickeln, der
kopfueber, in der Schwerelosigkeit und unter Wasser schreiben kann.
Die Russen benutzten einfach einen Bleistift...

[arch-general] spamassassin 3.2.5-2

[Gerhard Brauer]

Hi,

does anyone knows why the package binaries (spamd, spamc) are now in
/usr/bin/perlbin/vendor? On the previos version they were in /usr/bin.

Bug? Feature?


Gerhard

-- 
Dont't drink and root!

Re: [arch-general] spamassassin 3.2.5-2

[Gerhard Brauer]

On Thu, Sep 04, 2008 at 01:38:10PM -0400, Eric Belanger wrote:
> On Thu, 4 Sep 2008, Gerhard Brauer wrote:
>
>> does anyone knows why the package binaries (spamd, spamc) are now in
>> /usr/bin/perlbin/vendor? On the previos version they were in /usr/bin.
>
> It's a "feature" since perl 5.10:  
> http://wiki.archlinux.org/index.php/Perl_Policy#Binaries_and_Scripts

Ah, thanks for the explanation.
Some day a 'echo $PATH' would fill my whole terminal... ;-)

Gerhard

-- 
Ich bin root, also knie nieder vor mir!

Re: [arch-general] probs. with easynews mirror

[Gerhard Brauer]

Am Freitag, den 26.09.2008, 13:20 -0400 schrieb David Rosenstrauch:

> Anyone know the cause and/or who to contact over there to get it fixed? 
>   It's usually a great mirror, and very reliable, and I use it as my 
> primary.

This mirror is not reachable (ping, tracepath) since yesterday. It could
be some maintaince work during weekend. I will write a mail tomorrow if
the mirror don't come back.

Meanwhile i suggest to switch to an other US mirror.

> TIA,
> 
> DR

Gerhard

[arch-general] dhcpcd config files

[Gerhard Brauer]

Hi,

i would like to push this FeatureRequest a little more:
http://bugs.archlinux.org/task/11849

IMHO this could make our network scripts and dhcp more stable.

Regards
Gerhard

Re: [arch-general] [arch-dev-public] Election Night

[Gerhard Brauer]

Am Mittwoch 05 November 2008 11:26:28 schrieb RedShift:
> Aaron "Hussein" Griffin wrote:
> > So no one break the server tonight! Allan, I'm looking in your
> > direction :)
>
> Obama has won. But the real challenge has yet to come.

You mean: So that we can blame Barrack for further server breakage?
"Barrack has broken it", IMHO something Allan like to hear...

> Glenn

Gerhard ("Merkel hat's kaputt gemacht")

[arch-general] [sqlite3] x86_64 version mismatch?

[Gerhard Brauer]

Hello,


in the extra.db.tar.gz on ftp.archlinux.org sqlite3 version for x86_64
is 3.6.6-1. But the binary is
still /extra/os/x86_64/sqlite3-3.6.5-1-x86_64.pkg.tar.gz

Seems that this version upgrade have done today (22.11) so could it be
possible that ftp.archlinux.org mirrors have currently only synced the
database file? Is it a missing upload or only a sync problem?

Regards
Gerhard

Re: [arch-general] [arch-dev-public] Can we trust our mirrors?

[Gerhard Brauer]

Am Sat, 29 Nov 2008 15:00:20 +0100
schrieb Thomas Bächler <[EMAIL PROTECTED]>:

> Pierre Schmitz schrieb:
> > The simplest solution would be if we sign the db files
> > (automatically) on gerolde. Of course this is less secure than
> > signing every single package by its packager; but on the other side
> > it would be easy to implement and there would be no overhead for
> > packagers.
> 
> If this is to provide any security, we need to stop using md5! md5 is 
> okay when trying to detect corrupted downloads, however it is
> possible to find collisions and thus build a "bad" package that has
> the same md5 as the good package.

For myself i don't accept the "md5sum is bad" argument as a "stopper"
for each idea to provide a pacman secure concept ;-)

Current situation is:
Everyone who offers a mirror could provide a manipulated pacman or bash
package. He could reduce the content of a binaray to a simple rm -rf,
fdisk or something. He only has to tar "his" package and edit the
core.db.tar,gz

If we sign our db files as a minimum! security:
This would make package manipulating more difficult. Content changes of
pacman or bash packages (*.pkg.tar.gz) with getting the same md5sum or
sha checksum is surely not impossible - but much more difficult as in
our current situation.

So let's mak a first step!

Gerhard


> 

Re: [arch-general] [arch-dev-public] Can we trust our mirrors?

[Gerhard Brauer]

Am Sat, 29 Nov 2008 17:24:19 -0600
schrieb "Aaron Griffin" <[EMAIL PROTECTED]>:
> 
> I talked to Dan about this briefly the other day. What we concluded
> was that the most proper and secure way to do this is as follows:
> * gerolde hosts a "developer keyring"
> * developers sign their individual packages with their own keys
> * the database file still contains the integrity checksums
> * the database file also includes package signing data

You were right: signing of packages must be done before it gets
transported do any destination. That's the part of each developer IMHO.
We trust them, we must trust them. Each developers public key must be
available in a arch-devel keyring. Pacman itself must pick the right
public key from this keyring (based of package signing data from the
db) to verify the downloaded package. Arch overlord must have the power
to revoke end delete the developers key from this keyring.
repo-add at gerolde could check the correct signing of new packages as
a "first instance". The public keyring must be available for the user
side - best with pacman itself and/or as a seperate package.

> The current proposition, with one key on gerolde used to sign the DB,
> is insecure in that it makes the developers the weak point. If all of
> gerolde, or even only those with sudo rights, can see this private
> key, all it takes is maliciousness on one person's part and all our
> packages are vulnerable.
> 
> The whole point of a private key is just that - that it's private. If
> we suddenly make this key "semi-public", we open the door to lots of
> other issues, at the human level.

AFAIK from Pierre is that repo-add i neither called directly by the
developers - only from scripts when they upload their packages. The
private key for signing the database files could be kept private by
using a dedicated user which runs repo-add under his uid. In the
scripts we could call repo-add with su/sudo and this uid. So the
private key is in $HOME, only available for users with super powers on
gerolde. If one must call repo-add directly this is also possible with
su/sudo. But all in all: signing the database files must be done on
gerolde from/during the process when they are created.

> When I last spoke to Dan, the biggest issue here was that gpg doesn't
> have a library interface. We'd have to call the binary directly from
> pacman.

THAT's sound bad! I'm not a c programmer but is there no useable
library from those on:
http://www.gnupg.org/related_software/libraries.en.html ?
What's with this gpgme also in [extra]?

> If we look at the above solution, we can leverage the
> XferCommand to cover this, without affecting pacman at all:
> * Create a download script that will download a package, check the
> integrity checksum, and verify the signature in the database using the
> archlinux.org keyring
> * Pacman will continue to work as is, considering the checksum is
> still in the DB
> 
> All we'd need is to patch repo-add to include signature data in the
> DB. To do this properly, signatures should be uploaded with the
> package itself, from the packager's machine... hmmm

In the starting mail on arch-dev-public Pierre attached a quick patch
and download script that i have tested with my own repo. This is
working in this way that a whatever modified database file don't get
installed as new data during -Syu when the signature could not be
verified. No new database -> no new packages.

Dirty things with such a solution (as special download script) is:
libalpm/pacman download mechanism gets broken/useless, and the gpg
output (and wget/curl output) is bad to integrate this way in pacman.

Regards
Gerhard

Re: [arch-general] [arch-dev-public] Can we trust our mirrors?

[Gerhard Brauer]

Am Sun, 30 Nov 2008 01:20:13 +0100
schrieb Gerhard Brauer <[EMAIL PROTECTED]>:

> Am Sat, 29 Nov 2008 17:24:19 -0600
> schrieb "Aaron Griffin" <[EMAIL PROTECTED]>:
> > 
> > All we'd need is to patch repo-add to include signature data in the
> > DB. To do this properly, signatures should be uploaded with the
> > package itself, from the packager's machine... hmmm
> 
> In the starting mail on arch-dev-public Pierre attached a quick patch
> and download script that i have tested with my own repo. This is
> working in this way that a whatever modified database file don't get
> installed as new data during -Syu when the signature could not be
> verified. No new database -> no new packages.

I think i misunderstood Aaron part. He mentioned that repo-add should
also add the "signature data" to the db.
Maybe we don't need special data to verify a package against a valid
signature.
We could sign a package inline, that means the tar.gz is enveloped by a
signature (default --sign option). After/during verifying the tar.gz
could be seperated from the signature with --output. The disadvantage
with this methode is maybe that the package archiv could not be used
directly without verifying it.
On the other side we sign with --detach-sign which provides a .sig File
releated to the signed pkg.tar.gz. Upload (and pacman  download) then
must handle two files.

Database signature entries: Maybe we could use existing fields to get
the proper key id from the public keyring to verify. Email oder
packager data. But this could be only done when package is always and
only signed by it's maintainer - and AFAIK we have situations where one
developer build packages for a other.
So you're right: the key id oder fingerprint of the actually
developer/packager/signer must be store in the database file to get the
proper key id.


Regards
Gerhard

Re: [arch-general] [arch-dev-public] Can we trust our mirrors?

[Gerhard Brauer]

Am Sun, 30 Nov 2008 12:54:34 +0100
schrieb Timm Preetz <[EMAIL PROTECTED]>:

> I think ftp.archlinux.org can be pretty slow sometimes (compared to
> near-by mirrors), so wouldn't it be equally sufficient to just fetch
> the DB-checksum from archlinux.org?

This is not possible cause mirrors sync times are different, so the
result was: newer package versions in the db - but the package file is
not available on users mirror.
(I've had make the same request earlier in a bugtracker thread, without
thinking a bit deeper... ;-)

Regards
Gerhard

Re: [arch-general] [arch-dev-public] Can we trust our mirrors?

[Gerhard Brauer]

Am Sun, 30 Nov 2008 07:06:09 -0500
schrieb "Daenyth Blank" <[EMAIL PROTECTED]>:

> On Sun, Nov 30, 2008 at 06:56, solsTiCe d'Hiver
> <[EMAIL PROTECTED]> wrote:
> > i like the original idea of pierre. i had the same one ;-)
> 
> I agree. We can talk until we're blue in the face about the "ideal"
> way to do it, but it doesn't mean a thing if it's not implemented.
> Let's get *something* done, even if it's not ideal.

You are both right.
Let's make a first step with signing the database file - either gpg or
RSA/DSA framework.
Also let's maybe switch package checksumming from md5 to maybe sha512
to get a higher secure of our than signed db/checksum.

In the "ideal solution, the golden way" the database must be signed as
well. So let's start with this. We could get expierience with handling
in repo-add, pacman etc.

In a further step we could think about package signing.

Maybe we/you could implement this as a christmas gift to us users? ;-)

Regards
Gerhard

Re: [arch-general] [arch-dev-public] Can we trust our mirrors?

[Gerhard Brauer]

Am Sun, 30 Nov 2008 15:09:04 +0100
schrieb vlad <[EMAIL PROTECTED]>:

> 
> yes, i also thought about that. that's why i suggested to establish a
> db file repository with a file retention of some days (mirrors
> ususally sync every 2h-24h).
...
> just my 2 cents.

IMHO this could not be handled in practice. We will end in a zillion of
different *.db.tar.gz files, cause the "main" db file could change
every minute/hour by a dev and mirrors don't sync every day in practice.

But more important: At the moment we can't guarantee the integrity of
*one* db file, with your solution we can't guarantee it for 100 db
files. That the file is (maybe) downloaded over a unsecure transport
from a mirror (ftp.archlinux.org are mirrors too) that **could** be
ftp.archlinux.org make it IMHO not more trusted.

> vlad

Regards
Gerhard

Re: [arch-general] [arch-dev-public] [signoff] wpa_supplicant 0.5.11-1

[Gerhard Brauer]

Am Tue, 02 Dec 2008 21:07:11 +0100
schrieb Thomas Bächler <[EMAIL PROTECTED]>:

> Thomas Bächler schrieb:
> > - Update 0.5.10->0.5.11
> > - Enabled dbus support (was already available on i686 in testing)
> > 
> > The daemon and the gui are in testing for both architectures,
> > please sign off.
> 
> ping, any more signoffs?

I could give a user signoff for i686.

Gerhard

Re: [arch-general] [arch-dev-public] Can we trust our mirrors?

[Gerhard Brauer]

Am Wed, 3 Dec 2008 19:40:59 -0600
schrieb "Dan McGee" <[EMAIL PROTECTED]>:

> So where do we stand on all of this? As I showed above, the makepkg
> and repo-add pieces are pretty much in place. We've done a decent
> amount of work on the libalpm/pacman side of things, but it isn't
> complete yet and is very rough around the edges. This is something
> that is very doable if people want to jump in and help us get this
> done. Obviously knowledge of C would be helpful, but we can always use
> some beta testers to help us work out kinks if necessary.
> 
> -Dan

I'm also very interessing to help. I think, mostly with testing but i'm
sure i have some ideas too.
It is ok to check out the named git repos or could you give/setup a
more complete test enviroment?

Gerhard

[arch-general] Offer help for our ISO building

[Gerhard Brauer]

Hi,

i would like to offer my help to the ISO build and test procedure. I'm
sure i have the time and skill to help on archiso and installer skripts.

Currently i will look deeper to get the isolinux thing get running as a
maybe alternative to grub-legacy.
Also to get the keyboard/font selection and the time zone setting
better integrated in the installer.

Also if there are concrete things to do feel free to contact me.

Regards
Gerhard "gerbra"

Re: [arch-general] [arch-dev-public] Can we trust our mirrors?

[Gerhard Brauer]

Am Thu, 4 Dec 2008 08:08:42 -0600
schrieb "Dan McGee" <[EMAIL PROTECTED]>:

> Yes, I would recommend checking out that GIT repo, taking a look at
> that branch, and seeing what it currently does.
> 
> -Dan

Ok, i'll report better to pacman-dev ML

Gerhard

[arch-general] mkinitcpio - Possible patch for ext4 autodetection

[Gerhard Brauer]

Hi, i modified the auto-detection function for file-system modules to
auto-detect a ext4 partition.
The advantage of using blkid instead of klibc-package/bin/fstype is
that blkid detects ext4 filesystems. I tried to rebuild klibc with
kernel 2.6.28, but this failed.

But maybe this could be a alternative method, and maybe better cause
klibc is often older than the kernel.

-
--- /lib/initcpio/install/autodetect.org2008-11-23 07:48:21.0 
+0100
+++ /lib/initcpio/install/autodetect2008-12-27 18:21:22.310364104 +0100
@@ -14,7 +14,7 @@
 findfs ()
 {
 for blkdev in $(find /dev -type b | grep -v -e loop -e ram -e fd); do
-eval $(/usr/lib/klibc/bin/fstype 2>/dev/null < ${blkdev})
+   FSTYPE=$(blkid -o value -s TYPE ${blkdev})
 if [ -n "${FSTYPE}" -a "${FSTYPE}" != "swap" -a "${FSTYPE}" != 
"unknown" -a "${FSTYPE}" != "luks" -a "${FSTYPE}" != "lvm2" ]; then
 echo ${FSTYPE}
 fi
@@ -50,6 +50,7 @@
 grep "^${modname}$" "${MODULE_FILE}" >/dev/null 2>&1 && continue
 case "${m}" in 
 #*/ieee1394/*) echo -e "sbp2\nsd_mod\nsr_mod" >> "${MODULE_FILE}";;
+   *ext4*) echo -e "jbd2\nmbcache\ncrc16" >> "${MODULE_FILE}" ;;
 *ext3*) echo "jbd" >> "${MODULE_FILE}" ;;
 *afs*) echo "rxrpc" >> "${MODULE_FILE}" ;;
 *cramfs*) echo "zlib_inflate" >> "${MODULE_FILE}" ;;
---

With this patch mkinitcpio -M detects the ext4 (and releated) modules,
and i could build a proper initrd image for booting from ext4 (with
grub2 as bootloader)

I don't want to file a bug/feature request while not tested enough.

Regards
Gerhard

Re: [arch-general] [arch-dev-public] grub with ext4 support

[Gerhard Brauer]

Am Mon, 29 Dec 2008 00:30:33 +0100
schrieb "Ronald van Haren" :

> I will check into the grub2 issue in that case.

I've played around last days with grub2 (Version from extra and svn)
for putting it as the ISO bootloader and with ext4 FS.

- I could made a test ISO (archiso based, 2.6.28) with grub2. This boots
  fine in virtual machines (like virtualbox or qemu). But on real
  machines the cdrom (biosdisk module) wasn't found. I never see cd0 on
  real hardware, only the harddisks (looked with ls when ls-module is
  aktivated). I tried question on #grub in IRC, but no answer. (With
  the ata module the cdrom could be handselected with low speed, but
  this is not practicable...)

- grub2 and ext4. Grub2 boots fine on ext4 partitions (i have a
  ext4 /boot partition on VM). But i have problems to (re)install grub2
  when the partition **is** ext4. I tested:

/boot is ext3, install grub2, boot is fine.
Also re-installing grub2 works.
Convert /boot to ext4 (with extent), grub2 boots fine.
If trying to reinstall grub2 then (grub-install --debug /dev/sda) it
rewrites the core.img file in /boot/grub. And then the core.img file
could not be parsed: error cannot read core.img correctly. Maybe a
result of using ext4 extends. During grub-install much files
from /usr/lib/grub(?) get copied to /boot/grub again, and the core.img
file is there also build correctly (thats part of grub-setup). But then
i could not be read (maybe grub2 does this "reading/parsing" in a
unusual way which leads to problems on ext4...

This i get both with the version from extra and from svn. If this
problem is not only based on my mistake or on my enviroment, then we
would have a problem during install to install grub2 on a ext4 prepared
partition - and later if grub2 must be reinstalled.

From my experience with grub/grub2 and ext4 i would assume (also as
part of the installer):
If one would use ext4 for Root-Partition then /boot should be still
ext2/3. Ok, this is one FS module more if ext4 is preferred, but it's
save.

> 
> Ronald

Gerhard

Re: [arch-general] Slow startup of mc

[Gerhard Brauer]

Am Mon, 29 Dec 2008 14:44:15 +0300
schrieb Sergej Pupykin :

> It is bug-feature I think.
> As I understand it is dns resolving problem.
> mc try to resolve local ips. You may put it into /etc/hosts
> 
> 127.0.0.1localhost.localdomainlocalhost
> 192.168.1.2myhostname
> 

Yeah, i always saw this on unusual installed DNS environments. Mostly
the time when the machine hostname could not be solved by local DNS,
either from an real DNS-Server or via /etc/hosts.
So for dhcp-based IP-setting (and the crappy router/box don't resolve
the hostname when the lease is provided) i would assume to put the
hostname as an alias on the localhost line in /etc/hosts.

Ideally there would be a command line parameter to disable all network
related checking for mc...

Gerhard

Re: [arch-general] grub2 and the ISOs (Was: Re: [arch-dev-public] grub with ext4 support)

[Gerhard Brauer]

Am Mon, 29 Dec 2008 17:17:35 +0100
schrieb Thomas Bächler :

> This is interesting: On many BIOSes, grub 0.x is unable to find the
> CD drive and thus many people want us to use isolinux.

Personally i prefer isolinux as a "better" solution for ISO bootloader,
but grub's advantage is the grub shell...

>  From what you write here, it seems that you can access the CD drive 
> through another than the BIOS boot device method. It doesn't matter
> that access is slow, it only matters that we are able to load the
> kernel and initramfs on a greater number of machines. IMO, this is
> worth looking into.

You get these ata0, ata0,1, ata1 devices when adding the ata module to
grub2 image. But the problem is: No one could say on which bus the
users cdrom is (ata1, ata3,...). So the boot ends always in a grub2
shell instead showing the menu. User then must set it per Hand, like:
set root=ata1
linux /boot/vmlinuz26
initrd /boot/kernel26.img
boot

And I've tested this ata method only on VMs. I'm not sure if on real
machines the cdrom is realy detected as ata device (it wasn't detected
as normal device cd0, cd1 on real hardware if using the biosdisk
module). And i realy don't know why, on virtualbox,qemu it work's.

If one would test - the way to make a grub2 bootloader image for
mkisofs is:
grub-makeimage -o mycore.img list_of_modules
cat /boot/grub/cdboot.img mycore.img > myboot.img
myboot.img could now used as mkisofs parameter (-b) like we does it
with grub-legacy in mkarchiso.

Grub2 modular design (and the available modules) have a great potential
IMHO (not only that one could make it terrible blinking and colored,
splash shit). But there is a lack on documentation IMHO

Gerhard

[arch-general] ftpd problem on ftp.archlinux.org?

[Gerhard Brauer]

Hi, today i have several failed connections to ftp.archlinux.org

---
[gerh...@tux1 ~]$ LANG=C wget 
ftp://ftp.archlinux.org/core/os/i686/core.db.tar.gz
--2008-12-29 21:18:15--
ftp://ftp.archlinux.org/core/os/i686/core.db.tar.gz =>
`core.db.tar.gz.7' Resolving ftp.archlinux.org... 209.85.41.145,
209.85.41.144 Connecting to ftp.archlinux.org|209.85.41.145|:21...
connected. Logging in as anonymous ... 
Error in server response, closing control connection.
Retrying.

--2008-12-29 21:18:16--
ftp://ftp.archlinux.org/core/os/i686/core.db.tar.gz (try: 2) =>
`core.db.tar.gz.7' Connecting to ftp.archlinux.org|209.85.41.145|:21...
connected. Logging in as anonymous ... 
Error in server response, closing control connection.
Retrying.

--2008-12-29 21:18:18--
ftp://ftp.archlinux.org/core/os/i686/core.db.tar.gz (try: 3) =>
`core.db.tar.gz.7' Connecting to ftp.archlinux.org|209.85.41.145|:21...
connected. Logging in as anonymous ... 
Error in server response, closing control connection.
Retrying.

--2008-12-29 21:18:22--
ftp://ftp.archlinux.org/core/os/i686/core.db.tar.gz (try: 4) =>
`core.db.tar.gz.7' Connecting to ftp.archlinux.org|209.85.41.145|:21...
connected. Logging in as anonymous ... 
Error in server response, closing control connection.
Retrying.
^C
--

Sometimes it goes fine after several tries. Seems onyl that 
209.85.41.145 has the problem.

Gerhard

Re: [arch-general] what happens with rsync?

[Gerhard Brauer]

Am Sat, 03 Jan 2009 13:36:01 +0300
schrieb Sergej Pupykin :

> Hi,
> 
> At least 2 mirrors do not update for a few days:
> 
> - mir1.archlinuxfr.org
> - mirrors.yandex.ru
> 
> What happens?

I could not see rsync lists, but there a quite more mirrors which
stopped syncing. Cause the time when they last syned is nearly equal i
assume that one mirror has a stall cron job, and the other mirrors sync
from this or from each other.

I will write a mail to all, i hoped that over night one or all of them
come back, but this wasn't so.

Regards
Gerhard

Re: [arch-general] xscreensaver broken?

[Gerhard Brauer]

Am Tue, 06 Jan 2009 22:45:32 +0100
schrieb Frédéric Perrin :

> Le Mardi 6 à 19:46, Guus Snijders a écrit :
> > Well, removing glib didn't make a difference, so i tried recompiling
> > it (with yaourt -Sb xscreensaver).
> >
> > But alas, compiling ended with:
> >
> > galaxy.c: In function 'draw_galaxy':
> > galaxy.c:462: internal compiler error: Segmentation fault
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See  for instructions.
> > make[1]: *** [galaxy.o] Error 1
> > make[1]: Leaving directory
> > `/tmp/yaourt-tmp-ghs/abs-xscreensaver/src/xscreensaver-5.08/hacks'
> > make: *** [default] Error 5
> > ==> ERROR: Build Failed.
> > Aborting...
> > Error: Makepkg was unable to build xscreensaver package.
> 
> Well, a C source that make GCC segfaults is a sign of a bug in GCC
> rather than in the code, isn't it ?

No problem here on i686. I could start/run xscreenserver-demo and
complile xscreensaver. Maybe a RAM problem?

Regards
Gerhard

Re: [arch-general] xscreensaver broken?

[Gerhard Brauer]

Am Wed, 7 Jan 2009 08:40:00 +0100
schrieb "Guus Snijders" :

> But later on i noticed some problems with other
> apps, so i think it's a problem with my current installation. I'll try
> a reinstall later this week.

Have you checked if you use some no-default optimizations in
makepkg.conf? Or if it maybe a yaourt problem? I always build packages
from abs tree and makepkg

> mvg,
>  Guus

Gerhard

Re: [arch-general] [arch-dev-public] [signoff] kernel26 2.6.28-3

[Gerhard Brauer]

Am Tue, 06 Jan 2009 17:54:08 +0100
schrieb Thomas Bächler :

> Aaron Griffin schrieb:
> > On Tue, Jan 6, 2009 at 5:08 AM, Tobias Powalowski 
> > wrote:
> >> Showstopper:
> >> klibc needs to be fixed. It breaks compilation of tools.
> > 
> > Could you be more specific? There was some talk on the klibc ML
> > about recent kernel changes, so I'd like to know what is broken.
> > Perhaps it is fixable (and Debian may have changes already)
> 
> klibc didn't build against 2.6.28 because some asm headers are now in 
> arch/x86/include/ instead of include/asm-x86/. I added a quick-fix to 
> the Makefile so klibc would build. However, I forgot that these
> headers weren't installed either, so now klcc does not compile
> anything that needs any of those headers (I didn't notice because I
> didn't have to recompile the klibc-* packages). This means: klibc
> works as a runtime library, but klcc is useless.

IMHO is the problem in our kernel26 package. Therein we have a bad
symlink to the architecture asm directory.

[gerh...@tux1 ~]$ ls -ld /usr/src/linux-2.6.28-ARCH/include/asm
lrwxrwxrwx 1 root root 7 26. Dez 11:01 /usr/src/linux-2.6.28-ARCH/include/asm 
-> asm-x86
[gerh...@tux1 ~]$ ls -l /usr/src/linux-2.6.28-ARCH/include/asm/
-rw-r--r-- 1 root root 5877 26. Dez 10:43 asm-offsets.h

If compiling klibc from testing (i use 1.5.15) with the 2.6.28 patch we have
in klibc:
-
/usr/lib/klibc/include/asm
total 8
lrwxrwxrwx 1 root root8 2009-01-09 11:54 asm-i386 -> asm-i386
-rw-r--r-- 1 root root 5877 2009-01-09 11:53 asm-offsets.h
lrwxrwxrwx 1 root root7 2009-01-09 11:54 asm-x86 -> asm-x86

two death symlinks (asm-i386, asm-x86). These are the problems that the other
klibc-* tools don't build.

But if i change the kernel asm Symlink to:
/usr/src/linux-2.6.28-ARCH/include/asm -> 
/usr/src/linux-2.6.28-ARCH/arch/x86/include/asm
(for i686), then i could build
a) klibc 1.5.15 without the 2.6.28-patch
b) the other klibc-* tools from core.

Regards
Gerhard

Re: [arch-general] [arch-dev-public] [signoff] kernel26 2.6.28-3

[Gerhard Brauer]

Am Fri, 9 Jan 2009 13:03:59 +0100
schrieb Gerhard Brauer :

> Am Tue, 06 Jan 2009 17:54:08 +0100
> schrieb Thomas Bächler :
> 
> > Aaron Griffin schrieb:
> > > On Tue, Jan 6, 2009 at 5:08 AM, Tobias Powalowski 
> > > wrote:
> > >> Showstopper:
> > >> klibc needs to be fixed. It breaks compilation of tools.
> > > 
> > > Could you be more specific? There was some talk on the klibc ML
> > > about recent kernel changes, so I'd like to know what is broken.
> > > Perhaps it is fixable (and Debian may have changes already)
> > 
> > klibc didn't build against 2.6.28 because some asm headers are now
> > in arch/x86/include/ instead of include/asm-x86/. I added a
> > quick-fix to the Makefile so klibc would build. However, I forgot
> > that these headers weren't installed either, so now klcc does not
> > compile anything that needs any of those headers (I didn't notice
> > because I didn't have to recompile the klibc-* packages). This
> > means: klibc works as a runtime library, but klcc is useless.
> 
> IMHO is the problem in our kernel26 package. Therein we have a bad
> symlink to the architecture asm directory.
> 
> [gerh...@tux1 ~]$ ls -ld /usr/src/linux-2.6.28-ARCH/include/asm
> lrwxrwxrwx 1 root root 7 26. Dez
> 11:01 /usr/src/linux-2.6.28-ARCH/include/asm -> asm-x86 [gerh...@tux1
> ~]$ ls -l /usr/src/linux-2.6.28-ARCH/include/asm/ -rw-r--r-- 1 root
> root 5877 26. Dez 10:43 asm-offsets.h
> 
> If compiling klibc from testing (i use 1.5.15) with the 2.6.28 patch
> we have in klibc:
> -
> /usr/lib/klibc/include/asm
> total 8
> lrwxrwxrwx 1 root root8 2009-01-09 11:54 asm-i386 -> asm-i386
> -rw-r--r-- 1 root root 5877 2009-01-09 11:53 asm-offsets.h
> lrwxrwxrwx 1 root root7 2009-01-09 11:54 asm-x86 -> asm-x86
> 
> two death symlinks (asm-i386, asm-x86). These are the problems that
> the other klibc-* tools don't build.
> 
> But if i change the kernel asm Symlink to:
> /usr/src/linux-2.6.28-ARCH/include/asm
> -> /usr/src/linux-2.6.28-ARCH/arch/x86/include/asm (for i686), then i
> could build a) klibc 1.5.15 without the 2.6.28-patch
> b) the other klibc-* tools from core.

Other (better?) solution without the need to modify kernel26:
Copy the needed asm Include files and directories to klibc/klcc's
include dir. I attach a modified PKGBUILD for klibc (upstream version
1.5.15).
This is quick&dirty, but it works. For klibc itself the 2.6.28.patch is
still needed but the other klibc-* tools build without errors.
BTW: about the two death symlinks: these are also in current core klibc
package. The i386 symlink is produced by klibc make itself, the other
(asm-x86) by our PKGBUILD.
For ext4 support the patch is no longer needed.

I tested on i686.

Regards
Gerhard


PKGBUILD
Description: Binary data

[arch-general] 2.6.28 to core?

[Gerhard Brauer]

Hello,

seems that all stopper for 2.6.28 are solved.
Are there any issues that causes 2.6.28 (and klibc, mkinitcpio) don't
went to [core]? Without these the new ISO's couldn't be build...

Regards
Gerhard