[Mageia-dev] libkolabxml rebuild

[Thomas Spuhler]

Funda:

Would you please have a look why libkolabxml doesn't build anymore.
-- 
Best regards
Thomas Spuhler


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

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

[David Walser]

Christiaan Welvaart wrote:
> On Mon, 7 Jan 2013, David Walser wrote:
> 
>> Thierry Vignaud wrote:
>>> Preparing... 
>>> #
>>> Installation failed:file /usr/lib64/audit from install of
>>> audit-2.2.2-3.mga3.x86_64 conflicts with file from package
>>> glibc-6:2.17-1.mga3.x86_64
>>
>> file?  %{_libdir}/audit is a directory, and even if it is owned by two 
>> packages, that shouldn't
>> cause a conflict.  That directory is owned by glibc and audit on mga2, so 
>> that's not new.  
Fedora's
>> audit package has it owning this directory, so that's not obviously wrong 
>> either.  Maybe an issue
>> with the new rpm version?
> 
> Different permissions:
> [cjw@hactar audit]$ ls -ld usr/lib64/audit /usr/lib64/audit
> drwxr-xr-x 2 root root 27 Jan  2 15:06 /usr/lib64/audit
> drwxr-x--- 2 cjw  cjw   6 Jan  8 02:34 usr/lib64/audit

750 appears to be the correct permissions, so I guess attr should be used to 
explicitly set it in 
glibc as well.

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

[Christiaan Welvaart]

On Mon, 7 Jan 2013, David Walser wrote:


Thierry Vignaud wrote:

Preparing... #
Installation failed:file /usr/lib64/audit from install of
audit-2.2.2-3.mga3.x86_64 conflicts with file from package
glibc-6:2.17-1.mga3.x86_64


file?  %{_libdir}/audit is a directory, and even if it is owned by two 
packages, that shouldn't
cause a conflict.  That directory is owned by glibc and audit on mga2, so 
that's not new.  Fedora's
audit package has it owning this directory, so that's not obviously wrong 
either.  Maybe an issue
with the new rpm version?


Different permissions:
[cjw@hactar audit]$ ls -ld usr/lib64/audit /usr/lib64/audit
drwxr-xr-x 2 root root 27 Jan  2 15:06 /usr/lib64/audit
drwxr-x--- 2 cjw  cjw   6 Jan  8 02:34 usr/lib64/audit


Christiaan

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

[David Walser]

Thierry Vignaud wrote:
> Preparing... #
> Installation failed:file /usr/lib64/audit from install of
> audit-2.2.2-3.mga3.x86_64 conflicts with file from package
> glibc-6:2.17-1.mga3.x86_64

file?  %{_libdir}/audit is a directory, and even if it is owned by two 
packages, that shouldn't 
cause a conflict.  That directory is owned by glibc and audit on mga2, so 
that's not new.  Fedora's 
audit package has it owning this directory, so that's not obviously wrong 
either.  Maybe an issue 
with the new rpm version?

Re: [Mageia-dev] [RPM Groups] RPM group change before Beta 2 (Reposted in new thread)

[Balcaen John]

Le lundi 7 janvier 2013 10:36:07 Barry Jackson a écrit :
> On 06/01/13 19:21, Balcaen John wrote:
> > Did you try to simply send an email to Luc Menut, Nicolas Lecureuil or me
> > for that purpose ?
> 
> No, but here is a list.
> Maybe some are fixed in svn, but have not been pushed - I don't have
> time to check just now.
> 
> audiokonverter
> k4guitune
> konvertible
> kradio
> basket
> kmplayer
> kmplayer-npplayer
> kubeplayer
Thoses packages are not part  of the KDE's stack so not really under our 
umbrella ;o)
You just have to check with their respective maintainers.

-- 
Mageia Contributor

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

[Juan Luis Baptiste]

On Mon, Jan 7, 2013 at 5:15 PM, Sander Lepik  wrote:

> 07.01.2013 21:19, Juan Luis Baptiste kirjutas:
> > 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.
> If i'm afraid that something might blow my connection during update then i
> use screen. It
> might drop me out but update will continue and usually quite soon i'm able
> to reconnect.
>

 I use screen too and the problem is that the user session is finished, so
the screen process is finished too.


-- 
Juancho

[Mageia-dev] Version freeze

[Anne Nicolas]

Attention please :)

As a reminder of Mageia 3 planning, version freeze is planned for 9th of 
january (end of the day). Please submit your changes before this date. 
We will speak about it in tomorrow's meeting


Cheers

--
Anne
http://mageia.org

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

[Sander Lepik]

07.01.2013 21:19, Juan Luis Baptiste kirjutas:
> 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.
If i'm afraid that something might blow my connection during update then i use 
screen. It
might drop me out but update will continue and usually quite soon i'm able to 
reconnect.

--
Sander

[Mageia-dev] FOSDEM coming up, will you meet us there?

[Oliver Burger]

Hi folks,

FOSDEM is nearing on the horizon.
The conference will take place on February 2nd and 3rd in Bruxelles.
It is a great place to meet other Open Source guis and discuss 
everything you want.


As tha last two years, we will have a booth at FOSDEM and we will have 
our General Assembly there.


If you want to come, please do register here:
https://wiki.mageia.org/en/Fosdem_2013

If you are coming to FOSDEM, we do need people for the booth and of 
course for the Saturday night dinner!


Cheers and see you in Bruxelles,

Oliver

--
Oliver Burger aka obgr_seneca

Mageia contributor

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

[Anssi Hannula]

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.

-- 
Anssi Hannula

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

[Thierry Vignaud]

On 1 January 2013 15:15, Thomas Backlund  wrote:
> this is a headsup that I'm about to push glibc-2.17 to core/release...
>
> It has worked well in initial test theese last days, so It's time
> for all to start using it :)
>
>
> You better wait for both glibc-2.17-1 and locales-2.17-1 to be
> available before updating or you will get many packages removed
> due to missing locales*

The following makes e4rac bounces in the BS (as well as anything BRing audit):
installing lib64auparse-devel-2.2.2-3.mga3.x86_64.rpm
lib64blkid-devel-2.22.2-1.mga3.x86_64.rpm
lib64uuid-devel-2.22.2-1.mga3.x86_64.rpm audit-2.2.2-3.mga3.x86_64.rpm
from /mageia/unstable/x86_64/media/core/release
Preparing... #
Installation failed:file /usr/lib64/audit from install of
audit-2.2.2-3.mga3.x86_64 conflicts with file from package
glibc-6:2.17-1.mga3.x86_64

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

[Juan Luis Baptiste]

On Mon, Jan 7, 2013 at 2:37 PM, Thomas Backlund  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
>
>
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.


-- 
Juancho

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

[Thierry Vignaud]

