Re: [Mageia-dev] [changelog] [RPM] cauldron core/release libetpan-1.1-5.mga3
On Tue, 31 Jul 2012 01:11:13 +0200 (CEST) fwang wrote: > fwang 1.1-5.mga3: > + Revision: 276308 > - rebuild for db-5.3 Did you patch configure.ac so that the build dependency is for db5.3 and not still 5.2 Charles -- Gibble, Gobble, we ACCEPT YOU ... -- Mageia release 3 (Cauldron) for x86_64$ On SuperSizehttp://www.eslrahc.com Registered Linux user #182463 3.5.0-server-1.mga3 x86_64 -- signature.asc Description: PGP signature
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release db53-5.3.21-1.mga3
On Mon, 30 Jul 2012 19:50:29 +0200 (CEST)
tv wrote:
> Name: db53 Relocations: (not
> relocatable) Version : 5.3.21Vendor:
> Mageia.Org Release : 1.mga3Build Date:
> Mon Jul 30 19:36:25 2012 Install Date: (not installed)
> Build Host: ecosse.mageia.org Group :
> System/Libraries Source RPM: (none) Size:
> 35083441 License: BSD Signature : (none)
> Packager: tv
%package -n %{libdbnssdev}
contains the conflict
Conflicts: db_nss-devel < %{__soversion}
but neither this version nor previous version of %{libdbnssdev}
provided db_nss-devel
Conflict should now be
Conflicts: db5_nss-devel < %{__soversion}
Charles
--
Suddenly, Professor Liebowitz realizes he has come to the seminar
without his duck ...
--
Mageia release 3 (Cauldron) for x86_64$
On SuperSizehttp://www.eslrahc.com
Registered Linux user #182463
3.5.0-server-1.mga3 x86_64
--
signature.asc
Description: PGP signature
Re: [Mageia-dev] [RFC] remove support for /etc/rpm/macros.d/*.macros
On Mon, Jul 30, 2012 at 06:55:01PM +0200, nicolas vigier wrote: > > Is the installer supposed to modify /etc/rpm/macros ?... > > Yes, the install (and maybe draklocale) modify /etc/rpm/macros : > http://svnweb.mageia.org/soft/drakx/trunk/perl-install/lang.pm?revision=4265&view=markup#l1100 > > Maybe this should be changed to modify/create /etc/rpm/macros.install_langs > instead ? Seems like a good change to me. -- Regards, Olav
Re: [Mageia-dev] [RFC] remove support for /etc/rpm/macros.d/*.macros
On Mon, 30 Jul 2012, Olivier Thauvin wrote: > * Olivier Blin (mag...@blino.org) wrote: > > Olav Vitters writes: > > > > > On Mon, Jul 30, 2012 at 04:47:54PM +0200, Thierry Vignaud wrote: > > >> I would like to drop that patch from rpm (one less to maintain). > > >> That means basically renaming files: > > >> /etc/rpm/macros.d/foobar.macros => /etc/rpm/macros/macros.foobar > > > [..] > > >> WDYT? > > > > > > I thought latest idea that /etc is solely for the sysadmin, so shouldn't > > > above be: > > > /usr/rpm/macros/macros.foobar > > > > Right, these macros are not supposed to be edited by the sysadmin, we > > could even use /usr/lib/rpm/macros. > > (we already use this for perl, php, python, systemd) > > But I never edited my /etc/rpm/macros. It has been modified by installer > long time ago and the /etc/rpm/macros.rpmnew has been created by an > update of rpm. > > Is the installer supposed to modify /etc/rpm/macros ?... Yes, the install (and maybe draklocale) modify /etc/rpm/macros : http://svnweb.mageia.org/soft/drakx/trunk/perl-install/lang.pm?revision=4265&view=markup#l1100 Maybe this should be changed to modify/create /etc/rpm/macros.install_langs instead ? We can also remove /etc/rpm/macros from rpm package.
Re: [Mageia-dev] [RFC] remove support for /etc/rpm/macros.d/*.macros
On Mon, 30 Jul 2012, Olivier Thauvin wrote: > * nicolas vigier (bo...@mars-attacks.org) wrote: > > On Mon, 30 Jul 2012, Thierry Vignaud wrote: > > > > > Hi > > > > > > For years, we patch our rpm in order to support for /etc/rpm/macros.d > > > (very old compat with rpm-4.4). > > > Upstream refused to merge it as "/etc/rpm/ is a "macros.d" style > > > directory already, except in name". > > > > In a previous mail Colin was suggesting moving all macro files to > > /usr/lib/rpm/ instead of /etc/rpm : > > http://www.mageia.org/pipermail/mageia-dev/2012-July/017654.html > > > > I think shipping macro files somewhere in /usr/lib/rpm with users using > > files in /etc/rpm to overwrite macros would be nice. Unfortunately this > > probably requires an other patch to rpm. > > > > Maybe a patch to read /usr/lib/rpm/mageia/macros.* could be accepted > > upstream ? > > Ask for /usr/lib/rpm/mageia/*.macros instead ! *.macros would be better than macros.*, but macros.* is more consistent with what is already done in /etc/rpm. In /usr/lib/rpm/* we don't have the problem with *.rpmnew files because we don't have to flag them as configuration, as people are not supposed to edit them.
Re: [Mageia-dev] [RFC] remove support for /etc/rpm/macros.d/*.macros
* Olivier Blin (mag...@blino.org) wrote: > Olav Vitters writes: > > > On Mon, Jul 30, 2012 at 04:47:54PM +0200, Thierry Vignaud wrote: > >> I would like to drop that patch from rpm (one less to maintain). > >> That means basically renaming files: > >> /etc/rpm/macros.d/foobar.macros => /etc/rpm/macros/macros.foobar > > [..] > >> WDYT? > > > > I thought latest idea that /etc is solely for the sysadmin, so shouldn't > > above be: > > /usr/rpm/macros/macros.foobar > > Right, these macros are not supposed to be edited by the sysadmin, we > could even use /usr/lib/rpm/macros. > (we already use this for perl, php, python, systemd) But I never edited my /etc/rpm/macros. It has been modified by installer long time ago and the /etc/rpm/macros.rpmnew has been created by an update of rpm. Is the installer supposed to modify /etc/rpm/macros ?... -- Olivier Thauvin CNRS - LATMOS ♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖ pgptqP5309qj7.pgp Description: PGP signature
Re: [Mageia-dev] [RFC] remove support for /etc/rpm/macros.d/*.macros
On Mon, 30 Jul 2012, Olivier Blin wrote: Olav Vitters writes: On Mon, Jul 30, 2012 at 04:47:54PM +0200, Thierry Vignaud wrote: I would like to drop that patch from rpm (one less to maintain). That means basically renaming files: /etc/rpm/macros.d/foobar.macros => /etc/rpm/macros/macros.foobar [..] WDYT? I thought latest idea that /etc is solely for the sysadmin, so shouldn't above be: /usr/rpm/macros/macros.foobar Right, these macros are not supposed to be edited by the sysadmin, we could even use /usr/lib/rpm/macros. (we already use this for perl, php, python, systemd) They are not automatically included it seems (consistent with earlier posted code from rpm). Christiaan
Re: [Mageia-dev] [RFC] remove support for /etc/rpm/macros.d/*.macros
On Mon, 30 Jul 2012, Olivier Blin wrote:
> Olav Vitters writes:
>
> > On Mon, Jul 30, 2012 at 04:47:54PM +0200, Thierry Vignaud wrote:
> >> I would like to drop that patch from rpm (one less to maintain).
> >> That means basically renaming files:
> >> /etc/rpm/macros.d/foobar.macros => /etc/rpm/macros/macros.foobar
> > [..]
> >> WDYT?
> >
> > I thought latest idea that /etc is solely for the sysadmin, so shouldn't
> > above be:
> > /usr/rpm/macros/macros.foobar
>
> Right, these macros are not supposed to be edited by the sysadmin, we
> could even use /usr/lib/rpm/macros.
> (we already use this for perl, php, python, systemd)
Actually rpm provide some macro file in /usr/lib/rpm/macros., but
they need to be included manually from spec file. They start with a
comment like this :
# To make use of these macros insert the following line into your spec
# file:
# %include %{_rpmconfigdir}/macros.perl
Re: [Mageia-dev] [RFC] remove support for /etc/rpm/macros.d/*.macros
Olav Vitters writes: > On Mon, Jul 30, 2012 at 04:47:54PM +0200, Thierry Vignaud wrote: >> I would like to drop that patch from rpm (one less to maintain). >> That means basically renaming files: >> /etc/rpm/macros.d/foobar.macros => /etc/rpm/macros/macros.foobar > [..] >> WDYT? > > I thought latest idea that /etc is solely for the sysadmin, so shouldn't > above be: > /usr/rpm/macros/macros.foobar Right, these macros are not supposed to be edited by the sysadmin, we could even use /usr/lib/rpm/macros. (we already use this for perl, php, python, systemd) -- Olivier Blin - blino
Re: [Mageia-dev] ANNOUNCE: The /usr move cometh! <---- Instructions
I realized /usr move now, and my computer is all ok for now. Thanks mages, 2012/7/30 andre999 : > Colin Guthrie a écrit : > >> OK, so the packages have now all been uploaded. >> >> You should see several packages now that you cannot install on Cauldron. >> This is intended behaviour. >> >> Here is how to update your cauldron systems: >> >> 1. Run "urpmi --auto-update" install everything that can be installed. >> 2. Ensure that latest dracut is installed. Run "urpmi dracut" to make >> sure (it may have been excluded in the --auto-update if it was in a >> transaction with other packages that could not be installed). >> 3. Ensure that you do not have zapata or dpkg installed (rpm -e zapata; >> rpm -e dpkg) >> 4. Generate a new initrd and include the conversion script: dracut -f >> -a convertfs >> 5. If you have /usr on a separate partition >> - Ensure there is enough free space to hold /bin, /sbin, /lib and >> /lib64 content. >> - If your /usr is mounted readonly, change your /etc/fstab to mount >> it rw. >> > > > Just a random thought. > Is there an easy way to make /bin, /sbin, /lib or /lib64 > relocatable in any packages that use them to usr/*, > when a certain flag is set ? (say a certain file in /) > > Then when the appropriate conditions are met, > such as /usr on / or dracut installed and /usr with rw permissions, we could > set the flag, and then after progressively migrate the various files. > In this transition we would probably have to put syslinks in the old > locations, etc. > > If this works, maybe we could convert many mga2 systems before mga3 release, > to minimise any problems ? > > Haven't really thought this through, and I haven't been following this in > detail, just something that occured to me. > > >> All the best and good luck!!! >> >> Col >> >> > > Regards :) > > -- > André > -- Filipe Saraiva http://filipesaraiva.info/
Re: [Mageia-dev] [RFC] remove support for /etc/rpm/macros.d/*.macros
* nicolas vigier (bo...@mars-attacks.org) wrote:
> On Mon, 30 Jul 2012, Thierry Vignaud wrote:
>
> > Hi
> >
> > For years, we patch our rpm in order to support for /etc/rpm/macros.d
> > (very old compat with rpm-4.4).
> > Upstream refused to merge it as "/etc/rpm/ is a "macros.d" style
> > directory already, except in name".
>
> In a previous mail Colin was suggesting moving all macro files to
> /usr/lib/rpm/ instead of /etc/rpm :
> http://www.mageia.org/pipermail/mageia-dev/2012-July/017654.html
>
> I think shipping macro files somewhere in /usr/lib/rpm with users using
> files in /etc/rpm to overwrite macros would be nice. Unfortunately this
> probably requires an other patch to rpm.
>
> Maybe a patch to read /usr/lib/rpm/mageia/macros.* could be accepted
> upstream ?
Ask for /usr/lib/rpm/mageia/*.macros instead !
>
> Something like this :
>
> diff --git a/lib/rpmrc.c b/lib/rpmrc.c
> index 96f05ce..bef589f 100644
> --- a/lib/rpmrc.c
> +++ b/lib/rpmrc.c
> @@ -439,6 +439,7 @@ static void setDefaults(void)
> macrofiles = rstrscat(NULL, confdir, "/macros", ":",
> confdir, "/platform/%{_target}/macros", ":",
> confdir, "/fileattrs/*.attr", ":",
> + confdir, "/" RPMCANONVENDOR "/macros.*", ":",
> confdir, "/" RPMCANONVENDOR "/macros", ":",
> SYSCONFDIR "/rpm/macros.*", ":",
> SYSCONFDIR "/rpm/macros", ":",
>
>
--
Olivier Thauvin
CNRS - LATMOS
♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖
pgpCpqKwDmrQ6.pgp
Description: PGP signature
Re: [Mageia-dev] [RFC] remove support for /etc/rpm/macros.d/*.macros
On Mon, 30 Jul 2012, Thierry Vignaud wrote:
> Hi
>
> For years, we patch our rpm in order to support for /etc/rpm/macros.d
> (very old compat with rpm-4.4).
> Upstream refused to merge it as "/etc/rpm/ is a "macros.d" style
> directory already, except in name".
In a previous mail Colin was suggesting moving all macro files to
/usr/lib/rpm/ instead of /etc/rpm :
http://www.mageia.org/pipermail/mageia-dev/2012-July/017654.html
I think shipping macro files somewhere in /usr/lib/rpm with users using
files in /etc/rpm to overwrite macros would be nice. Unfortunately this
probably requires an other patch to rpm.
Maybe a patch to read /usr/lib/rpm/mageia/macros.* could be accepted
upstream ?
Something like this :
diff --git a/lib/rpmrc.c b/lib/rpmrc.c
index 96f05ce..bef589f 100644
--- a/lib/rpmrc.c
+++ b/lib/rpmrc.c
@@ -439,6 +439,7 @@ static void setDefaults(void)
macrofiles = rstrscat(NULL, confdir, "/macros", ":",
confdir, "/platform/%{_target}/macros", ":",
confdir, "/fileattrs/*.attr", ":",
+ confdir, "/" RPMCANONVENDOR "/macros.*", ":",
confdir, "/" RPMCANONVENDOR "/macros", ":",
SYSCONFDIR "/rpm/macros.*", ":",
SYSCONFDIR "/rpm/macros", ":",
Re: [Mageia-dev] [RFC] remove support for /etc/rpm/macros.d/*.macros
On Mon, Jul 30, 2012 at 04:47:54PM +0200, Thierry Vignaud wrote: > I would like to drop that patch from rpm (one less to maintain). > That means basically renaming files: > /etc/rpm/macros.d/foobar.macros => /etc/rpm/macros/macros.foobar [..] > WDYT? I thought latest idea that /etc is solely for the sysadmin, so shouldn't above be: /usr/rpm/macros/macros.foobar ? Less difference with upstream is IMO good. Only suggestion is changing rpmlint / preventing uploads with the old macros in it. -- Regards, Olav
Re: [Mageia-dev] [RFC] remove support for /etc/rpm/macros.d/*.macros
* Christiaan Welvaart (c...@daneel.dyndns.org) wrote: > On Mon, 30 Jul 2012, Thierry Vignaud wrote: > >> For years, we patch our rpm in order to support for /etc/rpm/macros.d >> (very old compat with rpm-4.4). >> Upstream refused to merge it as "/etc/rpm/ is a "macros.d" style >> directory already, except in name". >> >> I would like to drop that patch from rpm (one less to maintain). >> That means basically renaming files: >> /etc/rpm/macros.d/foobar.macros => /etc/rpm/macros/macros.foobar > > I think you meant: >/etc/rpm/macros.d/foobar.macros => /etc/rpm/macros.foobar > > (/etc/rpm/macros is a file) I did this patch because /etc/rpm/macros.* will included macros.*.rpmsave/.rpmnew and other vim backup. And it's exactly the case on my own laptop (installed as Mageia): $ ls /etc/rpm macros macros.d/ macros.fjava macros.jpackage macros.rpmnew Notice the macros.rpmnew ! Upstream just sucks to not see this issue, even jbj has admit the problem. This patch is not the most problematic in rpm as it's just a line in the configuration. -- Olivier Thauvin CNRS - LATMOS ♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖ pgph4puudRH0h.pgp Description: PGP signature
Re: [Mageia-dev] [RFC] remove support for /etc/rpm/macros.d/*.macros
On Mon, 30 Jul 2012, Thierry Vignaud wrote: For years, we patch our rpm in order to support for /etc/rpm/macros.d (very old compat with rpm-4.4). Upstream refused to merge it as "/etc/rpm/ is a "macros.d" style directory already, except in name". I would like to drop that patch from rpm (one less to maintain). That means basically renaming files: /etc/rpm/macros.d/foobar.macros => /etc/rpm/macros/macros.foobar I think you meant: /etc/rpm/macros.d/foobar.macros => /etc/rpm/macros.foobar (/etc/rpm/macros is a file) Christiaan
[Mageia-dev] [RFC] remove support for /etc/rpm/macros.d/*.macros
Hi For years, we patch our rpm in order to support for /etc/rpm/macros.d (very old compat with rpm-4.4). Upstream refused to merge it as "/etc/rpm/ is a "macros.d" style directory already, except in name". I would like to drop that patch from rpm (one less to maintain). That means basically renaming files: /etc/rpm/macros.d/foobar.macros => /etc/rpm/macros/macros.foobar So I suggest we: - fix the packages that needs it - drop the patch from rpm. There's not that many packages to fix: $ urpmf /etc/rpm/macros.d | sort -u apache-devel:/etc/rpm/macros.d/httpd.macros cmake:/etc/rpm/macros.d/cmake.macros fdupes:/etc/rpm/macros.d/fdupes.macros firefox-devel:/etc/rpm/macros.d/firefox.macros haskell-macros:/etc/rpm/macros.d/haskell-macros.macros ibus-devel:/etc/rpm/macros.d/ibus.macros java-1.5.0-gcj-devel:/etc/rpm/macros.d/java-1.5.0-gcj.macros kde4-macros:/etc/rpm/macros.d/kde4.macros lib64qt4-devel:/etc/rpm/macros.d/qt4.macros lib64scim-devel:/etc/rpm/macros.d/scim.macros lib64tcl-devel:/etc/rpm/macros.d/tcl.macros lib64uClibc-devel:/etc/rpm/macros.d/uclibc.macros lib64xulrunner-devel:/etc/rpm/macros.d/xulrunner.macros mageia-release-Default:/etc/rpm/macros.d/Default.macros mingw32-filesystem:/etc/rpm/macros.d/mingw32.macros multiarch-utils:/etc/rpm/macros.d/multiarch.macros postgresql8.4:/etc/rpm/macros.d/postgresql8.4.macros postgresql9.0:/etc/rpm/macros.d/postgresql9.0.macros postgresql9.1:/etc/rpm/macros.d/postgresql9.1.macros prelink:/etc/rpm/macros.d/prelink.macros python3:/etc/rpm/macros.d/python3.macros python-sip:/etc/rpm/macros.d/sip.macros rpm:/etc/rpm/macros.d rpm-helper:/etc/rpm/macros.d/rpm-helper.macros rpm-mageia-setup-build:/etc/rpm/macros.d/20build.macros rpm-mageia-setup-build:/etc/rpm/macros.d/dwz.macros rpm-mageia-setup:/etc/rpm/macros.d rpm-mageia-setup:/etc/rpm/macros.d/20common.macros ruby:/etc/rpm/macros.d/ruby.macros scons:/etc/rpm/macros.d/scons.macros spec-helper:/etc/rpm/macros.d/spec-helper.macros vdr-devel:/etc/rpm/macros.d/vdr.macros waf:/etc/rpm/macros.d/waf.macros waf-python3:/etc/rpm/macros.d/waf-python3.macros WDYT?
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release kernel-3.5.0-1.mga3
> Am 30.07.2012 14:47, schrieb AL13N: >>> Am 30.07.2012 13:35, schrieb Maarten Vanraes: also, not directly related, btrfs.fsck doesn't have a -a option, which means it's not executed at boot time, if needed... >>> Is btrfs.fsck production ready now? last I read something about it, it >>> was still quite buggy... >> >> IIRC, we use the one the other distro's (including Oracle Linux) use >> (the >> danger-dont-ever-use branch) > So the question is, is it wise to activate it by default? tmb seemed to think so... (or did you mean btrfs by default) but hopeefully now that cmason isn't employed by oracle anymore, that he can spend some time on it. coming features are RAID5/6 functionality (normally for 3.6) and also send/receive functionality
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release kernel-3.5.0-1.mga3
Am 30.07.2012 14:47, schrieb AL13N: Am 30.07.2012 13:35, schrieb Maarten Vanraes: also, not directly related, btrfs.fsck doesn't have a -a option, which means it's not executed at boot time, if needed... Is btrfs.fsck production ready now? last I read something about it, it was still quite buggy... IIRC, we use the one the other distro's (including Oracle Linux) use (the danger-dont-ever-use branch) So the question is, is it wise to activate it by default? Oliver -- Oliver Burger aka obgr_seneca Mageia contributor
Re: [Mageia-dev] [soft-commits] [4436] german keyboard: default to variant with enabled deadkeys instead of "nodeadkeys variant" ( mga#3791)
Am 30.07.2012 14:41, schrieb Wolfgang Bornath:
2012/7/30 Thierry Vignaud:
On 28 June 2012 02:51, Thierry Vignaud wrote:
german keyboard: default to variant with enabled deadkeys instead
of"nodeadkeys variant" (mga#3791)
Oups, why that?
As far as I'm concerned no deadkeys is the default for German users and
that's good!
Any reasons for this change?
Call it "Competitive analysis" if you want. Keyboards comes with those
little keys that are meant to produce accented characters in
combination with regular letters, and this how it works on Windows,
the platform most users will migrate from, and also on Mac OS X.
Regular users don't have any use of stand-alone-accent-characters. And
even with deadkeys it is easy to produce the standalone accent by just
pressing the key twice (so you can get backticks easily).
If you're a programmer and are using a nodeadkeys variant for that
reason, you're not the target population of a suggested default. (If
you know what is meant with "deadkeys" and "nodeadkeys", you're not in
target of that dialog, and have the knowledge to not accept the
default, but choose the nodeadkeys variant that is listed right next
to the regular variant).
The variant with deadkeys is called "German" without any addition for
a reason. If nodeadkeys were the expected/more common choice, then it
would be "German (international)" or "German (deadkeys)", like it is
the case for the US-variants.
So Olivier, do you agree with that change or not?
It may be logical but German users have been taught to use
"nodeadkeys" for ages. Changing this now just because of semantics
does not seem to be a wise move (I always use "German"). But OTOH it
is not such a big thing. It will cause the usual number of questions
in the forums ("MAG3 breaks my keyboard!") but this will vanish over
the years. :)
This must have slipped my mind...
I concur with wobo. This change will cause such forums posts but that
will be solved soon after Mga3 release.
The question is, how do other distros do it? A colleague just told me,
his Ubuntu chose the no dead key variant by default.
What about Fedora and openSUSE or don't we care at all?
As for myself, I will just change it back on my systems so it's no big deal.
Oliver
--
Oliver Burger aka obgr_seneca
Mageia contributor
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release kernel-3.5.0-1.mga3
> Am 30.07.2012 13:35, schrieb Maarten Vanraes: >> >> also, not directly related, btrfs.fsck doesn't have a -a option, which >> means it's not executed at boot time, if needed... > Is btrfs.fsck production ready now? last I read something about it, it > was still quite buggy... IIRC, we use the one the other distro's (including Oracle Linux) use (the danger-dont-ever-use branch)
Re: [Mageia-dev] [soft-commits] [4436] german keyboard: default to variant with enabled deadkeys instead of "nodeadkeys variant" ( mga#3791)
2012/7/30 Thierry Vignaud :
> On 28 June 2012 02:51, Thierry Vignaud wrote:
> german keyboard: default to variant with enabled deadkeys instead
> of"nodeadkeys variant" (mga#3791)
Oups, why that?
As far as I'm concerned no deadkeys is the default for German users and
that's good!
Any reasons for this change?
>>>
>>> Call it "Competitive analysis" if you want. Keyboards comes with those
>>> little keys that are meant to produce accented characters in
>>> combination with regular letters, and this how it works on Windows,
>>> the platform most users will migrate from, and also on Mac OS X.
>>>
>>> Regular users don't have any use of stand-alone-accent-characters. And
>>> even with deadkeys it is easy to produce the standalone accent by just
>>> pressing the key twice (so you can get backticks easily).
>>> If you're a programmer and are using a nodeadkeys variant for that
>>> reason, you're not the target population of a suggested default. (If
>>> you know what is meant with "deadkeys" and "nodeadkeys", you're not in
>>> target of that dialog, and have the knowledge to not accept the
>>> default, but choose the nodeadkeys variant that is listed right next
>>> to the regular variant).
>>>
>>> The variant with deadkeys is called "German" without any addition for
>>> a reason. If nodeadkeys were the expected/more common choice, then it
>>> would be "German (international)" or "German (deadkeys)", like it is
>>> the case for the US-variants.
>>
>> So Olivier, do you agree with that change or not?
It may be logical but German users have been taught to use
"nodeadkeys" for ages. Changing this now just because of semantics
does not seem to be a wise move (I always use "German"). But OTOH it
is not such a big thing. It will cause the usual number of questions
in the forums ("MAG3 breaks my keyboard!") but this will vanish over
the years. :)
--
wobo
Re: [Mageia-dev] [soft-commits] [4436] german keyboard: default to variant with enabled deadkeys instead of "nodeadkeys variant" ( mga#3791)
On 28 June 2012 02:51, Thierry Vignaud wrote: german keyboard: default to variant with enabled deadkeys instead of"nodeadkeys variant" (mga#3791) >>> >>> Oups, why that? >>> As far as I'm concerned no deadkeys is the default for German users and >>> that's good! >>> >>> Any reasons for this change? >> >> Call it "Competitive analysis" if you want. Keyboards comes with those >> little keys that are meant to produce accented characters in >> combination with regular letters, and this how it works on Windows, >> the platform most users will migrate from, and also on Mac OS X. >> >> Regular users don't have any use of stand-alone-accent-characters. And >> even with deadkeys it is easy to produce the standalone accent by just >> pressing the key twice (so you can get backticks easily). >> If you're a programmer and are using a nodeadkeys variant for that >> reason, you're not the target population of a suggested default. (If >> you know what is meant with "deadkeys" and "nodeadkeys", you're not in >> target of that dialog, and have the knowledge to not accept the >> default, but choose the nodeadkeys variant that is listed right next >> to the regular variant). >> >> The variant with deadkeys is called "German" without any addition for >> a reason. If nodeadkeys were the expected/more common choice, then it >> would be "German (international)" or "German (deadkeys)", like it is >> the case for the US-variants. > > So Olivier, do you agree with that change or not? Ping?
[Mageia-dev] HAL woes
On a pre-/usr cauldron which has intentionally not been updated, wine apps have suddenly stopped being able to "see" mounted DVDs. Checking syslog immediately after ejecting and reloading the disk, I find: ** Jul 29 10:50:50 localhost kernel: [ 302.664794] sr 0:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE Jul 29 10:50:50 localhost kernel: [ 302.664798] sr 0:0:0:0: [sr0] Sense Key : Illegal Request [current] Jul 29 10:50:50 localhost kernel: [ 302.664801] sr 0:0:0:0: [sr0] Add. Sense: Read of scrambled sector without authentication Jul 29 10:50:50 localhost kernel: [ 302.664805] sr 0:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 04 00 00 00 02 00 Jul 29 10:50:50 localhost kernel: [ 302.664810] end_request: I/O error, dev sr0, sector 4096 Jul 29 10:50:50 localhost kernel: [ 302.664812] Buffer I/O error on device sr0, logical block 512 Jul 29 10:50:50 localhost kernel: [ 302.697982] sr 0:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE Jul 29 10:50:50 localhost kernel: [ 302.697984] sr 0:0:0:0: [sr0] Sense Key : Illegal Request [current] Jul 29 10:50:50 localhost kernel: [ 302.664801] sr 0:0:0:0: [sr0] Add. Sense: Read of scrambled sector without authentication Jul 29 10:50:50 localhost kernel: [ 302.664805] sr 0:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 04 00 00 00 02 00 Jul 29 10:50:50 localhost kernel: [ 302.664810] end_request: I/O error, dev sr0, sector 4096 Jul 29 10:50:50 localhost kernel: [ 302.664812] Buffer I/O error on device sr0, logical block 512 Jul 29 10:50:50 localhost kernel: [ 302.697982] sr 0:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE Jul 29 10:50:50 localhost kernel: [ 302.697984] sr 0:0:0:0: [sr0] Sense Key : Illegal Request [current] Jul 29 10:50:50 localhost kernel: [ 302.697987] sr 0:0:0:0: [sr0] Add. Sense: Read of scrambled sector without authentication Jul 29 10:50:50 localhost kernel: [ 302.697990] sr 0:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 04 00 00 00 02 00 Jul 29 10:50:50 localhost kernel: [ 302.697994] end_request: I/O error, dev sr0, sector 4096 Jul 29 10:50:50 localhost kernel: [ 302.697996] Buffer I/O error on device sr0, logical block 512 Jul 29 10:50:50 localhost systemd-udevd[32108]: failed to execute '/lib/udev/socket:@/org/freedesktop/hal/udev_event' 'socket:@/org/freedesktop/hal/udev_event': No such file or directory Jul 29 10:50:50 localhost systemd-udevd[32109]: failed to execute '/lib/udev/socket:/org/kernel/dm/multipath_event' 'socket:/org/kernel/dm/multipath_event': No such file or directory Jul 29 10:50:50 localhost udisksd[29333]: Error opening /etc/crypttab file: Failed to open file '/etc/crypttab': No such file or directory (g-file-error-quark, 4) Jul 29 10:50:54 localhost haldaemon[27164]: Starting HAL daemon: [FAILED] Jul 29 10:50:54 localhost systemd[1]: haldaemon.service: control process exited, code=exited status=2 Jul 29 10:50:54 localhost systemd[1]: Unit haldaemon.service entered failed state. Jul 29 10:50:54 localhost systemd[1]: Startup finished in 1s 93ms 504us (kernel) + 5s 214ms 916us (initrd) + 5min 1s 511ms 645us (userspace) = 5min 7s 820ms 65us. *** Based on observation, the stuff timestamped 10:50:50 is the result of ejecting the disk, and the last few lines timestamped 10:50:54 are the result of reloading it, with the intervening 4 seconds consumed by reading the disk headers and such. I seem to remember here that nothing is supposed to be using HAL, so it's puzzling as to why systemd would be trying to start it in response to the load. It's equally puzzling as to why this should suddenly affect wine, when nothing's been upgraded (this worked 2 or 3 days ago). The disk is correctly mounted and identified by KDE, and is usable by k3b and command-line utilities. k3b also detects the load event, and switches its GUI prompt from "insert a disk" to the actual label. Is wine still hal-dependent when it ought not to be ?
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release kernel-3.5.0-1.mga3
Am 30.07.2012 13:35, schrieb Maarten Vanraes: also, not directly related, btrfs.fsck doesn't have a -a option, which means it's not executed at boot time, if needed... Is btrfs.fsck production ready now? last I read something about it, it was still quite buggy... -- Oliver Burger aka obgr_seneca Mageia contributor
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release kernel-3.5.0-1.mga3
> On 28 July 2012 05:11, tmb wrote: >> tmb 3.5.0-1.mga3: >> + Revision: 275103 >> - fix perf build with glibc-2.16 >> - fix unionfs build with 3.5 series kernels >> - rediff mrproper patch >> - update defconfigs >> - drop merged patches >> - rediff unionfs patch >> - add include/memory/ to -devel and -source filelists >> - update to 3.5 > > Could you enable fontswap & zcache please? > Thx > also, not directly related, btrfs.fsck doesn't have a -a option, which means it's not executed at boot time, if needed...
