Nabble - Mandriva - cooker-x86

Re: [Cooker] Is this a kernel bug?

2009-11-27T08:22:22Z

On Fri, Nov 27, 2009 at 17:08, Luiz Alberto Saba <las@...> wrote:
>
> I've already updated my bios for A05 with exactly the same error.

Then complain to dell with this info, maybe it will get transmitted to
someone who can fix it in next bios...

Re: [Cooker] Is this a kernel bug?

2009-11-27T08:08:03Z

Em Sexta-feira 27 Novembro 2009, às 12:56:14, R James escreveu:
> The message says your BIOS is broken. If you go to www.dell.com and search
> for drivers and downloads for your Optiplex 760, you will see that
> they have issued
> BIOS version A05 (which is newer than your A03) with importance level
> of "Urgent"
>
> "Dell highly recommends applying this update as soon as possible. The
> update contains changes to improve the reliability and availability of
> your Dell system."

I've already updated my bios for A05 with exactly the same error.

------------[ cut here ]------------
WARNING: at drivers/pci/dmar.c:642 alloc_iommu+0x217/0x2b0()
Hardware name: OptiPlex 760
Your BIOS is broken; DMAR reported at address fedc1000 returns all ones!
BIOS vendor: Dell Inc.; Ver: A05; Product Version:
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.31.6-desktop-1mnb #1
Call Trace:
[<ffffffff8105b44b>] warn_slowpath_common+0x7b/0xc0
[<ffffffff8105b4f1>] warn_slowpath_fmt+0x41/0x50
[<ffffffff81201127>] alloc_iommu+0x217/0x2b0
[<ffffffff816754e0>] dmar_table_init+0x1b2/0x35a
[<ffffffff8165cb22>] enable_IR_x2apic+0x12/0x17e
[<ffffffff8165a6e7>] native_smp_prepare_cpus+0x126/0x35a
[<ffffffff8164e508>] kernel_init+0x56/0x1a6
[<ffffffff810130aa>] child_rip+0xa/0x20
[<ffffffff8164e4b2>] ? kernel_init+0x0/0x1a6
[<ffffffff810130a0>] ? child_rip+0x0/0x20
---[ end trace a7919e7f17c0a725 ]---

>
> On Fri, Nov 27, 2009 at 6:24 AM, Luiz Alberto Saba <las@...>
wrote:

> > ------------[ cut here ]------------
> > WARNING: at drivers/pci/dmar.c:642 alloc_iommu+0x217/0x2b0()
> > Hardware name: OptiPlex 760
> > Your BIOS is broken; DMAR reported at address fedc1000 returns all ones!
> > BIOS vendor: Dell Inc.; Ver: A03; Product Version:
> > Modules linked in:
> > Pid: 1, comm: swapper Not tainted 2.6.31.6-desktop-1mnb #1
> > Call Trace:
> > [<ffffffff8105b44b>] warn_slowpath_common+0x7b/0xc0
> > [<ffffffff8105b4f1>] warn_slowpath_fmt+0x41/0x50
> > [<ffffffff81201127>] alloc_iommu+0x217/0x2b0
> > [<ffffffff816754e0>] dmar_table_init+0x1b2/0x35a
> > [<ffffffff8165cb22>] enable_IR_x2apic+0x12/0x17e
> > [<ffffffff8165a6e7>] native_smp_prepare_cpus+0x126/0x35a
> > [<ffffffff8164e508>] kernel_init+0x56/0x1a6
> > [<ffffffff810130aa>] child_rip+0xa/0x20
> > [<ffffffff8164e4b2>] ? kernel_init+0x0/0x1a6
> > [<ffffffff810130a0>] ? child_rip+0x0/0x20
> > ---[ end trace a7919e7f17c0a725 ]---
>

Re: [Cooker] rsyslog incoming

2009-11-27T07:41:20Z

On Fri, 27 Nov 2009 15:29:02 +0100, Frederik Himpe wrote about Re: [Cooker]
rsyslog incoming:

>Are you using high security level in msec? Apparently in that case, only
>services whitelisted in /etc/security/msec/server.remote are added with
>chkconfig. I opened this bug:
>https://qa.mandriva.com/show_bug.cgi?id=56025

Yes, that's the reason. Thanks for the fix!

Cheers,
=Dick Gevers=

Re: [Cooker] Is this a kernel bug?

2009-11-27T06:56:14Z

The message says your BIOS is broken. If you go to www.dell.com and search
for drivers and downloads for your Optiplex 760, you will see that
they have issued
BIOS version A05 (which is newer than your A03) with importance level
of "Urgent"

"Dell highly recommends applying this update as soon as possible. The update
contains changes to improve the reliability and availability of your
Dell system."

On Fri, Nov 27, 2009 at 6:24 AM, Luiz Alberto Saba <las@...> wrote:

> ------------[ cut here ]------------
> WARNING: at drivers/pci/dmar.c:642 alloc_iommu+0x217/0x2b0()
> Hardware name: OptiPlex 760
> Your BIOS is broken; DMAR reported at address fedc1000 returns all ones!
> BIOS vendor: Dell Inc.; Ver: A03; Product Version:
> Modules linked in:
> Pid: 1, comm: swapper Not tainted 2.6.31.6-desktop-1mnb #1
> Call Trace:
> [<ffffffff8105b44b>] warn_slowpath_common+0x7b/0xc0
> [<ffffffff8105b4f1>] warn_slowpath_fmt+0x41/0x50
> [<ffffffff81201127>] alloc_iommu+0x217/0x2b0
> [<ffffffff816754e0>] dmar_table_init+0x1b2/0x35a
> [<ffffffff8165cb22>] enable_IR_x2apic+0x12/0x17e
> [<ffffffff8165a6e7>] native_smp_prepare_cpus+0x126/0x35a
> [<ffffffff8164e508>] kernel_init+0x56/0x1a6
> [<ffffffff810130aa>] child_rip+0xa/0x20
> [<ffffffff8164e4b2>] ? kernel_init+0x0/0x1a6
> [<ffffffff810130a0>] ? child_rip+0x0/0x20
> ---[ end trace a7919e7f17c0a725 ]---
>

Re: [Cooker] rsyslog incoming