On 7 January 2013 12:18, Olivier Thauvin  wrote:
> 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/isolinux/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/Mageia/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/cauldron/x86_64/isolinux/alt0/all.rdz
>  
> automatic=method:http,ser:distrib-coffee.ipsl.jussieu.fr,dir:/pub/linux/Mageia/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...

not directly related, but why the "vga=788". Have you tried without it?
And without automatic, do you got stage1 menu?

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

[Thomas Backlund]

Juan Luis Baptiste skrev 7.1.2013 21:19:



On Mon, Jan 7, 2013 at 9:22 AM, Thomas Spuhler mailto:tho...@btspuhler.com>> wrote:

Try to do a urpmi --replacepkgs glibc
I had some of these when I upgrade an old mga2 install.
It did the trick.


That did the trick, although when doing it remotely through an ssh
connection, the connection was closed and the installation can't finish.
Fortunately it's a vbox vm which I have rdp access so I was able to run
that command "locally".

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

--
Thomas

Re: [Mageia-dev] Help with package

[Juan Luis Baptiste]

Hi Colin,

On Mon, Jan 7, 2013 at 5:53 AM, Colin Guthrie  wrote:

> > Well, it worked on x86_64, but  on i586 the symlinks are created under
> > /usr/lib64/games/warsow/basewsw instead of /usr/lib/games/warsow/basewsw
> > but I don't understand why, it seems that for some reason, the
> > %{_libdir} macro is expanding to /usr/lib64 on the BS. This is the spec
> > if someone wants to take a look:
> >
> >
> http://svnweb.mageia.org/packages/cauldron/warsow-data/current/SPECS/warsow-data.spec?revision=338836&view=markup
>
> %_libdir expands to the given architecture's libdir. On i586 it's
> /usr/lib, on x86_64 it's /usr/lib64.
>
>
I know, that's why it's strange to me why when the package is built on the
BS the links end up on /usr/lib64 on the i586 package.


> Looking at the spec, I think you're doing it a bit wrong.
>
> It's in the %post for a start which is wrong. It should be done as part
> of package build, not install. Doing it during install will mean the
> files are not "owned" by the package so users cannot tell where they
> come from.
>
>
Well, that was just a suggestion from someone on this thread and it looked
to me like the right place too. On this particular case what I'm doing here
is not installing some files but creating some symlinks that the other
warsow package needs.


>
> Also as you use %_libdir, your package cannot be noarch.
>

