Re: [Mageia-dev] ncurses ABI breakage (Re: [changelog] [RPM] cauldron core/release iftop-0.17-9.mga3)
On 25 September 2012 21:59, Olivier Blin wrote: >> blino 0.17-9.mga3: >> + Revision: 297720 >> - rebuild for new ncurses ABI (broken by #7235) > > Hi, > > After a configuration change in ncurses (from bug #7235), it seems that > the ncurses ABI has been broken. > > Thierry, any plan/roadmap for a mass rebuild of ncurses users? No, will be done when someone will do the mass rebuild for the new build chain
Re: [Mageia-dev] grub2 integration into installer and drakx tools
On 25 September 2012 22:48, Barry Jackson wrote: > We already have a grub2 package which needs integrating into Mageia tools. > > This is beyond my capabilities, so I am calling for developers who are able > to do this work. > > The package already handles kernel updates. > > The installer, drakboot etc. will need some work. send me what a typical config file would look with the corresponding grub1 conf file.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release fatpack-0.9.11-1.mga3
On 26 September 2012 10:21, jquelin wrote: > Description : > no description found Please fix that > jquelin 0.9.11-1.mga3: > + Revision: 297962 > - update to 0.009011
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release perl-App-Module-Locate-0.500.0-1.mga3
On 26 September 2012 10:21, jquelin wrote: > Description : > no description found Please fix that > jquelin 0.500.0-1.mga3: > + Revision: 297943 > - update to 0.5 > - imported package perl-App-Module-Locate
Re: [Mageia-dev] Fwd: Distributor notes about GNOME 3.6.0
'Twas brillig, and Olav Vitters at 25/09/12 21:32 did gyre and gimble: > I just submitted accountsservice 0.6.25. > > The other bugs I guess should be mentioned. We have systemd 189 at the > moment... 192 landing "soon" (built here, just not yet fully tested). If it's ready by tonight I might push it but will double check with Anne/Thomas re ISOs and any problems it may cause. I avoided 190 and 191 deliberately due to some issues that have now been resolved in 192. As well as the bug you listed regarding sessions not closing, I also fixed another bug that caused gdms own session never to exit (due it's use of PulseAudio and PA's systemd-login module which caused a "closing" state deadlock which prevented sessions from fully closing). These patches (in systemd) are all included upstream now. 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] grub2 integration into installer and drakx tools
On 26/09/12 09:10, Thierry Vignaud wrote:
send me what a typical config file would look with the corresponding grub1 conf
file.
I think I can see where you are heading.
Grub2 generates it own grub.cfg using os-prober, so maybe some work not
needed.
Additional entries to the grub2 menu (anything not found by os-prober)
need adding to /etc/grub.d/40_custom and are incuded when the menu is
re-built. If thay are added to grub.cfg they will be overwritten at
kernel update etc.
I have attached grub.cfg and menu.lst from a vbox installation of mga3
running grub2. It is a lot less noisy than those on my desktop.
For basic grub2 commands see my README.Mageia in the package.
Barry
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
load_env
fi
set default="0"
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
if loadfont unicode ; then
set gfxmode=1024x768x32
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=en_GB
insmod gettext
fi
terminal_output gfxterm
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1
6e6a4414-2fff-413b-b224-4675025cb4cf
else
search --no-floppy --fs-uuid --set=root 6e6a4414-2fff-413b-b224-4675025cb4cf
fi
insmod gfxmenu
insmod png
set theme=($root)/boot/grub2/themes/maggy/theme.txt
export theme
set timeout=5
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/10_linux ###
menuentry 'Mageia GNU/Linux' --class mageia --class gnu-linux --class gnu
--class os $menuentry_id_option
'gnulinux-simple-6e6a4414-2fff-413b-b224-4675025cb4cf' {
set gfxpayload=text
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1
6e6a4414-2fff-413b-b224-4675025cb4cf
else
search --no-floppy --fs-uuid --set=root
6e6a4414-2fff-413b-b224-4675025cb4cf
fi
echo'Loading Linux desktop ...'
linux /boot/vmlinuz-desktop
root=UUID=6e6a4414-2fff-413b-b224-4675025cb4cf ro splash
echo'Loading initial ramdisk ...'
initrd /boot/initrd-desktop.img
}
submenu 'Advanced options for Mageia GNU/Linux' $menuentry_id_option
'gnulinux-advanced-6e6a4414-2fff-413b-b224-4675025cb4cf' {
menuentry 'Mageia GNU/Linux, with Linux desktop' --class mageia --class
gnu-linux --class gnu --class os $menuentry_id_option
'gnulinux-desktop-advanced-6e6a4414-2fff-413b-b224-4675025cb4cf' {
set gfxpayload=text
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1
6e6a4414-2fff-413b-b224-4675025cb4cf
else
search --no-floppy --fs-uuid --set=root
6e6a4414-2fff-413b-b224-4675025cb4cf
fi
echo'Loading Linux desktop ...'
linux /boot/vmlinuz-desktop
root=UUID=6e6a4414-2fff-413b-b224-4675025cb4cf ro splash
echo'Loading initial ramdisk ...'
initrd /boot/initrd-desktop.img
}
menuentry 'Mageia GNU/Linux, with Linux 3.5.4-desktop-1.mga3' --class
mageia --class gnu-linux --class gnu --class os $menuentry_id_option
'gnulinux-3.5.4-desktop-1.mga3-advanced-6e6a4414-2fff-413b-b224-4675025cb4cf' {
set gfxpayload=text
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1
6e6a4414-2fff-413b-b224-4675025cb4cf
else
search --no-floppy --
Re: [Mageia-dev] grub2 integration into installer and drakx tools
On 25/09/12 23:17, AL13N wrote: should this be made as an alternative to lilo, grub, grub-text ? to add grub2 to that list? and make it actually generate proper code? That may be a good way to introduce grub2 whist keeping grub as a fall-back Not sure what you mean about "proper code" or are we obsoleting grub1? I guess that will be the long term aim, but I think mga3 is maybe too soon now. imho, perhaps it's better to add grub2 and grub2-text to that list... so we don't have to handle conversions... Yes. Barry
[Mageia-dev] Fwd: Re: M3 won't complete boot after update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Colin, I sent this last evening, but I haven't seen it on-list. For some reason a fair number of my messages don't get through. Could it be that the digital signing worries the filters? Anne - Original Message Subject: Re: [Mageia-dev] M3 won't complete boot after update Date: Tue, 25 Sep 2012 16:37:20 +0100 From: Anne Wilson To: Mageia development mailing-list On 25/09/12 15:41, Colin Guthrie wrote: > 'Twas brillig, and Anne Wilson at 25/09/12 15:02 did gyre and > gimble: >> Sent yesterday, but not seen on-list, so apologies if this is a >> duplicate. >> >> I finally got around to connecting my netbook, which has been >> running Cauldron for some time. This was fully up to date before >> my holidays, and apart from the recent display problem (which as >> Angelo Naselli suspected, is a KDE problem) it has behaved >> beautifully. Today, though, needed almost 3 weeks worth of >> updates, and when it finished, it won't boot. >> >> There are obviously problems with my remote mounts, but we are >> talking in detail about that on another thread. Mostly things >> look to be going well up to that stage, then I see messages like >> >> Started RPC bind service Reached target Remote File Systems >> (Pre). Mounting /mnt/QNAS-Lydgate-Data... Mounting >> /mnt/borg2/home... Mounting /mnt/borg2_Data1... Reached target >> RPC Port Mapper. Failed to mount /mnt/QNAS-Lydgate-Data. See >> systemctl status /mnt-QNAS\x2dLydgate\x2dData.mount for details. >> (other similar pairs of lines) Dependency failed for Remote >> File Systems >> >> After these lines, suddenly two of the QNAS mounts (one of which >> is /mnt/QNAS/Lydgate-Data mentioned above) do succeed. The two >> borg2 mounts still fail, as do some of the other QNAS mounts. >> >> A few more lines, and all looks reasonable, until >> >> [FAILED] Failed to start Wait for Plymouth Boot Screen to Quit >> >> then Reached target Multi-User Reached target Graphical >> Interface >> >> and there it freezes. >> >> Later: >> >> I tried booting from the older kernel. On the graphical screen, >> it appears to get a lot further, 5 bubbles instead of 2, but >> when I tried it again watching the messages it appears to follow >> the same path as the new kernel boot, ending at the same place. >> >> Interestingly, though, the nfs mount that succeeds, after saying >> it had failed, was not the same one as yesterdays. Still, >> that's probably a side-issue. >> >> The situation now is that I appear to have a completely unusable >> M3. The line >> >> [DEPEND] Dependency failed for Remote File Systems >> >> is obviously important. Not knowing what that dependency is, I >> don't know whether it could do more damage than failing to mount >> remote systems. It doesn't sound likely, but > > If the remote mounts are not critical, just add nofail to the fstab > options. > > I suspect strongly that any issues with these mounts is entirely > separate to the actual graphical boot. > Agreed. Adding nofail makes no difference. I've also tried removing all options, down to a minimum defaults. However, they shouldn't stop boot. FWIW, I'm still seeing that message about a dependency failure for remote file systems. > Personally, I was seeing crashes with qt4... perhaps try switching > to gdm as you're DM and see if the graphical boot comes up OK, > that way we could see easily if it's something high level. > No, gdm doesn't get that far either. > Also you could try and look and see what systemctl status > prefdm.service says to you (you might need to switch to tty2). > prefdm.service - Display Manager Loaded: loaded (/usr/lib/systemd/system/prefdm.service: static) Active: inactive (dead) CGroup: name=systemd:system/prefdm.service (This from looking over my shoulder, so ignore any typos) I'll worry about the mounts later - the first thing is to get the system back :-) Anne - - -- Need KDE help? Try http://userbase.kde.org or http://forum.kde.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlBjGIIACgkQj93fyh4cnBdBiACaA6FhH7+EsfztkBRG+74MCc0p Su4An194QfnXgW/onYCYArD0GI8BjueG =WbBO -END PGP SIGNATURE-
Re: [Mageia-dev] RPM groups policy
On Tue, 25 Sep 2012, Pierre-Malo Deniélou wrote: > Dear packagers, > > Tonight, following the packagers meeting, we agreed on a new RPM group > policy. > > The current policy is described at: > http://wiki.mageia.org/en/RPM_groups_policy > > The new policy is presented at: > http://wiki.mageia.org/en/Feature:RPMGroupRevamp > > This change in policy means that I will take the following actions by > the end of the week: > * update the wikipage http://wiki.mageia.org/en/RPM_groups_policy > * patch rpmlint to refuse new packages that do not follow the new > policy (I will send another email to -dev just before submitting > the new rpmlint). On build system, we also need to update youri to use the old rpmlint config for already released distributions.
Re: [Mageia-dev] Fwd: Re: M3 won't complete boot after update
On 26.09.2012 18:00, Anne Wilson wrote: > Colin, I sent this last evening, but I haven't seen it on-list. For > some reason a fair number of my messages don't get through. Could it > be that the digital signing worries the filters? > > Anne > I can see your (previous) mail, just like I saw the previous mail you resend. Are you using GMail?
Re: [Mageia-dev] Fwd: Re: M3 won't complete boot after update
2012/9/26 Jani Välimaa : > On 26.09.2012 18:00, Anne Wilson wrote: >> Colin, I sent this last evening, but I haven't seen it on-list. For >> some reason a fair number of my messages don't get through. Could it >> be that the digital signing worries the filters? >> >> Anne >> > > I can see your (previous) mail, just like I saw the previous mail you > resend. > > Are you using GMail? I did not see the previous mail, I use gmail. But I see that other people (like Marja) use to gpg-sign their mails to the lists, so this can't be the cause. -- wobo
Re: [Mageia-dev] M3 won't complete boot after update
On 24.09.2012 22:21, Anne Wilson wrote: > I finally got around to connecting my netbook, which has been running > Cauldron for some time. This was fully up to date before my holidays, > and apart from the recent display problem (which as Angelo Naselli > suspected, is a KDE problem) it has behaved beautifully. Today, > though, needed almost 3 weeks worth of updates, and when it finished, > it won't boot. > > There are obviously problems with my remote mounts, but we are talking > in detail about that on another thread. Mostly things look to be > going well up to that stage, then I see messages like > > Started RPC bind service > Reached target Remote File Systems (Pre). > Mounting /mnt/QNAS-Lydgate-Data... > Mounting /mnt/borg2/home... > Mounting /mnt/borg2_Data1... > Reached target RPC Port Mapper. > Failed to mount /mnt/QNAS-Lydgate-Data. > See systemctl status /mnt-QNAS\x2dLydgate\x2dData.mount for details. > (other similar pairs of lines) > Dependency failed for Remote File Systems > > After these lines, suddenly two of the QNAS mounts (one of which is > /mnt/QNAS/Lydgate-Data mentioned above) do succeed. The two borg2 > mounts still fail, as do some of the other QNAS mounts. > > A few more lines, and all looks reasonable, until > > [FAILED] Failed to start Wait for Plymouth Boot Screen to Quit > > then > Reached target Multi-User > Reached target Graphical Interface > > and there it freezes. > > Anne > Anne, can you see this now?
Re: [Mageia-dev] Fwd: Re: M3 won't complete boot after update
On 26.09.2012 18:29, Wolfgang Bornath wrote: > 2012/9/26 Jani Välimaa : >> On 26.09.2012 18:00, Anne Wilson wrote: >>> Colin, I sent this last evening, but I haven't seen it on-list. For >>> some reason a fair number of my messages don't get through. Could it >>> be that the digital signing worries the filters? >>> >>> Anne >>> >> >> I can see your (previous) mail, just like I saw the previous mail you >> resend. >> >> Are you using GMail? > > I did not see the previous mail, I use gmail. But I see that other > people (like Marja) use to gpg-sign their mails to the lists, so this > can't be the cause. > I've seen that you can't see your own mail to ML when using GMail with some mail client (like TB). And when replying to mails on MLs, you can see your own mail only if you chosed from settings to do a local copy of sent mail to the folder where the original mail is located. Dunno if this is a feature of GMail or some misconfiguration from my side.
Re: [Mageia-dev] [changelog] [RPM] cauldron nonfree/release drakx-installer-images-1.83-1.mga3.nonfree
Thierry Vignaud writes: > On 17 September 2012 21:37, Olivier Blin wrote: >>> tv 1.83-1.mga3: >>> + Revision: 295551 >>> - fix modules.order so that cciss got detected (mga#5833) >>> - use new hotplug (mga#6323) >> >> You are duplicating (with full knowledge it seems) the /sbin/hotplug >> script written by make_boot_img. As you noticed, it relied on /bin/sh. >> The shell used to be provided not only for KA, but also to provide a >> convenience shell in stage1. >> Couldn't we add a shell back? > > For years, we only add this shell if DEBUGSTAGE1 was set. > This is still the case > Then for a couple years, stage1 got bloated with KA stuff including busybox > (and thus a shell) by Antoine. But when KA has been merged in stage1, we meant to keep the shell. > We're just back at prior state. > If you need to debug, you can still rebuild stage1 package with the debug > option. It's not only me, it is also to ease reporting bugs about stage1. Otherwise, there is no way to get a look at the debug log from stage1. -- Olivier Blin - blino
Re: [Mageia-dev] ncurses ABI breakage (Re: [changelog] [RPM] cauldron core/release iftop-0.17-9.mga3)
Thierry Vignaud writes: > On 25 September 2012 21:59, Olivier Blin wrote: >>> blino 0.17-9.mga3: >>> + Revision: 297720 >>> - rebuild for new ncurses ABI (broken by #7235) >> >> Hi, >> >> After a configuration change in ncurses (from bug #7235), it seems that >> the ncurses ABI has been broken. >> >> Thierry, any plan/roadmap for a mass rebuild of ncurses users? > > No, will be done when someone will do the mass rebuild for the new > build chain It would be better to rebuild all ncurses programs before alpha2, because this change broke most of them. -- Olivier Blin - blino
Re: [Mageia-dev] wine [293158] disable 'fortify' to prevent crashes (mga#6723)
12.09.2012 22:13, r...@mageia.org kirjoitti: > Log Message > > disable 'fortify' to prevent crashes (mga#6723) [... > Modified: cauldron/wine/current/SPECS/wine.spec > === > --- cauldron/wine/current/SPECS/wine.spec 2012-09-12 19:02:56 UTC (rev > 293157) > +++ cauldron/wine/current/SPECS/wine.spec 2012-09-12 19:13:38 UTC (rev > 293158) > @@ -25,7 +25,7 @@ > Name:wine > Version: 1.5.12 > %define pre 0 > -%define rel 1 > +%define rel 2 > %if %pre > Release: %mkrel 0.%pre.%rel > %define o_ver%version-%pre > @@ -245,6 +245,10 @@ > > %build > autoreconf > +# disable fortify as it breaks wine > +# http://bugs.winehq.org/show_bug.cgi?id=24606#c22 > +# http://bugs.winehq.org/show_bug.cgi?id=25073 > +export CFLAGS="`echo $RPM_OPT_FLAGS | sed -e 's/-Wp,-D_FORTIFY_SOURCE=2//'` > -Wno-error" > %configure2_5x --with-x \ > --with-pulse \ > %ifarch x86_64 Strange, wine configure script already disables fortify since 1.3.6 (Oct 2010), so something weird must be going on: http://source.winehq.org/git/wine.git/?a=commitdiff;h=105793bff75f6a869bd9ccfb390b2f88fa861235 ... ok, it is actually because we use -Wp,-D_FORTIFY_SOURCE=2 instead of -D_FORTIFY_SOURCE=2 and -U_FORTIFY_SOURCE=2 fails to override the former. So I sent a patch to wine-patches@, no idea if they agree: http://www.winehq.org/pipermail/wine-patches/2012-September/118257.html Also, a cleaner way to disable fortify is %define _fortify_cflags %nil -- Anssi Hannula
Re: [Mageia-dev] rpmrc [5221] build with -fPIC on x86_64 too (pok, mdv)
26.07.2012 13:53, r...@mageia.org kirjoitti:
> Author
> tv
> Log Message
>
> build with -fPIC on x86_64 too (pok, mdv)
Why?
> Modified Paths
>
> * rpm/rpm-setup/trunk/NEWS <#rpmrpmsetuptrunkNEWS>
> * rpm/rpm-setup/trunk/rpmrc.in <#rpmrpmsetuptrunkrpmrcin>
>
> Modified: rpm/rpm-setup/trunk/NEWS
> ===
> --- rpm/rpm-setup/trunk/NEWS 2012-07-26 10:37:09 UTC (rev 5220)
> +++ rpm/rpm-setup/trunk/NEWS 2012-07-26 10:53:42 UTC (rev 5221)
> @@ -1,3 +1,5 @@
> +- build with -fPIC on x86_64 too (pok, mdv)
> +
> Version 1.149.1 - 25 Jul 2012, by Thierry Vignaud
> - merge patches from package repository:
>o fix build with rpm-4.9+
>
> Modified: rpm/rpm-setup/trunk/rpmrc.in
> ===
> --- rpm/rpm-setup/trunk/rpmrc.in 2012-07-26 10:37:09 UTC (rev 5220)
> +++ rpm/rpm-setup/trunk/rpmrc.in 2012-07-26 10:53:42 UTC (rev 5221)
> @@ -14,9 +14,9 @@
> optflags: pentium3 %{__common_cflags_with_ssp} -fomit-frame-pointer
> -march=pentium3 -fasynchronous-unwind-tables
> optflags: pentium4 %{__common_cflags_with_ssp} -fomit-frame-pointer
> -march=pentium4 -fasynchronous-unwind-tables
>
> -optflags: x86_64 %{__common_cflags_with_ssp}
> -optflags: amd64 %{__common_cflags_with_ssp}
> -optflags: ia32e %{__common_cflags_with_ssp}
> +optflags: x86_64 %{__common_cflags_with_ssp} -fPIC
> +optflags: amd64 %{__common_cflags_with_ssp} -fPIC
> +optflags: ia32e %{__common_cflags_with_ssp} -fPIC
>
> optflags: ia64 %{__common_cflags}
--
Anssi Hannula
Re: [Mageia-dev] M3 won't complete boot after update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/09/2012 16:44, Jani Välimaa wrote: > On 24.09.2012 22:21, Anne Wilson wrote: >> I finally got around to connecting my netbook, which has been >> running Cauldron for some time. This was fully up to date before >> my holidays, and apart from the recent display problem (which as >> Angelo Naselli suspected, is a KDE problem) it has behaved >> beautifully. Today, though, needed almost 3 weeks worth of >> updates, and when it finished, it won't boot. >> >> There are obviously problems with my remote mounts, but we are >> talking in detail about that on another thread. Mostly things >> look to be going well up to that stage, then I see messages like >> >> Started RPC bind service Reached target Remote File Systems >> (Pre). Mounting /mnt/QNAS-Lydgate-Data... Mounting >> /mnt/borg2/home... Mounting /mnt/borg2_Data1... Reached target >> RPC Port Mapper. Failed to mount /mnt/QNAS-Lydgate-Data. See >> systemctl status /mnt-QNAS\x2dLydgate\x2dData.mount for details. >> (other similar pairs of lines) Dependency failed for Remote >> File Systems >> >> After these lines, suddenly two of the QNAS mounts (one of which >> is /mnt/QNAS/Lydgate-Data mentioned above) do succeed. The two >> borg2 mounts still fail, as do some of the other QNAS mounts. >> >> A few more lines, and all looks reasonable, until >> >> [FAILED] Failed to start Wait for Plymouth Boot Screen to Quit >> >> then Reached target Multi-User Reached target Graphical >> Interface >> >> and there it freezes. >> >> Anne >> > > Anne, can you see this now? Jani, I'm not quite sure what you are asking, but after trying everything Colin suggested, nothing has changed. Anne -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlBjXXcACgkQj93fyh4cnBdo/gCgiY7ig7PO7+ttgbOPccDu2TZe j+gAniI/jUgo6L+9nOUUGjvIbYzQvz9n =kZCw -END PGP SIGNATURE-
Re: [Mageia-dev] Fwd: Re: M3 won't complete boot after update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/09/2012 16:24, Jani Välimaa wrote: > On 26.09.2012 18:00, Anne Wilson wrote: >> Colin, I sent this last evening, but I haven't seen it on-list. >> For some reason a fair number of my messages don't get through. >> Could it be that the digital signing worries the filters? >> >> Anne >> > > I can see your (previous) mail, just like I saw the previous mail > you resend. > > Are you using GMail? Hmm - yes. Just realised that my KDE alias does go through GMail, yet some of the messages from me get displayed in TBird, but not others. Strange - and difficult to follow threads. Thanks for prompting me. Anne -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlBjXjMACgkQj93fyh4cnBdfkACfQzD17LeWo00DCfLe30cajRx0 SocAoILAyiH1DjjK1yTyNmy26Pf7YmNr =+Qq6 -END PGP SIGNATURE-
Re: [Mageia-dev] rpmrc [5221] build with -fPIC on x86_64 too (pok, mdv)
On 26 September 2012 20:30, Anssi Hannula wrote: >> Author >> tv > >> Log Message >> >> build with -fPIC on x86_64 too (pok, mdv) > > Why? "-fPIC should already be used on x86_64 or you'll get sooner or later in troubles (for instance when linking libs). I think that any sane build script should already default to -fPIC on x86_64 but some other weird build script may not." (rtp)
Re: [Mageia-dev] Fwd: Re: M3 won't complete boot after update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/09/2012 17:05, Jani Välimaa wrote: > On 26.09.2012 18:29, Wolfgang Bornath wrote: >> 2012/9/26 Jani Välimaa : >>> On 26.09.2012 18:00, Anne Wilson wrote: Colin, I sent this last evening, but I haven't seen it on-list. For some reason a fair number of my messages don't get through. Could it be that the digital signing worries the filters? Anne >>> >>> I can see your (previous) mail, just like I saw the previous >>> mail you resend. >>> >>> Are you using GMail? >> >> I did not see the previous mail, I use gmail. But I see that >> other people (like Marja) use to gpg-sign their mails to the >> lists, so this can't be the cause. >> > > I've seen that you can't see your own mail to ML when using GMail > with some mail client (like TB). And when replying to mails on MLs, > you can see your own mail only if you chosed from settings to do a > local copy of sent mail to the folder where the original mail is > located. > > Dunno if this is a feature of GMail or some misconfiguration from > my side. It's GMail, and there doesn't seem to be any way to avoid it. I'll check configurations so that the Sent message stays in the folder with the thread, which at least will help me follow the thread. Thanks for everyone's patience. Anne -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlBjXpMACgkQj93fyh4cnBdM+QCcCGtPbIYk1cmECvgDCOblBEbW ZggAoIlcbkRdAFQYT/TZ4SGmKgIHMx3i =hVxA -END PGP SIGNATURE-
[Mageia-dev] ANNOUNCE: RPM group Policy change taking effect
Dear fellow packagers, In a few minutes, I will upload a new rpmlint-mageia-policy package that implements the new RPM group policy. Normally, packages that do not follow the new RPM groups will be rejected from the build system. I advise you to run rpmlint on your RPMs, SRPMs or spec files before submtting. The new RPM policy can be consulted at: https://wiki.mageia.org/en/RPM_groups_policy In a nutshell, the changes are: - Remove Books/* -> everything in Documentation - Add several Development/* to reduce Development/Other - Add Games/Shooter to reduce Games/Arcade and Games/Other - Split Office into Office/Dictionary, Office/Finance, ... - Split Sound into Sound/Editors and Convertors, Sound/Midi, ... - Split Video into Video/Editors and Convertors, Video/Players, ... - Split Graphics into Graphics/3D, Graphics/Editors, ... - Split Communications into Communications/Bluetooth, Communications/Fax, ... I will start collecting the list of packages that need to change group soon. I will write this list about what changes are urgent (current bugs) and what changes are necessary with respect to the new policy. So, all of us should feel free to start adapting our packages to the new policy :-). Cheers, -- Malo
Re: [Mageia-dev] RPM groups policy
On Tue, 25 Sep 2012 23:43:50 +0100 Pierre-Malo Deniélou wrote: > Tonight, following the packagers meeting, we agreed on a new RPM group > policy. > > The current policy is described at: > http://wiki.mageia.org/en/RPM_groups_policy > > The new policy is presented at: > http://wiki.mageia.org/en/Feature:RPMGroupRevamp What about xdg menu compliance? Charles -- Yow! I want to mail a bronzed artichoke to Nicaragua! -- Mageia release 3 (Cauldron) for x86_64$ On SuperSizehttp://www.eslrahc.com Registered Linux user #182463 3.5.4-tmb-server-1.mga3 x86_64 -- signature.asc Description: PGP signature
Re: [Mageia-dev] RPM groups policy
Le 26/09/12 22:09,Charles A Edwards nous adresse ces quelques mots : > On Tue, 25 Sep 2012 23:43:50 +0100 > Pierre-Malo Deniélou wrote: > >> Tonight, following the packagers meeting, we agreed on a new RPM group >> policy. >> >> The current policy is described at: >> http://wiki.mageia.org/en/RPM_groups_policy >> >> The new policy is presented at: >> http://wiki.mageia.org/en/Feature:RPMGroupRevamp > > > What about xdg menu compliance? There is already a policy in place, and automated checks that enforce it. Everyone seems happy with it, so it does not change :-). https://wiki.mageia.org/en/Packaging_guidelines#Desktop_files However, if you feel that some packages are in the wrong menu category, it's a bug that you should report. Cheers, -- Malo
Re: [Mageia-dev] RPM groups policy
On Wed, 26 Sep 2012 22:17:29 +0100 Pierre-Malo Deniélou wrote: > >> The current policy is described at: > >> http://wiki.mageia.org/en/RPM_groups_policy > >> > >> The new policy is presented at: > >> http://wiki.mageia.org/en/Feature:RPMGroupRevamp > > > > > > What about xdg menu compliance? > > There is already a policy in place, and automated checks that enforce > it. Everyone seems happy with it, so it does not change :-). Yes, but you will now be creating entries that Are Not registered categories http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html#category-registry Charles -- I have no doubt that it is a part of the destiny of the human race, in its gradual improvement, to leave off eating animals. -- Thoreau -- Mageia release 3 (Cauldron) for x86_64$ On SuperSizehttp://www.eslrahc.com Registered Linux user #182463 3.5.4-tmb-server-1.mga3 x86_64 -- signature.asc Description: PGP signature
Re: [Mageia-dev] RPM groups policy
27.09.2012 00:27, Charles A Edwards kirjoitti: > On Wed, 26 Sep 2012 22:17:29 +0100 > Pierre-Malo Deniélou wrote: > The current policy is described at: http://wiki.mageia.org/en/RPM_groups_policy The new policy is presented at: http://wiki.mageia.org/en/Feature:RPMGroupRevamp >>> >>> >>> What about xdg menu compliance? >> >> There is already a policy in place, and automated checks that enforce >> it. Everyone seems happy with it, so it does not change :-). > > Yes, but you will now be creating entries that Are Not > registered categories RPM groups are not related to menu categories in any way. -- Anssi Hannula
Re: [Mageia-dev] RPM groups policy
On Wednesday 26 September 2012 23:27, Charles A Edwards wrote: > Yes, but you will now be creating entries that Are Not > registered categories > > http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html#category-registry Perhaps I'm slow, but I thought there was a difference between RPM groups and desktop menu groups. So this shouldn't be an issiue. -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] RPM groups policy
Le 26/09/12 22:42,Anssi Hannula nous adresse ces quelques mots : > 27.09.2012 00:27, Charles A Edwards kirjoitti: >> On Wed, 26 Sep 2012 22:17:29 +0100 >> Pierre-Malo Deniélou wrote: >> > The current policy is described at: > http://wiki.mageia.org/en/RPM_groups_policy > > The new policy is presented at: > http://wiki.mageia.org/en/Feature:RPMGroupRevamp What about xdg menu compliance? >>> >>> There is already a policy in place, and automated checks that enforce >>> it. Everyone seems happy with it, so it does not change :-). >> >> Yes, but you will now be creating entries that Are Not >> registered categories > > RPM groups are not related to menu categories in any way. The RPM groups are seen only in rpmdrake (and smart and Mageia App Db), as far as I understand. And they are package-based. .desktop files (which are for menu entries) are for the desktop applications. So one package can have several .desktop files (for each application it contains) or none. They are in effect unrelated. There was however a proposal to base the new RPM groups on the freedektop standard for menu classification, but it seems not to be a possibility (mainly because packages <> applications). Cheers, -- Malo
Re: [Mageia-dev] RPM groups policy
On Thu, 27 Sep 2012 00:42:58 +0300 Anssi Hannula wrote: > > Yes, but you will now be creating entries that Are Not > > registered categories > > RPM groups are not related to menu categories in any way. I know the the rpm group is different. Are you saying that No packager will try to create or change a menu entry to reflect the new rpm groups? Example: 'Alien arena' in Games/Shooter instead of Games/Other Charles -- Gathering threads always break in the middle -- Murphy's Laws of Sewing n°18 -- Mageia release 3 (Cauldron) for x86_64$ On SuperSizehttp://www.eslrahc.com Registered Linux user #182463 3.5.4-tmb-server-1.mga3 x86_64 -- signature.asc Description: PGP signature
Re: [Mageia-dev] RPM groups policy
Le 26/09/12 22:58,Charles A Edwards nous adresse ces quelques mots : > On Thu, 27 Sep 2012 00:42:58 +0300 > Anssi Hannula wrote: > >>> Yes, but you will now be creating entries that Are Not >>> registered categories >> >> RPM groups are not related to menu categories in any way. > > > I know the the rpm group is different. > > Are you saying that No packager will try to create or change > a menu entry to reflect the new rpm groups? Exactly. > Example: > 'Alien arena' in Games/Shooter instead of Games/Other The RPM group of Alien arena will change to Games/Shooter, but its desktop file is not supposed to change. I understand your point, but there will always be mismatches between the two categories, since the two purposes are different. -- Malo
Re: [Mageia-dev] ANNOUNCE: RPM group Policy change taking effect
Le 26/09/12 22:00,Pierre-Malo Deniélou nous adresse ces quelques mots : > Dear fellow packagers, > > In a few minutes, I will upload a new rpmlint-mageia-policy package that > implements the new RPM group policy. Normally, packages that do not > follow the new RPM groups will be rejected from the build system. > I advise you to run rpmlint on your RPMs, SRPMs or spec files before > submtting. Thanks to boklm the checks are now in place and the new policy takes effect. Cheers, -- Malo
Re: [Mageia-dev] Fwd: Re: M3 won't complete boot after update
Op woensdag 26 september 2012 20:57:43 schreef Anne Wilson: > On 26/09/2012 16:24, Jani Välimaa wrote: > > On 26.09.2012 18:00, Anne Wilson wrote: > >> Colin, I sent this last evening, but I haven't seen it on-list. > >> For some reason a fair number of my messages don't get through. > >> Could it be that the digital signing worries the filters? > >> > >> Anne > > > > I can see your (previous) mail, just like I saw the previous mail > > you resend. > > > > Are you using GMail? > > Hmm - yes. Just realised that my KDE alias does go through GMail, yet > some of the messages from me get displayed in TBird, but not others. > Strange - and difficult to follow threads. Thanks for prompting me. > > Anne this is normal behavior for gmail, it's why i stopped using it: it works like this, if you are on a mailing list, and it ends up at google, and you're using the gmail imap gateway, you will not be getting your own message, thus not knowing if it was there or not, and your threading will break. same thing with aliasses. i filed a bug but it is a "feature"
Re: [Mageia-dev] new fonts?
On 25/09/12 21:54, David Walser wrote: This topic came up in the packagers meeting. It was stated that: - the change was initiated by Thierry Vignaud (tv) - the change was also done in Fedora Ah, thanks for the infos! Although I think the first reason is a good reason (tv), the second is not. Have you seen their logo, it looks like facebook :))) Possibilities: 1) revert this change 2) someone put their foot down and decide we're sticking with this Also, if it's really that bothersome for some people, maybe it would be good to have an easy way for users to change this locally. Personally 1); but 2) + a user-friendly way to change it is good too. cheers, chris.
