Re: [Mageia-dev] Problems with gnome-shell and polkit
JA Magallón writes: > On 09/24/2012 07:51 PM, Olav Vitters wrote: >> On Mon, Sep 24, 2012 at 12:42:58AM +0200, JA Magallón wrote: >>> Perhaps polkit-gnome is out of sync ? >> >>>From the .spec: >> >> # install the autostart file manually, since upstream doesn't ship it any >> more >> # and decided that it's the job of each DE to start >> polkit-gnome-authentication-agent-1 >> # this doesn't seem to apply to gnome-session in GNOME 2.32 >> # ACK'ed by pterjan >> # >> # this file was nicked from the gnome-polkit-0.99 binary rpm, to get all the >> translations >> # (ahmad) 02-05-2011 >> >> >> I removed the autostart file in a newly submitted polkit-gnome. >> > > Thanks !! > BTW, do we need both polkit and policykit installed ? > I can remove libpolkit2-0.9-8.mga1,policykit-0.9-8.mga1 without any problem. > Should new version obsolete old one ? I was in the process of obsoleting it, a few things had to be done, like fixing a sectool dep, and ... killing hal :) I'll do a recap mail later. -- Olivier Blin - blino
Re: [Mageia-dev] Mageia 3 final set of isos
Thomas Backlund a écrit :
zezinho skrev 24.9.2012 12:52:
Em 24-09-2012 09:55, Thomas Backlund escreveu:
Just because they have a 64bit hw, it does not mean they have accees
to cheap bw since that depends on where they live, what isp they have,
and so on...
Well, we can't keep the same service to users without keeping the same
number of medias. And we NEED to reduce this number. So let's only
decide if DVD keeps without nonfree or not. A poll? Both choices will
keep the same numbers of medias.
Sorry, my response got somewhat easy to misunderstand :)
I meant it only as a response to the:
"it seems much less likely that 64-bit users will have the download
bandwidth problems of many 32-bit users."
As far as I can see, the easiest way to REDUCE media number is to switch
Live medias from 700MB to at most DVD size :
- It removes the different localized version, it is 40% medias less.
- It does not remove ALL CD-R solutions, as we long as keep DualArch and
boot.iso media.
- It fits in most current USB keys (4GB is the lowest size I can see in
shops).
But many people have only 1-2GB sticks they could re-use ...
Not everyone can go out and buy new hw all the time...
And the downside of getting bigger live images is that they
do get slower to boot...
Yes, it removes supports for some old hardware solutions, which I
install often, but we can't keep testing 19 medias. We have still lack
of QA people!
Yes, I know... I've been doing ISO qa :)
we do need to reduce the media sets...
which is why I earlier in this thread suggested:
- 1 i586 GNOME english liveCD ("works everywhere")
- 1 i586 KDE english liveCD ("works everywhere")
We should consider the target users of live CDs.
If it is only for the purpose of reviews (by english speakers), then
downloading 2 cds for testing in english only is fine.
But if we want to introduce other users to mageia, many of whom would be
more confortable in another language, if they speak english at all, it
would be very useful to keep the other languages.
At least for the i586 cds.
(x64 users can always use the i586 cds if they don't want to use a dvd)
- 1 i586 GNOME all-lang liveDVD
- 1 i586 KDE all-lang liveDVD
- 1 x86_64 GNOME all-lang liveDVD
- 1 x86_64 KDE all-lang liveDVD
Would producing live dvd instead of a non-live dvd take much more space
? My impression is no.
If that is correct, then we could make just one live all-desktop live
DVD for each of i586 and x86_64.
Unless you think that the current non-live DVDs are missing important a
lot of important packages ?
That would bring the live* media down from 16 -> 6
Simply dropping 64-bit live cds, without any other changes, would reduce
isos from 19 -> 11.
Without much loss, as those with 64-bit hw could always use 32-bit live
cds, and then install with 64-bit media.
Although it would be better if a 64-bit live dvd were available.
And as data point...
With current mga2 livecd package config, building a liveDVD for one
arch/DE results in a liveDVD image with ~ 1GB image size
This is your area of expertise. Is it possible to reduce this ? By
maybe dynamically installing various packages needed ?
What is the size needed for live cds ? (Obviously less, since cds can't
be more than 750M.)
If we squash more than one DE on the same liveDVD there will be some
questions:
- Which DM will we use ? GDM? KDM? XDM? ...?
Then we get the complaints:
- "why should I need to download KDE stuff when I want GNOME"?
- "why should I need to download GNOME stuff when I want KDE"?
- "why ..."
So how does that differ from the current dvds ?
Isn't the idea of live isos to test and explore mageia ?
A live dvd would make it easier for users to look at various desktops
available.
Once one knows what one wants, a live iso isn't needed any more,
particularly since running a live iso is necessarily much slower than
running an installed system.
As well, even once one knows the desktop prefered, prefered packages
don't necessarily belong to that particular desktop.
and the technical side:
- stuffing more than one DE on liveDVDs means altering build process,
also giving more problem for little if any gain
- every DE on liveDVDs still need to be validated, so no less testing/QA
- it means testing G/K/XDM starting GNOME/KDE/... so no less testing/QA
- ...
The same testing, but less downloading for testers.
--
Thomas
--
André
Re: [Mageia-dev] Mageia 3 final set of isos
Op dinsdag 25 september 2012 01:21:05 schreef andre999: > Thomas Backlund a écrit : > > andre999 skrev 24.9.2012 09:57: > >> Anne Nicolas a écrit : > >>> Hi there > >>> > >>> So here is the discussion about what isos we should keep or have for > >>> final release. We had several (many!) proposals on that topics and we > >>> need to take some decisions. > >>> > >>> Here are some prerequisites I can see for what I can read in comments > >>> and review about Mageia on the web. > >>> > >>> - provide a full open source software version > >>> - provide CD iso(s) so that it can be quick to download (people having > >>> low band-width or paying depending how much they use it) > >>> - provide live version(s) > >>> - decrease isos number. QA is just a hell on the set we had for Mageia 2 > >>> - provide localization as large as possible > >>> - provide isos including major drivers including proprietary one to make > >>> it easier to install and configure > >> > >> ... > >> > >>> Please add all explanations to your proposal. > >>> > >>> Let say we take one week on this so until 26/09 then we will make a > >>> final proposal > >>> > >>> Cheers > >> > >> My suggestions : > >> *Non-live isos* > >> 1 dual cd with proprietory firmware/drivers > >> -- based on comments by Alien and others > >> > >> 1 dvd 32-bit with proprietory firmware/drivers > > > > you do realize that this is a no-go as we already have problem fitting > > even LXDE on dual isos (as you only have ~350M / arch for rpms and > > installer, so trying to load a lot of extra fw and drivers on wont work. iinm the dual-arch CD just needs a small few nonfree things, like hardware raid cards and a few network firmwares. but then the rescue also needs ip (for vlan) and brctl (for bridging)... (in all actuallity, i'm prepared here to drop all of small parts of LXDE and/or other graphic stuff). perhaps if we can unlink a few more cycles, we get enough free space... > > And yes, we already hardlink noarch packages > > For the dual cd I was just going on comments by others, but I can > understand the space problem. I wasn't anticipating multiple desktops > for that iso. Whatever works for those who use it, and those who create > it, is fine by me. > > It has occured to me that maybe it would be better to have 2 cds, one > each for 32-bit and 64-bit. That would make it a lot easier to find > enough space, and maybe even make it simpler to create ? It would add > another cd, but maybe not increase the workload. > Testing should be about the same. > (And carrying 2 cds in a pocket instead of one shouldn't be a problem.) > > As for the 32-bit dvd with proprietory firmware and drivers where > reliable free aren't available, I think that that is important. > > >> -- we could ask at the beginning something like > >> "This disc can install proprietory firmware or drivers needed by your > >> hardware. Do you want to : > >> 1) Install such software automatically, > >> 2) Ask for each such software, or > >> 3) Never install such software." > >> > >> That way users can accept or avoid such software as they wish. > >> At the same time, users will never be stuck. This will be particularly > >> useful for new users, especially those who found the dvd in a magazine. > >> Also users preferring no non-free, including firmware or drivers, could > >> simply resinstall accepting certain firmware/drivers after finding that > >> their hardware doesn't work properly. > > > > As with all suggestions to mod the installer, we still need someone to > > do the work, not just expect that "someone" will do it... > > True. > If all installers, and not just the live installers, carry the > proprietory firmware/drivers, maybe that will alleviate some of the > workload ? > BTW, I'm sure that we all appreciate your important contributions on this. > > > [...] > > >> *Live isos* > >> 1 live (installable like current dvds) dvd 64-bit with > >> kde/gnome/lxde/xfce and all localizations, and the proprietory > >> firmware/drivers now found on live cds. > >> -- variation of suggestion by Sander > >> -- this replaces both the current 64-bit dvd + 8 live cds > >> -- it seems much less likely that 64-bit users will have the download > >> bandwidth problems of many 32-bit users. (If I'm not mistaken.) > > > > You are kidding, right ? > > Just because they have a 64bit hw, it does not mean they have accees > > to cheap bw since that depends on where they live, what isp they have, > > and so on... > > I agree that having 64-bit hw doesn't necessarily mean one has cheap bw. > Just thought that it was more likely than many with 32-bit hw. > In any case, if they do have a problem, they could always use the 32-bit > version. But the converse is not true. > > >> -- users with 64-bit machines could still use a 32-bit live cd if they > >> wish. > >> -- This should save a lot of problems testing, as many potential testers > >> don't have 64-bit machines available. > >> > >> 8 live cd
Re: [Mageia-dev] Mageia 3 final set of isos
Thomas Backlund a écrit : andre999 skrev 24.9.2012 09:57: Anne Nicolas a écrit : Hi there So here is the discussion about what isos we should keep or have for final release. We had several (many!) proposals on that topics and we need to take some decisions. Here are some prerequisites I can see for what I can read in comments and review about Mageia on the web. - provide a full open source software version - provide CD iso(s) so that it can be quick to download (people having low band-width or paying depending how much they use it) - provide live version(s) - decrease isos number. QA is just a hell on the set we had for Mageia 2 - provide localization as large as possible - provide isos including major drivers including proprietary one to make it easier to install and configure ... Please add all explanations to your proposal. Let say we take one week on this so until 26/09 then we will make a final proposal Cheers My suggestions : *Non-live isos* 1 dual cd with proprietory firmware/drivers -- based on comments by Alien and others 1 dvd 32-bit with proprietory firmware/drivers you do realize that this is a no-go as we already have problem fitting even LXDE on dual isos (as you only have ~350M / arch for rpms and installer, so trying to load a lot of extra fw and drivers on wont work. And yes, we already hardlink noarch packages For the dual cd I was just going on comments by others, but I can understand the space problem. I wasn't anticipating multiple desktops for that iso. Whatever works for those who use it, and those who create it, is fine by me. It has occured to me that maybe it would be better to have 2 cds, one each for 32-bit and 64-bit. That would make it a lot easier to find enough space, and maybe even make it simpler to create ? It would add another cd, but maybe not increase the workload. Testing should be about the same. (And carrying 2 cds in a pocket instead of one shouldn't be a problem.) As for the 32-bit dvd with proprietory firmware and drivers where reliable free aren't available, I think that that is important. -- we could ask at the beginning something like "This disc can install proprietory firmware or drivers needed by your hardware. Do you want to : 1) Install such software automatically, 2) Ask for each such software, or 3) Never install such software." That way users can accept or avoid such software as they wish. At the same time, users will never be stuck. This will be particularly useful for new users, especially those who found the dvd in a magazine. Also users preferring no non-free, including firmware or drivers, could simply resinstall accepting certain firmware/drivers after finding that their hardware doesn't work properly. As with all suggestions to mod the installer, we still need someone to do the work, not just expect that "someone" will do it... True. If all installers, and not just the live installers, carry the proprietory firmware/drivers, maybe that will alleviate some of the workload ? BTW, I'm sure that we all appreciate your important contributions on this. [...] *Live isos* 1 live (installable like current dvds) dvd 64-bit with kde/gnome/lxde/xfce and all localizations, and the proprietory firmware/drivers now found on live cds. -- variation of suggestion by Sander -- this replaces both the current 64-bit dvd + 8 live cds -- it seems much less likely that 64-bit users will have the download bandwidth problems of many 32-bit users. (If I'm not mistaken.) You are kidding, right ? Just because they have a 64bit hw, it does not mean they have accees to cheap bw since that depends on where they live, what isp they have, and so on... I agree that having 64-bit hw doesn't necessarily mean one has cheap bw. Just thought that it was more likely than many with 32-bit hw. In any case, if they do have a problem, they could always use the 32-bit version. But the converse is not true. -- users with 64-bit machines could still use a 32-bit live cd if they wish. -- This should save a lot of problems testing, as many potential testers don't have 64-bit machines available. 8 live cds 32-bit; kde or gnome; 4 localisation groups -- users with 32-bit machines are more likely to have bandwidth problems, or to not have dvd writers. This totals 11 isos, down from 19. (reduced by 8 live cds.) Note that I didn't include an iso without proprietory firmware/drivers, as with appropriate warnings on those with, an iso without would be redundant. Just unnecessarily increasing the testing workload. Note also that it would be useful to have a file in the iso directory listing the languages available on the various live cds. (Lacking for mga2, but did exist for mandriva.) Not so... every livecd is has a matching *.lang: http://mirrors.kernel.org/mageia/iso/2/Mageia-2-LiveCD-GNOME-Europe1-Americas-i586-CD/Mageia-2-LiveCD-GNOME-Europe1-Americas-i586-CD.langs My mirror doesn't carry the *.lang files (mageia.web
Re: [Mageia-dev] new fonts?
On 2012-09-24 13:21 (GMT-0400) Liam R E Quin composed: . rendering quality - irregularities tend to be distracting and cause fatigue but people often say they like them at first; Rendering quality is highly influenced by screen pixel density. The higher the density, the more pixels are required to render any glyph at a given physical size. As density increases, the effects of smoothing techniques diminish, eventually having no impact if density is high enough or viewing distance is longer. Kerning, character spacing an accuracy also improve as density increases, causing glyphs to render more faithfully to their designs. The converse is that on low density screens, there's more variability that readers can be sensitive to. Those who are sensitive do well to upgrade to higher quality (higher pixel density) display devices. Even the apparent 20% jump from 100 to 120 can be striking. The reality is the density increase is a function of the squares of 100 and 120: 44%! -- "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] new fonts?
On 2012-09-24 16:58 (GMT+0400) Dimitri composed: The changes in default fonts might be related to recent fonts-ttf-liberation update. Since 2.00, this package ships fontconfig settings that by default substitute Liberation fonts for "sans-serif", "serif" and "mono" families. This is done by /etc/fonts/conf.d/59-liberation-*.conf files (in fact, just symlinks to /usr/share/fontconfig/conf.avail/59-liberation-*.conf). I am too much accustomed to my usual font set, so I trashed those symlinks immediately :) I keep my fontconfig priorities for serif, sans serif and monospace families set to the Google Droids, regardless what's been chosen by the distro. Running at 120 DPI or higher, all the legibly large enough sizes look great without much impact from font smoothing settings. The sizes too small to read anyway don't matter. -- "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] Problems with gnome-shell and polkit
On 09/24/2012 07:51 PM, Olav Vitters wrote: On Mon, Sep 24, 2012 at 12:42:58AM +0200, JA Magallón wrote: Perhaps polkit-gnome is out of sync ? From the .spec: # install the autostart file manually, since upstream doesn't ship it any more # and decided that it's the job of each DE to start polkit-gnome-authentication-agent-1 # this doesn't seem to apply to gnome-session in GNOME 2.32 # ACK'ed by pterjan # # this file was nicked from the gnome-polkit-0.99 binary rpm, to get all the translations # (ahmad) 02-05-2011 I removed the autostart file in a newly submitted polkit-gnome. Thanks !! BTW, do we need both polkit and policykit installed ? I can remove libpolkit2-0.9-8.mga1,policykit-0.9-8.mga1 without any problem. Should new version obsolete old one ? -- J.A. Magallon \ Winter is coming...
Re: [Mageia-dev] Mageia 3 final set of isos
Op maandag 24 september 2012 13:33:49 schreef Thomas Backlund:
> zezinho skrev 24.9.2012 12:52:
> > Em 24-09-2012 09:55, Thomas Backlund escreveu:
> >> Just because they have a 64bit hw, it does not mean they have accees
> >> to cheap bw since that depends on where they live, what isp they have,
> >> and so on...
> >
> > Well, we can't keep the same service to users without keeping the same
> > number of medias. And we NEED to reduce this number. So let's only
> > decide if DVD keeps without nonfree or not. A poll? Both choices will
> > keep the same numbers of medias.
>
> Sorry, my response got somewhat easy to misunderstand :)
>
> I meant it only as a response to the:
> "it seems much less likely that 64-bit users will have the download
> bandwidth problems of many 32-bit users."
>
> > As far as I can see, the easiest way to REDUCE media number is to switch
> > Live medias from 700MB to at most DVD size :
> >
> > - It removes the different localized version, it is 40% medias less.
> > - It does not remove ALL CD-R solutions, as we long as keep DualArch and
> > boot.iso media.
> > - It fits in most current USB keys (4GB is the lowest size I can see in
> > shops).
>
> But many people have only 1-2GB sticks they could re-use ...
> Not everyone can go out and buy new hw all the time...
>
> And the downside of getting bigger live images is that they
> do get slower to boot...
>
> > Yes, it removes supports for some old hardware solutions, which I
> > install often, but we can't keep testing 19 medias. We have still lack
> > of QA people!
>
> Yes, I know... I've been doing ISO qa :)
> we do need to reduce the media sets...
> which is why I earlier in this thread suggested:
> - 1 i586 GNOME english liveCD ("works everywhere")
> - 1 i586 KDE english liveCD ("works everywhere")
>
> - 1 i586 GNOME all-lang liveDVD
> - 1 i586 KDE all-lang liveDVD
>
> - 1 x86_64 GNOME all-lang liveDVD
> - 1 x86_64 KDE all-lang liveDVD
>
> That would bring the live* media down from 16 -> 6
>
>
> And as data point...
> With current mga2 livecd package config, building a liveDVD for one
> arch/DE results in a liveDVD image with ~ 1GB image size
>
>
> If we squash more than one DE on the same liveDVD there will be some
> questions:
>
> - Which DM will we use ? GDM? KDM? XDM? ...?
>
> Then we get the complaints:
> - "why should I need to download KDE stuff when I want GNOME"?
> - "why should I need to download GNOME stuff when I want KDE"?
> - "why ..."
how about adding 32bit/64bit to one liveDVD, bringing total livemedia to 4 ?
> and the technical side:
> - stuffing more than one DE on liveDVDs means altering build process,
>also giving more problem for little if any gain
> - every DE on liveDVDs still need to be validated, so no less testing/QA
> - it means testing G/K/XDM starting GNOME/KDE/... so no less testing/QA
> - ...
>
> --
>
> Thomas
[Mageia-dev] M3 won't complete boot after update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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 - -- 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/ iEYEARECAAYFAlBgssYACgkQj93fyh4cnBfLsQCfc533FaIzXCMGL3d/l6YRKWLF UJIAnA7gmR5+6+MdTmLv1COAgYej6DIJ =qnxG -END PGP SIGNATURE-
Re: [Mageia-dev] need some help to build a linuxsampler.rpm
On 23/09/12 21:16, zezinho wrote: "svn export" gives a better tarball... Yes - thanks for the correction - maybe even better to use: svn co https://svn.linuxsampler.org/svn/linuxsampler/trunk linuxsampler tar -czf linuxsampler.tar.gz linuxsampler/ --exclude-vcs .. which strips the svn stuff during tarball creation. This way the tree may be updated if required.
Re: [Mageia-dev] new fonts?
On Mon, 2012-09-24 at 18:34 +0100, brian.sm...@blueyonder.co.uk wrote: > I assume any default font should have the complete UTF8 Character set? This isn't really meaningful, because of unification - fonts implement glyphs, not characters, and there are a great many Unicode characters that represent multiple glyphs, mostly as a result of CJK (Chinese/Chinese/Japanese/Korean) unification. So the right answer is to have a set of fonts that overall provides the necessary coverage for scripts and languages that Mageia's users actually use. > Are the Liberation Font's UTF8 Complete? Strictly speaking UTF-8 is an encoding, a way of representing 32-bit integers in as few bytes (octets) as possible while still working with text tools; those 32-bit integers are Unicode "codepoints", indices into a table of characters published by the Unicode Consortium. Currently the table actually only needs I think 18 bits (more than 16 and less than 24 at any rate), but is still growing. Wikipedia says, [[ The Liberation family supports only the Latin, Greek, and Cyrillic alphabets, leaving out many writing systems. Extension to other writing systems is prevented by its unique licensing terms ]] [1] However, asking for a single typeface to have a unified design for Vietnamese, Hindi, Traditional Chinese, Simplified Chinese, Japanese, English, French, Czech, Cree, ... is a tall order. You'd also have a rather large font file (probably between 500M and a gigabyte). So, the best approach is to choose smaller fonts that work OK with each other and give the best coverage. Hope this helps. I responded to more than your question to try & help others see the issues too :-) Liam [1] http://en.wikipedia.org/wiki/Liberation_fonts -- 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] Problems with gnome-shell and polkit
On Mon, Sep 24, 2012 at 12:42:58AM +0200, JA Magallón wrote: > Perhaps polkit-gnome is out of sync ? >From the .spec: # install the autostart file manually, since upstream doesn't ship it any more # and decided that it's the job of each DE to start polkit-gnome-authentication-agent-1 # this doesn't seem to apply to gnome-session in GNOME 2.32 # ACK'ed by pterjan # # this file was nicked from the gnome-polkit-0.99 binary rpm, to get all the translations # (ahmad) 02-05-2011 I removed the autostart file in a newly submitted polkit-gnome. -- Regards, Olav
Re: [Mageia-dev] new fonts?
On Monday 24 Sep 2012 13:21:58 Liam R E Quin wrote: > On Mon, 2012-09-24 at 15:57 +0200, EatDirt wrote: > > I think we should pay attention to the default fonts we will choose for > > mga3, indeed. That's the very first reflex of any user, either you like, > > or you don't, that would even deserve a contest may be. > > You won't find a single set of fonts that works for everyone, and a > popular vote probably isn't the best way forward to choose one. > > On the other foot, a community effort around font packaging and > improving themes would likely have a huge benefit. > > Liam I assume any default font should have the complete UTF8 Character set? Are the Liberation Font's UTF8 Complete? Brian
Re: [Mageia-dev] new fonts?
On Mon, 2012-09-24 at 15:57 +0200, EatDirt wrote: > I think we should pay attention to the default fonts we will choose for > mga3, indeed. That's the very first reflex of any user, either you like, > or you don't, that would even deserve a contest may be. Reaction to typefaces depends on several factors - . familiarity (e.g. Europeans are generally more familiar with reading long texts in sans serif faces than Americans); . eyesight, contrast, lighting and viewing distance (this is especially true of whether antialiasing is considered a huge, 10,000 times improvement in readability or is considered an ugly distraction; . rendering quality - irregularities tend to be distracting and cause fatigue but people often say they like them at first; . culture (e.g. Cyrillic / Fraktur / Antiqua); . default font sizes and inter-linear spacing - unfortunately many applications don't give control over inter-linear spacing, showing that the programmers do not have a background in typography :-) There's a whole bunch of research that's been done around each of these factors (and more). You won't find a single set of fonts that works for everyone, and a popular vote probably isn't the best way forward to choose one. On the other foot, a community effort around font packaging and improving themes would likely have a huge benefit. 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 The barefoot typographer - http://www.holoweb.net/~liam/
Re: [Mageia-dev] new fonts?
On 24/09/12 14:58, Dimitri wrote: Hi guys, The changes in default fonts might be related to recent fonts-ttf-liberation update. Since 2.00, this package ships fontconfig settings that by default substitute Liberation fonts for "sans-serif", "serif" and "mono" families. This is done by /etc/fonts/conf.d/59-liberation-*.conf files (in fact, just symlinks to /usr/share/fontconfig/conf.avail/59-liberation-*.conf). I am too much accustomed to my usual font set, so I trashed those symlinks immediately :) Fantastic, thanks for the tips. I think we should pay attention to the default fonts we will choose for mga3, indeed. That's the very first reflex of any user, either you like, or you don't, that would even deserve a contest may be. cheers, chris.
Re: [Mageia-dev] new fonts?
Hi guys, The changes in default fonts might be related to recent fonts-ttf-liberation update. Since 2.00, this package ships fontconfig settings that by default substitute Liberation fonts for "sans-serif", "serif" and "mono" families. This is done by /etc/fonts/conf.d/59-liberation-*.conf files (in fact, just symlinks to /usr/share/fontconfig/conf.avail/59-liberation-*.conf). I am too much accustomed to my usual font set, so I trashed those symlinks immediately :) Cheers, Mitya
Re: [Mageia-dev] need some help to build a linuxsampler.rpm
Thomas Backlund a écrit : > > > > Actually the way to fix it is to look at the error to help narrow down > where the fix is needed: > > > > -- > Thomas I won ... I found that there is only one Makefile.in to modify 1 chance among more that 2 millions combinations ... and I did it, thanks for your help !! I'm gonna go and win lot of money in the casino now ! ;) and I will share the won money with you... Philippe
Re: [Mageia-dev] Mageia 3 final set of isos
Thomas Backlund writes: > and the technical side: > - stuffing more than one DE on liveDVDs means altering build process, It should be fine already. IIRC, dual-desktop live systems were done at Mandriva. > also giving more problem for little if any gain > - every DE on liveDVDs still need to be validated, so no less testing/QA > - it means testing G/K/XDM starting GNOME/KDE/... so no less testing/QA It will still factorize the drivers/basesystem testing. But there will be issues at the install part: - it will last longer, because it is basically a "cp" of the uncompressed live system, the more DE and langs you put, the longer it will take - it will require much more disk space, since that kind of install process without handling packages makes hard to unselect languages or desktops -- Olivier Blin - blino
Re: [Mageia-dev] need some help to build a linuxsampler.rpm
Thomas Backlund a écrit : > PhilippeDidier skrev 24.9.2012 14:25: >> >> Hey ! You ! you are a happiness breaker :-( >> > > [...] >> >> Argh ! >> You killed me ;-( >> > > Nope, just showing how to learn about and fix some problems :) > >> Mageia will have to wait for sometime :... >> There are 21 makefiles >> There are 0 or 1 or 2 links to add to them (but which of them really >> need the added links ?) >> Than means some combinations to try : >> 2 square to the power of 21 = 2097152 if I blindly test all of them ! >> If I win early I will try the casino >> ;-) >> >> I will try a rational approach to decrease the number of tests to do... >> > > > > Actually the way to fix it is to look at the error to help narrow down > where the fix is needed: > > ../src/plugins/.libs/liblinuxsamplerplugins.a(InstrumentEditorFactory.o): In > > function `__exchange_and_add_dispatch': > /usr/lib/gcc/i586-mageia-linux-gnu/4.6.3/../../../../include/c++/4.6.3/ext/atomicity.h:80: > > undefined reference to `pthread_cancel' > > ../src/common/.libs/liblinuxsamplercommon.a(Path.o): In function > `__exchange_and_add_dispatch': > /usr/lib/gcc/i586-mageia-linux-gnu/4.6.3/../../../../include/c++/4.6.3/ext/atomicity.h:80: > > undefined reference to `pthread_cancel' > > > so the files that uses "pthread_cancel", need linking help. > in this case the Makefiles responsible for the build of > "liblinuxsamplerplugins" and "liblinuxsamplercommon" are the > ones you need to fix.. > > > Same goes for the: > "There came now undefined references to 'dlopen' 'dlerror' 'dlclose' > > I had to add -ldl to each Makefile.in" > > > -- > Thomas > > > Thanks again ! I was thinking about this rational approach ... Thank you for affording some humour too ;)
Re: [Mageia-dev] need some help to build a linuxsampler.rpm
PhilippeDidier skrev 24.9.2012 14:25: Hey ! You ! you are a happiness breaker :-( [...] Argh ! You killed me ;-( Nope, just showing how to learn about and fix some problems :) Mageia will have to wait for sometime :... There are 21 makefiles There are 0 or 1 or 2 links to add to them (but which of them really need the added links ?) Than means some combinations to try : 2 square to the power of 21 = 2097152 if I blindly test all of them ! If I win early I will try the casino ;-) I will try a rational approach to decrease the number of tests to do... Actually the way to fix it is to look at the error to help narrow down where the fix is needed: ../src/plugins/.libs/liblinuxsamplerplugins.a(InstrumentEditorFactory.o): In function `__exchange_and_add_dispatch': /usr/lib/gcc/i586-mageia-linux-gnu/4.6.3/../../../../include/c++/4.6.3/ext/atomicity.h:80: undefined reference to `pthread_cancel' ../src/common/.libs/liblinuxsamplercommon.a(Path.o): In function `__exchange_and_add_dispatch': /usr/lib/gcc/i586-mageia-linux-gnu/4.6.3/../../../../include/c++/4.6.3/ext/atomicity.h:80: undefined reference to `pthread_cancel' so the files that uses "pthread_cancel", need linking help. in this case the Makefiles responsible for the build of "liblinuxsamplerplugins" and "liblinuxsamplercommon" are the ones you need to fix.. Same goes for the: "There came now undefined references to 'dlopen' 'dlerror' 'dlclose' I had to add -ldl to each Makefile.in" -- Thomas
Re: [Mageia-dev] need some help to build a linuxsampler.rpm
Thomas Backlund a écrit : >>> writes: >> Hello ! >> Some news : >> Indeed it was more difficult than I thought : >> There were 21 different Makefile.in in 21 directories to modify : >> I wrote a patch that replaces >> -LDFLAGS = @LDFLAGS@ >> by >> +LDFLAGS = @LDFLAGS@ -lpthread >> in each of them... >> > > And now you are overlinking :) > > You only need to patch the Makefile(s) that is responsible for > building the code that relies on pthread > Hey ! You ! you are a happiness breaker :-( > >> Now each Makefile contains : >> LDFLAGS = -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-O1 >> -Wl,--build-id -Wl,--enable-new-dtags -lpthread >> >> >> And I discover that my first workaround was indeed bad : >> I used >> %build >> %configure2_5x >> %make LDFLAGS="-lpthread" >> >> instead of >> %build >> %configure2_5x >> %make >> >> this allowed to package and I felt happy ;) ... but wrongly happy :( >> >> >> Now that I use a correct LDFLAGS I got new errors about other undefined >> references (thanks to --as-needed option) >> ... and I feel sad :( >> >> There came now undefined references to 'dlopen' 'dlerror' 'dlclose' >> >> I had to add -ldl to each Makefile.in >> > > And overlinking again :) > Argh ! You killed me ;-( >> And now it's OK >> >> Thanks to all of you ! I'm now less ignorant than I was ... >> >> But packaging for Mageia will need more skill and more time than for >> Mandriva ... and more patches ! (hope it's worth of it) >> > > Of course it is worth it... > By finding and fixing issues like this (and also send the fix upstream) > the quality of the code is improving... > > -- > > Thomas > You gave me some more work indeed : >> I will provide my spec and patch files to anyone (perhaps through >> bugzilla with a package request) > Mageia will have to wait for sometime :... There are 21 makefiles There are 0 or 1 or 2 links to add to them (but which of them really need the added links ?) Than means some combinations to try : 2 square to the power of 21 = 2097152 if I blindly test all of them ! If I win early I will try the casino ;-) I will try a rational approach to decrease the number of tests to do... Anyway... Did you think that inactivating the --as needed option will imply so much time to build only one package ? I really am afraid with this ! > > Regards Philippe
Re: [Mageia-dev] new fonts?
On Sun, 23 Sep 2012 11:30:49 +0200 eatdirt wrote: > Hi, > is that a bug that all default fonts on kdm, firefox, terminal titles > changed to an ugly one? ;) > I noticed the change too on my system - Mageia 3/Cauldron x86-64 , KDE 4.9.1, Core i3 machine. Regards, Shlomi Fish > cheers, > chris. > -- - Shlomi Fish http://www.shlomifish.org/ Original Riddles - http://www.shlomifish.org/puzzles/ I am not solvable. I am Turing hard. Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: [Mageia-dev] Problems with gnome-shell and polkit
On 09/24/2012 12:42 AM, JA Magallón wrote:
Hi...
After latest updates GDM works again, but
I get a sad-computer-screen-of-death when I try to log in in Gnome.
The culprit seems to be the gnome-shell / polkit interaction.
With startx from vconsole I get this on .xsession-errors:
Window manager warning: Log level 16: Unable to register authentication agent:
GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: An authentication agent
already exists for the given subject
JS ERROR: !!! Exception was: Polkit.Error:
GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: An authentication agent
already exists for the given subject
JS ERROR: !!! message =
'"GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: An authentication agent
already exists for the given subject"'
JS ERROR: !!! fileName =
'"/usr/share/gnome-shell/js/ui/components/polkitAgent.js"'
JS ERROR: !!! lineNumber = '329'
JS ERROR: !!! stack = '"0
anonymous()@/usr/share/gnome-shell/js/ui/components/polkitAgent.js:329
1 wrapper()@/usr/share/gjs-1.0/lang.js:204
2 anonymous("name" =
""polkitAgent"")@/usr/share/gnome-shell/js/ui/components/__init__.js:56
3 wrapper(""polkitAgent"")@/usr/share/gjs-1.0/lang.js:204
4 anonymous("name" = ""polkitAgent"", 1, [object
Array])@/usr/share/gnome-shell/js/ui/components/__init__.js:22
5 anonymous()@/usr/share/gnome-shell/js/ui/components/__init__.js:21
6 wrapper()@/usr/share/gjs-1.0/lang.js:204
7 anonymous()@/usr/share/gnome-shell/js/ui/components/__init__.js:13
8 wrapper()@/usr/share/gjs-1.0/lang.js:204
9 anonymous()@/usr/share/gjs-1.0/lang.js:145
10 anonymous()@/usr/share/gjs-1.0/lang.js:239
11 start()@/usr/share/gnome-shell/js/ui/main.js:150
12 @:1
"'
If I comment this in /usr/share/gnome-shell/js/ui/components/polkitAgent.js, at
least I
can log in again:
enable: function() {
//this._native.register();
},
disable: function() {
//this._native.unregister();
},
I have this versions of polkit:
lib64polkit1_0-0.107-1.mga3 x86_64
lib64polkit-gir1.0-0.107-1.mga3 x86_64
polkit-0.107-1.mga3 x86_64
polkit-desktop-policy-0.107-1.mga3 noarch
polkit-gnome-0.105-1.mga2 x86_64
Perhaps polkit-gnome is out of sync ?
TIA
From what I looked in Google, they are all the latest versions.
I solved the issue uncomenting those lines and adding this:
AutostartCondition=GNOME3 unless-session gnome
in /etc/xdg/autostart/polkit-gnome-authentication-agent-1.desktop, as
explained here:
http://www.linuxfromscratch.org/blfs/view/svn/gnome/polkit-gnome.html
Is this right for Mageia, or should the tags "GNOME3" and "gnome" changed
to something else ? Is this worth a bug report ?
TIA
--
J.A. Magallon \ Winter is coming...
Re: [Mageia-dev] Mageia 3 final set of isos
zezinho skrev 24.9.2012 12:52:
Em 24-09-2012 09:55, Thomas Backlund escreveu:
Just because they have a 64bit hw, it does not mean they have accees
to cheap bw since that depends on where they live, what isp they have,
and so on...
Well, we can't keep the same service to users without keeping the same
number of medias. And we NEED to reduce this number. So let's only
decide if DVD keeps without nonfree or not. A poll? Both choices will
keep the same numbers of medias.
Sorry, my response got somewhat easy to misunderstand :)
I meant it only as a response to the:
"it seems much less likely that 64-bit users will have the download
bandwidth problems of many 32-bit users."
As far as I can see, the easiest way to REDUCE media number is to switch
Live medias from 700MB to at most DVD size :
- It removes the different localized version, it is 40% medias less.
- It does not remove ALL CD-R solutions, as we long as keep DualArch and
boot.iso media.
- It fits in most current USB keys (4GB is the lowest size I can see in
shops).
But many people have only 1-2GB sticks they could re-use ...
Not everyone can go out and buy new hw all the time...
And the downside of getting bigger live images is that they
do get slower to boot...
Yes, it removes supports for some old hardware solutions, which I
install often, but we can't keep testing 19 medias. We have still lack
of QA people!
Yes, I know... I've been doing ISO qa :)
we do need to reduce the media sets...
which is why I earlier in this thread suggested:
- 1 i586 GNOME english liveCD ("works everywhere")
- 1 i586 KDE english liveCD ("works everywhere")
- 1 i586 GNOME all-lang liveDVD
- 1 i586 KDE all-lang liveDVD
- 1 x86_64 GNOME all-lang liveDVD
- 1 x86_64 KDE all-lang liveDVD
That would bring the live* media down from 16 -> 6
And as data point...
With current mga2 livecd package config, building a liveDVD for one
arch/DE results in a liveDVD image with ~ 1GB image size
If we squash more than one DE on the same liveDVD there will be some
questions:
- Which DM will we use ? GDM? KDM? XDM? ...?
Then we get the complaints:
- "why should I need to download KDE stuff when I want GNOME"?
- "why should I need to download GNOME stuff when I want KDE"?
- "why ..."
and the technical side:
- stuffing more than one DE on liveDVDs means altering build process,
also giving more problem for little if any gain
- every DE on liveDVDs still need to be validated, so no less testing/QA
- it means testing G/K/XDM starting GNOME/KDE/... so no less testing/QA
- ...
--
Thomas
Re: [Mageia-dev] Mageia 3 final set of isos
Em 24-09-2012 09:55, Thomas Backlund escreveu: Just because they have a 64bit hw, it does not mean they have accees to cheap bw since that depends on where they live, what isp they have, and so on... Well, we can't keep the same service to users without keeping the same number of medias. And we NEED to reduce this number. So let's only decide if DVD keeps without nonfree or not. A poll? Both choices will keep the same numbers of medias. As far as I can see, the easiest way to REDUCE media number is to switch Live medias from 700MB to at most DVD size : - It removes the different localized version, it is 40% medias less. - It does not remove ALL CD-R solutions, as we long as keep DualArch and boot.iso media. - It fits in most current USB keys (4GB is the lowest size I can see in shops). Yes, it removes supports for some old hardware solutions, which I install often, but we can't keep testing 19 medias. We have still lack of QA people!
Re: [Mageia-dev] new fonts?
On 23/09/12 14:28, brian.sm...@blueyonder.co.uk wrote: I noticed the change... but on my machine it looks like an improvement I don't know if just my eyesight or the change is having different effects on different set ups. I'm using X86-64 with a Radeon graphics card On 24/09/12 08:31, Liutauras Adomaitis wrote: It is not ugly for me, but some char like ", : are not displayed correctly on Firefox. Not sure if this is related. Thanks for your answers! On my system it is indeed quite bad, the font is smaller than before and aliased which makes it tiring to read. I am using "ati" driver. Does someone knows how to set the font, or revert to the old one? Cheers, Chris.
Re: [Mageia-dev] Mageia 3 final set of isos
andre999 skrev 24.9.2012 09:57: Anne Nicolas a écrit : Hi there So here is the discussion about what isos we should keep or have for final release. We had several (many!) proposals on that topics and we need to take some decisions. Here are some prerequisites I can see for what I can read in comments and review about Mageia on the web. - provide a full open source software version - provide CD iso(s) so that it can be quick to download (people having low band-width or paying depending how much they use it) - provide live version(s) - decrease isos number. QA is just a hell on the set we had for Mageia 2 - provide localization as large as possible - provide isos including major drivers including proprietary one to make it easier to install and configure ... Please add all explanations to your proposal. Let say we take one week on this so until 26/09 then we will make a final proposal Cheers My suggestions : *Non-live isos* 1 dual cd with proprietory firmware/drivers -- based on comments by Alien and others 1 dvd 32-bit with proprietory firmware/drivers you do realize that this is a no-go as we already have problem fitting even LXDE on dual isos (as you only have ~350M / arch for rpms and installer, so trying to load a lot of extra fw and drivers on wont work. And yes, we already hardlink noarch packages -- we could ask at the beginning something like "This disc can install proprietory firmware or drivers needed by your hardware. Do you want to : 1) Install such software automatically, 2) Ask for each such software, or 3) Never install such software." That way users can accept or avoid such software as they wish. At the same time, users will never be stuck. This will be particularly useful for new users, especially those who found the dvd in a magazine. Also users preferring no non-free, including firmware or drivers, could simply resinstall accepting certain firmware/drivers after finding that their hardware doesn't work properly. As with all suggestions to mod the installer, we still need someone to do the work, not just expect that "someone" will do it... -- It seems unlikely that magazines would care about the free/nonfree issue, as long as the software is redistributable without cost. And I'm only talking about firmware/drivers where a reliable free version doesn't exist. *Live isos* 1 live (installable like current dvds) dvd 64-bit with kde/gnome/lxde/xfce and all localizations, and the proprietory firmware/drivers now found on live cds. -- variation of suggestion by Sander -- this replaces both the current 64-bit dvd + 8 live cds -- it seems much less likely that 64-bit users will have the download bandwidth problems of many 32-bit users. (If I'm not mistaken.) You are kidding, right ? Just because they have a 64bit hw, it does not mean they have accees to cheap bw since that depends on where they live, what isp they have, and so on... -- users with 64-bit machines could still use a 32-bit live cd if they wish. -- This should save a lot of problems testing, as many potential testers don't have 64-bit machines available. 8 live cds 32-bit; kde or gnome; 4 localisation groups -- users with 32-bit machines are more likely to have bandwidth problems, or to not have dvd writers. This totals 11 isos, down from 19. (reduced by 8 live cds.) Note that I didn't include an iso without proprietory firmware/drivers, as with appropriate warnings on those with, an iso without would be redundant. Just unnecessarily increasing the testing workload. Note also that it would be useful to have a file in the iso directory listing the languages available on the various live cds. (Lacking for mga2, but did exist for mandriva.) Not so... every livecd is has a matching *.lang: http://mirrors.kernel.org/mageia/iso/2/Mageia-2-LiveCD-GNOME-Europe1-Americas-i586-CD/Mageia-2-LiveCD-GNOME-Europe1-Americas-i586-CD.langs And this page lists the langs on the isos too: http://www.mageia.org/en/downloads/ A final point - to me it is really important to be able to upgrade an existing installation, instead of forcing a clean install. This allows DVDs and netinstalls already support upgrades... (DVDs will still always have some problem unless you add online medias, as we cant fit all of the online repos on the DVDs) The mga3 upgrade path will need more work due to UsrMove, but it should still be possible... the user to more easily keep their current configuration, and in some cases essential drivers/firmware not on the iso. Referring to the dvds and the dual cd, and not the live cds, which are not primarily for installation. I guess you mean livecds _are_ meant for installation, not upgrades -- Thomas
Re: [Mageia-dev] Any progress on the NFS mount problem? - One step further
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24/09/12 08:26, Thierry Vignaud wrote: > On 23 September 2012 11:18, Anne Wilson > wrote: Package nfs-utils blahblah is already installed >>> nfs-common service, sorry. >>> >> That may well point to the problem, though I've no idea what >> needs doing to solve it: >> >> service nfs-commons status Cannot find nfs-commons service > > that's "nfs-common" without a "s" at end... Yes - you'll see that I immediately realised that. I didn't intend to include that bit in the quote, though. The rest of it is what I wanted to show you. 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/ iEYEARECAAYFAlBgEMoACgkQj93fyh4cnBfDrgCcCb37z14VJcUd79dedkXWmaeC UuMAn3AyhtQl+rj73b+JDuvpFeGteOm+ =wKIG -END PGP SIGNATURE-
Re: [Mageia-dev] Any progress on the NFS mount problem? - One step further
On 23 September 2012 11:18, Anne Wilson wrote: >>> Package nfs-utils blahblah is already installed >> nfs-common service, sorry. >> > That may well point to the problem, though I've no idea what needs > doing to solve it: > > service nfs-commons status > Cannot find nfs-commons service that's "nfs-common" without a "s" at end...
Re: [Mageia-dev] Mageia 3 final set of isos
Anne Nicolas a écrit : Hi there So here is the discussion about what isos we should keep or have for final release. We had several (many!) proposals on that topics and we need to take some decisions. Here are some prerequisites I can see for what I can read in comments and review about Mageia on the web. - provide a full open source software version - provide CD iso(s) so that it can be quick to download (people having low band-width or paying depending how much they use it) - provide live version(s) - decrease isos number. QA is just a hell on the set we had for Mageia 2 - provide localization as large as possible - provide isos including major drivers including proprietary one to make it easier to install and configure ... Please add all explanations to your proposal. Let say we take one week on this so until 26/09 then we will make a final proposal Cheers My suggestions : *Non-live isos* 1 dual cd with proprietory firmware/drivers -- based on comments by Alien and others 1 dvd 32-bit with proprietory firmware/drivers -- we could ask at the beginning something like "This disc can install proprietory firmware or drivers needed by your hardware. Do you want to : 1) Install such software automatically, 2) Ask for each such software, or 3) Never install such software." That way users can accept or avoid such software as they wish. At the same time, users will never be stuck. This will be particularly useful for new users, especially those who found the dvd in a magazine. Also users preferring no non-free, including firmware or drivers, could simply resinstall accepting certain firmware/drivers after finding that their hardware doesn't work properly. -- It seems unlikely that magazines would care about the free/nonfree issue, as long as the software is redistributable without cost. And I'm only talking about firmware/drivers where a reliable free version doesn't exist. *Live isos* 1 live (installable like current dvds) dvd 64-bit with kde/gnome/lxde/xfce and all localizations, and the proprietory firmware/drivers now found on live cds. -- variation of suggestion by Sander -- this replaces both the current 64-bit dvd + 8 live cds -- it seems much less likely that 64-bit users will have the download bandwidth problems of many 32-bit users. (If I'm not mistaken.) -- users with 64-bit machines could still use a 32-bit live cd if they wish. -- This should save a lot of problems testing, as many potential testers don't have 64-bit machines available. 8 live cds 32-bit; kde or gnome; 4 localisation groups -- users with 32-bit machines are more likely to have bandwidth problems, or to not have dvd writers. This totals 11 isos, down from 19. (reduced by 8 live cds.) Note that I didn't include an iso without proprietory firmware/drivers, as with appropriate warnings on those with, an iso without would be redundant. Just unnecessarily increasing the testing workload. Note also that it would be useful to have a file in the iso directory listing the languages available on the various live cds. (Lacking for mga2, but did exist for mandriva.) A final point - to me it is really important to be able to upgrade an existing installation, instead of forcing a clean install. This allows the user to more easily keep their current configuration, and in some cases essential drivers/firmware not on the iso. Referring to the dvds and the dual cd, and not the live cds, which are not primarily for installation. my 2 cents :) -- André