The "warsow-data" package contains the data files of the game which are
arch independent. The "warsow" package contains all the binaries and libs,
but to be able to run the game, the binary expects to find the data files
on the same directory where the libs are, if not then the angelscript
module will fail loading. So, what I'm trying to accomplish is that when
warsow-data is installed, symlinks of the files in the data directory
(/usr/share/warsow/basewsw/*) are created on
/usr/lib{64}/games/warsow/basewsw/. It works on x86_64 but on i586 is
creating the links on lib64 instead of lib and I don't get why, you saw the
code in the spec, I'm not hardcoding any path on it:


%define gamelibdir %{_libdir}/games/warsow

%post
#Add symbolic links of the contents of basewsw to the directory were the
#package warsow install the libs, if not then angelscript fails to load.
for i in %{_datadir}/warsow/basewsw/*;
do
  file=`basename $i`
  ln -sf $i  %{gamelibdir}/basewsw/$file
done

%postun
rm -rf %{gamelibdir}/basewsw


>
> If you want to use /usr/lib all the time then do so (if that's what the
> game binary expects) via %{_prefix}/lib not via %_libdir.
>


That's not the case, as explained before, the symlinks have to be created
at /usr/lib for i586 and at /usr/lib64 for x86_64, but on i586 for some
reason isn't doing it.



>
> Also your fdupes command seems to do nothing other than display
> duplicate information, not actually resolve anything. So I'd just remove
> it or add appropriate arguments to do hardlinking as needed. Unless this
> package has a particular problem with duplicated data, then I'd just
> kill it off completely.
>

I'll check this too.


>
> Hope that gives you some hints.
>
>
Thanks for the comments.

-- 
Juancho

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

[Juan Luis Baptiste]

On Mon, Jan 7, 2013 at 9:22 AM, Thomas Spuhler  wrote:

> Try to do a urpmi --replacepkgs glibc
> I had some of these when I upgrade an old mga2 install.
> It did the trick.
>
>
That did the trick, although when doing it remotely through an ssh
connection, the connection was closed and the installation can't finish.
Fortunately it's a vbox vm which I have rdp access so I was able to run
that command "locally".

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.


-- 
Juancho

Re: [Mageia-dev] df lying?

[Dan Fandrich]

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? A symbolic link in the path could easily change that if you
don't explicitly check.  Have you tried giving df an argument of the
actual path to one of the downloaded files instead of the filesystem
mount point? df is smart enough to extract the actual filesystem on
which that file is stored and display information for that.

>>> Dan

Re: [Mageia-dev] help files in soft svn - status?

[Manuel Hiebel]

Le 07/01/2013 12:59, Oliver Burger a écrit :
> In our soft svn we have
>
> mageia-gfxboot-theme help-boot and help-install.
>
> Are those leftovers from the old documnetation, before the work using
> calenco started or are those actually used?
>
> We should know at i18n.
>
> Thanks,
>
> Oliver
>

For gfxboot you mean here
http://svnweb.mageia.org/soft/theme/mageia-gfxboot-theme/trunk/help-install/ 
and
http://svnweb.mageia.org/soft/theme/mageia-gfxboot-theme/trunk/help-boot/ ?

Because before mga2 I reported a bug
(https://bugs.mageia.org/show_bug.cgi?id=5275) which was fixed in
english for cauldron but I missed to reopen for other language.

*But*, maybe we will not use anymore gfxboot (what is iso maker opinion
?) and maybe grenoya's change was not complete.

Re: [Mageia-dev] df lying?

[Felix Miata]

On 2013-01-07 13:04 (GMT-0500) Liam R E Quin composed:


On Mon, 2013-01-07 at 12:54 -0500, Felix Miata wrote:



On 2013-01-07 15:15 (GMT+0200) Anssi Hannula composed:



$ df /disks/esata
Filesystem 1K-blocks  Used Available Use% Mounted on
/dev/sdb1  969063752 942471244  26592508  98% /disks/esata



Do total space in df & du output exclude inode blocks?



Yes, and indirect blocks that may be needed, depending on the file
system, and also the size of any filesystem journal. Th du command
doesn't know about such things, and can't in general (e.g. not all file
systems have ways to report it). The df command looks at total available
space, which will be reduced by inode blocks; df -i gives some
information about inode usage.


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?


2-how can I find out how much the free space really is, before adding enough 
files to reduce it to 0?

--
"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] df lying?

[Liam R E Quin]

On Mon, 2013-01-07 at 12:54 -0500, Felix Miata wrote:
> On 2013-01-07 15:15 (GMT+0200) Anssi Hannula composed:

> $ df /disks/esata
> Filesystem 1K-blocks  Used Available Use% Mounted on
> /dev/sdb1  969063752 942471244  26592508  98% /disks/esata

> Do total space in df & du output exclude inode blocks?

Yes, and indirect blocks that may be needed, depending on the file
system, and also the size of any filesystem journal. Th du command
doesn't know about such things, and can't in general (e.g. not all file
systems have ways to report it). The df command looks at total available
space, which will be reduced by inode blocks; df -i gives some
information about inode usage.

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] Booting on GPT + UEFI + Secure Boot...

[Liam R E Quin]

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.

-- 
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] df lying?

[Felix Miata]

On 2013-01-07 15:15 (GMT+0200) Anssi Hannula composed:


Felix Miata composed:



What is upstream for df command? In openSUSE 12.2, Cauldron & F18 on the
same 64 bit system, df on the only partition on my 1TB data HD is
obviously lying as to usage and free on a nearly full EXT2 partition:



# df# before copy Filesystem 1K-blocks  Used Available Use%
Mounted on /dev/sdb1  968990412 942397904  26592508  98%
/disks/esata



-rw-rw-r-- 1 5548561312 Jan  6 14:59 monk0714IonE-201301061400s2.ts
-rw-rw-r-- 1 5548200540 Jan  6 15:59 monk0715IonE-201301061500s2.ts
-rw-rw-r-- 1 5548657192 Jan  6 16:59 monk0716IonE-201301061600s2.ts
-rw-rw-r-- 1 5547676772 Jan  6 17:59 monk0801IonE-201301061700s2.ts
-rw-rw-r-- 1 5546660256 Jan  6 18:59 monk0802IonE-201301061800s2.ts
-rw-rw-r-- 1 5547738436 Jan  6 19:59 monk0803IonE-201301061900s2.ts
-rw-rw-r-- 1 5548427644 Jan  6 20:59 monk0804IonE-201301062000s2.ts



# df# after copying above 37,925,705K bytes in 7 files to #   #
/disks/esata from another system on the network Filesystem 1K-blocks
Used Available Use% Mounted on /dev/sdb1  968990412 942397904
26592508  98% /disks/esata



Unless this is a bug in df, how is this lack of info possible given the
following filesystem info (e.g., no reserved blocks, and no journal)
about the partition?



tune2fs 1.42.5 (29-Jul-2012) Filesystem volume name:   full1TazboxWD
Last mounted on:  /disks/esata

[...]

Free blocks:  6648127



This seems to be in line with the above "df" output.



What is the result of "du -sk /disks/esata"? It should be approximately
same as the number of used 1K-blocks in "df" output (968990412).


$ df /disks/esata
Filesystem 1K-blocks  Used Available Use% Mounted on
/dev/sdb1  969063752 942471244  26592508  98% /disks/esata

$ du -sk /disks/esata
942397900   /disks/esata

difference in free count: 73344

Repeating after umounting, fsck.ext2 -f /dev/sdb1 then remounting changed 
nothing.


fsck output included:
528/61054976 files
237541825/244189952 blocks (237541825 * 4 = 950167300; 244189952 * 4 = 
976759808)

What could be the reason for the differences, all overhang? 0 overhang? 
Something else?


Do total space in df & du output exclude inode blocks?
--
"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] outdated packages missed by youri

[David Walser]

Guillaume Rousse wrote:
> Le 06/01/2013 23:04, David Walser a écrit :
>> As far as why youri missed these,
> Just because it is not configured to check those data sources... 

Yes, as I said it doesn't check some of these other distros, but that doesn't 
explain the packages it missed from gentoo, debian, and fedora, 
which we do check.

> A simple parser for directory content would be enough, as for instance the 
> Fedora source, before its optimisation to use repodata content:
> http://www.zarb.org/cgi-bin/viewvc.cgi/youri/soft/check/branches/0.10/lib/Youri/Check/Test/Updates/Source/Fedora.pm?revision=2359&view=markup
> 
> BTW, the software refered to is 'youri-check', not 'youri'...

Thanks, I'll try to remember that.

Re: [Mageia-dev] [packages-commits] [340431] fixed lib major

[Matteo Pasotti]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/01/2013 16:40, Jani Välimaa wrote:
> On Mon,  7 Jan 2013 00:32:07 +0100 (CET) r...@mageia.org wrote:
> 
>> Revision: 340431 Author:   matteo Date: 2013-01-07 00:32:06
>> +0100 (Mon, 07 Jan 2013) Log Message: --- fixed lib
>> major
>> 
>> Modified Paths: -- 
>> cauldron/grail/current/SPECS/grail.spec
>> 
>> Modified: cauldron/grail/current/SPECS/grail.spec 
>> ===
>>
>> 
- --- cauldron/grail/current/SPECS/grail.spec   2013-01-06
>> 23:31:33 UTC (rev 340430) +++ 
>> cauldron/grail/current/SPECS/grail.spec  2013-01-06 23:32:06 UTC
>> (rev 340431) @@ -1,11 +1,11 @@ -%define _major   5 +%define
>> _major 6 %define _name   grail %define   libname 
>> %mklibname
>> %{_name} %{_major} %define   devname %mklibname -d %{_name} 
>> Name:
>> %_name Version:  3.0.9 -Release: %mkrel 1 +Release:  %mkrel 2 
>> License: GPLv3 Summary:  Gesture Recognition And Instantiation
>> Library Group:   Development/Other
> 
> You should add a "%{major} check" to %files section of the lib
> pkg. (Use %{major} in file names).
> 
Definitely yes, thank you for the tip.
> It catches %{major} changes and build fails if %{major} versions 
> doesn't match.
Done.
- -- 
Matteo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQ6vlMAAoJED3LowjDDWbN6F0H/ReCunRV4cJzKViG2UomdppW
qPP8+XJuh/+oTcu7RGYgvoiqlggGznQsu3LA+FTcTTSVB7iLI5HYVoe8/Cfjx3ON
42VwssngAB/zd1ZNctTOJnzrdJDREFJJpJRCkeLUDu0NzK4jk+i64HQ2CKeztRVZ
3ZG8ANozrJNPMwKIvSvTSsarDG7fwgc9dwl0KXgj6bu+VE4CYqFsj1EllDTOFGL2
VWUkR72kiCMUblJVxGBh+XTgPmSnuZVvIR8BeHP62y6Lo0hHn+TB1UGvpQ8Ar4j2
8buEB37uRimnG+QA7HVmnv3B6ZnXynxEd+D04NIuQuxQvOXO8Z6wKDvKrs8kDkk=
=eFLw
-END PGP SIGNATURE-

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

[Olivier Thauvin]

* Thomas Backlund (t...@mageia.org) wrote:
> Olivier Thauvin skrev 7.1.2013 15:41:
> >* Pascal Terjan (pter...@gmail.com) wrote:
> >>On Mon, Jan 7, 2013 at 11:31 AM, Olivier Thauvin
> >> wrote:
> >>
> >>Do you know how it fails?
> >
> >The "Bios" claim the disk is not bootable and it switch to the next
> >device (network card or UEFI/windows 8).
> >
> 
> That's because the bootloader installed is not an efi one,
> so it will be ignored.

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).

Regards.

-- 

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


pgpmfPBGhQKbR.pgp
Description: PGP signature

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

[Colin Guthrie]

'Twas brillig, and Colin Guthrie at 07/01/13 11:51 did gyre and gimble:
> Hi,
> 
> I just updated rootcerts package on my cauldron box and got about 50 ish
> .rpmnew files for changed pem files.
> 
> It seems mostly indentation changes (*sigh*) but it made me think - Are
> these really config files? I'd expect these to not be marked as config
> even if they are kept in /etc/ Ideally I'd rather see them kept in
> /usr/share anyway as that seems more appropriate, but that's likely not
> possible without causing a lot of pain.


Just for completeness, I started this thread over on systemd ML which
talked about a "CoreOS" goal of being able to boot with an empty /etc

http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/7908

I've been slowly trying to push this anyway (i.e. moving all shipped
udev rules and tmpfiles to /usr) but there is a long, long way to go
here to get this fully working (and a crap-load of packages to fix up in
this regards so it won't really happen anytime soon).

Still, it would make running a chrooted/multi-root/shared-/usr system
much more manageable and I think it's something we should all keep in
mind as we package and develop things :)

Happy hacking.

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?

[Colin Guthrie]

'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

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] [Mageia-i18n] About net monitor

[Marek Laane]

2013/1/7 Yuri Chornoivan 

> написане Mon, 07 Jan 2013 17:05:04 +0200, Yuri Chornoivan  >:
>
>
>  написане Mon, 07 Jan 2013 16:29:28 +0200, Marek Laane :
>>
>>  Just about a week to go to the freezing and I remembered one nasty
>>> problem.
>>> There is a not-working button in Network Center called Monitor. The
>>> reason
>>> is simple - net_monitor is not installed by default (at least it was not
>>> in
>>> my case).
>>> And the second problem is that when you install net_monitor it is still
>>> all
>>> in English. I'm even not sure if it possible at all to translate
>>> net_monitor for now.
>>> Surely untranslated tool is nothing we do want? And also not-working
>>> button
>>> in Network Center?
>>>
>>> Marek Laane,
>>> Estonian translator
>>>
>>
>> Hi,
>>
>> The code is on github [1], ready for translation. But its developer is no
>> longer with us... To the great regrets. Rest in peace Eugeni.
>>
>> If the developers of Mageia can copy the code somewhere and add
>> extraction scripts we can translate net_monitor. If not... Well, it was
>> never translated.
>>
>> Best regards,
>> Yuri
>>
>> [1] 
>> https://github.com/eugeni/net_**monitor
>>
>
> Just in case that someone is interested, attached is the extraction script
> and POT gettext catalog for the current code.
>
> Can someone from packagers side help us to translate net_monitor?
>
> Thanks in advance for your answers.
>
> Best regards,
> Yuri


If I'm not mistaken, in fact there was and still is drakx-net's "native"
code for net monitor (
http://svnweb.mageia.org/soft/drakx-net/trunk/bin/net_monitor?revision=3607&view=markup)
which should be also translated but just is not used after Eugeni developed
more modern net monitor ... As a no-coder I'm not sure if it is possible
but about not-working button - maybe there is a possibility to use old code
and it's translation if package net_monitor is not installed (it appears to
be by default not installed)?
(I CC to dev-list as probably a dedicated developer is needed to resolve
our problems ...)

Marek Laane,
Estonian translator

Re: [Mageia-dev] [packages-commits] [340431] fixed lib major

[Jani Välimaa]

On Mon,  7 Jan 2013 00:32:07 +0100 (CET)
r...@mageia.org wrote:

> Revision: 340431
> Author:   matteo
> Date: 2013-01-07 00:32:06 +0100 (Mon, 07 Jan 2013)
> Log Message:
> ---
> fixed lib major
> 
> Modified Paths:
> --
> cauldron/grail/current/SPECS/grail.spec
> 
> Modified: cauldron/grail/current/SPECS/grail.spec
> ===
> --- cauldron/grail/current/SPECS/grail.spec   2013-01-06
> 23:31:33 UTC (rev 340430) +++
> cauldron/grail/current/SPECS/grail.spec   2013-01-06 23:32:06
> UTC (rev 340431) @@ -1,11 +1,11 @@ -%define
> _major5 +%define  _major
> 6 %define _name   grail
>  %define  libname %mklibname %{_name}
> %{_major} %define devname %mklibname -d
> %{_name} 
>  Name:%_name
>  Version: 3.0.9
> -Release: %mkrel 1
> +Release: %mkrel 2
>  License: GPLv3
>  Summary: Gesture Recognition And Instantiation Library
>  Group:   Development/Other

You should add a "%{major} check" to %files section of the lib pkg.
(Use %{major} in file names).

It catches %{major} changes and build fails if %{major} versions
doesn't match.

Re: [Mageia-dev] Packages backlog

[Joseph Wang]

Nightfall just got fixed and I'm getting clean i586 builds in iurt.

I'll fix up vstar next.  Also if you can look at raceintospace next.
It's a really cool game.

Also I made an effort to clean up the fedora packages.  Is there
anything in particular with an issue?  I'd also like to fix up rpmlint
to highlight clean issues.

Re: [Mageia-dev] Minimal mageia install

[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.

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

[Thomas Backlund]

Olivier Thauvin skrev 7.1.2013 15:41:

* Pascal Terjan (pter...@gmail.com) wrote:

On Mon, Jan 7, 2013 at 11:31 AM, Olivier Thauvin
 wrote:

Hello again,

I just buy a wonderfull HP ENVY23 smartscreen.

It has:
- Windows 8 (I'd like to keep it)
- GPT Formated disk (2T)
- UEFI
- SecureBoot

I am trying to install a Mageia on it:
I disabled secure boot.
I succeed to boot using PXE (using legacy boot) and to install mageia2,
but it failed to boot on Mageia using legacy boot.


Do you know how it fails?


The "Bios" claim the disk is not bootable and it switch to the next
device (network card or UEFI/windows 8).



That's because the bootloader installed is not an efi one,
so it will be ignored.




So questions:
- is it possible to boot Mageia using legacy boot on GPT disk ?


Yes (using grub, not lilo)


It's the case, but it's not working.



The gpt part works, the (u)efi part needs a (u)efi capable bootloader
installed in ESP partition on the disk (usually mounted as /boot/efi)

On a Windows7 system I used the fedora grub-efi package following this:
http://www.rodsbooks.com/efi-bootloaders/grub_legacy.html

I havent tested if grub2 is capable of booting it...



I did try in rescue mode to reinstall grub but it failed with "hd0 not
found".




- is it possible to boot Mageia using UEFI ?


I think so but I have never tried. I remember someone reporting success.


I'll seek archives then.




I have a Win8 system here too wich I have plans to try and get
all isos to boot in efi mode on and install properly on but
haven't had time to do much of it yet.

--
Thomas

[Mageia-dev] Help on #8000

[Sandro CAZZANIGA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

This bug is about msec, and probably about the code itself. I don't
find anything in the class that could cause this behaviour.
If someone can give advice, that would be appreciated.

Thanks guys! :)

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

iQEcBAEBAgAGBQJQ6tr4AAoJEOk/tJ1aQIB9WpsH/3a+9MOy9iWsoKAzzn8LhmqV
MrOPCAAGK14Hpm6DCdBpwkZDMvFx5WcVu0v8X5s7rprYaDWrTY+eakZDzZsiElxV
EhztBflGlWDGkP1aQ2F2iila+1KeVcmXCli+96IhdWnBBkCPPjTHwPmiUmzKe31E
llnITqYZTBigG7084HWSLuQW4rTMfuDPY7RKAiGCUrEtqdlsKactLgWLRFfv5aJr
l+IJrB9GrEKenxRv1lCA0MNCjTVR2Rp1cvnjp2UEc7QwvIwkoBR71fdM9EtQ+bTe
V/MyocdFBD3REV+b4eCeeMcjyejWCq5Y+PSchQgCE9yGbRvdQvS73QSBuNVZUxg=
=R6ZN
-END PGP SIGNATURE-

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

[Thomas Spuhler]

On Monday, January 07, 2013 01:41:23 AM Juan Luis Baptiste wrote:
> On Tue, Jan 1, 2013 at 2:44 PM, Thomas Backlund  wrote:
> > And glibc-2.17-1 and locales-2.17-1 are now built and should soon
> > show up on the mirrors and it should be safe to update then...
> 
> And now on one of my cauldron boxes I can't update glibc, thus blocking the
> rest of updates:
> 
> The following package has to be removed for others to be upgraded:
> glibc-2.17-1.mga3.x86_64
>  (in order to install glibc-2.17-1.mga3.x86_64)
> 
> 
> installing glibc-devel-2.17-1.mga3.x86_64.rpm
> meta-task-3-22.mga3.noarch.rpm rpm-build-4.11.0-0.beta1.7.mga3.x86_64.rpm
> lib64rpm3-4.11.0-0.beta1.7.mga3.x86_64.rpm
> rpm-4.11.0-0.beta1.7.mga3.x86_64.rpm
> python-rpm-4.11.0-0.beta1.7.mga3.x86_64.rpm glibc-2.17-1.mga3.x86_64.rpm
> from /var/cache/urpmi/rpms
> Preparing...
> ###
>  Installation failed:package
> glibc-6:2.17-1.mga3.x86_64 is already installed
Try to do a urpmi --replacepkgs glibc
I had some of these when I upgrade an old mga2 install.
It did the trick.

-- 
Best regards
Thomas Spuhler


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

Re: [Mageia-dev] Kernel panic after latest update from Cauldron

[AL13N]

> On Sun, Jan 6, 2013 at 11:56 PM, AL13N  wrote:
>
>> i had this in my chrooted installs, but since /proc was mounted there, i
>> figured it was a minor chrooted error only. i guess not.
>
> Thanks for a quick reply!
>
> Now that we know there is a problem, what would be the best way to fix it?
> If I boot using Mageia rescue disk, I can't query/install any RPM
> package on my PC using "rpm --root=/mnt ...". RPM database on hard
> disk is version 4.10, while RPM on Live CD is 4.9.x.
>
> Any help is greatly appreciated!

wouldn't it be better to chroot into your old system and use urpmi from
there?

for me, that worked, even if it gave that error

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

[Thomas Backlund]

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.

--
Thomas

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

[Colin Guthrie]

'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?

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] Booting on GPT + UEFI + Secure Boot...

[Olivier Thauvin]

* Pascal Terjan (pter...@gmail.com) wrote:
> On Mon, Jan 7, 2013 at 11:31 AM, Olivier Thauvin
>  wrote:
> > Hello again,
> >
> > I just buy a wonderfull HP ENVY23 smartscreen.
> >
> > It has:
> > - Windows 8 (I'd like to keep it)
> > - GPT Formated disk (2T)
> > - UEFI
> > - SecureBoot
> >
> > I am trying to install a Mageia on it:
> > I disabled secure boot.
> > I succeed to boot using PXE (using legacy boot) and to install mageia2,
> > but it failed to boot on Mageia using legacy boot.
> 
> Do you know how it fails?

The "Bios" claim the disk is not bootable and it switch to the next
device (network card or UEFI/windows 8).

> 
> > So questions:
> > - is it possible to boot Mageia using legacy boot on GPT disk ?
> 
> Yes (using grub, not lilo)

It's the case, but it's not working.

I did try in rescue mode to reinstall grub but it failed with "hd0 not
found".

> 
> > - is it possible to boot Mageia using UEFI ?
> 
> I think so but I have never tried. I remember someone reporting success.

I'll seek archives then.

-- 

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


pgpAC6OHJB0eW.pgp
Description: PGP signature

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

[Eatdirt]

On 01/07/2013 12:31 PM, Olivier Thauvin wrote:


So questions:
- is it possible to boot Mageia using legacy boot on GPT disk ?



Yes, was working fine for me with various harddrives of 2T and more (grub)

Cheers,
Chris.

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

[Anssi Hannula]

07.01.2013 13:51, Colin Guthrie kirjoitti:
> Hi,
> 
> I just updated rootcerts package on my cauldron box and got about 50 ish
> .rpmnew files for changed pem files.
> 
> It seems mostly indentation changes (*sigh*) but it made me think - Are
> these really config files? I'd expect these to not be marked as config
> even if they are kept in /etc/ Ideally I'd rather see them kept in
> /usr/share anyway as that seems more appropriate, but that's likely not
> possible without causing a lot of pain.

Agreed, not config files.

Of course, the appearance of .rpmnew suggests that something has
modified them in your system - not sure what would've done that.

-- 
Anssi Hannula

Re: [Mageia-dev] df lying?

[Anssi Hannula]

07.01.2013 08:40, Felix Miata kirjoitti:
> What is upstream for df command? In openSUSE 12.2, Cauldron & F18 on the same 
> 64 bit system, df on the only partition on my 1TB data HD is obviously lying 
> as to usage and free on a nearly full EXT2 
> partition:
> 
> # df# before copy
> Filesystem 1K-blocks  Used Available Use% Mounted on
> /dev/sdb1  968990412 942397904  26592508  98% /disks/esata
> 
> -rw-rw-r-- 1 5548561312 Jan  6 14:59 monk0714IonE-201301061400s2.ts
> -rw-rw-r-- 1 5548200540 Jan  6 15:59 monk0715IonE-201301061500s2.ts
> -rw-rw-r-- 1 5548657192 Jan  6 16:59 monk0716IonE-201301061600s2.ts
> -rw-rw-r-- 1 5547676772 Jan  6 17:59 monk0801IonE-201301061700s2.ts
> -rw-rw-r-- 1 5546660256 Jan  6 18:59 monk0802IonE-201301061800s2.ts
> -rw-rw-r-- 1 5547738436 Jan  6 19:59 monk0803IonE-201301061900s2.ts
> -rw-rw-r-- 1 5548427644 Jan  6 20:59 monk0804IonE-201301062000s2.ts
> 
> # df# after copying above 37,925,705K bytes in 7 files to
> #   # /disks/esata from another system on the network
> Filesystem 1K-blocks  Used Available Use% Mounted on
> /dev/sdb1  968990412 942397904  26592508  98% /disks/esata
> 
> Unless this is a bug in df, how is this lack of info possible given the 
> following filesystem info (e.g., no reserved blocks, and no journal) about 
> the partition?
> 
> tune2fs 1.42.5 (29-Jul-2012)
> Filesystem volume name:   full1TazboxWD
> Last mounted on:  /disks/esata
[...]
> Free blocks:  6648127

This seems to be in line with the above "df" output.

What is the result of "du -sk /disks/esata"?
It should be approximately same as the number of used 1K-blocks in "df"
output (968990412).

[...]

-- 
Anssi Hannula

Re: [Mageia-dev] help files in soft svn - status?

[Marja van Waes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/01/13 12:59, Oliver Burger wrote:
> In our soft svn we have
> 
> mageia-gfxboot-theme help-boot and help-install.
> 
> Are those leftovers from the old documnetation, before the work 
> using calenco started or are those actually used?
> 
> We should know at i18n.
> 
> Thanks,
> 
> Oliver
> 

There are at least 2 help buttons in drakx-installer-stage2 that give
a text that comes from somewhere else than the rest of the help texts.

Documentation team does not touch those texts.

That is (at least):

* the help text that appears when clicking on the help button in the
Resolution (Choose the resolution and the color depth) screen

* the help text about configuring your sound card

There may be another one in an old doc-discuss mail, I don't remember.

Cheers,
Marja
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQ6sKiAAoJEKWubDMI5nEBwR8H/1YG7GuXBuNq3ZGcQpx38GqD
X9tuKUfPV9/7GZXCRrNrUwJ1YbkcLrcSQzM6I44EZhan76ZthxhTKm4oVkF3K2He
ddD7yww0JGDf3QXCN5lfldLhZcyR0RFkkIARy9q3rIblDGYAphnV0wjZuCKDTCRf
NN4sFjxciuTvALJVgMoRF3sZQVZYwm5VUsPENLOKTf4FBtvuQtCQ/vQrF4d0qbVa
F0psio484HAfgfgAZiUaD1odle/OMNPsM29UB2X/wKZUtrFhP95iVUWCZcpd6IXV
UQuPb4A9PV2SMsugz+l/JjEwcifn3xtloA0DLDI71A+hXDlypC2RSv0xl0ePqwk=
=GkPM
-END PGP SIGNATURE-

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

[Johnny A. Solbu]

On Monday 7. January 2013 12.51, Colin Guthrie wrote:
> Are these really config files?

What's more, isn't these just noarch files?
Then why build architecture dependent packages?

-- 
Johnny A. Solbu
PGP key ID: 0xFA687324


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

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

[Sander Lepik]

07.01.2013 13:51, Colin Guthrie kirjutas:
> Hi,
>
> I just updated rootcerts package on my cauldron box and got about 50 ish
> .rpmnew files for changed pem files.
>
> It seems mostly indentation changes (*sigh*) but it made me think - Are
> these really config files? I'd expect these to not be marked as config
> even if they are kept in /etc/ Ideally I'd rather see them kept in
> /usr/share anyway as that seems more appropriate, but that's likely not
> possible without causing a lot of pain.
>
> Col
>
I fully agree. Certs are quite far from config files. And I even see
some possible trouble here. If some cert is updated and the user gets it
as .rpmnew file and is noob enough to not notice it then (s)he will be
using wrong cert..

--
Sander

[Mageia-dev] help files in soft svn - status?

[Oliver Burger]

In our soft svn we have

mageia-gfxboot-theme help-boot and help-install.

Are those leftovers from the old documnetation, before the work using 
calenco started or are those actually used?


We should know at i18n.

Thanks,

Oliver

--
Oliver Burger aka obgr_seneca

Mageia contributor

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

[Colin Guthrie]

Hi,

I just updated rootcerts package on my cauldron box and got about 50 ish
.rpmnew files for changed pem files.

It seems mostly indentation changes (*sigh*) but it made me think - Are
these really config files? I'd expect these to not be marked as config
even if they are kept in /etc/ Ideally I'd rather see them kept in
/usr/share anyway as that seems more appropriate, but that's likely not
possible without causing a lot of pain.

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] Booting on GPT + UEFI + Secure Boot...

[Barry Jackson]

On 07/01/13 11:36, Pascal Terjan wrote:

On Mon, Jan 7, 2013 at 11:31 AM, Olivier Thauvin
 wrote:

Hello again,

I just buy a wonderfull HP ENVY23 smartscreen.

It has:
- Windows 8 (I'd like to keep it)
- GPT Formated disk (2T)
- UEFI
- SecureBoot

I am trying to install a Mageia on it:
I disabled secure boot.
I succeed to boot using PXE (using legacy boot) and to install mageia2,
but it failed to boot on Mageia using legacy boot.


Do you know how it fails?


So questions:
- is it possible to boot Mageia using legacy boot on GPT disk ?


Yes (using grub, not lilo)


- is it possible to boot Mageia using UEFI ?


I think so but I have never tried. I remember someone reporting success.



The grub2-efi package in Cauldron has a README.efi file that may be 
useful. (Note efibootmgr package referred to is also in Cauldron)
The author of that README file has been using Mageia with grub2-efi on a 
Mac for some time now.

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

[Pascal Terjan]

On Mon, Jan 7, 2013 at 11:31 AM, Olivier Thauvin
 wrote:
> Hello again,
>
> I just buy a wonderfull HP ENVY23 smartscreen.
>
> It has:
> - Windows 8 (I'd like to keep it)
> - GPT Formated disk (2T)
> - UEFI
> - SecureBoot
>
> I am trying to install a Mageia on it:
> I disabled secure boot.
> I succeed to boot using PXE (using legacy boot) and to install mageia2,
> but it failed to boot on Mageia using legacy boot.

Do you know how it fails?

> So questions:
> - is it possible to boot Mageia using legacy boot on GPT disk ?

Yes (using grub, not lilo)

> - is it possible to boot Mageia using UEFI ?

I think so but I have never tried. I remember someone reporting success.

Re: [Mageia-dev] weird dependencies that i've seen

[Colin Guthrie]

'Twas brillig, and AL13N at 04/01/13 16:49 did gyre and gimble:
> 2. pulseaudio suggests it's i586 counterparts (plz don't)
> 2. in spec file, requested for closed source 3rd party binaries that
are 32bit

This is expected. As several people install third party 32-bit apps that
use Audio (e.g. Skype) we suggest that people have the 32-bit alsa libs,
pulse plugin and pulse libraries even on 64 bit installs.

So either we suggest this or I have to deal with loads of bug reports
about why it doesn't work. I prefer the current solution (after
suffering the pain of the other option over the years).

> 3. qtwebkit requires gstreamer (not phonon)

Does qtwebkit use phonon these days? I think it used to use gstreamer
directly, but no clue about the current status quo.

> 5. hugin directly requires make... why would a gui require a buildtool?

hugin is a bit special tho'. It generates jobs and runs them. Perhaps
make is an integral part of this? I don't know specifically. Maybe it
used to be many years ago but isn't needed now? Dunno, but having used
hugin a bit, it's not super surprising to me to see this here.

> 6. kipi-plugins suggested by gwenview
> 6. gwenview really uses all kipi-plugins?

Isn't gwenview a kipi-host? It used to be... As such users should be
able to access all the kipi functionality from within gwenview.

It's not so much that gwenview uses them, but the users of gwenview who
may want to use them...


On the others I have no clue :)

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] Booting on GPT + UEFI + Secure Boot...

[Olivier Thauvin]

Hello again,

I just buy a wonderfull HP ENVY23 smartscreen.

It has:
- Windows 8 (I'd like to keep it)
- GPT Formated disk (2T)
- UEFI
- SecureBoot

I am trying to install a Mageia on it:
I disabled secure boot.
I succeed to boot using PXE (using legacy boot) and to install mageia2,
but it failed to boot on Mageia using legacy boot.

So questions:
- is it possible to boot Mageia using legacy boot on GPT disk ?
- is it possible to boot Mageia using UEFI ?

Regards.

-- 

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


pgpodb2xkd9h2.pgp
Description: PGP signature

[Mageia-dev] PXE boot on cauldron failed

[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/isolinux/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/Mageia/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/cauldron/x86_64/isolinux/alt0/all.rdz
 
automatic=method:http,ser:distrib-coffee.ipsl.jussieu.fr,dir:/pub/linux/Mageia/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 ?

-- 

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


pgpOiVE8ShIjz.pgp
Description: PGP signature

[Mageia-dev] RE : Re: [RPM Groups] RPM group change before Beta 2 (Reposted in new thread)

[nicolas.lecureuil]

Done


Envoyé depuis un mobile Samsung

 Message d'origine 
De : Barry Jackson  
Date :  
A : Mageia development mailing-list  
Objet : Re: [Mageia-dev] [RPM Groups] RPM group change before Beta 2 (Reposted 
in new thread) 
 
On 06/01/13 19:21, Balcaen John wrote:

> Did you try to simply send an email to Luc Menut, Nicolas Lecureuil or me for
> that purpose ?
>
No, but here is a list.
Maybe some are fixed in svn, but have not been pushed - I don't have 
time to check just now.

audiokonverter
k4guitune
konvertible
kradio
basket
kmplayer
kmplayer-npplayer
kubeplayer

Re: [Mageia-dev] df lying?

[Colin Guthrie]

'Twas brillig, and Felix Miata at 07/01/13 06:40 did gyre and gimble:
> What is upstream for df command? 

rpm -qf `which df`
coreutils-8.20-1.mga3

So http://www.gnu.org/software/coreutils/ I guess.

> In openSUSE 12.2, Cauldron & F18 on the
> same 64 bit system, df on the only partition on my 1TB data HD is
> obviously lying as to usage and free on a nearly full EXT2 partition:
> 
> # df# before copy
> Filesystem 1K-blocks  Used Available Use% Mounted on
> /dev/sdb1  968990412 942397904  26592508  98% /disks/esata
> 
> -rw-rw-r-- 1 5548561312 Jan  6 14:59 monk0714IonE-201301061400s2.ts
> -rw-rw-r-- 1 5548200540 Jan  6 15:59 monk0715IonE-201301061500s2.ts
> -rw-rw-r-- 1 5548657192 Jan  6 16:59 monk0716IonE-201301061600s2.ts
> -rw-rw-r-- 1 5547676772 Jan  6 17:59 monk0801IonE-201301061700s2.ts
> -rw-rw-r-- 1 5546660256 Jan  6 18:59 monk0802IonE-201301061800s2.ts
> -rw-rw-r-- 1 5547738436 Jan  6 19:59 monk0803IonE-201301061900s2.ts
> -rw-rw-r-- 1 5548427644 Jan  6 20:59 monk0804IonE-201301062000s2.ts
> 
> # df# after copying above 37,925,705K bytes in 7 files to
> #   # /disks/esata from another system on the network
> Filesystem 1K-blocks  Used Available Use% Mounted on
> /dev/sdb1  968990412 942397904  26592508  98% /disks/esata
> 
> Unless this is a bug in df, how is this lack of info possible given the
> following filesystem info (e.g., no reserved blocks, and no journal)
> about the partition?

Could be a kernel issue I guess. I dunno. Perhaps Thomas will know?

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] Help with package

[Colin Guthrie]

'Twas brillig, and Juan Luis Baptiste at 07/01/13 08:00 did gyre and gimble:
> 
> 
> On Sat, Jan 5, 2013 at 2:02 AM, Juan Luis Baptiste  > wrote:
> 
> 
>  Got it working with:
> 
> for i in `%{_datadir}/warsow/basewsw/*`;
> do
>file=`basename $i`
>ln -sf $i  %{gamelibdir}/basewsw/$file
> done 
> 
> The game name in the for loop was wrong.
> 
> 
> 
> Well, it worked on x86_64, but  on i586 the symlinks are created under
> /usr/lib64/games/warsow/basewsw instead of /usr/lib/games/warsow/basewsw
> but I don't understand why, it seems that for some reason, the
> %{_libdir} macro is expanding to /usr/lib64 on the BS. This is the spec
> if someone wants to take a look:
> 
> http://svnweb.mageia.org/packages/cauldron/warsow-data/current/SPECS/warsow-data.spec?revision=338836&view=markup

%_libdir expands to the given architecture's libdir. On i586 it's
/usr/lib, on x86_64 it's /usr/lib64.

Looking at the spec, I think you're doing it a bit wrong.

It's in the %post for a start which is wrong. It should be done as part
of package build, not install. Doing it during install will mean the
files are not "owned" by the package so users cannot tell where they
come from.

You also then do things such as rm -rf on %postun but that doesn't
actually check whether you are upgrading or removing. Remember that
%postun is run when upgrading a package too (i.e. when the old version
is removed).


Also as you use %_libdir, your package cannot be noarch.

If you want to use /usr/lib all the time then do so (if that's what the
game binary expects) via %{_prefix}/lib not via %_libdir.

Also your fdupes command seems to do nothing other than display
duplicate information, not actually resolve anything. So I'd just remove
it or add appropriate arguments to do hardlinking as needed. Unless this
package has a particular problem with duplicated data, then I'd just
kill it off completely.

Hope that gives you some hints.

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] [changelog] [RPM] cauldron core/release iozone-3.414-1.mga3

[Damien Lallement]

Le 04/01/2013 17:16, Damien Lallement a écrit :

Le 04/01/2013 16:50, oden a écrit :

Name: iozone   Relocations: (not relocatable)
Version : 3.414 Vendor: Mageia.Org
Release : 1.mga3Build Date: Fri Jan  4
16:49:26 2013
Install Date: (not installed)   Build Host: jonund.mageia.org
Group   : System/Kernel and hardwareSource RPM: (none)
Size: 1843391  License: BSD-like
Signature   : (none)
Packager: oden 
URL : http://www.iozone.org/
Summary : Iozone Filesystem Benchmark
Description :
IOzone is a filesystem benchmark tool. The benchmark generates and
measures a
variety of file operations. Iozone has been ported to many machines
and runs
under many operating systems.

Iozone is useful for performing a broad filesystem analysis of a vendors
computer platform. The benchmark tests file I/O performance for the
following
operations: Read, write, re-read, re-write, read backwards, read strided,
fread, fwrite, random read, pread ,mmap, aio_read, aio_write.

oden  3.414-1.mga3:
+ Revision: 338711
- imported package iozone


http://svnweb.mageia.org/packages/cauldron/iozone3/
So, was there.


Oden? Ping. :-)
--
Damien Lallement
twitter: damsweb - IRC: damsweb/coincoin

Re: [Mageia-dev] [RPM Groups] RPM group change before Beta 2 (Reposted in new thread)

[Barry Jackson]

On 06/01/13 19:21, Balcaen John wrote:


Did you try to simply send an email to Luc Menut, Nicolas Lecureuil or me for
that purpose ?


No, but here is a list.
Maybe some are fixed in svn, but have not been pushed - I don't have 
time to check just now.


audiokonverter
k4guitune
konvertible
kradio
basket
kmplayer
kmplayer-npplayer
kubeplayer

[Mageia-dev] usbdumper - what's the status?

[Oliver Burger]

Hi there,

I have a question from i18n team.
In our soft svn is a "usbdumper" but we don't knoiw, what to do with it.

Is this an "official" Mageia software, that should be translated by i18n 
team or is this just some work i n progress, we can handle with less 
priority?


Thanks,

Oliver

--
Oliver Burger aka obgr_seneca

Mageia contributor

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

[Guillaume Rousse]

Le 06/01/2013 23:04, David Walser a écrit :

In honor of the upcoming version freeze in Cauldron (this week according to 
current planning), I went looking for packages with newer versions available, 
that are NOT seen by our youri tool, and therefore will not be seen here:
http://check.mageia.org/cauldron/updates.html

Because of that, some of you may be interested in some of these packages and be 
unaware that newer versions are available.

I compiled the list over the past two days, and queried the Sophie bot for the 
maintainers, so they're listed below by the IRC log.  Sorry if you're on IRC 
and got pinged 50 times this weekend :o)

As far as why youri missed these,
Just because it is not configured to check those data sources... A 
simple parser for directory content would be enough, as for instance the 
Fedora source, before its optimisation to use repodata content:

http://www.zarb.org/cgi-bin/viewvc.cgi/youri/soft/check/branches/0.10/lib/Youri/Check/Test/Updates/Source/Fedora.pm?revision=2359&view=markup

BTW, the software refered to is 'youri-check', not 'youri'...

--
BOFH excuse #76:

Unoptimized hard drive

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

[Johnny A. Solbu]

On Monday 7. January 2013 09.51, Juan Luis Baptiste wrote:
> Done mines, thanks for the info :)

As have I. :-)=

-- 
Johnny A. Solbu
PGP key ID: 0xFA687324


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

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

[Juan Luis Baptiste]

On Sun, Jan 6, 2013 at 5:04 PM, David Walser  wrote:

> In honor of the upcoming version freeze in Cauldron (this week according
> to current planning), I went looking for packages with newer versions
> available, that are NOT seen by our youri tool, and therefore will not be
> seen here:
> http://check.mageia.org/cauldron/updates.html
>
> Because of that, some of you may be interested in some of these packages
> and be unaware that newer versions are available.
>
> I compiled the list over the past two days, and queried the Sophie bot for
> the maintainers, so they're listed below by the IRC log.  Sorry if you're
> on IRC and got pinged 50 times this weekend :o)
>
>
Done mines, thanks for the info :)

-- 
Juancho

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

[Juan Luis Baptiste]

On Tue, Jan 1, 2013 at 2:44 PM, Thomas Backlund  wrote:

> And glibc-2.17-1 and locales-2.17-1 are now built and should soon
> show up on the mirrors and it should be safe to update then...
>
>
And now on one of my cauldron boxes I can't update glibc, thus blocking the
rest of updates:

The following package has to be removed for others to be upgraded:
glibc-2.17-1.mga3.x86_64
 (in order to install glibc-2.17-1.mga3.x86_64)


installing glibc-devel-2.17-1.mga3.x86_64.rpm
meta-task-3-22.mga3.noarch.rpm rpm-build-4.11.0-0.beta1.7.mga3.x86_64.rpm
lib64rpm3-4.11.0-0.beta1.7.mga3.x86_64.rpm
rpm-4.11.0-0.beta1.7.mga3.x86_64.rpm
python-rpm-4.11.0-0.beta1.7.mga3.x86_64.rpm glibc-2.17-1.mga3.x86_64.rpm
from /var/cache/urpmi/rpms
Preparing...
###
Installation failed:package glibc-6:2.17-1.mga3.x86_64 is already
installed



-- 
Juancho

Re: [Mageia-dev] Help with package

[Juan Luis Baptiste]

On Sat, Jan 5, 2013 at 2:02 AM, Juan Luis Baptiste wrote:

>
>  Got it working with:
>
> for i in `%{_datadir}/warsow/basewsw/*`;
> do
>file=`basename $i`
>ln -sf $i  %{gamelibdir}/basewsw/$file
> done
>
> The game name in the for loop was wrong.
>
>
>
Well, it worked on x86_64, but  on i586 the symlinks are created under
/usr/lib64/games/warsow/basewsw instead of /usr/lib/games/warsow/basewsw
but I don't understand why, it seems that for some reason, the %{_libdir}
macro is expanding to /usr/lib64 on the BS. This is the spec if someone
wants to take a look:

http://svnweb.mageia.org/packages/cauldron/warsow-data/current/SPECS/warsow-data.spec?revision=338836&view=markup

-- 
Juancho