[Mageia-dev] xonotic and nexuiz
Is it intentional that we package/provides both xonotic; the successor, and nexuiz "classic"; now owned by IllFonic and being completely rewritten for a different engine? Charles -- Q: How many Martians does it take to screw in a light bulb? A: One and a half. -- Mageia release 2 (Cauldron) for x86_64$ On SuperSizehttp://www.eslrahc.com Registered Linux user #182463 3.2.9-server-2.mga2 x86_64 -- signature.asc Description: PGP signature
Re: [Mageia-dev] Version freeze: reminder
11.03.2012 02:59, Thierry Vignaud skrev: > In the meantime, please let go in: > > 1) drakxtools: > - english message improvement (mga#456) > - diskdrake: > o fix error on removing LVs > o fix resizing LVs (mga#4666) > > 2) drakx-installer-stage2: > - explain why acpi, acpid & mageia-gfxboot-theme packages are selected > - install more packages earlier (shorewall & mandi), preventing useless > installing steps later at summary stage > - partitionning: > o fix error on removing LVs > o fix resizing LVs (mga#4666) Both pushed. -- Thomas
Re: [Mageia-dev] Version freeze: reminder
On 8 March 2012 11:31, Anne nicolas wrote: > Version freeze is now active. As a reminder please have a look here > https://www.mageia.org/pipermail/mageia-dev/2012-March/012533.html > > for more details. For years, the freeze never impacted our own tools since unless packages we are not upstream, we prefer to release than patch (which also helps get latest translations). Now, drakx* stuff got blocked. So I would request we relax the freeze for our own stuff. else It'll made pushing fixes quite slow & painfull. In worst case, instead of pushing the stack in ~30mns, it may takes days. eg if I fix sg in urpmi, I've to wait for someone to actually push urpmi before asking to push drakx-installer-stage2 with new urpmi. eg if I fix sg in rpm, I've to wait for someone to actually push rpm before asking to push perl-URPM to drakx-installer-stage2. It can become way more painful for eg: dietlibc fix>kmod|ldetect>drakx-installer-binaries>drakx-installer-images eg: if would fix sg in dietlibc for kmod. Thus I would have 4 requests with delays between each. Or enable me to push new perl-URPM/urpmi/drakx* like I was able to do in the old days We're not that many working on our tool bugs to let us die of slow pain... Pushing fixes in the installer usually involves many stages... In the meantime, please let go in: 1) drakxtools: - english message improvement (mga#456) - diskdrake: o fix error on removing LVs o fix resizing LVs (mga#4666) 2) drakx-installer-stage2: - explain why acpi, acpid & mageia-gfxboot-theme packages are selected - install more packages earlier (shorewall & mandi), preventing useless installing steps later at summary stage - partitionning: o fix error on removing LVs o fix resizing LVs (mga#4666)
Re: [Mageia-dev] Deprecating startx
Am 10.03.2012 22:39, schrieb Maarten Vanraes: Op zaterdag 10 maart 2012 22:06:09 schreef Florian Hubold: Am 10.03.2012 14:15, schrieb eatdirt: On 10/03/12 10:12, Maarten Vanraes wrote: I have a pentium 66MHz (not MMX) With the turbo button 33 -> 66 ? Man, that's a proper collector :) Normally turbo button was only effective for 468DX/586DX type of machines, not for pentium IIRC. you likely mean 486/586 and alas 586 machines are called pentium there's a difference between pentium and pentium MMX though, even though i recall there are even pentium MMX's who had a turbo button... if it was really effective of not, that's another matter entirely... Whoops, yes 486dx/586dx. 586 machines are not necessarily only pentiums, even if the majority only knows pentium machines as 586. AMD and Cyrix at that time produced also 586 cpus, and couldn't call those pentium because that's a trademark. Also the turbo button was more tied to the case, and not to the processor. But that's getting too much offtopic ...
[Mageia-dev] packagekit, gstreamer and urpmi
Hello, Is there any work in progress about the packagekit-gstreamer-backend ? I ask that because totem (or others gstreamer player plugin) use this feature but don't work with urpmi. https://bugs.mageia.org/show_bug.cgi?id=4869 If it will stay in this state, maybe we should drop these pop-up and the others stuff ? mail from pok: https://www.mageia.org/pipermail/mageia-dev/2011-July/006422.html Another old thread: http://comments.gmane.org/gmane.linux.mageia.devel/3707
Re: [Mageia-dev] Release_blocker bugs
Le jeudi 08 mars 2012 à 09:37 +0100, Michael Scherer a écrit : > Le mercredi 07 mars 2012 à 21:43 +0100, Manuel Hiebel a écrit : > > Hello, > > > > How can we (the bugsquad or other people) determinate what can be a > > release_blocker bug ? > > > > in the triage guide we can see: > > > > "The release_blocker priority is only relevant to bugs filed on Cauldron > > or beta releases, and should only be used for issues which are > > sufficiently critical that it would severely impair the overall quality > > of a release if it were made available without the issue being > > resolved." > > > > That is not clear for me. And the only mail relating to that, was from > > Anne in May and not useful for me. > > I would say "stuff that cannot be fixed after release" would be release > blocker. Not to say that the rest cannot be too, but at least, that's > the first criteria. > > So a software on livecd that crash on startup would also be a blocker. > Ok thanks, I will keep that in mind.
Re: [Mageia-dev] RFC: Splash + Quiet.
'Twas brillig, and Florian Hubold at 10/03/12 21:39 did gyre and gimble: > Am 10.03.2012 22:15, schrieb Barry Jackson: >> On 10/03/12 19:29, Colin Guthrie wrote: >>> 'Twas brillig, and Thierry Vignaud at 10/03/12 17:04 did gyre and >>> gimble: >> just make sure upgrade is done smoothly (s/splash=verbose/splash/ and /splash=quiet//) >>> >>> I think I'll go for the exact opposite :) >>> >> >> Thanks - I was totally confused. >> >> So "splash" for a splash screen and nothing for text >> >> Sounds good to me ;) >> > Maybe do it in a way that for cauldron we have only text by default, > and on a stable release splash by default? I'd rather not TBH. It's easy enough if people want to configure their cauldron system to show all the gory details. I don't think it's a good idea to have things done automatically different on cauldron vs. release. Kinda defeats the point in testing things on cauldron afterall. 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] RFC: Splash + Quiet.
'Twas brillig, and Barry Jackson at 10/03/12 21:15 did gyre and gimble: > On 10/03/12 19:29, Colin Guthrie wrote: >> 'Twas brillig, and Thierry Vignaud at 10/03/12 17:04 did gyre and gimble: > >>> just make sure upgrade is done smoothly (s/splash=verbose/splash/ >>> and /splash=quiet//) >> >> I think I'll go for the exact opposite :) >> > > Thanks - I was totally confused. > > So "splash" for a splash screen and nothing for text > > Sounds good to me ;) Yup. Tho' with the other part of the proposal it would actually be "splash quiet". Two technically separate bits that combine to give a nicer on the eye boot. 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] RFC: Splash + Quiet.
Am 10.03.2012 22:15, schrieb Barry Jackson: On 10/03/12 19:29, Colin Guthrie wrote: 'Twas brillig, and Thierry Vignaud at 10/03/12 17:04 did gyre and gimble: just make sure upgrade is done smoothly (s/splash=verbose/splash/ and /splash=quiet//) I think I'll go for the exact opposite :) Thanks - I was totally confused. So "splash" for a splash screen and nothing for text Sounds good to me ;) Maybe do it in a way that for cauldron we have only text by default, and on a stable release splash by default?
Re: [Mageia-dev] Deprecating startx
Op zaterdag 10 maart 2012 22:06:09 schreef Florian Hubold: > Am 10.03.2012 14:15, schrieb eatdirt: > > On 10/03/12 10:12, Maarten Vanraes wrote: > >> I have a pentium 66MHz (not MMX) > > > > With the turbo button 33 -> 66 ? Man, that's a proper collector :) > > Normally turbo button was only effective for 468DX/586DX type > of machines, not for pentium IIRC. you likely mean 486/586 and alas 586 machines are called pentium there's a difference between pentium and pentium MMX though, even though i recall there are even pentium MMX's who had a turbo button... if it was really effective of not, that's another matter entirely...
Re: [Mageia-dev] executable libraries
Den 13:45 3. mars 2012 skrev Guillaume Rousse følgende: > Le 02/03/2012 22:01, Per Øyvind Karlsen a écrit : > >> Den 21:51 2. mars 2012 skrev Maarten Vanraes følgende: >>> >>> Op vrijdag 02 maart 2012 21:29:05 schreef Anssi Hannula: 02.03.2012 21:57, Maarten Vanraes kirjoitti: > > Op vrijdag 02 maart 2012 15:22:23 schreef Anssi Hannula: >> >> 02.03.2012 00:17, Maarten Vanraes kirjoitti: >>> >>> Op donderdag 01 maart 2012 23:05:35 schreef Anssi Hannula: >>> [...] >>> > does this mean debug info fails for these? I'm not immediately sure (I never remember how the debug/stripping stuff works exactly), but I think either a) debug symbols extraction and thus -debug packaging, b) stripping, or c) both will fail with non-executable shared libs. >>> >>> >>> in that case i guess we would need a policy or bs check to make sure >>> we >>> don't fail some libraries debug and strip >> >> >> Possibly. >> >> Interestingly, Debian policy disallows executable permission on shared >> libs: >> >> http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs- >> ru ntime >> >> "Shared libraries should not be installed executable, since the >> dynamic >> linker does not require this and trying to execute a shared library >> usually results in a core dump." > > > which is sort of strange, since libc is actually executable by design. > > i see where they are coming from > > but i guess the first part of this is, why is there a find with > executable restrictions for the code relating to stripped binaries and > debug? > > is it because it's also used for real executables? I guess it is there just to speed up the process, otherwise it would have to run 'file' for every file in the package (and many packages have lots of files). >>> >>> >>> still, it seems kind of weird, there are rpmlint checks for unstripped >>> libraries, but i do have 34 libraries not marked as executable, while the >>> stripping+ debug seems to target only executables? >>> >>> i wonder if we should make another check library unset as executable or >>> even >>> check what happened with these libraries not marked as executable? >> >> I posted a link to a rpmlint patch implementing such a check to this >> thread two >> hours ago.. :p > > I don't much point to a check, when a rpm-helper scriptlet would be able to > automatically enforce any given permission set. I eventually reached that conclusion as well, especially as I ran into same issues with mono libraries as well.. I've just pushed a new spec-helper to cooker with the following script: http://svn.mandriva.com/viewvc/soft/rpm/spec-helper/trunk/fix_file_permissions?view=markup -- Regards, Per Øyvind
Re: [Mageia-dev] RFC: Splash + Quiet.
On 10/03/12 19:29, Colin Guthrie wrote: 'Twas brillig, and Thierry Vignaud at 10/03/12 17:04 did gyre and gimble: just make sure upgrade is done smoothly (s/splash=verbose/splash/ and /splash=quiet//) I think I'll go for the exact opposite :) Thanks - I was totally confused. So "splash" for a splash screen and nothing for text Sounds good to me ;)
Re: [Mageia-dev] Deprecating startx
Am 10.03.2012 14:15, schrieb eatdirt: On 10/03/12 10:12, Maarten Vanraes wrote: I have a pentium 66MHz (not MMX) With the turbo button 33 -> 66 ? Man, that's a proper collector :) Normally turbo button was only effective for 468DX/586DX type of machines, not for pentium IIRC.
Re: [Mageia-dev] RFC: Splash + Quiet.
'Twas brillig, and Thierry Vignaud at 10/03/12 17:04 did gyre and gimble: > On 10 March 2012 17:40, Colin Guthrie wrote: >> We've used the kernel command line "splash=silent" in the past (as >> opposed to "splash=verbose") to indicate that we want a splash screen. >> >> Most of the upstream projects just check for "splash" on it's own. The >> absence of the word "splash" means the same as our current "splash=verbose". >> >> In order to make this work properly we have to patch both upstream >> systemd, initscripts, dracut and plymouth. >> >> As far as I can tell, there is no gain in doing this so I'm intending to >> convert our usage to the upstream defaults. If anyone objects, please >> speak out now!! > > just make sure upgrade is done smoothly (s/splash=verbose/splash/ > and /splash=quiet//) I think I'll go for the exact opposite :) >> As a separate issue, kernel debug output is controlled by the "quiet" >> keyword. We don't use this (haven't since 2003) but personally I believe >> it's time to include this. It gives a much smoother and more user >> friendly boot. > > Yeah I was thinking about that one for some time... I've also asked Thomas about the frame buffer logo images that get displayed very early on. Ideally we could kill them too. 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] package update request: gif2png
Reason for update: Security update, CVE-2009-5018, filename buffer overflow. Update is in SVN. Package builds, installs, and works fine locally.
Re: [Mageia-dev] RFC: Splash + Quiet.
On 10 March 2012 17:40, Colin Guthrie wrote: > We've used the kernel command line "splash=silent" in the past (as > opposed to "splash=verbose") to indicate that we want a splash screen. > > Most of the upstream projects just check for "splash" on it's own. The > absence of the word "splash" means the same as our current "splash=verbose". > > In order to make this work properly we have to patch both upstream > systemd, initscripts, dracut and plymouth. > > As far as I can tell, there is no gain in doing this so I'm intending to > convert our usage to the upstream defaults. If anyone objects, please > speak out now!! just make sure upgrade is done smoothly (s/splash=verbose/splash/ and /splash=quiet//) > As a separate issue, kernel debug output is controlled by the "quiet" > keyword. We don't use this (haven't since 2003) but personally I believe > it's time to include this. It gives a much smoother and more user > friendly boot. Yeah I was thinking about that one for some time...
Re: [Mageia-dev] RFC: Splash + Quiet.
Le 10 mars 2012 17:40, "Colin Guthrie" a écrit : > > Hi, > > We've used the kernel command line "splash=silent" in the past (as > opposed to "splash=verbose") to indicate that we want a splash screen. > > Most of the upstream projects just check for "splash" on it's own. The > absence of the word "splash" means the same as our current "splash=verbose". > > In order to make this work properly we have to patch both upstream > systemd, initscripts, dracut and plymouth. > > As far as I can tell, there is no gain in doing this so I'm intending to > convert our usage to the upstream defaults. If anyone objects, please > speak out now!! > > > As a separate issue, kernel debug output is controlled by the "quiet" > keyword. We don't use this (haven't since 2003) but personally I believe > it's time to include this. It gives a much smoother and more user > friendly boot. > > So again, unless anyone objects, I'll update the tools to set these two > keywords together when we boot. (I thought that there used to be a GUI > tool to choose the theme here and whether it was verbose or silent... I > can't seem to see it - what am I missing?) > Unless it's all done tonight please wait after beta 2 > 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] RFC: Splash + Quiet.
Hi, We've used the kernel command line "splash=silent" in the past (as opposed to "splash=verbose") to indicate that we want a splash screen. Most of the upstream projects just check for "splash" on it's own. The absence of the word "splash" means the same as our current "splash=verbose". In order to make this work properly we have to patch both upstream systemd, initscripts, dracut and plymouth. As far as I can tell, there is no gain in doing this so I'm intending to convert our usage to the upstream defaults. If anyone objects, please speak out now!! As a separate issue, kernel debug output is controlled by the "quiet" keyword. We don't use this (haven't since 2003) but personally I believe it's time to include this. It gives a much smoother and more user friendly boot. So again, unless anyone objects, I'll update the tools to set these two keywords together when we boot. (I thought that there used to be a GUI tool to choose the theme here and whether it was verbose or silent... I can't seem to see it - what am I missing?) 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] Deprecating startx
Den 14:15 10. mars 2012 skrev eatdirt følgende: > On 10/03/12 10:12, Maarten Vanraes wrote: > >> I have a pentium 66MHz (not MMX) With a divide by zero bug? :o) >> > > With the turbo button 33 -> 66 ? Man, that's a proper collector :) You're confusing with 486. :p -- Regards, Per Øyvind
Re: [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia
On Sunday, January 08, 2012 05:07:38 PM Kamil Rytarowski wrote:
> W dniu 08.01.2012 22:04, Luc Menut pisze:
> > Le 08/01/2012 21:18, Kamil Rytarowski a écrit :
> >> W dniu 08.01.2012 15:19, Luc Menut pisze:
> >>> Hello,
> >
> > [...]
> >
> >>> if the versionned provides indicates the location, we can use it if
> >>> necessary in Conflicts or Requires in others packages.
> >>> e.g. currently Firefox searches dictionnaries in
> >>> /usr/share/dict/mozilla (myspell dictionaries). when we change this
> >>> location, we could add a Requires enchant-dictionary = 4.
> >>>
> >>> same for hunspell-dictionary and dictionary-%{languagecode}, a
> >>> versionned provides could indicate the location of the dictionary.
> >>> if we want to be able to remove easily all the compatibility link in
> >>> the future, we should really consider this.
> >>
> >> If a package requires enchant-dictionary, then language specific will be
> >> chosen before Aspell. This is the whole idea behind it. (eg. Voikko is
> >> chosen before hunspell-fi and aspell-fi too).
> >
> > OK, I understand the use for enchant-dictionary.
> >
> >> And I'm against some
> >> special versioning for directories, we don't really need it.
> >
> > sorry but I don't agree with you here.
> > e.g. in coming days, we will fix firefox (and other mozilla apps) to
> > use hunspell-dictionaries; we will update the link to
> > /usr/lib64/firefox-9.0.1/dictionaries -> /usr/share/hunspell
> > and change the requires to hunspell-dictionary.
> >
> > but hunspell-dictionaries "old generation" (mga1) provide
> > hunspell-dictionary, and install dictionaries only in /usr/share/myspell.
>
> Just a technical note:
> Old Hunspell dictionaries don't provide anything additional. They are
> just dangling without any special integration with the system, please
> take a look:
> http://svnweb.mageia.org/packages/cauldron/hunspell-fr/current/SPECS/hunspe
> ll-fr.spec?revision=134361&view=markup
>
> $ urpmq --provides hunspell-nl
> hunspell-nl[== 2.00-2.mga1]
>
> New Hunspell dictionaries obsolete&provide Myspell packages and come
> into the Myspell place. They also install dictionaries into the same
> place as the predecessor - this is why I put it into the place of the
> old enchant-dictionary=2 place.
>
> Gentoo uses common packages for Myspell and Hunspell dictionaries. So
> this is additional argument to put Hunspell in the place of Myspell.
>
> > how do you plan to handle that the fixed firefox will absolutly need
> > hunspell-dictionaries "new generation",
>
> Fix Mozilla packages (in Mga2) to use new generation dictionaries in
> /usr/share/hunspell
>
> > and can't work with hunspell-dictionaries "old generation" ?
>
> Is there need for anything needed in addition of just higher
> version&release of every new generation hunspell-dictionary in Mga2,
> then the one in Mga1? In Mga2 every hunspell-dictionary will be in the
> new generation version.
>
> And I think we support Mga1->Mga2 full migration, so everything will be
> working.
>
> Am I right?
>
> > regards,
> >
> > Luc
Are we making any progress with this. Currenly Hunspell doesn't work in Lyx
(error no dictionaries installed and digging through the Hunspell spec file it
installs a patch and gives the dictionary path as /usr/share/dict/ooo:
but there is only a one empty file in that directory called dictionary.lst
Hunspell works on libreoffice.
--
Best regards
Thomas Spuhler
Re: [Mageia-dev] lvm2 initscript is marked as a config file...?
'Twas brillig, and Michael Scherer at 10/03/12 10:10 did gyre and gimble: > The systemd approach with inheritance is much cleaner on this regard. Absolutely! The units in etc *are* config/customisation. The ones in /lib (or eventually in /usr/lib) are provided by packages. All very sensible :) 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 mageia-release-2-0.5.mga2
'Twas brillig, and Thierry Vignaud at 10/03/12 09:27 did gyre and gimble: > On 10 March 2012 02:25, colin wrote: >> colin 2-0.5.mga2: >> + Revision: 222352 >> - Flesh out os-release as per upstream docs. > > Please add bug reference and close the BR: > https://bugs.mageia.org/show_bug.cgi?id=4528 Oh, I wasn't aware there was a bug. I was just fixing it because it needed fixing. 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] Deprecating startx
On 10/03/12 10:12, Maarten Vanraes wrote: I have a pentium 66MHz (not MMX) With the turbo button 33 -> 66 ? Man, that's a proper collector :)
Re: [Mageia-dev] [changelog] [RPM] cauldron nonfree/release get-skype-2.2.0.35-18.mga2.nonfree
Am 08.03.2012 15:42, schrieb Guillaume Rousse: Le 08/03/2012 15:18, Sander Lepik a écrit : I was quite sure that Mageia would keep the usability bit that Mandriva had. But with our current direction Gentoo is soon easier to use for non-developer/sysadmin user. Gentoo is still too much user-friendly for my taste, I'd rather target LFS :) C'mon guy, stop the FUD, and write correct user-readable documentation instead of ressorting to this kind of dirty hacks. FWIW, we already have documentation about that for quite some time: https://forums.mageia.org/en/viewtopic.php?f=36&t=1121 Feel free to give any proposals about improvements.
Re: [Mageia-dev] lvm2 initscript is marked as a config file...?
Le mardi 06 mars 2012 à 22:12 +0200, Anssi Hannula a écrit : > 06.03.2012 21:48, Colin Guthrie kirjoitti: > > Hiya > > > > I noticed while doing the updates round that the file > > /etc/init.d/lvm2-monitor had a .rpmnew... Thus is seems to be marked as > > a config file. Is this correct? Most initscripts are not meant to be > > configured... is this the exception that proves the rule? > > Doesn't look like configurable. > > I have many times seen random non-config files marked as > %config(noreplace) in very old .specs just because they are in /etc. > This instance also predates mdv SVN migration (unfortunately their CVS > has been brought down). > > (maybe rpmlint wrongly warned about them many many years ago, causing > people to add unwanted %config flags...) That's it. And that's something that always bothered me on a fundamental level, if that's not config, it should not be in /etc/, as this gave likely wrong expectation to people ( ie, that they could safely hack around initscripts and have no problem on upgrade ). The systemd approach with inheritance is much cleaner on this regard.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release mageia-release-2-0.5.mga2
On 10 March 2012 02:25, colin wrote: > colin 2-0.5.mga2: > + Revision: 222352 > - Flesh out os-release as per upstream docs. Please add bug reference and close the BR: https://bugs.mageia.org/show_bug.cgi?id=4528
Re: [Mageia-dev] Deprecating startx
Op zaterdag 10 maart 2012 08:23:29 schreef zezinho: > Le vendredi 9 mars 2012 23:56:28, eatdirt a écrit : > > [got another reason for startx, my pentium 133MHz running mga.1 does not > > like kdm, even xdm :)] > > Ah, I feel less alone (well, Pentium 166 MMX for my side. I have a pentium 66MHz (not MMX)