2009-11-27T06:29:02Z

On vr, 2009-11-27 at 13:09 +0000, Dick Gevers wrote:

> On Fri, 27 Nov 2009 12:04:24 +0100, Frederik Himpe wrote about Re: [Cooker]
> rsyslog incoming:
>
> >On do, 2009-11-26 at 22:49 +0000, Dick Gevers wrote:
> >> On Tue, 24 Nov 2009 22:12:50 +0100, Frederik Himpe wrote about [Cooker]
> >> rsyslog incoming:
> >>
> >> >A new rsyslog package which obsoletes sysklogd is currently on its way
> >> >to the mirrors.
> >>
> >> I noticed after upgrade to 4.4.2-5mdv that rsyslog is off in chkconfig
> >> --list at all runlevels: I had to add them manually.
> >
> >The package has %_post_service rsyslog in its
> >%post script. For me it works fine. Did you somehow interrupt or disable
> >the %post scripts?
>
> Nope, just plain old urpmi --auto-select.

Are you using high security level in msec? Apparently in that case, only
services whitelisted in /etc/security/msec/server.remote are added with
chkconfig. I opened this bug:
https://qa.mandriva.com/show_bug.cgi?id=56025

--
Frederik Himpe <fhimpe@...>

Re: [Cooker] rsyslog incoming

2009-11-27T05:09:28Z

On Fri, 27 Nov 2009 12:04:24 +0100, Frederik Himpe wrote about Re: [Cooker]
rsyslog incoming:

>On do, 2009-11-26 at 22:49 +0000, Dick Gevers wrote:
>> On Tue, 24 Nov 2009 22:12:50 +0100, Frederik Himpe wrote about [Cooker]
>> rsyslog incoming:
>>
>> >A new rsyslog package which obsoletes sysklogd is currently on its way
>> >to the mirrors.
>>
>> I noticed after upgrade to 4.4.2-5mdv that rsyslog is off in chkconfig
>> --list at all runlevels: I had to add them manually.
>
>The package has %_post_service rsyslog in its
>%post script. For me it works fine. Did you somehow interrupt or disable
>the %post scripts?

Nope, just plain old urpmi --auto-select.

Cheers,
=Dick Gevers=

[Cooker] Is this a kernel bug?

2009-11-27T04:24:58Z

------------[ cut here ]------------
WARNING: at drivers/pci/dmar.c:642 alloc_iommu+0x217/0x2b0()
Hardware name: OptiPlex 760
Your BIOS is broken; DMAR reported at address fedc1000 returns all ones!
BIOS vendor: Dell Inc.; Ver: A03; Product Version:
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.31.6-desktop-1mnb #1
Call Trace:
[<ffffffff8105b44b>] warn_slowpath_common+0x7b/0xc0
[<ffffffff8105b4f1>] warn_slowpath_fmt+0x41/0x50
[<ffffffff81201127>] alloc_iommu+0x217/0x2b0
[<ffffffff816754e0>] dmar_table_init+0x1b2/0x35a
[<ffffffff8165cb22>] enable_IR_x2apic+0x12/0x17e
[<ffffffff8165a6e7>] native_smp_prepare_cpus+0x126/0x35a
[<ffffffff8164e508>] kernel_init+0x56/0x1a6
[<ffffffff810130aa>] child_rip+0xa/0x20
[<ffffffff8164e4b2>] ? kernel_init+0x0/0x1a6
[<ffffffff810130a0>] ? child_rip+0x0/0x20
---[ end trace a7919e7f17c0a725 ]---

Re: [Cooker] ANNOUNCE: parole 0.1.98 released ( don't laugh ! )

2009-11-27T03:15:09Z

Le vendredi 27 novembre 2009 12:09:37, patrick.2@... a écrit :

> parole 0.1.98 is now available for download from
>
> http://archive.xfce.org/src/apps/parole/0.1/parole-0.1.98.tar.bz2
> http://archive.xfce.org/src/apps/parole/0.1/parole-0.1.98.tar.bz2.md5
> http://archive.xfce.org/src/apps/parole/0.1/parole-0.1.98.tar.bz2.sha1
>
> SHA1 checksum: 5a6a72aecce300771f1a8db9f79a7521394b157b
> MD5 checksum: 62fc89acb02052de585e7c2f2618198f
>
> Nicolas, hope it work now ^^

uploaded ;)

--
Nicolas Lécureuil
Mandriva KDE team

signature.asc (205 bytes) Download Attachment

[Cooker] ANNOUNCE: parole 0.1.98 released ( don't laugh ! )

2009-11-27T03:09:37Z

parole 0.1.98 is now available for download from

http://archive.xfce.org/src/apps/parole/0.1/parole-0.1.98.tar.bz2
http://archive.xfce.org/src/apps/parole/0.1/parole-0.1.98.tar.bz2.md5
http://archive.xfce.org/src/apps/parole/0.1/parole-0.1.98.tar.bz2.sha1

SHA1 checksum: 5a6a72aecce300771f1a8db9f79a7521394b157b
MD5 checksum: 62fc89acb02052de585e7c2f2618198f

Nicolas, hope it work now ^^

-
Patrick.
envoye depuis Mandriva One 2009.0 Xfce :)

Gratuite, garantie à vie et déjà utilisée par des millions d'internautes...
vous aussi, pour votre adresse e-mail, choisissez laposte.net.

Laposte.net, bien + qu'une messagerie

Re: [Cooker] rsyslog incoming

2009-11-27T03:04:24Z

On do, 2009-11-26 at 22:49 +0000, Dick Gevers wrote:
> On Tue, 24 Nov 2009 22:12:50 +0100, Frederik Himpe wrote about [Cooker]
> rsyslog incoming:
>
> >A new rsyslog package which obsoletes sysklogd is currently on its way
> >to the mirrors.
>
> I noticed after upgrade to 4.4.2-5mdv that rsyslog is off in chkconfig
> --list at all runlevels: I had to add them manually.

The package has %_post_service rsyslog in its
%post script. For me it works fine. Did you somehow interrupt or disable
the %post scripts?

--
Frederik Himpe <fhimpe@...>

Re: [Cooker] Some interesting KDE additions

