date:20130108

'Twas brillig, and Juan Luis Baptiste at 07/01/13 19:43 did gyre and gimble:
 
 
 On Mon, Jan 7, 2013 at 2:37 PM, Thomas Backlund t...@mageia.org
 mailto:t...@mageia.org wrote:
 
 This ssh closed connection issue I have seen it since a long
 time, is
 there any way to avoid it ? it sometimes breaks the update
 process of
 that remote vm.
 
 
 https://wiki.mageia.org/en/__Mageia_2_Errata#SSH_daemon___issues
 https://wiki.mageia.org/en/Mageia_2_Errata#SSH_daemon_issues
 
 
 Thanks for the link but I have UsePAM=no commented on
 /et/ssh/sshd_config, I suppose that's the default sshd configuration, I
 have never touched that file on that machine. 

The default is UsePAM=yes and has been since Mageia 2.

You likely had a .rpmnew at some point and never resolved the differences.

Col


-- 

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

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

Re: [Mageia-dev] rootcerts: Are the certs really config files?

'Twas brillig, and Anssi Hannula at 07/01/13 20:48 did gyre and gimble:
 07.01.2013 17:47, Colin Guthrie kirjoitti:
 'Twas brillig, and Thomas Backlund at 07/01/13 14:15 did gyre and gimble:
 Colin Guthrie skrev 7.1.2013 16:05:
 'Twas brillig, and Anssi Hannula at 07/01/13 13:19 did gyre and gimble:
 Of course, the appearance of .rpmnew suggests that something has
 modified them in your system - not sure what would've done that.

 Wouldn't:
   %config(noreplace)
 cause this?

 Even if I/something had not changed the original files, doesn't the
 noreplace trigger this behaviour anyway?


 Nope.

 noreplace part only triggers if the file installed by previous rpm
 has been altered.

 otherwise it will be updated.

 Hmm, somewhat worrying then... Wonder how mine got changed :s
 
 What is the difference? (i.e. local compared to the old version)
 
 .. unless you replaced them already.

Yup already replaced sadly.

Seemed mostly indentation changes on the few I actually looked at.

Col


-- 

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

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

Re: [Mageia-dev] PHP treadsafe

2013-01-08 Thread Frederik Himpe

On Sat, 05 Jan 2013 10:20:35 -0700, Thomas Spuhler wrote:

 If nobody objects I am going to rebuild php treadsafe
 (--enable-maintainer-zts)
 it is needed for running apache with mpm-module-worker instead of
 prefork and php apache module worker is needed by 389-ds. It is now
 declared as stable.
 
 But apache mpm-prefork starts with php compiled treadsafe apache
 mpm-worker doesn't start with php compiled none-treadsafe

You can run PHP with apache2-mpm-worker with mod_fcgid and php5-cgi or 
php5-fpm.

This is what Debian Wheezy's README file for php says:

Using PHP 5 with threaded webservers (e.g. apache2-mpm-worker)
--

  After much back-and-forth with upstream (and even building our
  packages thread-safe for a while), we're currently admitting defeat
  on that front, and are NOT building any thread-safe versions of PHP
  5 for any webservers. Our recommendation is that, if you need to use
  a threaded webserver, you should use php5-fpm and interface to your
  webserver with FastCGI.



I think Mageia is hurting itself by enabling too experimental features. 
Another example is the uas kernel module, of which I saw a complaint 
recently in this mailing list. This module is known to be buggy, and 
disabled in Debian.

-- 
Frederik Himpe

Re: [Mageia-dev] ANN: glibc-2.17 landing on cauldron...

'Twas brillig, and Guillaume Rousse at 08/01/13 10:04 did gyre and gimble:
 Le 08/01/2013 10:55, Colin Guthrie a écrit :
 Thanks for the link but I have UsePAM=no commented on
 /et/ssh/sshd_config, I suppose that's the default sshd configuration, I
 have never touched that file on that machine.

 The default is UsePAM=yes and has been since Mageia 2.
 The term 'default' isn't quite appropriate here, as 'default' is usually
 perceived as 'what is hardcoded in the binary if nothing is specified in
  the configuration file'. In our case, we don't change this, we just
 tune the default configuration file.

Bit of a grey area really as to what default could mean but I accept
your point. We probably should patch the binary to be complete - I just
took the same patch as fedora out of convenience.

Col



-- 

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

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

[Mageia-dev] Tonight's meeting

2013-01-08 Thread Anne Nicolas


Hi there

Let start again our weekly meeting! As usual on #mageia-dev at 20h UTC
Here are the proposed topics

- Mageia 3 release (planning, freeze, coming isos)
- mass rebuild (would be nice to have pterjan and tmb around for this topic)
- release critical bugs
- following build errors
- FOSDEM 2013

Cheers

--
Anne
http://mageia.org

Re: [Mageia-dev] PHP treadsafe

2013-01-08 Thread Oliver Burger


Am 08.01.2013 11:04, schrieb Frederik Himpe:

On Sat, 05 Jan 2013 10:20:35 -0700, Thomas Spuhler wrote:


If nobody objects I am going to rebuild php treadsafe
(--enable-maintainer-zts)
it is needed for running apache with mpm-module-worker instead of
prefork and php apache module worker is needed by 389-ds. It is now
declared as stable.

But apache mpm-prefork starts with php compiled treadsafe apache
mpm-worker doesn't start with php compiled none-treadsafe


You can run PHP with apache2-mpm-worker with mod_fcgid and php5-cgi or
php5-fpm.

This is what Debian Wheezy's README file for php says:

Using PHP 5 with threaded webservers (e.g. apache2-mpm-worker)
--

   After much back-and-forth with upstream (and even building our
   packages thread-safe for a while), we're currently admitting defeat
   on that front, and are NOT building any thread-safe versions of PHP
   5 for any webservers. Our recommendation is that, if you need to use
   a threaded webserver, you should use php5-fpm and interface to your
   webserver with FastCGI.



I think Mageia is hurting itself by enabling too experimental features.
Another example is the uas kernel module, of which I saw a complaint
recently in this mailing list. This module is known to be buggy, and
disabled in Debian.


+1

That's what Oden told me yesterday on IRC.

So as current php maintainer I vote against enabling this.

Oliver

--
obgr_seneca aka Oliver Burger
Mageia.Org