2009-11-27T02:10:33Z

Le mardi 24 novembre 2009 à 17:00 +0100, Nicolas Lécureuil a écrit :

> Le mardi 24 novembre 2009 16:57:13, Luis Daniel Lucio Quiroz a écrit :
> > Le lundi 23 novembre 2009 23:47:35, Glen Ogilvie a écrit :
> > > Hi Luis
> > >
> > > On Tue, 24 Nov 2009, Luis Daniel Lucio Quiroz wrote:
> > > > Le mardi 4 août 2009 16:06:41, Glen Ogilvie a écrit :
> > > > > Hi Vincent,
> > > > >
> > > > > On Tue, 4 Aug 2009 13:10:33 +0200, Vincent Panel <yohonet@...>
> > > > >
> > > > > wrote:
> > > > > > Kopete facebook-chat protocol support :
> > > > >
> > > > > http://software.opensuse.org/search?baseproject=openSUSE:Factory&p=1&
> > > > >q= kd e4 -kopete-protocol-facebook
> > > > >
> > > > > I have been testing the Kopete facebook-chat app. It's not 100% but
> > > > > seem to work most of the time,
> > > > > therefor, I have not submitted it to be part of cooker.
> > > > >
> > > > > If you want to try it, packages for 2009.1 64 bit, and srpms, are
> > > > > available on my website:
> > > > >
> > > > > http://www.linuxbox.co.nz/kopete-facebook/
> > > > >
> > > > > Regards
> > > > > Glen Ogilvie
> > > >
> > > > It seems 1.4 (latest git) is pretty stable and usable. At least in my
> > > > laptop with 2010.0. I did submit it into contrib/testings.
> > > >
> > > > Please report if it works or we shall wait until 1.5.
> > >
> > > Thank you, nice to see it come back to me with a newer version.
> > >
> > > I had to add the attached patch for rpath, to get it to compile on my
> > > 2009.1, x86_64 machine, but then it seems to work much better, as the
> > > old version only connected sometimes. Do you not have problems with
> > > rpath on the machines your compiling it on?
> > >
> > > Regards
> > > Glen Ogilvie
> >
> > no, under 2010.0 and cooker it compiles okay,
> > I may add your patch as a condition when backporting to 2009.1
> >
>
> why as a condition ? is there any pb if this is used on all arch ?

If there is a problem on one architecture, then the patch is wrong, and
disabling it is likely to be wrong workaround.

Patch should not be applied conditionnaly based on architecture.
--
Michael Scherer

Re: [Cooker] Mirrorlist / generatelist.pl issues

2009-11-27T01:49:22Z

Le mercredi 25 novembre 2009 à 00:02 +0100, Davy Defaud a écrit :

> aapgorilla a écrit :
> > On Tue, Nov 24, 2009 at 6:31 PM, Guillaume Rousse
> > <Guillaume.Rousse@...> wrote:
> >
> >> Davy Defaud a écrit :
> >> Why don't you use hardcoded mirrors URLs then ?
> >>
> > Indeed, only a very small fraction of users have a mirror set up by
> > their ISP anyway...
> >
> >
>
> Free is the 2nd ISP in France, with 4 420 000 DSL subscribers and it is
> the favorite ISP of the Linux users.

reference needed :)

> at least 1% of Linux users = 44 200
> about 40% of Mandriva users = 17680

reference needed again

> Let's say 15 000, and this is only for Free subscribers.
> Indeed a small fraction of Mandriva users (< 1%).
> But 15 000 users is that negligible?

Well, that's the same number, so I fail to see how this will change.

But if you really want something, here are the requirement for a
change :
- no dynamic computation server side
- no incompatible changes ( yet, maybe a field could be added to the
list, provided this doesn't break older releases )

so if you want to improve client side mirror selection, feel free to do
so, the patch will likely be accepted on the design level ( which
doesn't mean it will refused based on others consideration ).

Personnaly, i think it could be easy to check AS in urpmi, provided we
find how we can get the AS of a network address ( perl-Net-Whois could
do the trick, except data are not structured enough from what I have
seen ).

--
Michael Scherer

Re: [Cooker] Mirrorlist / generatelist.pl issues

2009-11-27T01:15:37Z

Le mardi 24 novembre 2009 à 14:07 +0100, aapgorilla a écrit :

> On Tue, Nov 24, 2009 at 1:54 PM, Anssi Hannula <anssi@...> wrote:
> > It doesn't matter if they are transient. One should be able to see from
> > urpmi output what urpmi/aria2c is doing wrong, and then one can fix it.
> >
> I don't have many problems myself but many people on the forum have,
> eg see this thread (there are many similars ones )
> http://forum.mandriva.com/viewtopic.php?t=118676&highlight=carroll
>
> >> Anyway my main point it why we are not using the multidownload feature
> >> of aria2? We can simply try to download a file from all mirrors at the
> >> same time, this will ensure both good speeds and reliability
> >
> > My guess would be we are not using that by default in order to avoid
> > stressing mirrors.
> more request vs less bandwith per mirror, also in the current
> situation people tend to switch to wget and cherry pick certain known
> good mirrors, stressing these even more

Usually, network bandwidth is not the biggest issue with most mirror,
what is causing problem is i/o, memory, etc.

On distrib-coffee, http is limited to 200 simultaneous download because
of such issues. And there was also problem with people using parallel
downloader to work around the QOS , thus taking 10 http connections.

So if, to download 1 file, you open 6 connection to 6 mirrors ( as you
propose ), you are putting 6 time the stress needed to download the
file. This is not something that should be done imho, at least not
without the input of mirror operators.

--
Michael Scherer

Re: [Cooker] IRC support for kopete

2009-11-27T00:09:15Z

Le vendredi 27 novembre 2009 05:52:30, Luis Daniel Lucio Quiroz a écrit :

> Hi all,
>
> I've imported in contrib/testings for cooker and 2010.0 a plug for kopete
> to let it use IRC. It lacks some basic capabilities like room listing,
> but it is pretty stable (at least in my lap with 2010.0).
>
> I'd like your comments to know if is stable to import into
> contrib/releasee.
>
> LD
>

Hi,

why on testing ? isn't cooker already for testing ?
for such apps i think contrib/release directly is the right place

the same goes for ircclient-qt

Other things wrong not related to this mail but i need to speak about.
kopete-protocol-facebook have been uploaded in 2010.0 contrib/testing but not
in cooker.

The apps need to be on cooker too, i don't see any reason to skip cooker

Regards,

--
Nicolas Lécureuil
Mandriva KDE team

signature.asc (205 bytes) Download Attachment

[Cooker] IRC support for kopete

2009-11-26T20:52:30Z

Hi all,

I've imported in contrib/testings for cooker and 2010.0 a plug for kopete to
let it use IRC. It lacks some basic capabilities like room listing, but it is
pretty stable (at least in my lap with 2010.0).

I'd like your comments to know if is stable to import into contrib/releasee.

LD

[Cooker] libqjson has a buggy provides?

2009-11-26T20:46:05Z

AS I see
urpmq libqjson-devel-0.6-1mdv2010.0 --provides
libqjson-devel[== 0.6-1mdv2010.0]
pkgconfig(QJson)[== 0.6.0]
devel(libqjson)
libqjson-devel[== 0.6-1mdv2010.0]
libqjson-devel(x86-32)[== 0.6-1mdv2010.0]

libqjson does not provides qjson-devel, should it? istead of providing
libqson-devel. I have this doubt because lib64json :) If so, package name
shoud change to qjson, but libqjson,.

:)

Re: [Cooker] [2010.0] UDEV failure after upgrade from 2009.1

2009-11-26T20:00:05Z

On Friday 27 of November 2009 01:00:23 Steve Morris wrote:
> I have just finished upgrading all my 2009.1 packages to 2010.0 from
> the 2010.0 repositories. Now when I boot I get the following
> messages displayed on UDEV startup:
>
> ERROR: sil: only 1/4 metadata areas found on /dev/sdb, picking ...

This message comes from dmraid

> failed to stat() /dev/mapper//dev/sdb:
> failed to stat() /dev/mapper/"sil"
> failed to stat() /dev/mapper/and
> failed to stat() /dev/mapper/"pdc"
> failed to stat() /dev/mapper/formats
> failed to stat() /dev/mapper/discovered
> failed to stat() /dev/mapper/(using
> failed to stat() /dev/mapper/pdc)!
> failed to stat() /dev/mapper/pdc_bciegdef
>
> Also udev cannot see any partitions on /dev/sdb whereas 2009.1 had no
> problems.

Was this disk ever part of fake raid in some PC?

> I suspect the problem is that udev cannot handle the
> partition numbers of the partitions actually on the disk. I only
> have 1 partition on the disk, being an extended partition containing
> 2 logical partitions. These are addressed as /dev/sdb2 (extended
> partition), /dev/sdb5 (1st logical) and /dev/sdb6 (2nd logical).
> Fdisk shows the partitions quite happily.
> The sdb harddisk contains my cooker system which I have no trouble
> booting from, hence there are no problems with the hardware.
>
> Does anyone know what the problem in udev could be that would cause
> these problems and do I need to raise a bug report?
>
> regards,
> Steve
>

signature.asc (205 bytes) Download Attachment

Re: [Cooker] rsyslog incoming

2009-11-26T14:49:05Z

On Tue, 24 Nov 2009 22:12:50 +0100, Frederik Himpe wrote about [Cooker]
rsyslog incoming:

>A new rsyslog package which obsoletes sysklogd is currently on its way
>to the mirrors.

I noticed after upgrade to 4.4.2-5mdv that rsyslog is off in chkconfig
--list at all runlevels: I had to add them manually.

HTH

Cheers,
=Dick Gevers=

Re: [Cooker] [2010.0] UDEV failure after upgrade from 2009.1

2009-11-26T14:22:32Z

Colin Guthrie wrote:
> 'Twas brillig, and Steve Morris at 26/11/09 22:00 did gyre and gimble:
>> Does anyone know what the problem in udev could be that would cause
>> these problems and do I need to raise a bug report?
>
> Did you make sure to upgrade the kernel?
>
> Col
>
Thanks for replying Col. I believe I upgraded the kernel unless the
mirror I used did not have the latest kernel. The kernel I am booting
from is vmlinuz-2.6.31.5-desktop-1mnb.
The other thing I forgot to mention is that during the upgrade the
installation of the udev rpm also produced the metadata and stat failure
messages.

regards,
Steve

[samorris.vcf]

begin:vcard fn:Steve Morris n:Morris;Steve email;internet:samorris@... x-mozilla-html:TRUE version:2.1 end:vcard

Re: [Cooker] Re: Using dash for init scripts

2009-11-26T14:20:21Z

On Wednesday 25 November 2009, Éric Piel wrote:
> How about implementing /bin/sh as an alternative?

IMHO, bad idea. /bin/sh shouldn't depend on anything outside /bin and /lib.
It would be genuinely bad, if that link ever broke.

--
Say NO to spam and viruses. Stop using Microsoft Windows!

Re: [Cooker] [2010.0] UDEV failure after upgrade from 2009.1

2009-11-26T14:12:39Z

'Twas brillig, and Steve Morris at 26/11/09 22:00 did gyre and gimble:
> Does anyone know what the problem in udev could be that would cause
> these problems and do I need to raise a bug report?

Did you make sure to upgrade the kernel?

Col

--

Colin Guthrie
cguthrie(at)mandriva.org
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

[Cooker] [2010.0] UDEV failure after upgrade from 2009.1

2009-11-26T14:00:23Z

I have just finished upgrading all my 2009.1 packages to 2010.0 from the
2010.0 repositories. Now when I boot I get the following messages
displayed on UDEV startup:

ERROR: sil: only 1/4 metadata areas found on /dev/sdb, picking ...
failed to stat() /dev/mapper//dev/sdb:
failed to stat() /dev/mapper/"sil"
failed to stat() /dev/mapper/and
failed to stat() /dev/mapper/"pdc"
failed to stat() /dev/mapper/formats
failed to stat() /dev/mapper/discovered
failed to stat() /dev/mapper/(using
failed to stat() /dev/mapper/pdc)!
failed to stat() /dev/mapper/pdc_bciegdef