i18n team leader
doc team deputy leader
secretary of the Association

Mageia council
Mageia board

Re: [Mageia-dev] 3.0 release - some initial notes; failure

2013-01-08 Thread Shlomi Fish

Hi Liam,

let me reply to your E-mail - not necessarily disagreeing.

On Mon, 07 Jan 2013 02:46:39 -0500
Liam R E Quin l...@holoweb.net wrote:

Tried installing 3.0 beta over a Mandriva Cooker system today.
Mageia-3-beta1-x86_64-DVD.iso

Can Mandriva Cooker be upgraded to Mageia 3? I don't think it can be (due to
Mandriva's switch to rpm5). Or do you mean you reformatted the relevant
partitions and installed a new system?

Some notes. Mostly about problems because I never got to see a working
system, so the tone is probably more negative than I'd like.

No problem with that for me - bring on the negativity, I say, because that will
help us improve the program. Also Lawrence Lessig's anecdote which I quoted at:

http://teachingopensource.org/index.php/How_to_start_contributing_to_or_using_Open_Source_Software#Some_Mental_Preparation

(short URL - http://xrl.us/biknkf ).

On boot, there was a long delay followed by Loading program and a
progress bar appearing and disappearing again almost before I had time
to read the message. This didn't seem optimal.

I see. What are your system's specifications? I think I usually install from a
CD (just to have a working system) and then install more packages using urpmi. I
am downloading the DVD .iso now and will try it in a VirtualBox VM later to see
if I can reproduce any problems.

Choice of keyboard - there was a link to wikipedia in the Help text, but
it gave me an error that there was no network. There are two entries for
US Keyboard with no obvious reason, and a third for US International
(which I chose since I'm not in the US :-))

Sounds like a bug or at least a problem in the installer. Can you file a bug
for it on https://bugs.mageia.org/ ?

I have 2 disk drives. the installer wanted to use the spare space on my
Windows drive, when the other drive already had Linux. Yes, I could
choose from the drop-down, but it wasn't clear that I was choosing where
to put Mageia. Suggest add,
Multiple disk drives found. Choose which one you want to use for the
main Mageia system.

Sounds like a good enhancement.

The disk was formatted. That was actually what I wanted, in this case,
but please add a warning that data will be lost - most humans on the
planet won't know that.

Yes, true. Of course, you cannot expect your users to read:

http://www.joelonsoftware.com/uibook/chapters/fog62.html

Or like my Technion lecturer once noted in one of the first talks in our
Computer Graphics course, which taught us about designing for usability (from
the P.O.V. of this book -
http://www.shlomifish.org/philosophy/books-recommends/#design_of_everyday_things
) a typical session can go like that:

User: delete My_most_important_work.doc
Computer: are you sure? [Yes] [No]
User: Yes!
Computer My_most_important_work.doc deleted.
User: damn!

But I approve of issuing a warning before that, or somehow preventing this
from happening.

There's no indication of how long the formatting will take, or how much
has been done. I'll leave it running for an hour or two (it's a 250G
SATA hard drive) and see if it finishes, or maybe it crashed.
Please add a note that this may take a long time, preferably with an
OK/Cancel/Skip since (1) it wasn't needed here, and (2) users may well
give it a minute or so and then move on to the next Linux distribution
on the magazine, saying Mageia hung my computer, it's crap.

Suggest progress bar or at least some quotes from Moliére.

Heh. Well, formatting normally did not take too long for me, at least not in
its fast formatting mode. But maybe a progress bar will be doable.

Note: eventually the bad block scan started giving a progress percentage
on another virtual terminal, but most users won't find that, of course,
even if they wait half an hour or more for it to begin.

Oh, bad block scan. :-(. It should be displayed in the graphical installer.

I'm assuming the graphics and ugly font are not final. If they are, the
pink stripes look like an error. Maybe caused by running my monitor
(1920x1200/deep colour) in 800x600 16-bit mode.

I'll see if it happens to me in the installer.

The long list of packages being installed - would be nicer to show the
name of the current package, and its description, and more slowly to
show a more detailed description of just one program.

By default the installer does not display the names of the packages installed I
think - just a progress bar.

If there was a clear and obvious option to choose the LCD's native
resolution, a font like Matthew Carter's Bitstream Charter Italic would
look more sophisticated and also get more information on a line.

Is it an open font.

Choosing a desktop - help said broken link

Shouldn't the help be included inside the installer's media.

Choosing a desktop - please add versions, not just KDE, GNOME, Other.

I'm not sure versions are a good idea because they may be confusing. I'm also
not sure many users who start with

[Mageia-dev] Boot borked cause procfs :((

2013-01-08 Thread JA Magallón


Hi...

After updating cauldron to latest packages, I rebuilt manually the boot
initrd with dracut -f. After that, the system does not boot:

mount: /proc: filesystem mounted, but mount(8) failed: No such file or directory
Cannot mount proc on /proc! Compile the kernel with CONFIG_PROC_FS!

And then a kernel panic...

I think that I have boxes that boot because I have not rebuilt the initrd,
but I don't dare to try one other :).

Any ideas o how to debug/fix this ?

TIA

--
J.A. Magallon jamagallon()ono!com\   Winter is coming...

Re: [Mageia-dev] ANN: glibc-2.17 landing on cauldron...

2013-01-08 Thread Guillaume Rousse


Le 08/01/2013 11:34, Colin Guthrie a écrit :

'Twas brillig, and Guillaume Rousse at 08/01/13 10:04 did gyre and gimble:

Le 08/01/2013 10:55, Colin Guthrie a écrit :

Thanks for the link but I have UsePAM=no commented on
/et/ssh/sshd_config, I suppose that's the default sshd configuration, I
have never touched that file on that machine.


The default is UsePAM=yes and has been since Mageia 2.

The term 'default' isn't quite appropriate here, as 'default' is usually
perceived as 'what is hardcoded in the binary if nothing is specified in
  the configuration file'. In our case, we don't change this, we just
tune the default configuration file.


Bit of a grey area really as to what default could mean but I accept
your point. We probably should patch the binary to be complete - I just
took the same patch as fedora out of convenience.
I don't think that would be very wise. Changing hardcoded value is 
really evil, because it's invisible from end-user point of view.


--
BOFH excuse #413:

Cow-tippers tipped a cow onto the server.

Re: [Mageia-dev] Boot borked cause procfs :((

2013-01-08 Thread JA Magallón


On 01/08/2013 02:01 PM, Thomas Backlund wrote:

Colin Guthrie skrev 8.1.2013 14:28:

'Twas brillig, and JA Magallón at 08/01/13 12:11 did gyre and gimble:

Hi...

After updating cauldron to latest packages, I rebuilt manually the boot
initrd with dracut -f. After that, the system does not boot:

mount: /proc: filesystem mounted, but mount(8) failed: No such file or
directory
Cannot mount proc on /proc! Compile the kernel with CONFIG_PROC_FS!

And then a kernel panic...



https://bugs.mageia.org/show_bug.cgi?id=8614



Well, i copied the libraries amd mount binary from a beta3 image,
rebuilt initrd and the system boots.




I think that I have boxes that boot because I have not rebuilt the initrd,
but I don't dare to try one other :).

Any ideas o how to debug/fix this ?


I heard this is due to new util-linux. My initrd was from 3rd Jan, but
util-linux installed on 5th Jan. I've regenerated my initrd so will
reboot sometime today to see if it now breaks with the new version of mount.



It will.

I hope you have a backup initrd to use.



Now I have ;)



  We maybe need to patch mount? I don't think it's really the kernel

that's at fault here.


I will investigte it tonight..

--
Thomas





--
J.A. Magallon jamagallon()ono!com\   Winter is coming...

Re: [Mageia-dev] Mesa 9.1 in mga3 or revert to llvm 3.1?

2013-01-08 Thread David Walser

Christiaan Welvaart cjw@... writes:
 Since Mesa 9.0 apparently doesn't build with llvm 3.2 we are getting many 
 build failures because mesa packages depend on libllvm3.1 which isn't 
 available. I have llvm 3.2pre+amdgpu and mesa 9.1pre ready to upload which 
 should fix those build problems. Gnome-shell and armagetron seem to work 
 OK with them, for neverball I get 
 https://bugs.freedesktop.org/show_bug.cgi?id=58839 but it still works 
 (maybe with a lower framerate). Mesa 9.1 release is scheduled for february 
 2013 AFAIK.
 
 So is there a reason why I should not upload these two packages?

We should probably see that this doesn't affect us:
http://www.phoronix.com/scan.php?page=news_itempx=MTI2OTE

Re: [Mageia-dev] Booting on GPT + UEFI + Secure Boot...

* Liam R E Quin (l...@holoweb.net) wrote:
 On Mon, 2013-01-07 at 17:01 +0100, Olivier Thauvin wrote:
 
  I found the key of the issue: grub has not install because block number
  is to big (my /boot is at 1,6TB from the start of the disk).
 
 With my HP Elitebook I found that all the partitions were allocated, so
 I booted in Windows 7 (this was 2 years ago) and used the program that
 came with Windows to resize the partitions and move them around a bit.

I did succeed to setup grub2-efi on my mageia2.
But I want cauldron on it and since upgrading mga2 = cauldron is no
longer possible I decided to try to install cauldron.

The system is installed with grub2-efi but the boot failed with all
kernel I've tried: cannot mount /proc - mount return error, no such
file or directory.

Any idea ?

-- 

Olivier Thauvin
CNRS  -  LATMOS
♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖


pgp6M5wSoKTO6.pgp
Description: PGP signature

Re: [Mageia-dev] Booting on GPT + UEFI + Secure Boot...

2013-01-08 Thread Pascal Terjan

On Tue, Jan 8, 2013 at 2:01 PM, Olivier Thauvin
nanar...@nanardon.zarb.org wrote:
 * Liam R E Quin (l...@holoweb.net) wrote:
 On Mon, 2013-01-07 at 17:01 +0100, Olivier Thauvin wrote:

  I found the key of the issue: grub has not install because block number
  is to big (my /boot is at 1,6TB from the start of the disk).

 With my HP Elitebook I found that all the partitions were allocated, so
 I booted in Windows 7 (this was 2 years ago) and used the program that
 came with Windows to resize the partitions and move them around a bit.

 I did succeed to setup grub2-efi on my mageia2.
 But I want cauldron on it and since upgrading mga2 = cauldron is no
 longer possible I decided to try to install cauldron.

 The system is installed with grub2-efi but the boot failed with all
 kernel I've tried: cannot mount /proc - mount return error, no such
 file or directory.

 Any idea ?

Yes, it seems a cauldron bug :)

Re: [Mageia-dev] Booting on GPT + UEFI + Secure Boot...

'Twas brillig, and Olivier Thauvin at 08/01/13 14:01 did gyre and gimble:
 But I want cauldron on it and since upgrading mga2 = cauldron is no
 longer possible I decided to try to install cauldron.

Why is this no longer possible?

Col

-- 

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

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

Re: [Mageia-dev] PHP treadsafe

2013-01-08 Thread Thomas Spuhler

On Tuesday, January 08, 2013 04:36:26 AM Oliver Burger wrote:
 Am 08.01.2013 11:04, schrieb Frederik Himpe:
  On Sat, 05 Jan 2013 10:20:35 -0700, Thomas Spuhler wrote:
  If nobody objects I am going to rebuild php treadsafe
  (--enable-maintainer-zts)
  it is needed for running apache with mpm-module-worker instead of
  prefork and php apache module worker is needed by 389-ds. It is now
  declared as stable.
  
  But apache mpm-prefork starts with php compiled treadsafe apache
  mpm-worker doesn't start with php compiled none-treadsafe
  
  You can run PHP with apache2-mpm-worker with mod_fcgid and php5-cgi or
  php5-fpm.
  
  This is what Debian Wheezy's README file for php says:
  
  Using PHP 5 with threaded webservers (e.g. apache2-mpm-worker)
  --
  
 After much back-and-forth with upstream (and even building our
 packages thread-safe for a while), we're currently admitting defeat
 on that front, and are NOT building any thread-safe versions of PHP
 5 for any webservers. Our recommendation is that, if you need to use
 a threaded webserver, you should use php5-fpm and interface to your
 webserver with FastCGI.
  
  I think Mageia is hurting itself by enabling too experimental features.
  Another example is the uas kernel module, of which I saw a complaint
  recently in this mailing list. This module is known to be buggy, and
  disabled in Debian.
 
 +1
 
 That's what Oden told me yesterday on IRC.
 
 So as current php maintainer I vote against enabling this.
 
 Oliver
I guess I then will revert it to NTS. 
Fedora builds it with both options. But it may be too late now going that way.

-- 
Best regards
Thomas Spuhler


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

Re: [Mageia-dev] Booting on GPT + UEFI + Secure Boot...

* Colin Guthrie (mag...@colin.guthr.ie) wrote:
 'Twas brillig, and Olivier Thauvin at 08/01/13 14:01 did gyre and gimble:
  But I want cauldron on it and since upgrading mga2 = cauldron is no
  longer possible I decided to try to install cauldron.
 
 Why is this no longer possible?

This mga2 has been installed yesterday:
urpmi --auto-update --skip '/filesystem|ncurses/' = urpmi ran during 10
minutes without doing nothing the I did stop it.

urpmi urpmi --skip '/filesystem|ncurses/' = pull perl - glibc -
and it complain the rpmlib(...) was necessary.

I guess any new binary will pull the latest glibc.

That's true I haven't check if my rpm version was the last but since I
did an network install I hope rpms from updates were installed.


-- 

Olivier Thauvin
CNRS  -  LATMOS
♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖


pgp5_OKPOkWlQ.pgp
Description: PGP signature

Re: [Mageia-dev] df lying?

2013-01-08 Thread Felix Miata


On 2013-01-07 20:18 (GMT+0100) Dan Fandrich composed:


On Mon, Jan 07, 2013 at 01:46:37PM -0500, Felix Miata wrote:



So the OP questions remain:



1-how can the free block count be identical before and after adding
37,925,705K bytes in 7 files to that journal-free, 0 reserved for
root filesystem?



Are you absolutely positive that this is the right filesystem you're
checking?


I really need to stop persisting to continue ad hoc maintenance projects past 
when I should have gone to bed. :-(


The source files were coming from a Linux STB with woeful throughput to the 
LAN. These 5200MB video files were averaging 20 minutes each to copy off. I 
started that activity Sunday night by mounting the external destination HD to 
a PC and checked it for available space. Then, being tired and not being sure 
of my math in that condition, I proceeded to first copy from the STB to ample 
internal HD freespace where I would be working on those files anyway, 
intending to copy them after retrieval from the STB to the external HD at the 
much much faster SATA clip. I never made the second copies, so the freespace 
on the external HD's mount point was never touched. I never checked to see 
where the original copies landed, and then when booting openSUSE and Fedora 
to confirm, made the same omission, checking only the external HD mount point 
freespace without once confirming the location of the copied files. :-p

--
The wise are known for their understanding, and pleasant
words are persuasive. Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: [Mageia-dev] Tonight's meeting

Hi,

'Twas brillig, and Anne Nicolas at 08/01/13 11:21 did gyre and gimble:
 Let start again our weekly meeting! As usual on #mageia-dev at 20h UTC
 Here are the proposed topics

I don't think I'll be able to attend this evening :( (maybe later - but
that somewhat depends on how the evening plays out)

 - Mageia 3 release (planning, freeze, coming isos)
 - mass rebuild (would be nice to have pterjan and tmb around for this
 topic)
 - release critical bugs
 - following build errors
 - FOSDEM 2013

Nothing much new from me. I hardly touched my computer for 2 weeks over
the holidays (\o/). Still need to tweak a whole bunch of packages that
are still shipping files in /var/run and /var/lock and convert them to
tmpfiles. I'll get this done, but not sure exactly when.

Col

-- 

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

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

Re: [Mageia-dev] chromium {beta|stable} versions

2013-01-08 Thread Christiaan Welvaart


On Tue, 8 Jan 2013, Adrien Guichard wrote:


I noticed that chromium-browser-unstable was version 25 (which is ok), but
stable/beta was stick to version 21.

According to
http://googlechromereleases.blogspot.fr/
stable version should be 23, beta version 24. Many sandboxing enhancement
comes with recent chrome releases and Native API vesion 23 and further are
interesting to me, so it would be cool to have those (stable/beta up to
date) in Mageia 3.


The -unstable 25.x was done by me. It crashes on some pages, e.g.
http://pkgsubmit.mageia.org/ and I disabled Native API support because it 
relied on bundled binaries. OTOH it does support h.264 video through 
system ffmpeg. A build of version 24 exhibited the same renderer 
process segfault so I did not upload any beta or stable packages.



Christiaan

[Mageia-dev] Kernel Panic after latest Mageia-3-Alpha2 s/w update c

2013-01-08 Thread Maurice Batey

Trying Mageia-3-Alpha2 on a Samsung NC110 netbook and  enjoying it, I
today did a 720+ file s/w update.

Result: When rebooting:

   Kernel panic - not syncing
  Attempted to kill init!  exitcode = 0x0100
  Pid: 1, comm: init not tainted 3.7.1-desktop-1.mga3 #1

I can access its root partition from Mageia-2 on the same machine.

Anyone know of a fix for the above, please?

-- 
/\/\aurice 
(Retired in Surrey, UK)

Re: [Mageia-dev] Kernel Panic after latest Mageia-3-Alpha2 s/w update c

2013-01-08 Thread Sandro CAZZANIGA

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Le 08/01/2013 17:35, Maurice Batey a écrit :
 Trying Mageia-3-Alpha2 on a Samsung NC110 netbook and  enjoying it,
 I today did a 720+ file s/w update.
 
 Result: When rebooting:
 
 Kernel panic - not syncing Attempted to kill init!  exitcode =
 0x0100 Pid: 1, comm: init not tainted 3.7.1-desktop-1.mga3 #1
 
 I can access its root partition from Mageia-2 on the same machine.
 
 Anyone know of a fix for the above, please?
 

the same here ...


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQ7EsMAAoJEOk/tJ1aQIB9c98IAI0qcvIvMH1inD2pL3dK9uUo
ipsPVsBOFhYhzlcHOd7S4h79O8puQugNZdIDtxTA1sgrvVy5rxbobKAIz4LxfzSM
nv7vwv4gKfTvMROefGhkPUhBnyF6ULcOE1nRNEgu5s8/m+QV2SaI0ucBbmiZjq0f
QaZu0R4qRIkPtkf4ptUwmZ3D2duxLHBW/TUD5jXxpo2zg6RatcWrP7CCgF3VGktb
HmypEp+dww7PYsO3+0tArK/9U/kLZYzHaAGsQCiJ9oApRTpzuet5heHv6lMpQpux
4nA6k9Lo87+rZsJa6JszsC1Sta+kpmUVDJuuu4FbZ4RbYzdBVMPZ4vbUvcGMUpE=
=D8eB
-END PGP SIGNATURE-

Re: [Mageia-dev] 3.0 release - some initial notes; failure

2013-01-08 Thread Liam R E Quin

On Tue, 2013-01-08 at 13:41 +0200, Shlomi Fish wrote:
 Hi Liam,
 
 let me reply to your E-mail - not necessarily disagreeing.

Thanks!
 
 On Mon, 07 Jan 2013 02:46:39 -0500
 Liam R E Quin l...@holoweb.net wrote:
 
  Tried installing 3.0 beta over a Mandriva Cooker system today.
  Mageia-3-beta1-x86_64-DVD.iso
 
 Can Mandriva Cooker be upgraded to Mageia 3? I don't think it can be (due to
 Mandriva's switch to rpm5). Or do you mean you reformatted the relevant
 partitions and installed a new system?

It's a fresh install, sorry for not being clear.

[...]

  On boot, there was a long delay followed by Loading program and a
  progress bar appearing and disappearing again almost before I had time
  to read the message. This didn't seem optimal.
 
 I see. What are your system's specifications? I think I usually install from a
 CD (just to have a working system) and then install more packages using 
 urpmi. I
 am downloading the DVD .iso now and will try it in a VirtualBox VM later to 
 see
 if I can reproduce any problems.

It's several years old, HP Media Center m7680n with 8G of RAM,
Intel Core 2 Duo E6400 2.1GHz, DDR2 533MHz memory.

  Choice of keyboard - there was a link to wikipedia in the Help text, but
  it gave me an error that there was no network. There are two entries for
  US Keyboard with no obvious reason, and a third for US International
  (which I chose since I'm not in the US :-)) 
 
 Sounds like a bug or at least a problem in the installer. Can you file a bug
 for it on https://bugs.mageia.org/ ?
 
  
  I have 2 disk drives. the installer wanted to use the spare space on my
  Windows drive, when the other drive already had Linux. Yes, I could
  choose from the drop-down, but it wasn't clear that I was choosing where
  to put Mageia. Suggest add,
  Multiple disk drives found. Choose which one you want to use for the
  main Mageia system.
 
 Sounds like a good enhancement.
 
  
  The disk was formatted. That was actually what I wanted, in this case,
  but please add a warning that data will be lost - most humans on the
  planet won't know that.
 
 Yes, true. Of course, you cannot expect your users to read:
 
 http://www.joelonsoftware.com/uibook/chapters/fog62.html

No, but Mageia Linux's installer is obviously primarily intended at the
experienced or dedicated hobbyist or the experienced system
administrator.

Long term, Magiea needs of course to target (1) people new to Linux,
whether or not they are new to computers in general, and (2) programmers
and packagers, to keep the distribution and community alive, whether or
not they are administrators.  This double-headed focus was a lot of the
success of Mandrake Linux and in fact led to a response from Red Hat -
Fedora.


  There's no indication of how long the formatting will take, 
[...]
  Suggest progress bar or at least some quotes from Moliére.
 
 Heh. Well, formatting normally did not take too long for me, at least not in
 its fast formatting mode. But maybe a progress bar will be doable.

I said yes to doing a block scan.

 Oh, bad block scan. :-(. It should be displayed in the graphical installer.
Yes.


  I'm assuming the graphics and ugly font are not final. If they are, the
  pink stripes look like an error. Maybe caused by running my monitor
  (1920x1200/deep colour) in 800x600 16-bit mode.
 
 I'll see if it happens to me in the installer.
 
  
  The long list of packages being installed - would be nicer to show the
  name of the current package, and its description, and more slowly to
  show a more detailed description of just one program.
 
 By default the installer does not display the names of the packages installed 
 I
 think - just a progress bar.
I don't think I did anything special to get the list of packages, but
maybe.

  If there was a clear and obvious option to choose the LCD's native
  resolution, a font like Matthew Carter's Bitstream Charter Italic would
  look more sophisticated and also get more information on a line.
  
 
 Is it an open font.
Not sure, it s distributed with the X Window System and xorg.
We could use something from openfontlibrary too, that's a good point.

 
  Choosing a desktop - help said broken link
  
 
 Shouldn't the help be included inside the installer's media.

Help is there for most other things.

 
  Choosing a desktop - please add versions, not just KDE, GNOME, Other.
  
 
 I'm not sure versions are a good idea because they may be confusing. I'm also
 not sure many users who start with Linux will understand the difference 
 between
 KDE, GNOME or whatever, so maybe we should pick one or the other by default.

Many people know whether they want gnome 2 or 3 right now, and for
people who don't know the difference it's no more confusing.

 
  Also, I might want both KDE and GNOME installed, so I don't want to
  choose just one and not the other. If I'll get a chance to install more
  desktops later in the installer, please say so more clearly, not buried
  in help (once the link

Re: [Mageia-dev] Kernel Panic after latest Mageia-3-Alpha2 s/w update c

2013-01-08 Thread Claire Robinson

On 08/01/13 16:53, Maurice Batey wrote:
 On Tue, 08 Jan 2013 16:35:30 +, I wrote:
 
 Anyone know of a fix for the above,
 
   The Mageia-3-Alpha2 menu.lst is:
 
 timeout 10
 color black/cyan yellow/cyan
 gfxmenu (hd0,0)/boot/gfxmenu
 default 3
 
 title Mageia-3-Alpha2
 kernel (hd0,0)/boot/vmlinuz BOOT_IMAGE=Mageia-3-Alpha2
 root=UUID=50814013-9adf-4c14-82d2-16fbc8df5ec3 splash quiet
 resume=UUID=6044c21e-9281-406d-8db8-2af56e955dbf vga=788
 root (hd0,0)
 initrd /boot/initrd.img
 
 title linux-nonfb
 kernel (hd0,0)/boot/vmlinuz BOOT_IMAGE=linux-nonfb
 root=UUID=50814013-9adf-4c14-82d2-16fbc8df5ec3
 resume=UUID=6044c21e-9281-406d-8db8-2af56e955dbf
 root (hd0,0)
 initrd /boot/initrd.img
 
 title failsafe
 kernel (hd0,0)/boot/vmlinuz BOOT_IMAGE=failsafe
 root=UUID=50814013-9adf-4c14-82d2-16fbc8df5ec3 failsafe
 root (hd0,0)
 initrd /boot/initrd.img
 
 title Mageia-2
 root (hd0,8)
 configfile /boot/grub/menu.lst
 
 title linux
 kernel (hd0,0)/boot/vmlinuz BOOT_IMAGE=linux
 root=UUID=50814013-9adf-4c14-82d2-16fbc8df5ec3 splash quiet
 resume=UUID=6044c21e-9281-406d-8db8-2af56e955dbf vga=788
 root (hd0,0)
 initrd /boot/initrd.img
 
 title desktop 3.6.5-1.mga3
 kernel (hd0,0)/boot/vmlinuz-3.6.5-desktop-1.mga3
 BOOT_IMAGE=desktop_3.6.5-1.mga3
 root=UUID=50814013-9adf-4c14-82d2-16fbc8df5ec3 splash quiet
 resume=UUID=6044c21e-9281-406d-8db8-2af56e955dbf vga=788
 root (hd0,0)
 initrd /boot/initrd-3.6.5-desktop-1.mga3.img
 
 title desktop 3.3.6-2.mga2
 kernel (hd0,0)/boot/vmlinuz-3.3.6-desktop-2.mga2
 BOOT_IMAGE=desktop_3.3.6-2.mga2
 root=UUID=50814013-9adf-4c14-82d2-16fbc8df5ec3 splash quiet
 resume=UUID=6044c21e-9281-406d-8db8-2af56e955dbf vga=788
 root (hd0,0)
 initrd /boot/initrd-3.3.6-desktop-2.mga2.img
 
 title desktop 3.7.0-1.mga3
 kernel (hd0,0)/boot/vmlinuz-3.7.0-desktop-1.mga3
 BOOT_IMAGE=desktop_3.7.0-1.mga3
 root=UUID=50814013-9adf-4c14-82d2-16fbc8df5ec3 splash quiet
 resume=UUID=6044c21e-9281-406d-8db8-2af56e955dbf vga=788
 root (hd0,0)
 initrd /boot/initrd-3.7.0-desktop-1.mga3.img
 
 title desktop 3.7.1-1.mga3
 kernel (hd0,0)/boot/vmlinuz-3.7.1-desktop-1.mga3
 BOOT_IMAGE=desktop_3.7.1-1.mga3
 root=UUID=50814013-9adf-4c14-82d2-16fbc8df5ec3 splash quiet
 resume=UUID=6044c21e-9281-406d-8db8-2af56e955dbf vga=788
 root (hd0,0)
 initrd /boot/initrd-3.7.1-desktop-1.mga3.img
 
 

It's actually Cauldron you're running Maurice. This issue is known, see
the ML thread 'Boot borked cause procfs :((' from earlier today.

Claire

Re: [Mageia-dev] Kernel Panic after latest Mageia-3-Alpha2 s/w update c

2013-01-08 Thread Liam R E Quin

On Tue, 2013-01-08 at 17:41 +, Claire Robinson wrote:

 It's actually Cauldron you're running Maurice. This issue is known, see
 the ML thread 'Boot borked cause procfs :((' from earlier today.

It's also in the 3.0 beta DVD, as I reported yesterday.

Liam


-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

Re: [Mageia-dev] Kernel Panic after latest Mageia-3-Alpha2 s/w update c

2013-01-08 Thread Claire Robinson

On 08/01/13 17:45, Liam R E Quin wrote:
 On Tue, 2013-01-08 at 17:41 +, Claire Robinson wrote:
 
 It's actually Cauldron you're running Maurice. This issue is known, see
 the ML thread 'Boot borked cause procfs :((' from earlier today.
 
 It's also in the 3.0 beta DVD, as I reported yesterday.
 
 Liam
 
 

The alphas and betas are snapshots of the current cauldron. Once you
install any updates you are actually installing cauldron updates and
using cauldron.

Claire

Re: [Mageia-dev] Booting on GPT + UEFI + Secure Boot...

* Pascal Terjan (pter...@gmail.com) wrote:
 On Tue, Jan 8, 2013 at 2:01 PM, Olivier Thauvin
 nanar...@nanardon.zarb.org wrote:
  The system is installed with grub2-efi but the boot failed with all
  kernel I've tried: cannot mount /proc - mount return error, no such
  file or directory.
 
  Any idea ?
 
 Yes, it seems a cauldron bug :)

Well I worked around the problem using by force util-linux from mga2 in
rescue mode.

So some notes here about installer, in my case legacy grub1 was not
usuable so I used grub2 + efi.

Two things are need:
- detect the fat32 partition containing EFI/ directory if any or create
  it, copy on it the grub2-efi boot code (done %post of grub2)
- enabling the grub2 boot code, this step is also done in %post fo
  grub2-efi but it doesn't work in rescue mode because 'efivars' kernel module 
is not load

Once this is done the grub2 configuration is perfectly updated when I
install a new kernel.

I can boot windows or mageia by setting the boot order in UEFI.

Regards.

-- 

Olivier Thauvin
CNRS  -  LATMOS
♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖


pgpAsA6Tlica4.pgp
Description: PGP signature

[Mageia-dev] Cauldron install broken with existing lvm

Hi,

There is currently two problem with lvm in cauldron installer:

1) If you already have a lvm the installer failed to detect it and if
you try to read it by clicking on the lvm partition you get error
division by 0 and the installer don't work anymore.

2) in rescue mode the mount system under /mnt failed to detect /, I
had to run manually lvm2 vgchange -a y and lvm2 vgmknodes.

Both were working fine in mga2.

Regards.

-- 

Olivier Thauvin
CNRS  -  LATMOS
♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖


pgpufZHWrEDlx.pgp
Description: PGP signature

Re: [Mageia-dev] UAS module (was: PHP treadsafe)


Frederik Himpe skrev 8.1.2013 12:04:


Another example is the uas kernel module, of which I saw a complaint
recently in this mailing list. This module is known to be buggy, and
disabled in Debian.



It's also disabled as broken upstream, in cauldron and in mga2 kernels
currently in updates_testing.

--
Thomas

Re: [Mageia-dev] [343016] provide need /var/run/ nscd in nscd package otherwise nscd failed to start


root-odjjhxpcy38dnm+yrof...@public.gmane.org skrev 8.1.2013 20:06:

Revision
343016
Author
nanardon
Date
2013-01-08 19:06:55 +0100 (Tue, 08 Jan 2013)


  Log Message

provide need /var/run/nscd in nscd package otherwise nscd failed to start


  Modified Paths

  * cauldron/glibc/current/SPECS/glibc.spec
#cauldronglibccurrentSPECSglibcspec

Modified: cauldron/glibc/current/SPECS/glibc.spec
===
--- cauldron/glibc/current/SPECS/glibc.spec 2013-01-08 17:58:03 UTC (rev 
343015)
+++ cauldron/glibc/current/SPECS/glibc.spec 2013-01-08 18:06:55 UTC (rev 
343016)
@@ -1041,6 +1041,7 @@
  install -m 644 %{SOURCE7} %{buildroot}%{_unitdir}/nscd.socket
  mkdir -p %{buildroot}%{_prefix}/lib/tmpfiles.d/
  install -m 644 %{SOURCE9} %{buildroot}%{_prefix}/lib/tmpfiles.d/nscd.conf
+mkdir -p %{buildroot}%{_var}/run/nscd
  %endif

  # These man pages require special attention
@@ -1673,6 +1674,7 @@
  %{_unitdir}/nscd.service
  %{_unitdir}/nscd.socket
  %{_prefix}/lib/tmpfiles.d/nscd.conf
+%{_var}/run/nscd
  %endif



Nope, wrong fix...

if there is something wrong, it must be fixed in SOURCE9 (nscd.conf) as 
/run (to wich  /var/run point at) is a tmpfs


--
Thomas

Re: [Mageia-dev] Kernel Panic after latest Mageia-3-Alpha2 s/w update c

2013-01-08 Thread Maurice Batey

On Tue, 08 Jan 2013 17:41:22 +, Claire Robinson wrote:

 see
 the ML thread 'Boot borked cause procfs :(('

  No - can't see that in here...

-- 
/\/\aurice

Re: [Mageia-dev] outdated packages missed by youri

2013-01-08 Thread David Walser

David Walser luigiwalser@... writes:
 Second list, based on:
 http://upstream-tracker.org/updates/rosa/2012/all/

I took another pass through that page and found that I missed a handful!

Sorry about that, here's the ones I missed:

Luigi12 :maint -s cfitsio
Sophie Luigi12: For Mageia (cfitsio): eatdirt
Luigi12 :maint -s malo
Sophie For Mageia (dblatex): malo
Luigi12 :maint -s drbd-utils
Sophie For Mageia (drbd-utils): tmb
Luigi12 :maint -s fonts-ttf-thai
Sophie For Mageia (fonts-ttf-thai): dmorgan
Luigi12 :maint -s gypsy
Sophie For Mageia (gypsy): nobody
Luigi12 :maint -s ini4j
Sophie For Mageia (ini4j): nobody
Luigi12 :maint -s jdom
Sophie For Mageia (jdom): dmorgan
Luigi12 :maint -s kawa
Sophie For Mageia (kawa): dmorgan
Luigi12 :maint -s libnfs
Sophie For Mageia (libnfs): anssi
Luigi12 :maint -s mingw32-w32api
Sophie For Mageia (mingw32-w32api): nobody
Luigi12 :maint -s mpd
Sophie For Mageia (mpd): jquelin
Luigi12 :maint -s openobex
Sophie For Mageia (openobex): nobody
Luigi12 :maint -s pmd
Sophie For Mageia (pmd): nobody
Luigi12 :maint -s python-gpgme
Sophie For Mageia (python-gpgme): philippem
Luigi12 :maint -s python-m2crypto
Sophie For Mageia (python-m2crypto): philippem
Luigi12 :maint -s python-pyinotify
Sophie For Mageia (python-pyinotify): philippem
Luigi12 :maint -s python-routes
Sophie For Mageia (python-routes): neoclust
Luigi12 :maint -s python-setuptools
Sophie For Mageia (python-setuptools): philippem

Re: [Mageia-dev] Minimal mageia install

Op maandag 7 januari 2013 15:39:30 schreef Eatdirt:
 On 10/23/2012 02:53 PM, Bruno Cornec wrote:
  Helo,
  
  I'm in the process of redeploying automatically my firewall machine,
  using Mageia. For that I'd like to have a very minimal install.
  
  However, I'm ending up with 580 packages, among them a lot of X11
  content, whereas I want a text base install only.
 
 +1
 I agree with this, we have some bugs in package dependencies. Please,
 don't hesitate to report them on bugzilla for the next bugfest!
 
 We should also try to fix them. I reported this one months ago, Colin
  :)))
 
 https://bugs.mageia.org/show_bug.cgi?id=7960
 
 Cheers,
 Chris.

i'm always up for lowering the minimum install.

a while ago, i did some work on that, but they are not easy.

in particular the X libs are pretty difficult to get out.

some of it is due to some drak tools being required by stuff and requiring some 
other stuff.

it does mean that for instance some code will need to have some functions 
split off into another class or something... iinm (but this is all quite a 
while back, i'd need to check more on that)

Re: [Mageia-dev] Minimal mageia install

Op maandag 7 januari 2013 00:53:05 schreef Bruno Cornec:
[...]
 Ok so it's now available at https://wiki.mageia.org/en/Auto_inst with an
 addition and s/Mandriva/Mageia/ done.
[...]this is nice!

Re: [Mageia-dev] Packages backlog

Op zondag 6 januari 2013 23:30:34 schreef Pierre-Malo Deniélou:
 Le 06/01/13 23:03,Joseph Wang nous adresse ces quelques mots :
  [...]
  
  vstar
 
 I just looked at vstar. I have several remarks or comments:
 - there is a typo in the URL
 - Usually it's better not to have a weird downloading script in SOURCES
 for svn revisions, but to put it as a comment in the SPEC file.

== be advised that the build system does NOT have internet access and cannot 
fetch anything.

i too in my packages had to remove those parts.

 - BTW, why can't you use the stable version instead of the svn release?
 There is a very recent one at
 http://sourceforge.net/projects/vstar/files/2.14.2/
 If you use that one, you can just put as Source0 the sourceforge URL to
 the archive
 - your desktop file does not mention an icon, which makes for an blank
 entry in the menu.
 
 If you fix these things, I happy to submit it.
 
 Cheers,

Re: [Mageia-dev] RPM group change before Beta 2

Op zondag 6 januari 2013 23:24:34 schreef Pierre-Malo Deniélou:
 Le 06/01/13 23:22,Joseph Wang nous adresse ces quelques mots :
  Sure thing.  I can start patching some of the rpms that aren't haven't
  been done yet.  However, I was wondering if I can do that with just
  subversion commit privileges or do I need to be able to submit build
  requests to do this?
 
 To patch, you do not need to submit. But it's good practice to contact
 the maintainer when you do that: IRC is a fast way to do that.
 
 Cheers,

in particular, on #mageia-dev the Sophie bot can tell you which maintainer is 
from which package by:

:maint package

also, if it tells nobody, you can still see who last Packaged it

with mgarepo log package

or on irc with :p -s package

Re: [Mageia-dev] PXE boot on cauldron failed

Op maandag 7 januari 2013 12:18:05 schreef Olivier Thauvin:
 Hello,
 
 We use PXE to install computers, it works very fine for Mageia 2 but it
 failed with Cauldron with same parameters:
 
 LABEL manual64bits
   KERNEL
 http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/2/x86_64/iso
 linux/alt0/vmlinuz APPEND
 initrd=http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/2/x86
 _64/isolinux/alt0/all.rdz
 automatic=method:http,ser:distrib-coffee.ipsl.jussieu.fr,dir:/pub/linux/Mag
 eia/distrib/2/x86_64/,int:eth0,netw:dhcp vga=788
 
 and for cauldron:
 
 LABEL manual64bits
   KERNEL
 http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86
 _64/isolinux/alt0/vmlinuz APPEND
 initrd=http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauld
 ron/x86_64/isolinux/alt0/all.rdz
 automatic=method:http,ser:distrib-coffee.ipsl.jussieu.fr,dir:/pub/linux/Mag
 eia/distrib/cauldron/x86_64/,int:eth0,netw:dhcp vga=788
 
 I can see the end of kernel messages but I cannot see the first
 message...
 
 Any idea ?

huh, i never knew that you could specify URLs in pxe configs... for kernel and 
initrds

Re: [Mageia-dev] PXE boot on cauldron failed

2013-01-08 Thread eatdirt


On 08/01/13 20:51, AL13N wrote:


Any idea ?


huh, i never knew that you could specify URLs in pxe configs... for kernel and
initrds



Me neither, this is very cool actually. If you make it work again 
Olivier, that would deserve a mini wiki somewhere...

Re: [Mageia-dev] help for libreoffice packaging


Thierry Vignaud skrev 8.1.2013 22:13:

Hi

We need some help with building libreoffice which fails for a couple months.
We follow RH packaging, tracking it regularly.
They successfully packaged LO-4.0b but we fail to compile both 3.6.x  4.0.
Which hints that maybe a 3rd party library has broken in the mean time.
We've tried various tricks w/o much success.

We could disable every failing test until it works but others have succeeded.
Also some very similar errors have been seen by people on both linux  bsd
with prior releases too.

So we need fresh eyes to look for the issue.

4.0 failure:
http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20130107211950.tv.valstar.7795/log/libreoffice-4.0.0.0-0.beta2.mga3/build.0.20130107212026.log

3.6 failure:
http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20130107210604.tv.valstar.29241/log/libreoffice-3.6.3.2-6.mga3/build.0.20130107210655.log

Here's 4.0  3.6 branches:
http://svnweb.mageia.org/packages/cauldron/libreoffice/current/
http://svnweb.mageia.org/packages/cauldron/libreoffice/branches/3.6/current/

So if someone can help (it takes one day for me to locally build).


it took ~5h for me to build libreoffice-4.0.0.0-6.beta2.mga3 beta on a 
core i7, and x86_64 built ok ???


maybe we should limit LO build to 4 cores ?

--
Thomas

Re: [Mageia-dev] help for libreoffice packaging

2013-01-08 Thread Frank Griffin


On 01/08/2013 03:16 PM, Thomas Backlund wrote:

Thierry Vignaud skrev 8.1.2013 22:13:

Hi

We need some help with building libreoffice which fails for a couple 
months.
it took ~5h for me to build libreoffice-4.0.0.0-6.beta2.mga3 beta on a 
core i7, and x86_64 built ok ???


maybe we should limit LO build to 4 cores ?



So you're saying that the same RPM that fails to build on the 
buildsystem builds OK on your system ?

Re: [Mageia-dev] help for libreoffice packaging

2013-01-08 Thread D.Morgan

On Tue, Jan 8, 2013 at 9:16 PM, Thomas Backlund t...@mageia.org wrote:
 Thierry Vignaud skrev 8.1.2013 22:13:

 Hi

 We need some help with building libreoffice which fails for a couple
 months.
 We follow RH packaging, tracking it regularly.
 They successfully packaged LO-4.0b but we fail to compile both 3.6.x 
 4.0.
 Which hints that maybe a 3rd party library has broken in the mean time.
 We've tried various tricks w/o much success.

 We could disable every failing test until it works but others have
 succeeded.
 Also some very similar errors have been seen by people on both linux  bsd
 with prior releases too.

 So we need fresh eyes to look for the issue.

 4.0 failure:

 http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20130107211950.tv.valstar.7795/log/libreoffice-4.0.0.0-0.beta2.mga3/build.0.20130107212026.log

 3.6 failure:

 http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20130107210604.tv.valstar.29241/log/libreoffice-3.6.3.2-6.mga3/build.0.20130107210655.log

 Here's 4.0  3.6 branches:
 http://svnweb.mageia.org/packages/cauldron/libreoffice/current/

 http://svnweb.mageia.org/packages/cauldron/libreoffice/branches/3.6/current/

 So if someone can help (it takes one day for me to locally build).


 it took ~5h for me to build libreoffice-4.0.0.0-6.beta2.mga3 beta on a core
 i7, and x86_64 built ok ???

 maybe we should limit LO build to 4 cores ?

 --
 Thomas




LO 4.0beta2 fails only on i586

Re: [Mageia-dev] help for libreoffice packaging