Also udev cannot see any partitions on /dev/sdb whereas 2009.1 had no
problems. I suspect the problem is that udev cannot handle the partition
numbers of the partitions actually on the disk. I only have 1 partition
on the disk, being an extended partition containing 2 logical
partitions. These are addressed as /dev/sdb2 (extended partition),
/dev/sdb5 (1st logical) and /dev/sdb6 (2nd logical). Fdisk shows the
partitions quite happily.
The sdb harddisk contains my cooker system which I have no trouble
booting from, hence there are no problems with the hardware.

Does anyone know what the problem in udev could be that would cause
these problems and do I need to raise a bug report?

regards,
Steve

[samorris.vcf]

begin:vcard fn:Steve Morris n:Morris;Steve email;internet:samorris@... x-mozilla-html:TRUE version:2.1 end:vcard

Re: [Cooker] startx no more runs default xinitrc (Xsession)

2009-11-26T09:38:41Z

On Wednesday 25 of November 2009 21:03:10 Paulo Zanoni wrote:
> Ok, I have updated xinit again. I had to revert part of an upstream
> change. if it's now working again, please tell me how you tested it
> so I can reproduce the bug.
>

It works. Thank you.

Although personally I would simply remove this patch :)

signature.asc (205 bytes) Download Attachment

[Cooker] [Bug 55854] NEW: reset full speed USB device using uhci_hcd... @~4x/sec

2009-11-26T07:24:33Z

https://qa.mandriva.com/show_bug.cgi?id=55854

Summary : reset full speed USB device using uhci_hcd... @~4x/sec
Product : Mandriva Linux
Component : Kernel
Version : 2010.0
Status : NEW
Severity : normal
Priority : normal
Assigned To: kernel@...
Reported By: rolfpedersen@...

--- Comment #1 from rolfpedersen@... 2009-11-26 16:20:13
CEST ---
This happened again: a print job did not appear to get processed and tailf
showed the log being flooded with the reset messages. Re-plugging the
printer
was sufficient to have the job process normally. Surely seems plausible
it is
a hardware problem but, in case not, submitted for review.

I did find a recent lkml thread that could be related:
http://lkml.indiana.edu/hypermail/linux/kernel/0910.1/01048.html

Snippet of today's boot showing the loop starting immediately, where sdh
is the
printer as mass storage device:

[..]
Nov 26 04:49:12 localhost klogd: Floppy drive(s): fd0 is 1.44M
Nov 26 04:49:12 localhost klogd: FDC 0 is a post-1991 82077
Nov 26 04:49:12 localhost klogd: input: PC Speaker as
/devices/platform/pcspkr/input/input6
Nov 26 04:49:12 localhost klogd: Bluetooth: Core ver 2.15
Nov 26 04:49:12 localhost klogd: NET: Registered protocol family 31
Nov 26 04:49:12 localhost klogd: Bluetooth: HCI device and connection
manager
initialized
Nov 26 04:49:12 localhost klogd: Bluetooth: HCI socket layer initialized
Nov 26 04:49:12 localhost klogd: Initializing USB Mass Storage driver...
Nov 26 04:49:12 localhost klogd: scsi10 : SCSI emulation for USB Mass
Storage
devices
Nov 26 04:49:12 localhost klogd: usbcore: registered new interface driver
usb-storage
Nov 26 04:49:12 localhost klogd: USB Mass Storage support registered.
Nov 26 04:49:12 localhost klogd: usblp0: USB Bidirectional printer dev 2
if 0
alt 0 proto 2 vid 0x04F9 pid 0x0165
Nov 26 04:49:12 localhost klogd: usbcore: registered new interface
driver usblp
Nov 26 04:49:12 localhost klogd: iTCO_vendor_support: vendor-support=0
Nov 26 04:49:12 localhost klogd: iTCO_wdt: Intel TCO WatchDog Timer Driver
v1.05
Nov 26 04:49:12 localhost klogd: iTCO_wdt: Found a ICH10R TCO device
(Version=2, TCOBASE=0x0860)
Nov 26 04:49:12 localhost klogd: iTCO_wdt: initialized. heartbeat=30 sec
(nowayout=1)
Nov 26 04:49:12 localhost klogd: input: HDA Digital PCBeep as
/devices/pci0000:00/0000:00:1b.0/input/input7
Nov 26 04:49:12 localhost klogd: ohci1394 0000:05:03.0: PCI INT A -> GSI 19
(level, low) -> IRQ 19
Nov 26 04:49:12 localhost klogd: Bluetooth: Generic Bluetooth USB driver ver
0.5
Nov 26 04:49:12 localhost klogd: usbcore: registered new interface
driver btusb
Nov 26 04:49:12 localhost klogd: i801_smbus 0000:00:1f.3: PCI INT C ->
GSI 18
(level, low) -> IRQ 18
Nov 26 04:49:12 localhost klogd: ACPI: I/O resource 0000:00:1f.3
[0x400-0x41f]
conflicts with ACPI region SMRG [0x400-0x40f]
Nov 26 04:49:12 localhost klogd: ACPI: If an ACPI driver is available
for this
device, you should use it instead of the native driver
Nov 26 04:49:12 localhost klogd: ohci1394: fw-host0: OHCI-1394 1.0 (PCI):
IRQ=[19] MMIO=[febfe000-febfe7ff] Max Packet=[2048] IR/IT contexts=[8/8]
Nov 26 04:49:12 localhost klogd: device-mapper: uevent: version 1.0.3
Nov 26 04:49:12 localhost klogd: device-mapper: ioctl: 4.15.0-ioctl
(2009-04-01) initialised: dm-devel@...
Nov 26 04:49:12 localhost klogd: scsi 10:0:0:0: Direct-Access Brother
MFC-620CN 1.00 PQ: 0 ANSI: 2
Nov 26 04:49:12 localhost klogd: sd 10:0:0:0: Attached scsi generic sg9
type 0
Nov 26 04:49:12 localhost klogd: sd 10:0:0:0: [sdh] Attached SCSI removable
disk
Nov 26 04:49:12 localhost klogd: usblp0: removed
Nov 26 04:49:12 localhost klogd: usb 6-1: reset full speed USB device using
uhci_hcd and address 2
Nov 26 04:49:12 localhost klogd: usblp0: USB Bidirectional printer dev 2
if 0
alt 0 proto 2 vid 0x04F9 pid 0x0165
Nov 26 04:49:12 localhost klogd: usblp0: removed
Nov 26 04:49:12 localhost klogd: usb 6-1: reset full speed USB device using
uhci_hcd and address 2
Nov 26 04:49:12 localhost klogd: usblp0: USB Bidirectional printer dev 2
if 0
alt 0 proto 2 vid 0x04F9 pid 0x0165
Nov 26 04:49:12 localhost klogd: usblp0: removed
[..]

----------------------------------------------------------------------------
Original Bug Text:

Description of problem:
OK, 'kernel component' is a guess but the reported log message is
clearly related:

Nov 21 07:19:00 localhost klogd: usblp0: USB Bidirectional printer dev 2
if 0 alt 0 proto 2 vid 0x04F9 pid 0x0165
Nov 21 07:19:00 localhost klogd: usblp0: removed

Nov 21 07:19:00 localhost klogd: usb 6-1: reset full speed USB device
using uhci_hcd and address 2
Nov 21 07:19:00 localhost klogd: usblp0: USB Bidirectional printer dev 2
if 0 alt 0 proto 2 vid 0x04F9 pid 0x0165
Nov 21 07:19:00 localhost klogd: usblp0: removed

Nov 21 07:19:00 localhost klogd: usb 6-1: reset full speed USB device
using uhci_hcd and address 2
Nov 21 07:19:00 localhost klogd: usblp0: USB Bidirectional printer dev 2
if 0 alt 0 proto 2 vid 0x04F9 pid 0x0165
Nov 21 07:19:00 localhost klogd: usblp0: removed

Nov 21 07:19:00 localhost klogd: usb 6-1: reset full speed USB device
using uhci_hcd and address 2
Nov 21 07:19:00 localhost klogd: usblp0: USB Bidirectional printer dev 2
if 0 alt 0 proto 2 vid 0x04F9 pid 0x0165
Nov 21 07:19:00 localhost klogd: usblp0: removed

Nov 21 07:19:00 localhost klogd: usb 6-1: reset full speed USB device
using uhci_hcd and address 2
Nov 21 07:19:01 localhost klogd: usblp0: USB Bidirectional printer dev 2
if 0 alt 0 proto 2 vid 0x04F9 pid 0x0165

I have seen this before and, perhaps, it's hardware/proprietary driver
failure but there was a long period in 2009.1.i586, before moving to
2010.0, when this problem did not arise. The hardware is a
Brother_MFC-620CN multifunction connected via usb. The problem is,
frequently, with a recent installation of 2010.0 PWP x86_64, print jobs
stack in queue, with the first job shown as 'processing' in
http://localhost:631/jobs/

At this point, I tailf /var/log/messages and see the loop, above. It
seems 'processing' can't progress because of this loop as, when I replug
the printer usb cable, perhaps re-start CUPS, the loop goes away and
printing resumes. I have, in the past, tried different cables and usb
ports w/o seeing a correlation, so I don't think the issue is there.

Version-Release number of selected component (if applicable):
[rolf@localhost sounds]$ uname -r
2.6.31.5-desktop-1mnb

How reproducible: Unpredictable except, perhaps, reboot.

Steps to Reproduce:
1.
2.
3.

--
Configure bugmail: https://qa.mandriva.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You reported the bug.

[Cooker] Re: [RPM] cooker main/release libproxy-0.3.1-1mdv2010.1

2009-11-26T06:11:32Z

On Thu, Nov 26, 2009 at 2:05 PM, Funda Wang <devel@...> wrote:
> Funda Wang <fwang@...> 0.3.1-1mdv2010.1:
> + Revision: 470293
> - New version 0.3.1
> - fix linkage of modules

Hi,

why did you update it? It is not compatible with the previous version.
Can you please ask the maintainer next time?

Regards, Götz

--
AL I:40: Do what thou wilt shall be the whole of the Law.

Re: [Cooker] Re: Using dash for init scripts

2009-11-26T05:10:06Z

Éric Piel wrote:
> But changing the first line of every initscript from /bin/sh to
> /bin/dash is super ugly.
Maybe, but it's *correct*. That is what #! is there for, after all.

>> If there's some reason to want the initscripts to request /bin/sh but
>> get dash, I'd just run them with a $PATH that starts with a dummy
>> directory that links sh to dash. At least that way, nothing else in the
>> system gets affected.
>>
> It could be another solution, but might be hard to avoid "leakage" of
> the PATH to the users (eg: should crond remove it...).
>
And an unconditional symlink of sh to dash won't have this effect ?

Re: [Cooker] Re: Using dash for init scripts

2009-11-26T02:02:06Z

Op 25-11-09 18:55, Frank Griffin schreef:

> I tend to agree with Claudio. Most people who learned shell on Linux
> learned bash, whether they realize it or not. Substituting something
> else as the default shell would undermine god-knows-how-many existing
> scripts. It's much cleaner to simply migrate initscripts that can use
> dash to use it, and either fix the ones that have bashisms or else have
> them explicitly request /bin/bash.
But changing the first line of every initscript from /bin/sh to
/bin/dash is super ugly. Not only it forces to patch every script but it
also is not very meaningful because you don't want to say explicitly
"this script should go fast" in the script, it should be hidden by the
platform.

With Ubuntu and Debian doing it for a long time, and in addition lots of
people know that if you use bashisms, you should put /bin/bash at the
top of your script. To me it looks like the right time, at the beginning
of a Cooker cycle, to try linking sh to dash and see how much breaks. At
worse, the alternative priority of dash could be lowered, so that bash
stays the default.

> If there's some reason to want the initscripts to request /bin/sh but
> get dash, I'd just run them with a $PATH that starts with a dummy
> directory that links sh to dash. At least that way, nothing else in the
> system gets affected.
It could be another solution, but might be hard to avoid "leakage" of
the PATH to the users (eg: should crond remove it...).

Eric

Re: [Cooker] Re: Using dash for init scripts

2009-11-26T01:48:21Z

Op 25-11-09 23:12, Jerome Quelin schreef:

> On 09/11/25 18:36 +0100, Olivier Blin wrote:
>>>> How about implementing /bin/sh as an alternative? Either it points to
>>>> dash or to bash. The dash alternative could be of higher priority, so as
>>>> soon as you install dash, you benefit of the speed boost (and of the
>>>> bugs in case of bashisms ;-) ). Still, it'd be very easy to revert to
>>>> old behaviour.
>>> Given than we prefered to drop alternative usage whenever possible,
>>> for sake of robustness, I don't think that's a wise idea.
>> How would we switch the default shell then?
>
> user shell should remain bash (explicit)
> people running sh generally expect to have a bourne shell. not a bourne
> *again* shell. well, at least if you come from traditional unixes.

I think Olivier was talking about the default shell (to what links
/bin/sh), not the default _user_ shell. The default user shell is
/bin/bash already, so it will not be affected by the change in any way.

Eric

Re: [Cooker] Re: Using dash for init scripts

2009-11-25T14:12:56Z

On 09/11/25 18:36 +0100, Olivier Blin wrote:
> >> How about implementing /bin/sh as an alternative? Either it points to
> >> dash or to bash. The dash alternative could be of higher priority, so as
> >> soon as you install dash, you benefit of the speed boost (and of the
> >> bugs in case of bashisms ;-) ). Still, it'd be very easy to revert to
> >> old behaviour.
> > Given than we prefered to drop alternative usage whenever possible,
> > for sake of robustness, I don't think that's a wise idea.
>
> How would we switch the default shell then?

user shell should remain bash (explicit)
people running sh generally expect to have a bourne shell. not a bourne
*again* shell. well, at least if you come from traditional unixes.

jérôme
--
jquelin@...

[Cooker] Re: [RPM] cooker main/release xinit-1.2.0-3mdv2010.1

2009-11-25T12:05:35Z

On Wed, 25 Nov 2009 19:25:37 +0100 (CET)
Paulo Ricardo Zanoni wrote:

> Name : xinit Relocations: (not
> relocatable) Version : 1.2.0 Vendor:
> Mandriva Release : 3mdv2010.1 Build Date: Wed
> Nov 25 19:04:39 2009 Install Date: (not installed)
> Build Host: klodia.mandriva.com Group :
> System/X11 Source RPM: (none) Size :
> 159146 License: MIT Signature : (none)
> Packager : Paulo Ricardo Zanoni <pzanoni@...>

This release solves the issues I was having with 1.2.2-1/-2 using
startx.

X now launches normally with all services on i586 and x86_64.

Using startx startxfce4, startx starte16

Charles

--
A meeting is an event at which the minutes are kept and the hours are
lost. ----------------------
Mandriva Linux release 2010.1 (Cooker) for x86_64$
On SuperSize....http://www.eslrahc.com
Registered Linux user #182463
2.6.31.6-tmb-server-4mdv AMD Athlon(tm) 64 X2 Dual Core Processor 6400+
----------------------

signature.asc (205 bytes) Download Attachment

Re: [Cooker] just released parole 0.1.95

2009-11-25T10:47:54Z

le Wed, 25 Nov 2009 18:27:38 +0100
Nicolas Lécureuil <nlecureuil@...> à écrit:

> > don't laugh :)
> > two release in one day :)
> >
> it is available now ;)

[patrick@localhost ~]$ parole cdda://
(parole:6018): parole-DEBUG: Yalla
Erreur de segmentation
[patrick@localhost ~]$ parole cdda:// --device /dev/sr0
(parole:6053): parole-DEBUG: Yalla
Erreur de segmentation
[patrick@localhost ~]$ rpm -qa | grep parole
parole-0.1.96-1mdv2010.1
[patrick@localhost ~]$

;(

--
Patrick.
envoye depuis le monde libre ...
par un Pc sous Mandriva 2010.1 ( cooker ) !
Claws-Mail 3.7.3 - xfce 4.6.1

Re: Using dash for init scripts (was: Re: [Cooker] FOSDEM 2010)

2009-11-25T10:44:48Z

2009/11/21 Andrey Borzenkov <arvidjaar@...>:

> On Saturday 21 of November 2009 15:01:33 Frederik Himpe wrote:
>> On za, 2009-11-21 at 12:24 +0100, Jerome Quelin wrote:
>> > On 09/11/21 14:13 +0300, Andrey Borzenkov wrote:
>> > > On Saturday 21 of November 2009 10:54:48 Jerome Quelin wrote:
>> > > > On 09/11/20 16:57 -0500, Juan Luis Baptiste wrote:
>> > > > > It would be VERY interesting to know what is their secret.
>> > > >
>> > > > one of them is linking /bin/sh to dash instead of bash.
>> > > > cf https://wiki.ubuntu.com/DashAsBinSh
>> > > >
>> > > > maybe it would be interesting to try it.
>> > >
>> > > Output of checkbashisms -f /etc/rc.d/init.d/* is not entirely
>> > > encouraging :)
>> >
>> > known bashism-user can still use #!/bin/bash to force interpreter.
>> > but if we can change the default to dash, that's interesting. and
>> > we still have 5 monthes to convert init scripts to dash...
>>
>> I agree that we should at least try to use dash for init scripts. We
>> are trying to speed up booting by introducing new stuff like
>> speedboot, but we are not taking advantage of this more "logical"
>> speed up (which would also benefit all people not using speedboot).
>>
>> IIRC this was already considered years ago, but for some reason was
>> never implemented
>
> Most likely because our initscripts are based on fedora, not debian.
> Patching all bashisms out locally is not maintainable in the long run

what about asking the Fedora's initscripts guy ?
There's a non-zero chance he's considering the switch already.

Re: [Cooker] startx no more runs default xinitrc (Xsession)

2009-11-25T10:03:10Z

Ok, I have updated xinit again. I had to revert part of an upstream change.
if it's now working again, please tell me how you tested it so I can
reproduce the bug.

By the way, I have tested xinit without the startx patch and it seems
to be working except for the fact that I have to do "xinit $(which
startxfce4)" instead of "xinit startxfce4", but I'm really not sure
this is a bug (although it's not mentioned on the manpage).

On Wed, Nov 25, 2009 at 1:54 AM, Andrey Borzenkov <arvidjaar@...> wrote:

> On Tuesday 24 of November 2009 23:06:00 Paulo Zanoni wrote:
>> Hmm...
>>
>> I've updated xinit today and I had to redo an undocumented patch that
>> involved that piece of code (the code changed by our patch was
>> changed upstream).
>>
>> I have no idea why we have that patch . It seems to be very old and
>> undocumented.
>> I've just submitted a new xinit with the patch fixed. Please tell me
>> if it works.
>
> It can't work.
>
> if [ x"$clientargs" = x ]; then
> if [ -f "$userclientrc" ]; then
> client=$userclientrc
> elif [ -f "$sysclientrc" ]; then
> client=$sysclientrc
> fi
>
> But your patch completely removes handling of $client so this assignment
> makes no effect.
>
>> If it doesn't work we'll have to rethink that patch and
>> carefully analyze upstream's changes.
>>
>> Thanks,
>> Paulo.
>>
>> On Tue, Nov 24, 2009 at 5:05 PM, Andrey Borzenkov <arvidjaar@...>
> wrote:
>> > Since update startx leaves me with lone rxvt in upper left corner.
>> >
>> > The problem is, patch is over-eager and removes handling of
>> > defaultclientrc together with defaultclient:
>> >
>> > -XCOMM process client arguments
>> > -if [ x"$client" = x ]; then
>> > - client=$defaultclient
>> > -
>> > - XCOMM if no client arguments either, use rc file instead
>> > - if [ x"$clientargs" = x ]; then
>> > - if [ -f "$userclientrc" ]; then
>> > - client=$userclientrc
>> > - elif [ -f "$sysclientrc" ]; then
>> > - client=$sysclientrc
>> >
>> > This is trivial to fix by adding back
>> >
>> > if [ -f $userclientrc ]; then
>> > defaultclientargs=$userclientrc
>> > elif [ -f $sysclientrc ]; then
>> > defaultclientargs=$sysclientrc
>> > fi
>> >
>> > before argument parsing loop but it rather conflicts with
>> > (intended?) patch:
>> >
>> > - it removes the default client and server from the startx
>> > arguments, so if
>> > nothing is specified the default server or client will be the one
>> > chosen by
>> > xinit
>> >
>> >
>> > Unfortunately up to now default client was xinitrc :(
>>
>

--
Paulo R. Zanoni

Re: [Cooker] Re: Using dash for init scripts

2009-11-25T09:55:06Z

>>> Op 23-11-09 17:29, Claudio Matsuoka schreef:
>>>
>>>> I tend to agree with Jerome here, this seems to be the best possible
>>>> moment do make disruptive changes. IMHO fixing scripts using bashisms to
>>>> use /bin/bash instead of /bin/sh is the right thing to
>>>> do. Unfortunately bash has a very "embrace-and-extend"-style
>>>> approach when
>>>> it takes over /bin/sh and leaks bash-specific features even if its
>>>> documentation say it shouldn't.
>>>>

I tend to agree with Claudio. Most people who learned shell on Linux
learned bash, whether they realize it or not. Substituting something
else as the default shell would undermine god-knows-how-many existing
scripts. It's much cleaner to simply migrate initscripts that can use
dash to use it, and either fix the ones that have bashisms or else have
them explicitly request /bin/bash.

If there's some reason to want the initscripts to request /bin/sh but
get dash, I'd just run them with a $PATH that starts with a dummy
directory that links sh to dash. At least that way, nothing else in the
system gets affected.

Re: [Cooker] Some interesting KDE additions

2009-11-25T09:54:07Z

Le mardi 24 novembre 2009 23:37:27, Glen Ogilvie a écrit :

> On Wed, 25 Nov 2009, Luis Daniel Lucio Quiroz wrote:
> > Le lundi 23 novembre 2009 23:47:35, Glen Ogilvie a écrit :
> > > Hi Luis
> > >
> > > On Tue, 24 Nov 2009, Luis Daniel Lucio Quiroz wrote:
> > > > Le mardi 4 août 2009 16:06:41, Glen Ogilvie a écrit :
> > > > > Hi Vincent,
> > > > >
> > > > > On Tue, 4 Aug 2009 13:10:33 +0200, Vincent Panel
> > > > > <yohonet@...>
> > > > >
> > > > > wrote:
> > > > > > Kopete facebook-chat protocol support :
> > > > >
> > > > > http://software.opensuse.org/search?baseproject=openSUSE:Factory&p=
> > > > >1& q= kd e4 -kopete-protocol-facebook
> > > > >
> > > > > I have been testing the Kopete facebook-chat app. It's not 100%
> > > > > but seem to work most of the time,
> > > > > therefor, I have not submitted it to be part of cooker.
> > > > >
> > > > > If you want to try it, packages for 2009.1 64 bit, and srpms, are
> > > > > available on my website:
> > > > >
> > > > > http://www.linuxbox.co.nz/kopete-facebook/
> > > > >
> > > > > Regards
> > > > > Glen Ogilvie
> > > >
> > > > It seems 1.4 (latest git) is pretty stable and usable. At least in
> > > > my laptop with 2010.0. I did submit it into contrib/testings.
> > > >
> > > > Please report if it works or we shall wait until 1.5.
> >
> > Trying to backport I had this problems:
> > error: Failed build dependencies:
> > kdenetwork4-devel is needed by
> > kopete-protocol-facebook-0.1.4-3mdv2009.1.src libqjson-devel >= 0.6 is
> > needed by kopete-protocol-
> > facebook-0.1.4-3mdv2009.1.src
> > Installing /home/mandrake/rpm/SRPMS/@469367:kopete-protocol-
> > facebook-0.1.4-3mdv2009.1.src.rpm
> >
> >
> > I understand under 2009.1 kde4 is not official, what BR did you put,
> > also, I should BP qjson because 0.6 is needed, I'm not pretty sure that
> > 2009.1 is a good distro to thise plug. Maybe published in MiB
>
> The libqjson I used for 2009.1 is:
> http://www.linuxbox.co.nz/kopete-facebook/libqjson0-0.6.2-1mdv2009.1.src.rp
> m
>

It seems json you are usign is newer than in cooker