Re: [Mageia-dev] Mailing list migration: this list is closing

[Christian Lohmaier]

Hi *,

On Mon, Apr 8, 2013 at 12:54 AM, Mageia Sysadmins
 wrote:
>
> This mailing list will be closed in coming hours and is now replaced by
> d...@ml.mageia.org.

Too bad you didn't keep the list-id the same, so people have to adapt
their filters and mail-archives need to be manually mapped...

ciao
Christian

Re: [Mageia-dev] HEADSUP: Full git clone of all package specs (with history)

[Christian Lohmaier]

Hi Colin, *,

On Fri, Apr 5, 2013 at 8:46 AM, P. Christeas  wrote:
> On Saturday 23 March 2013, Colin Guthrie wrote:
>> 'Twas brillig, and Colin Guthrie at 22/03/13 09:32 did gyre and gimble:
>> [...]
>> > Just to avoid a crazy amount of scripting with svn checkouts and such
>> > like, I've set running a git svn clone of the cauldron package
>> > subversion tree.
>>
>> That said, running git blame takes *ages* even on an SSD drive. It was
>> at least a couple minutes to display the results of a blame on a spec file.
>
>  Let me remind you of the other suggestion:
>  Put each package in a separate git repo, and then use "submodules" to bind
> all of them together into the "Mageia" repo..

Somewhat surprised that it takes so long - LO's core repo is much
larger and is reasonably fast, even on traditional disk.
Maybe git maintenance commands (gc and/or prune) may help? Care
uploading the repo to github or similar?

And I'd not put every package into submodules, as those are not /that/
easy to work with - but maybe splitting by alphabet might indeed be a
good idea. (pagackages starting with A or a in one module, B or b in
another, etc.) So you need only 27 subrepos instead of lots and
lots...

ciao
Christian

Re: [Mageia-dev] Ibus bug

[Christian Lohmaier]

Hi *,

On Tue, Apr 2, 2013 at 1:54 PM, Anne Nicolas  wrote:
>
> It seems Mageia 2 at least got some regression on ibus for our japanese
> users
> https://bugs.mageia.org/show_bug.cgi?id=9073
>
> If you are familiar with ibus can you please have a look on it

FYI: I don't have any problem with anthy in GNOME. When the system is
under high load, it takes a while to switch the method, so sometimes
I'm too inpatient and switch twice (i.e. immediately turn back to
regular mode) - but  that's my personal problem, not one with ibus or
anthy :-)

$ rpm -qa |grep anthy
lib64anthy0-9100h-25.20110409.1.mga2
ibus-anthy-1.2.6-1.mga2
anthy-9100h-25.20110409.1.mga2

ciao
Christian

PS: nice that the mailinglist settings have been fixed re nonsubscribed posters

Re: [Mageia-dev] Script for rediffing patches

[Christian Lohmaier]

Hi Anssi, *,

On Sun, Mar 31, 2013 at 11:17 PM, Anssi Hannula  wrote:
>
> Colin's question reminded me of another hacky script I use for rediffing
> patches.

OOo / LO used a tool to minimize changes between patches (i.e. ignore
different timestamps (or different date-formats) when the change
itself still is the same, avoid huge diffs because different order of
files in old version of the patch vs the new one, etc):
http://opengrok.libreoffice.org/xref/core/solenv/bin/patch_sanitizer.pl

Now mostly obsolete for LibreOffice, as LO's buildsystem allows
multiple separate patches, and there is no need to change existing
patches when adding some more.

So it isn't really the same usecase, but maybe you find it helpful nevertheless.

ciao
Christian

[Mageia-dev] Changelog entries - why not delimited by release/build?

[Christian Lohmaier]

Hi *,

I wondered about this for quite some time.. When you view the
changelog when updating your system, it is very hard to see what
actually did change in that new release.

For example the current cups update:
Version available: 1.5.4-1.1.mga2
currently installed: 1.5.4-1.mga2

Changelog:
   * So 16 Dez 2012 13:00:00 CET oden  1.5.4-1.1.mga2

+ Revision: 331722
- P103: attempt to fix #8318 (some usb printers stopped working)
- 1.5.4
- sync patches and some changes from cauldron
- P102: security fix for CVE-2012-5519 (upstream, redhat)
- merge spec file changes from fedora to deal with the new
cups-files.conf file

  + guillomovitch 
- add upstream patches to fix #4673

  + tmb 
- Require rpm-helper >= 0.24.8-1 for systemd support

* Fr 27 Apr 2012 14:00:00 CEST tmb  1.5.2-4.mga2

+ Revision: 233546
[]

So what did actually change between 1.5.4-1.mga2 to 1.5.4-1.1.mga2?

This time there is a hint about a major version bump in an update, so
I can only assume the change is only "P103: attempt to fix #8318 (some
usb printers stopped working)"
(what does P# stand for btw? Is there a list of annotations used in changelogs?)

Why aren't changelogs separated by actual release?

ciao
Christian

[Mageia-dev] Fwd: [Bug 8426] mlocate - cron should use idle i/o priority

[Christian Lohmaier]

Hi *,

bringing it to the list as suggested.

So anyone who thinks it would be a bad idea to run the mlocate cronjob
in IDLE i/o class?

ciao
Christian

-- Forwarded message --
From: David Walser 
Date: Tue, Dec 18, 2012 at 11:09 PM
Subject: [Bug 8426] mlocate - cron should use idle i/o priority
To: lohmaier+mag...@googlemail.com


https://bugs.mageia.org/show_bug.cgi?id=8426

David Walser  changed:

   What|Removed |Added

 CC||luigiwal...@yahoo.com

--- Comment #1 from David Walser  2012-12-18
23:09:32 CET ---
This sounds reasonable to me.  Maybe send a mail to the mageia-dev mailing list
and see if anyone can think of any reason not to do this?  If no objections, I
can make the change.

--
Configure bugmail: https://bugs.mageia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You reported the bug.

Re: [Mageia-dev] Mailing-list archives and robots

[Christian Lohmaier]

 Hi Sander, *,

On Mon, Nov 26, 2012 at 4:08 PM, Sander Lepik  wrote:
>
> Good point! So we are probably missing links to our archives (as i can't
> find anything that links to mageia-dev archives).

Not only that, it is also just misconfigured.
Mail-headers contain:

List-Archive: 

Thankfully there also is

List-Subscribe: ,


And that in turn has a archive-link.

But also moderators of the list need to be setup, or the list needs to
be configured to immediately reject mails from non-subscribers.

None of my mails where I forgot to set correct from-address was
approved by a moderator, and for none of those there was a
notification that it would have been rejected.

So if you don't want mails from non-subscribers or have no moderators
to process mails → configure the list accordingly.

ciao
Christian

Re: [Mageia-dev] Repo down: repository fallback by default...

[Christian Lohmaier]

Hi *,

On Fri, Nov 9, 2012 at 7:50 AM, Jehan Pagès  wrote:
>
> So I guess the repo is down, hopefully temporarily. I went to the "configure
> media sources" UI and "add a specific media mirror" (was using the
> $MIRRORLIST default until now).
>
> So my real question is: couldn't the $MIRRORLIST fallback to other servers
> than the "closer" instead of failing?

https://bugs.mageia.org/show_bug.cgi?id=3166

would solve all that

ciao
Christian

Re: [Mageia-dev] Fwd: fallback mode

[Christian Lohmaier]

Hi *,

On Tue, Nov 6, 2012 at 1:33 AM, andre999  wrote:
> Olav Vitters a écrit :
>> On Mon, Nov 05, 2012 at 06:56:55PM -0500, andre999 wrote:
>>> Olav Vitters a écrit :
>> [...]
>
> Nothing in the visual appearance of gnome3 could not be displayed
> efficiently on gnome2 on machines without hardware acceleration of display,
> so there is obviously a problem with the implementation in gnome3, at least
> up to version 3.4

Just FYI: It is not only display performance of gnome itself, but also
driver bugs that only trigger in 3d-destkop environment.

I for example have non-smooth video-playback ("stutter" when there are
pans, as if it would not display frames like "*   *   *   *   *" but
more like "****  * **". Playback is flawless in fallback
mode. Unfortunately the problem is minor after reboot, and slowly gets
worse with uptime (restarting gnome-shell using +,r,
also helps somewhat, as does using
CLUTTER_PAINT=disable-clipped-redraws:disable-culling and
CLUTTER_VBLANK=True
(black magic variables found via google that help to solve all sorts
of problems (that don't occur here, like tearing), esp. don't see the
relation between vblank and the other one, as they only have an impact
when used in combination..


Long story short: performance/rendering of gnome itself is not the
actual problem, it is those little driver-bugs that can spoil the
party... (I had created a separate account with gnome-fallback just
for the usecase of watching videos - don't use that for regular
watching anymore, but still when I need to check videos for
encoding/playback errors)

ciao
Christian

Re: [Mageia-dev] Fwd: fallback mode

[Christian Lohmaier]

Hi *,

On Mon, Nov 5, 2012 at 6:58 PM, Olav Vitters  wrote:
>
> -- Forwarded message --
> From: Matthias Clasen 
> To: distributor-l...@gnome.org
> Cc: GNOME release team 
> [...]
> - move background rendering entirely into gnome-shell; this is most
> likely to cause some problems for other environments that reuse g-s-d
> for background rendering. Splitting off the desktop-rendering
> functionality from nautilus is a separate issue, and does not
> necessarily have to happen for 3.8.

Please clarify whether that means no more desktop-icons.

ciao
Christian

Re: [Mageia-dev] cinelerra/audiokonverter/arista (war Re: rehashing the faac issue)

[Christian Lohmaier]

Hi Olivier, *,

On Fri, Nov 2, 2012 at 12:05 AM, Olivier Blin  wrote:
> Christian Lohmaier  writes:
>> On Thu, Nov 1, 2012 at 1:56 PM, Wolfgang Bornath  
>> wrote:
>>> [...]
>>> After reading all arguments again I must confess that I changed my
>>> opinion: Being consequent and following our road we need a
>>> /tainted-free and a /tainted-nonfree branch.
>>
>> I still think this would be a very user-*un*friendly way to handle it.
>>
> [...]
>> Much better would then be to create an "ugly" repo (in the spirit of
>> gstreamer) that contains the "doesn't fit into the other repos" stuff.
>
> That's just a naming issue then, are you just suggesting to rename the
> "tainted-nonfree" repository proposal as "ugly"?

No - my point was that I think a split of tainted into tainted-free
and tainted-nonfree is pointless and not user-friendly.
I only want one repository for the "problematic" stuff.

Not naming it "tainted" is just because what ends up there is not only
stuff that really is tainted, but also packages that just depend on
tainted ones.

> If we go for the "tainted + nonfree" way, its definition should be that
> it contains packages that:
> (1) are both tainted and not free software
> or
> (2) packages having a hard requirement on packages from (1)

See - and that from my POV is pointless. so the tainted+nonfree
contains a happy mixture of tainted and non-tainted, all variants of
free to tainted-nonfree.

I just don't see the point in splitting "tainted" repo that way (other
than that bureaucratic thing that I as a user think is superfluous)

ciao
Christian

Re: [Mageia-dev] cinelerra/audiokonverter/arista (war Re: rehashing the faac issue)

[Christian Lohmaier]

Hi Wolfgang, *,

On Thu, Nov 1, 2012 at 1:56 PM, Wolfgang Bornath  wrote:
> [...]
> After reading all arguments again I must confess that I changed my
> opinion: Being consequent and following our road we need a
> /tainted-free and a /tainted-nonfree branch.

I still think this would be a very user-*un*friendly way to handle it.

You cannot put packages that itself is "free", but depends on
"tainted&nonfree" packages into the "free" repo, since the core repos
need to be self-contained.

The natural approach would then be to put that package into the same
repo as the packages that fulfill the requirement.

If now you have two tainted repositories, one "free" and one
"non-free", you would put the "free with dependencies" package into
the tainted-free repo. But it itself isn't tainted, so actually
wouldn't belong in there. But even when you have tainted-free enabled,
and you try to install the package, you need to enable the
tainted-nonfree one.
Or you put it into tainted-nonfree to keep the repos more
self-contained, but then the distinction is rendered useless, as
packages end up there for completely different reasons.

And if you have to enable both tainted variants anyway, there is no
point in having them separate in the first place other than to please
some bureaucratic nitpicking.

So by creating a tainted-nonfree repo that only a handful of packages
actually belong into anyway, you create a situation of non-satisfiable
dependencies that make the distinction pointless from a user-POV.

Much better would then be to create an "ugly" repo (in the spirit of
gstreamer) that contains the "doesn't fit into the other repos" stuff.

AFAIK only multimedia related stuff falls into tainted-nonfree. And it
is either you want to use it or not. If you want to use it, the user
doesn't care whether it is free or nonfree (by whatever definition,
there isn't the one-and-only definition that everyone agrees with
anyway). You only might care about whether it is tainted or not (and
many don't give a damn about software patents even where they could
apply in theory). It is not like you have a chance in most of these
cases. Either you use a "100% free but sucks" implementation, or you
use the "tainted and possibly "nonfree", but working just fine" one.

ciao
Christian

Re: [Mageia-dev] Packages not updating?

[Christian Lohmaier]

Hi Anne, *,

On Mon, Oct 29, 2012 at 8:29 PM, Anne Wilson  wrote:
>
> Earlier today I did a big update on Cauldron.  Since then my wireless
> connection has not been working.  I started to gather information to
> report this, but when I asked MCC for hardware detection I was
> immediately told that broadcom-wl-kernel and two other packages (one
> was broadcom-wl-kernel-netbook, I think) needed installing.

Yeah, that beast is stubborn unfortunately. That driver is unusable
with the additional channels, and I also struggled to convince
MCC/Network manager to use the free driver (that unfortunately
requires firmware to be loaded and thus manual installation of the
firmware-cutter package and manual extraction of the firmware before
it can be made usable).

> Have I missed doing something, or should they have been picked up in
> the usual way?

Have you been using that driver before?

ciao
Christian

Re: [Mageia-dev] rehashing the faac issue

[Christian Lohmaier]

Hi *,

On Tue, Oct 30, 2012 at 1:32 AM, Christiaan Welvaart
 wrote:
> On Tue, 30 Oct 2012, Wolfgang Bornath wrote:
>>
>> There has been a wide consensus for the solution to put it into
>> tainted as has been said in this thread as well. There are 2 options
>
> Each package in non-free must be inspected case-by-case to know if it can be
> distributed/used, but their licenses are valid world-wide (because copyright
> is pretty much universally accepted). The packages in tainted can all be
> used/distributed *if* patents on software are not considered valid in the
> country where the user/mirror resides. Do you really want to mix those two?

Bad argument, as even with a separate repository these then *will* be mixed.
As you cannot have "free" packages that depend on the nonfree-tainted
in the free repo. Those would have to be put into nonfree-tainted as
well.

So nonfree-tainted will end up having "nonfree & tainted" and "free,
but depends on nonfree-tainted" packages.

I don't see a gain here.

ciao
Christian

Re: [Mageia-dev] Mageia versus Mageia.

[Christian Lohmaier]

On Sun, Oct 28, 2012 at 1:02 PM, jpbfree  wrote:
> I have a desktop machine installed with mga2
> and a test machine installed with cauldron
> both machines are up to date (according to distrib-coffee) and are
> time-synced with fr.pool.ntp.org.
> this morning the cauldron machine is one hour in advance (and wrong).

Well, very likely it is just that you didn't configure the proper
timezone on that machine.

> Is this transient or should i open a bugzilla ticket?

first check
$ date
and/or
$ date -u

on both machines.
The -u one (UTC) should be the same on both, and the one without -u
should display the local (i.e. in the timezone configured for the
machine)

ciao
Christian

Re: [Mageia-dev] rehashing the faac issue

[Christian Lohmaier]

On Wed, Oct 3, 2012 at 4:07 PM, Guillaume Rousse
 wrote:
>
> OK, let's vote here:
> - how many people for using 'tainted' ?
> - how many people for using 'non-free' ?

Definitely vote for tainted.

The only question is whether packages that depend on tainted stuff as
a hard/non-optional dependency need to be themselves in tainted.

I don't care, but this is the next thing to consider.
Having stuff in free (and thus enabled for selection/installation by
default) depending on stuff from tainted (and thus non-installable,
since the media is not enabled/not checked for availability) might be
more problematic than having those packages in tainted.

ciao
Christian

Re: [Mageia-dev] Final set of isos for Mageia 3

[Christian Lohmaier]

HI Anne, *,

On Tue, Oct 2, 2012 at 5:58 PM, Anne Nicolas  wrote:
> 2 liveCDs:
>
>  - GNOME 700M i586 - english only - Nonfree
>  - KDE   700M i586 - english only - Nonfree
>
> These are mainly targetted for distribution during events or for Newspapers
>
> 4 liveDVDs:
>
>  - GNOME DVD i586   - all locales - Nonfree
>  - GNOME DVD x86_64 - all locales - Nonfree
>  - KDE   DVD i586   - all locales - Nonfree
>  - KDE   DVD x86_64 - all locales - Nonfree

Not happy with this solution.
DVDs / the full set of packages is so *not* needed.

Downoad 4GB just to have 3GB obsoleted in a few months. :-((

Just create USB-editions of the english only media with additional languages.

So what fits into 700MB en-US only, will fit into <1GB for all languages.

As was written numerous times: Most people don't burn actual CDs
anymore, but rather put the image onto usb-sticks.

ciao
Christian

Re: [Mageia-dev] rehashing the faac issue

[Christian Lohmaier]

On Tue, Oct 2, 2012 at 3:17 PM, Johnny A. Solbu  wrote:
> On Tuesday 02 October 2012 14:03, James Kerr wrote:
>> perhaps a statement in the package description would suffice.
>
> There should be a clear difference in the tree. A description is not enouch.

Says who? You alone?

With tainted, you need to check each individual package anyway before
installing, to check whether whatever reason it is put into tainted
does affect you.

What about asking uses via a poll whether they actually need the
distinction of a separate tree.

I surely don't.

ciao
Christian

Re: [Mageia-dev] rehashing the faac issue

[Christian Lohmaier]

On Tue, Oct 2, 2012 at 10:20 AM, PhilippeDidier
 wrote:
>
> Look at the closed bugs containing the word faac... there are other
> programs than cinerella

But none as mature, as powerful. But that's beside the point anyway.

> Anyway Blogdrake repo proposes a faac rpm ...

Never heard of blogdrake, seems to be a Spanish-only site...

I don't understand the difference between tainted and non-free anyway
(without reading definitions what goes into what repo), and I guess
most users don't either.

and BTW:
http://www.mageia.org/en/1/notes/ reads:
##
The Tainted repository includes packages under various licenses, free
and nonfree ones, but the main criteria for packages in this
repository is that they may infringe patents and copyright laws in
some countries in the world (e.g. multimedia codecs needed to play
various audio/video files, packages needed to play commercial video
DVD… etc);
[...]
##
So I absolutely don't understand why there is so much fuzz about this
topic/so much contradiction. There already was a sane definition.

non-free is a misnomer. It should be named after what the mass of
users cares about, whether it is free & "safe" to use or whether it
might cause problems.

So tainted is the right repo to put it in.

Change the definition back to that of Mageia 1 and you're done.

ciao
Christian

Re: [Mageia-dev] Mageia 3 final set of isos

[Christian Lohmaier]

Hi *,

as my first mail from Sep. 19 has not been moderated through (if
you're not going to moderate posts, then just completely reject the
mail, don't claim it is being sent to moderators for review)..

See my comments re target/usage of LiveISOs below

Hi *,

On Wed, Sep 19, 2012 at 9:40 AM, Anne Nicolas  wrote:
>
> - provide a full open source software version

don't see a need for this when there is a checkbox or similar switch
to enable/disable "nonfree" stuff.

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

Yes please!

> - provide live version(s)

Especially live-ISOs should be CD-ROM size.

> - decrease isos number. QA is just a hell on the set we had for Mageia 2

I don't see the need for DVD-size special ISOs. To be precise: A
simple snapshot of the repositories, to use as additional installation
source should be enough for more or less everyone.
Have a CD with the basic stuff, and then install the rest either via
network or from an additional repo-DVD.

The more time passes, the more useless the initial repo's data gets,
as updates will be released for many packages. System builders/people
who need to do offline installation could then just sync their
favorite mirror/create a DVD with current packages and use that
instead of the initially released one.

The repo-packages can be tested completely automatically, as all that
needs to be done is to verify the iso-creation (directory layout, no
read-errors/partial files in the iso)

> - provide localization as large as possible
> - provide isos including major drivers including proprietary one to make it
> easier to install and configure

This is the only item where "completely open source/free" vs "one with
proprietary stuff" would be of relevance. If there was a boot option
to switch between the two, then one single iso would be enough.

> Keep in mind that what you want is not necessarily what another one want. So
> let start proposals here and discussion. Please add all explanations to your
> proposal.

So my proposal:
##
* Only CD-ROM as installation media,
** one dual arch for text-based installation
** one live for each architecture and major Desktop, i.e. one GNOME,
one KDE (english+whatever other western languages fit)
** isos for more languages only if you got QA for it. But editions for
CJK and RTL surely would be nice.

* additional packages on DVD as simple repository snapshot

There have been arguments: "But you cannot fit all packages that make
up GNOME or KDE onto a CD-ROM sized iso".
My reply is: It doesn't need to be the complete desktop environment.
Live isos are used to:
* Check whether the hardware is supported at all
* Check whether the distro's structure fits oneself
* As installation media
* As rescue system for whatever unforeseen circumstances, and to
backup that windows-PC from $friend_or_family

Also the questions whether people have DVD or CD-Rom drives isn't so
much of a question. If it has a drive, you can assume it also can use
DVD, but at least myself and ~everyone I know don't use actual CDs
anymore, but rather put the ISO onto an USB-Stick. I don't own a
USB-Stick in DVD-capacity, but I own a few that can fit a CD-ROM
image.

I'm against DVD sized installation media because
* It is only of use right after release, the more time passes, the
more outdated the packages are, and the more updates will have to be
installed over the net anyway
* it is a big download
* USB-media in DVD-size not as widespread as CD-Rom sized ones
* DVD for live-isos: You'll not be able to use all that is available
anyway, since RAM is limited, and providing all kinds of stuff that
then just leads into programs being killed because of OOM is
counter-productive.

So bottom line: Drop the DVD-size images, provide
repository/additional packages images as a convenience for
offline-installers instead. (i.e. it would only contain repository
data, would not be bootable. To boot, use one of the CD-sized options)

ciao
Christian

Re: [Mageia-dev] Video/X/GL/gnome-shell issues? (was: Re: ANNOUNCE: The /usr move cometh! <---- Instructions)

[Christian Lohmaier]

Hi *,

On Mon, Jul 23, 2012 at 10:13 PM, Colin Guthrie  wrote:
> 'Twas brillig, and Olav Vitters at 23/07/12 19:31 did gyre and gimble:
>> On Mon, Jul 23, 2012 at 11:55:31AM +0200, Thierry Vignaud wrote:
>>> On 22 July 2012 19:15, Colin Guthrie  wrote:
> I am having other issues (X/audio/network related). Making Cauldron
> totally unstable.

 I'm having issues with X due to intel drivers. Gnome-shell crashes
 frequently with "out of space" errors in some intel thing which smells
 to me like something leaking textures.

In case this thread is used as a reference to graphic-driver related
problems, I'll throw in mine as well:

Besides a corrupted display (unreadable fonts/glitches on screen) that
occurs after longer uptime and/or when using lots of memory (that also
was present in Mageia1 / 2d desktop) as described here:
https://bugs.freedesktop.org/show_bug.cgi?id=45092

I also experience problems playing back video in gnome-shell. The
video is jerky/choppy/jumpy (the opposite of smooth).
I.e. when there is a pan in the video (camera moves in a smooth
motion), the video jumps. Instead of playing back the frames as
*  *  *  *  *  *  *  *  *
it is more like
 * * **** *

As with the previous problem, it gets worse the longer the machine is
running (I didn't find out what exactly makes it worse). As a
workaround one can restart gnome-shell (+, r, )
While the problem is minimal after a fresh reboot or after restarting
gnome-shell, it still occurs. No such problem in gnome-classic, i.e.
in the 2d version of the desktop. There playback is always smooth, no
matter how long the uptime was.

Intel 965GM in Fujitsu Siemens Esprimo Mobile U9200

So I agree that something is fishy.

But as long as I can just restart gnome-shell and get adequate
(although not as-good-as-with-classic-gnome) playback

ciao
Christian

Re: [Mageia-dev] What is Mageia's policy reagarding filesize display? (units/base 2 vs base 10)

[Christian Lohmaier]

On Tue, Jun 26, 2012 at 6:13 PM, Oliver Burger
 wrote:
> At the moment we have
> the bash showing values in base 2 with the unit K,
> dolphin showing them in base 2 with the unit KiB,
> pcmanfm showing them in base 2 with the unit KB.
>
> So patching nautilus to use base 2 woul make for a more common behaviour of
> the distro, but it will create work for our GNOME maintainer since he would
> have to maintain that patch for every future version.

To get a better idea of the "effort" it would take: This is the patch

diff -ru nautilus-3.4.1_orig/libnautilus-private/nautilus-file.c
nautilus-3.4.1/libnautilus-private/nautilus-file.c
--- nautilus-3.4.1_orig/libnautilus-private/nautilus-file.c 2012-04-13
19:01:03.0 +0200
+++ nautilus-3.4.1/libnautilus-private/nautilus-file.c  2012-06-26
16:13:48.649538611 +0200
@@ -5847,7 +5847,7 @@
if (file->details->size == -1) {
return NULL;
}
-   return g_format_size (file->details->size);
+   return g_format_size_full (file->details->size, 
G_FORMAT_SIZE_IEC_UNITS);
 }

 /**
@@ -5885,7 +5885,7 @@
return NULL;
}

-   return g_format_size_full (file->details->size, 
G_FORMAT_SIZE_LONG_FORMAT);
+   return g_format_size_full (file->details->size,
G_FORMAT_SIZE_IEC_UNITS & G_FORMAT_SIZE_LONG_FORMAT);
 }


@@ -5945,7 +5945,7 @@
 * directly if desired.
 */
if (report_size) {
-   return g_format_size (total_size);
+   return g_format_size_full (total_size, G_FORMAT_SIZE_IEC_UNITS);
}

return format_item_count_for_display (report_directory_count
@@ -6675,7 +6675,7 @@

res = NULL;
if (file->details->free_space != (guint64)-1) {
-   res = g_format_size (file->details->free_space);
+   res = g_format_size_full (file->details->free_space,
G_FORMAT_SIZE_IEC_UNITS);
}

return res;
diff -ru nautilus-3.4.1_orig/src/nautilus-view.c
nautilus-3.4.1/src/nautilus-view.c
--- nautilus-3.4.1_orig/src/nautilus-view.c 2012-04-13 19:01:03.0 
+0200
+++ nautilus-3.4.1/src/nautilus-view.c  2012-06-26 16:13:48.652538574 +0200
@@ -2826,7 +2826,7 @@
if (non_folder_size_known) {
char *size_string;

-   size_string = g_format_size (non_folder_size);
+   size_string = g_format_size_full (non_folder_size, 
G_FORMAT_SIZE_IEC_UNITS);
/* This is marked for translation in case a localiser
 * needs to use something other than parentheses. The
 * first message gives the number of items selected;


> And it could break any other thing in GNOME since GNOME apps are quite
> interweaved with one another and you never know, what app uses nautilus in
> parts for what.

See above. It is not a massive change in the internals of nautilus.
This is nautilus-only.

And unless glib breaks its API the patch will continue to work. Both
g_format_size and g_format_size_full return a human-readable string,
just the default units differ. If you'd use

g_format_size(size); is the very same as
g_format_size_full(size, G_FORMAT_SIZE_DEFAULT)

So this is purely switching the base, nothing else. No custom "hacks",
no black magic.

ciao
Christian

Re: [Mageia-dev] What is Mageia's policy reagarding filesize display? (units/base 2 vs base 10)

[Christian Lohmaier]

Hi Colin, *,

On Tue, Jun 26, 2012 at 5:14 PM, Colin Guthrie  wrote:
> 'Twas brillig, and Christian Lohmaier at 26/06/12 15:26 did gyre and gimble:
>
> What about if they transfer a file from OSX to Linux? OSX uses base 10:

can not confirm, see
http://frupic.frubar.net/25973

But regardless...

> Personally I don't give a flying fig what's shown :)

I take that as you're not opposing a patch to change nautilus'
file-size-display.

ciao
Christian

Re: [Mageia-dev] What is Mageia's policy reagarding filesize display? (units/base 2 vs base 10)

[Christian Lohmaier]

On Tue, Jun 26, 2012 at 3:51 PM, Thierry Vignaud
 wrote:
> On 26 June 2012 14:57, Christian Lohmaier
>  wrote:
>> * Would a patch against nautilus that restores base2 behavior be accepted?
>
> No.

Why not?

>> If not:
>> * Do you think it is OK to have commandline tools show different
>> values from GUI tools?

You did not provide and answer to this one.

>> * Do you think it is OK to display different numeric values than the
>> rest of the computer world?

You did not provide an answer to this one.

> Are you aware KiB != Kb ?

Obviously I am. That's why I started the thread in the first place.
And that is why I wrote *numeric* values explicitly. It shows
"different numbers", the user doesn't pay so much attention to the
units themselves, only "k vs M vs G" - what matters is that a file
that has 240MB on Windows now is 252MB in nautilus.
Or that file he copied over the network from linux to his windows
computer now suddenly is 14 MB smaller.

Irrespective of that windows uses wrong units, that is not what the
user cares about, the user knows that there is a difference between MB
and KB. Whether the user is aware that windows uses 1024*1024 for "M"
as supposed to SI-style multiplier is irrelevant.
You don't expect users to compare the sizes in raw bytes, do you?

> https://en.wikipedia.org/wiki/Kilobit
> https://en.wikipedia.org/wiki/KiB

Thanks for clearly demonstrating that you did not bother trying to
understand the topic at hand.

ciao
Christian

Re: [Mageia-dev] What is Mageia's policy reagarding filesize display? (units/base 2 vs base 10)

[Christian Lohmaier]

Hi Olav, *,

On Tue, Jun 26, 2012 at 3:35 PM, Olav Vitters  wrote:
> On Tue, Jun 26, 2012 at 02:57:16PM +0200, Christian Lohmaier wrote:
>> Apparently this did originate from ubuntu with their unit policy
>> https://wiki.ubuntu.com/UnitsPolicy which is rather flawed in my
>> opinion.
>
> FWIW, I'm not interested in making such changes. I prefer base 2, but
> don't see the point of making glib/gtk+ behave differently across
> distributions.

It is not making glib/gtk behave differently, it is just requesting
differently processed string from glib.

glib already provides functions / corresponding flags to switch
between the two bases.

A patch would be passing G_FORMAT_SIZE_IEC_UNITS to the function call.

ciao
Christian

[Mageia-dev] What is Mageia's policy reagarding filesize display? (units/base 2 vs base 10)

[Christian Lohmaier]

Hi *,

having installed Mageia 2 recently and not only peaked into it using
the live-disk I noticed something that really bothers me a lot:

* Nautilus uses base10 to display filesizes

This to me is very annoying and contrary to all the previous years I
have been using a computer. As I use both the commandline as well as
the graphical filemanager, this discrepancy is driving me nuts.

Apparently this did originate from ubuntu with their unit policy
https://wiki.ubuntu.com/UnitsPolicy which is rather flawed in my
opinion.

Why I fully support the idea to be clear about what value is
represented, the only sensible way to do it would have been to change
the units accordingly as opposed to the values. (as many comments also
read)
The policy even contradicts its own use-case. Bob is not able to
compare the filesizes between ubuntu (nautilus) and windows
(explorer), unless they patched nautilus to use base2, and that is
contradicting their implementation requirements).
##

So what is Mageia's POV on this topic?

* Would a patch against nautilus that restores base2 behavior be accepted?
If not:
* Do you think it is OK to have commandline tools show different
values from GUI tools?
* Do you think it is OK to display different numeric values than the
rest of the computer world?

Note that I don't question the use of correct units, i.e. 132 KiB for
base2 and 135 kB for base10 - and I also don't question changing the
default basis in any random software, but the use in the filemanager.

Upstream very likely will not revert to base10 for nautilus
https://bugzilla.gnome.org/show_bug.cgi?id=665005 a after-the-change
bug and https://bugzilla.gnome.org/show_bug.cgi?id=554172 a bug asking
for clear values, i.e. matching units that resulted in keeping the
unit and changing the base instead of the other way round, heated
discussion, with not much consensus)

ciao
Christian

Re: [Mageia-dev] Mageia 3 specifications

[Christian Lohmaier]

Hi Olav, *,

On Tue, Jun 5, 2012 at 11:41 PM, Olav Vitters  wrote:
> On Tue, Jun 05, 2012 at 10:44:31PM +0200, Guillaume Rousse wrote:
>> Le 05/06/2012 16:20, Olav Vitters a écrit :
>> >Also, with latest NetworkManager, it seems you can do pretty advanced
>> >network configurations (lacks UI).

lacks UI part is probably the most problematic issue today.

>> >However, seems that loads of Mageia users have issues with
>> >NetworkManager [...]

>> Approximatively 50% of those problems come from the coexistence with
>> drakxtools and sysinit, conflicting for the control of the
>> interface, rather than actual problems in NM code.

Doesn't match my personal problems where I can only successfully setup
a connection when I use a combination of both, because of the
abovementioned lack of UI for "basic" (or better: essential)
configuration item, namely setting CRDA comain.

> Ah ok, but shouldn't that all be fixed now that the patch is back to
> make NetworkManager properly ignore stuff that it should ignore?

Nope. Network manager needs to have the featues that are currently
lacking, but that net-applet did provide.

* Setting CRDA domain
* Allowing to setup static IP before setting up a connection with DHCP first
* Leave hostname alone unless explicitly asked for changing it. (there
is no option to disable it, so when using dhcp NM will change your
hostname when the router suggests one, rendering your x-session
unusable for administrative tools that then no longer can connect to
the user's X-session)
* allow to configure wireless netorks without those networks being
available. You cannot preconfigure an access point without it actually
be in reach. With preconfiguring I mainly mean assign the
passphrase/authentification options.

> But drakxtools was
> more advanced IIRC, so first NetworkManager needs to get more advanced,
> more documentation, etc.

NM in the beta iso was a horrible experience, and now it halfway works
in the release, but my sympathies still are with drakxtools..

> All bugs above are really server like things. I thought drakxtools still
> was better at setting up Wifi; and I think that is more important to get
> right than vlan/bridging/etc.

I absolutely agree. drakxtools didn't have any problem with open, WEP,
WPA, be it with pre-shared keys or enterprise-style. Adding a VPN
tunnel was easy as well (apart from the bug that the tun-device had to
be added to the firewall manually, thankfully only once).

Only bug with netapplet/drakx tools is that it doesn't properly handle
static IP configuration after having connected to a dhcp network. Have
to manually disconnect and reconnect to make use of static IP. Didn't
have chance yet to check with NM...

ciao
Christian

Re: [Mageia-dev] [soft-commits] [4436] german keyboard: default to variant with enabled deadkeys instead of "nodeadkeys variant" ( mga#3791)

[Christian Lohmaier]

Hi Oliver, *,

On Thu, May 10, 2012 at 12:09 AM, Oliver Burger
 wrote:
> Am 09.05.2012 23:48, schrieb r...@mageia.org:
>>
>>      Log Message
>>
>> 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.

ciao
Christian

Re: [Mageia-dev] painful discussion n°1: debloating

[Christian Lohmaier]

On Tue, Apr 10, 2012 at 9:29 AM, You-Cheng Hsieh  wrote:
>
> I've made the changes of 1) and 2) locally:
> - remove Suggests: seahorse in gnome-keyring
> - add Suggests: seahorse in task-gnome-minimal

It is pointless to "optimize" for minimal installation and then break
usability for regular installs.

Manually install of gnome-keyring not resulting in a GUI to manage the
keys/passwords/other entries is of little use for the casual user, but
of course it works without, as applications can access the stored
passwords nevertheless, that's why it seahorse is a suggested package
and not a required one.

Suggests to seahorse in gnome-keyring makes perfect sense.

Adding seahorse as suggests to task-gnome-*minimal* is
counter-productive, it is not an application that is needed to run
gnome, it is not needed to have gnome-applications store passwords and
access them again.

It is the completely wrong way to fix this in my POV.

The actual fix would be to just not install suggested packages when
minimal install is requested. Or to prompt the user so that he can
deselect suggested packages manually. But when someone performs an
explicit minimal installation, this for me implies he only wants the
required stuff, and no suggests at all.

ciao
Christian

Re: [Mageia-dev] Removal of sun java

[Christian Lohmaier]

Hi Guillaume,

On Fri, Mar 30, 2012 at 3:11 PM, Guillaume Rousse
 wrote:
> Le 30/03/2012 15:04, Christian Lohmaier a écrit :
>> On Fri, Mar 30, 2012 at 2:52 PM, Dimitrios Glentadakis
>>  wrote:
>>
>> Well - that is what he said:
>> "Don't push security updates to users by replacing package A by package
>> B."
>> Or: "I don't care that other people will continue using software with
>> security flaws, since I know what I am doing."
>
> That is pure over-interpretation of my argumentation. I could be as well
> irrespective of your point of view by replying "you lie".

I think that paraphrasing matched what you were writing prettly closely.

But let's use a few quotes then:
"[...] don't treat uses as blatant idiots.
If I want to keep a proprietary JRE [...] that is my choice, not yours."

"I think I'm best placed than anyone else to evaluate the exact risk
I'm facing on the machines I'm running [...]. The decision [...]
belongs to me. You [Mageia] are not a system administrator [...], you
are a technical solution provider. You're clearly confusing the roles
here."

If that is not reading: Don't push the security updates to the users,
let the user take care of that manually, then what else?

Sure, call me lying, but then I call you schizophrenic.

ciao
Christian

Re: [Mageia-dev] Removal of sun java

[Christian Lohmaier]

Hi Dimitrios, *,

On Fri, Mar 30, 2012 at 2:52 PM, Dimitrios Glentadakis  wrote:
> [...]
> I interpreted Guillaume's approach as about the impact that can have Mageia's 
> decisions in a
> system and the respect of the user and his system as a priority, but it was 
> finally interpreted
> as he wants something for his personal use or he does nt care about a 
> security issue, for the
> same reason.  At least, is what i got.

Well - that is what he said:
"Don't push security updates to users by replacing package A by package B."
Or: "I don't care that other people will continue using software with
security flaws, since I know what I am doing."

And I strongly oppose to this attitude/point of view. Not limited to
Java, but in general. When a package *cannot* be updated and thus
there will never be a security fix (and not just a delay of a couple
of days/weeks), then the only sane thing for a distro is to replace
the package by something equivalent. In the case of Java it is just so
much easier, as there already exists a package that virtually does the
very same thing.

He wants to keep java for a special need, so that "I don't want this
package A to be removed" is his own personal use. I'm sure that >98%
of the users will not be amused when you tell them after a year or two
that they have been running a version of java that has a big security
flaw for all that time, just because one didn't want to obsolete the
package.

Of course "obsoletes" shall not be taken lightly. But i the case for
Java, the rationale that oracle gives for no longer having the
distributor's license is that OpenJDK and Oracle's java are now very
close, that they are no longer separate things, but that Oracle's Java
just builds on top of OpenJDK.

For people just in need for "java" there will hardly be any
difference. People with a special need for specific versions of java
can still download and install java from Oracle's site.

It is not a case where installing OpenJDK would make using Oracle's
java impossible/that you have to install OpenJDK in the first place.

ciao
Christian

Re: [Mageia-dev] Removal of sun java

[Christian Lohmaier]

Hi *,

On Fri, Mar 30, 2012 at 9:52 AM, Guillaume Rousse
 wrote:
> [...]
> You're not a system administrator, whose duty is to take this kind of
> decision, you are a technical solution provider. You're clearly confusing
> the roles here.

I don't get your problem really. Of course Mageia will only replace
the mageia packaged version of Sun's java, not a version you obtained
from Oracle.

So while the user who has a security-flawed version of mageia's
sun-java installed will have it scheduled for an update and replaced
by OpenJDK, that user
a) is not forced to do the update
b) can just install a fixed version of Java from Oracle instead
c) update and not care that much (>90% of the user base)

> But automatically removing software
> for security concerns, without asking for user consent,

You are asked for confirmation when installing updates - you get
notification that there are updates, and then have the choice to
accept them or decline them.

And there is a possiblilty to flag packages as "don't update those"
via configuration files.

> would be a first
> step into transfering decision power from user to operating system vendor.
> Trusted computing approach, in other terms.

This is a weak argument really, as there were always security updates.
Those as well were telling the user to update, and not wait until
$system-admin decided it is time to check for vulnerabilities.
There have been obsolete packages in the past as well, replacing
unmaintained/outdated packages by better (for most) alternatives.

This time it is just both at the same time.

So if you want your outdated mageia-version of java, just tell urpmi
to not touch it.

But don't argue that the rest of the userbase should continue running
a flawed version just because you have a special need. Users have a
choice to unselect updates. If they don't read the update's
description, it is their fault, not mageias.
Users have the choice to specify packages that must never be removed
in configuration files

ciao
Christian

Re: [Mageia-dev] installing minimal is not really that minimal

[Christian Lohmaier]

On Thu, Mar 22, 2012 at 10:45 AM, Thierry Vignaud
 wrote:
> On 22 March 2012 09:31, You-Cheng Hsieh  wrote:
>
> It's easy to add a suggest ("hey it'll just make the user experience better"),
> but eventually the suggested package can start a cycles that will pull
> quite a lot more packages.

This is a lame excuse, really.
What you are actually saying is that rpmdrake sucks because it doesn't
distinguish between required and suggested packages and doesn't let
the user choose.

The topic started off with a user using minimal installation without
suggested packages - just to remind you of that.

> [...]
> And none of it (but python) has actually to do with systemd.
> It was just that required library actually suggest or requires another one
> which also suggested or required ...

Don't mix up suggests with requires in this matter please.

> Everyone should be concerned about that.

Yes, but don't force crippling of package's interdependencies/suggests
because one part of the tooling ignores the difference between
requires and suggests.

> I think that some of those "comfort" suggests should be moved
> from some low level library or tool package to task-
> packages.

I completely disagree.

Give the user control of the suggested packages, highlight stuff that
is suggested and what is required.

ciao
Christian

Re: [Mageia-dev] installing minimal is not really that minimal

[Christian Lohmaier]

On Thu, Mar 22, 2012 at 10:26 AM, Wolfgang Bornath
 wrote:
> 2012/3/22 Olav Vitters :
>> I care about GNOME and giving
>> a full experience. If people want a more minimal install to the
>> detriment of GNOME, then I don't like it.
>
> Well, no comment on the other parts of the mail, but:
>
> Despite your commitment to Gnome, isn't this for the user to select
> what he wants?

Please, don't mix up things. That bug is about a *SUGGESTS* not a
requires, it is also not part of task-gnome itself, but of
gnome-keyring.

It is perfectly reasonable to have a suggests on seahorse from
gnome-keyring. It is the only sane thing to do I'd like to add.

totem (and even more so its mozilla plugin) tearing in all this is the
bug. Don't blame Olav here.

> If he wants a minimal installation, knowing that he may
> not get the full Gnome experience, isn't that for him to decide
> instead of being forced to pack things on his machine he does not care
> for, whether you like it or not?

A suggested package is not forced on anybody.

ciao
Christian

Re: [Mageia-dev] Mageia 2 beta 1

[Christian Lohmaier]

Hi Anne, *,

On Wed, Feb 22, 2012 at 2:44 PM, Anne Nicolas  wrote:
> Le 22/02/2012 14:41, Christian Lohmaier a écrit :
>> On Tue, Feb 21, 2012 at 9:00 PM, Anne nicolas  wrote:
>>>
>>> Still no live cds available
> [...]
>> without a live-iso, I won't be able to have a look - and probably
>> quite a few other won't have a look either...
>
> We are looking for people to make it possible in time. Join the team !

Unfortunately it is far from clear how one could help in this case.
Only info I have is that draklive needs adaptions because of migration
to dracut.

But with that info alone it is unclear how one could help really.

I just assume it would require installing cauldron/the beta, but
that's a catch-22, as I don't have enough free diskspace to install
two copies of Mageia, hence the need for the live iso to test-drive it
:-/

So all I can do is wait & hope for the best...

ciao
Christian

Re: [Mageia-dev] Mageia 2 beta 1

[Christian Lohmaier]

Hi Anne, *,

On Tue, Feb 21, 2012 at 9:00 PM, Anne nicolas  wrote:
> Hi there
>
> As announced on blog,  isos are now available on public mirrors.
> http://blog.mageia.org/en/2012/02/21/mageia-2-is-approaching-test-mageia-2-beta-1/
>
> Still no live cds available

:-/

> but we hope to have it ready in coming
> days, stay tuned.

Hope they will come soon as...

> Beta stage is just essential for final release. So please take some
> time for tests and use Bugzilla :)

without a live-iso, I won't be able to have a look - and probably
quite a few other won't have a look either...

ciao
Christian

Re: [Mageia-dev] Beta 1 isos

[Christian Lohmaier]

On Tue, Feb 14, 2012 at 10:48 AM, Juergen Harms  wrote:
> Sorry, I am yet another apprentice, and I started to listen to this list
> only quite recently. All I know is that backports have been an open issue.
> What document does your quote refer to?

https://wiki.mageia.org/en/Updates_policy

But that document still contains the stupid (yes, I said it again, as
nothing has changed) wording.

For the real policy, read
http://www.mail-archive.com/mageia-dev@mageia.org/msg11035.html and
the following mails.

No wonder the discussions come up again and again when after the
discussion the policies are not updated accordingly.

ciao
Christian

[Mageia-dev] where are the live-isos? (was: Consolidation of the spell checkers - current status before Beta 1 and general version freeze)

[Christian Lohmaier]

Hi *-

On Tue, Feb 7, 2012 at 3:23 AM, Kamil Rytarowski  wrote:
>
> We are just only one month before the version freeze and two weeks before
> planned release of Beta 1.

Not related to dictionaries/spell-checking engines, but isn't it still
too early for beta, given that there still are no live isos of alpha3.
The initial announcement mentioned a delay of about one week, but till
today no sign of alpha3 live isos.

ciao
Christian

Re: [Mageia-dev] Official VM images for Mageia 2?

[Christian Lohmaier]

Hi *,

On Thu, Jan 26, 2012 at 10:17 AM, Romain d'Alverny  wrote:
> On Wed, Jan 25, 2012 at 18:35, zezinho  wrote:
>> Le mercredi 25 janvier 2012 16:30:23, Romain d'Alverny a écrit :
>
> VMs can be used for scriptable config and deployment of
> test/staging/prod platforms, using shared recipes (chef, puppet,
> other). Providing a pre-installed, predictable minimal system is
> helpful in this case.

Why not provide a kickstart image then? Or is kickstart
auto-installation no longer supported by Mageia? I used it a while
back with mandriva, and while a little hard to discover that feature,
it worked quite well.
This is then much easier to distribute (regular install-media +
kickstart configuration) and can be installed unattended in any VM of
the user's choice...

ciao
Christian

Re: [Mageia-dev] Too many tmp directories

[Christian Lohmaier]

On Sat, Jan 21, 2012 at 6:21 PM, Oliver Burger
 wrote:
>
> while searching for some strange KDE behaviour (see bug 107 about
> those icons), I found at least three different tmp directories:
> /tmp/
> /var/tmp/

Those are historically grown ... /tmp is the really temporary one,
discarded when rebooting, while /var/tmp is for stuff that is to be
preserved after a reboot.

So while /tmp nowadays frequently is on a ramdisk, /var/tmp is not.

ciao
Christian

Re: [Mageia-dev] please stop doing "bugs" for updating magia 1

[Christian Lohmaier]

On Fri, Jan 13, 2012 at 10:28 AM, andre999  wrote:
> Christian Lohmaier a écrit :
>> On Thu, Jan 12, 2012 at 8:04 PM, Juan Luis Baptiste
>>  wrote:
>>> On Thu, Jan 12, 2012 at 1:01 PM, Christian Lohmaier
>>>   wrote:
>>>> On Wed, Jan 11, 2012 at 10:09 PM, Juan Luis Baptiste
>>>>  wrote:
>>>>
>>>>> [..]
> To make things entirely clear, the agreed base policy (in various meetings)
> was that updates should contain no new features.  Thus in general, a
> (verified) bug fix only release from upstream would qualify as an update.
> This being subject to exceptions, which were later agreed on after much
> discussion.

Thanks - this is the first time this has been stated explicitly.

> I don't really see the point of doing all this arguing about a wiki page
> that doesn't completely accord with update policy.  We just have to fix the
> wiki page.

Well - if you don't bother whether your policies are correct, you
should not bother to publish them in the first place but refer to
"whatever was discussed on the mailinglists".
Yes, you have to fix the wiki page. But judging from this discussion
people did not know what really is correct. The arguing is not about
the wiki-page, but about the policy that is reflected by that wiki
page.

You did now clarify the policy as it should be, and that is fine. But
please understand that the written policy did reflect a completely
different picture.

>> Yes, but this then changes the policy drastically (for the better, so
>> please change it)
>
> It is not that drastic a change.  The effect is essentially the same,

No, It is a drastic change from what is written. It probably is no big
difference compared to what people actually do today, but the policy
is changed drastically by this change.

> although it is of course much easier -- and generally safer -- to apply a
> (verified) bug fix only release from upstream.
> As stated above, and mentioned by others posting to this thread, the wiki
> page does not accurately affect the policy.

Well, you might have a different interpretation of this thread, but I
see people strongly supporting the policy as is written on the wiki,
so it is far from clear.

>> And when I write "whatever is against the policy" - I'm referring to
>> what is written in the wiki, not what people actually do.
>
> Policy is what was agreed on, and not any errors that may exist in what is
> written in the wiki.  We have corrected many similar errors in the wiki.

If things were so clear, than people could have written exactly what
you did and not continue with this discussion for so long.

> Calling your understanding of the policy "stupid" is not necessarily the
> most diplomatic approach.

Again: I did judge what is written in the wiki. When policies are
published, I have no other choice than to assume that what is written
reflects the policy that was discussed and decided upon.
And while it might not be diplomatic, I for sure prefer people
actually writing what they mean. I of course fully agree that just
writing "foo sucks" without stating how foo could suck less is
inappropriate/waste of time.

But well - thanks for making a concrete statement of what the policy
/actually/ is.

ciao
Christian

Re: [Mageia-dev] "Hear, hear" usage

[Christian Lohmaier]

Hi Oliver, *,

On Fri, Jan 13, 2012 at 9:01 AM, Oliver Burger
 wrote:
> Am Donnerstag, 12. Januar 2012, 22:43:54 schrieb Florian Hubold:
>> > On 01/12/2012 04:17 PM, Johnny A. Solbu wrote:
>> >> As far as I understand, that is a common British thing to do when one
>> >> agree
>> >> with the current speaker.

Thanks for the explanation :-)

>> Well, directly translating this phrase into german, it has another meaning.
>> Used in colloquial language, it means something like ironically saying
>> "well, look at that" or "enough with this nonsense" but also in the form
>> Johnny used it.
> You must have a different dirct translation than me. Directly translating it
> into German makes no sense at all :D

It does make sense, as the exact same phrase "Hört, hört" exists in
German - but just like Florian I know the double-meaning that can both
mean full approval (as the English meaning), but is also used as "look
at that guy, he is deconstructing his own argumentation/he is making a
fool of himself/the topic".
The double-meaning probably is depending on geographical region. (like
for example "Matz" in regional dialect - I know it as a (positive)
term for a self-confident, boldfaced/fresh/cheeky girl, while just
50km westwards it is a rather harsh curse word for a "mean/angry
bitch")

> But you should never translate anything directly between languages...

Sure - but if you don't understand a phrase/saying, all you can do is
to directly translate it and see whether you can make sense of it. In
this case it was ambiguous (at least for me), as the tone of the
voice, the other sources of information were missing.
It's like the phrase "Der Lehrer sagt mein Vater ist ein Esel" -
without the missing punctuation this sentence can have two rather
different meanings. No problem when you hear it, but when you read it
like that you can only guess who called whom a donkey.

And that was my point - what works perfectly fine in real life, in
direct interaction - might not work as well when you only have text
written on screen - so thanks again for clearing up the dust from this
expression :-)

ciao
Christian

Re: [Mageia-dev] please stop doing "bugs" for updating magia 1

[Christian Lohmaier]

On Thu, Jan 12, 2012 at 11:35 PM, Juan Luis Baptiste  wrote:
> On Thu, Jan 12, 2012 at 3:25 PM, Christian Lohmaier
>  wrote:
> [...] You could have made
> your point by saying that *you* don't like that t-shirt because of x
> and y motives and if he had chosen another one with Y characteristics
> would look much better on him.

If you reread my posts, you'll notice that whenever I called it
stupid, a "in my opinion" or equivalent is just around the corner. And
you'll also see that I also wrote what I consider the better
alternative (I wrote it so often that people surely are annoyed by
now)

ciao
Christian

Re: [Mageia-dev] please stop doing "bugs" for updating magia 1

[Christian Lohmaier]

Hi Florian,

On Thu, Jan 12, 2012 at 8:42 PM, Florian Hubold  wrote:
> Am 12.01.2012 19:01, schrieb Christian Lohmaier:
>>> [..]
> PS: Maybe next time you could improve on your wording, the policy may
> currently be incorrect, not reflecting good packaging practices, but as it's
> only a policy written by humans, it's not dumb. Just a hint. ;)

No, I disagree. The policy as written is dumb in my opinion. But that
doesn't mean I consider the people who edited the wiki to be dumb.
That is a huge difference in my opinion. If I tell someone "Ugh,
that's an ugly shirt you're wearing today" it is not the same as
telling the person "you are ugly" - but people on this list do get it
that way.

If you publish a policy, and the policy is incorrect, the whole
process of using policies is worthless. So I /have/ to assume that the
policy reflects the decisions/conclusions from the discussions by
people running the project.
To me it stays a silly/stupid policy. Whether you like the word or
not. It is not picking about typos or bad grammar or anything. It is
the fundamental approach reflected by the policy that I consider so
wrong that in my eyes it is stupid (and reason enough not to consider
officially packing stuff for Mageia).
I for myself prefer that people state what they really think, instead
of being sarcastic or trying to be smart in other ways (what point is
Johnny trying to make with his "hear, hear" for example?) . This just
doesn't work when you don't have other info than the text on your
screen (no facial expression, no tone of voice, ~no background
knowledge on the person making the statement).

It might be my lack of understanding the English language, but
"stupid" just is a regular word - it is not like I'd be using
something like "moth.*ker" here. Also my thesaurus only lists words
that I consider more harsh (like retarded, brainless,...).

So once again sorry if that did offend some people, feel free to
suggest (via pm, no need to continue this on the list) a wording that
still carries the same meaning, but is less "insulting".

ciao
Christian

Re: [Mageia-dev] please stop doing "bugs" for updating magia 1

[Christian Lohmaier]

Hi Juan Luis,

On Thu, Jan 12, 2012 at 8:53 PM, Juan Luis Baptiste  wrote:
> On Thu, Jan 12, 2012 at 2:10 PM, Christian Lohmaier
>  wrote:
>>> No, I'm doing exactly as the policy says, patch current stable
>>> version.
>>
>> But then you're *not* doing as the policy says, as policy says:
>> "same version of the package *released with the distribution*"
>> So whatever version that ended up in the initial release of the
>> distro. Not what is available upstream.
>>
>
> Were do you get that ? have you even went through the updates I have
> sent and found one that was a new version ? if you do will see that
> ALL of my updates are a patched mga 1 version.

You should learn to use unambiguous words then. Where I get that from
is in this quote:
"No, I'm doing exactly as the policy says, patch current stable version."

To me "current stable version" = whatever is available upstream as the
current stable version (=bugfixrelease) of the codeline that is in the
distro.
If distro has shipped 1.3.2 initially, and 1.3.4 is available in the
meantime, then "current stable" is 1.3.4 in my world, not 1.3.2.

ciao
Christian

Re: [Mageia-dev] please stop doing "bugs" for updating magia 1

[Christian Lohmaier]

On Thu, Jan 12, 2012 at 8:04 PM, Juan Luis Baptiste  wrote:
> On Thu, Jan 12, 2012 at 1:01 PM, Christian Lohmaier
>  wrote:
>> On Wed, Jan 11, 2012 at 10:09 PM, Juan Luis Baptiste  
>> wrote:
>>> [..]
>>> As I said, no one is talking about picking up a fix if there's a bug
>>> fix only release, it's for when it isn't and we need to reduce the
>>> chance of regressions by taking the modifications that *exactly* fix
>>> that bug.
>>
>> I strongly disagree. The policy is stating the exact opposite. And
>> also Michael seems to defend the policy as it is written, and not your
>> interpretation here.
>>
>
> No, I'm doing exactly as the policy says, patch current stable
> version.

But then you're *not* doing as the policy says, as policy says:
"same version of the package *released with the distribution*"
So whatever version that ended up in the initial release of the
distro. Not what is available upstream.

> The thing about bugfix only releases is something that it
> seems packagers have been doing implicitly as pterjan said before, and
> needs to be added to the policy.

Yes, but this then changes the policy drastically (for the better, so
please change it)

And when I write "whatever is against the policy" - I'm referring to
what is written in the wiki, not what people actually do.
If you don't care what is written, but do how you like, then there's
no point in having written policy, and even less reason to point
people to those policies to make them shut up/not ask questions.

ciao
Christian

Re: [Mageia-dev] please stop doing "bugs" for updating magia 1

[Christian Lohmaier]

Hi Juan Luis,

On Wed, Jan 11, 2012 at 10:09 PM, Juan Luis Baptiste  wrote:
> [..]
> As I said, no one is talking about picking up a fix if there's a bug
> fix only release, it's for when it isn't and we need to reduce the
> chance of regressions by taking the modifications that *exactly* fix
> that bug.

I strongly disagree. The policy is stating the exact opposite. And
also Michael seems to defend the policy as it is written, and not your
interpretation here.

That again you might have a different understanding of
bugfix-only-release. I think I stated mine often enough (increase in
micro version when package follows major.minor.micro versioning scheme
and no new features are introduced in micro releases).

So please change the wording of the update policy accordingly
https://wiki.mageia.org/en/Updates_policy reads:
##
For the most part, an update should consist of a patched build of the
same version of the package released with the distribution, with a few
exceptions:

* Software versions that are no longer supported upstream with updates
(firefox and thunderbird seem to fall into this category these days)
* Software that is version-bound to an online service (games, virus
scanners?) and will only work with the latest version.
* We will make exceptions for packages that did not make it into mga1
and are additions to the distribution, provided they do not impact any
other packages and can pass full QA.

Updates are not the appropriate place for packages created to satisfy
certain user's urges for "the latest". These types of builds belong in
backports.
##
I read it as "no version bumb is allowed (except for the three
exception-cases listed) - bugs are only fixed using patches", and I
don't see the interpretational freedom to allow upstream's bugfix
releases. Updating from 1.3.2 to 1.3.3 would not be in compliance with
the policy (if not in one of the three exception cases) - this is what
I have called stupid policy (and still do).

ciao
Christian

Re: [Mageia-dev] please stop doing "bugs" for updating magia 1

[Christian Lohmaier]

On Wed, Jan 11, 2012 at 8:32 PM, Michael Scherer  wrote:
> Le mercredi 11 janvier 2012 à 17:48 +0100, Christian Lohmaier a écrit :
>> On Wed, Jan 11, 2012 at 4:51 PM, Guillaume Rousse
>>  wrote:
>> > Le 11/01/2012 16:09, Antoine Pitrou a écrit :
>> >
>> >> As a Mageia user I would expect Mageia to package significant *bugfix
>> >> releases* and ship them in the updates for the stable distro.
>> >
>> > You'd rather read the current update policy, rather than expect blind
>> > assertions:
>> > https://wiki.mageia.org/en/Updates_policy
>>
>> Whoa - this is a rather stupid policy. (my opinion, yours obviously differs).
>> "For the most part, an update should consist of a patched build
>> of the same version of the package released with the
>> distribution,"
>
> I am pretty sure that you can express yourself without starting by
> insulting people.

Well, if you feel insulted when I state my personal opinion about the
policy, then I cannot help it.
I also find a different word for it - In my opinion it is a stupid
policy. It might not reflect what was discussed on the mailinglist,
but that is not my fault either - I can only judge what is written on
that wiki-page, and once again: that policy doesn't make any sense to
me.
Feeling insulted means that you apparently were deeply involved in
formulating the policy, too bad, but cannot be helped. Sorry if your
feelings are hurt.

>> Welcome to distro-isolation, putting burden on maintainers, giving
>> them all the reason to deny a reasonable request for a bugfix release
>> because it just is too much work to hunt for a specific commit that
>> fixed bug x.
>
> If that's too much work for a maintainer and if that's important for
> you, you can :
> - do your own package, supported by yourself for yourself

I do for the packages I care of.

> or :
> - provide the patch

No, that's pointless. I'd rather supply the patch upstream, so it will
be integrated in the upstream package.

> If that's too much work for you too, then that's likely too much work
> for others too.

You're mixing stuff around: We/I am talking about the case when there
*is* an bugfix release available from upstream, but the policy
dictates to extract individual patches for a subset of the fixes only-
and that subset being bugs filed in mageia's bugzilla. This doesn't
make sense.
If the maintainer could use the fixed upstream release, then all that
is needed is to bumb the version-tag in the spec and rebuild. You
don't question that this is easier than hunting down a patch and
adding that to the package, do you?
Any cases where just bumping the version and rebuilding won't work are
cases that don't fall in the bugfix-only category.

>> > [...]
>> > A bug may vary from a typo in a man page to a critical security update,
>>
>> And a typo-fix is not worthwhile to have?
>
> When we take in account the fact it would still need proper QA, there is
> likely stuff that are more important than a typo. And a typo is just a
> extreme case, and a simplificaition. If we start to have a complex
> update policy, we are just losing time for almost nothing.

No doubt about that - the above statement was more meant in the terms
of only applying selective fixes by patch, as opposed to taking the
release that has those bugs fixed+additional easy stuff.
So why only fix "bug that is reported in mageia's bugzilla", but not
"the typo that was fixed upstream".

>> Sure, you cannot be save of regressions, but what makes you think you
>> are smarter than upstream? What makes you so sure that not the one
>> commit you add as a patch to your package is the one that causes the
>> regressions?
>
> For 1, we usually do not do distro patch. I personnaly think this should
> be avoided as much as possible, and that we should push as much patch
> upstream. We have a rather huge backlog to clean.
>
> For 2, we also usually take patch from upstream. Some of us are also
> good enough to understand patchs, and to see what they mean, if they fix
> something, etc. Of course, there is some software that are rather
> specialized or obscure, but that's far from being the majority.

So then again: what makes selectively fixing bugs better in terms of
regression prevention than applying a bugfix release from upstream?
You an Juan Luis basically say: Less changes, less chance for
breakage. This is a "Milchmädchenrechnung"  (naive assessment of the
situation). Fixed done by upstream are applied by people familiar with
the code in question, usually way  more familiar than the package
maintainer. Yes the regressions do happen. Even if a fix looks simple,
it can i

Re: [Mageia-dev] please stop doing "bugs" for updating magia 1

[Christian Lohmaier]

On Wed, Jan 11, 2012 at 8:56 PM, zezinho  wrote:
> Le mercredi 11 janvier 2012 19:22:23, Antoine Pitrou a écrit :
>> Just because someone doesn't file a bug against Mageia doesn't mean the
>> bug doesn't bother anybody, because many users don't report upstream
>> bugs to the distro's tracker.
>> (also, other users don't bother reporting bugs at all :-))
>
> That's it. This is why we provide the whole bugfix release from upstream as
> update when it is a PURE BUGFIX release (no new features).

This would be sane, but this is not what is written in the update
policy wiki page.

ciao
Christian

Re: [Mageia-dev] please stop doing "bugs" for updating magia 1

[Christian Lohmaier]

On Wed, Jan 11, 2012 at 6:43 PM, Juan Luis Baptiste  wrote:
> On Wed, Jan 11, 2012 at 11:48 AM, Christian Lohmaier
>  wrote:
> [...]
> You don't do packaging, right ?

Wrong. I do packaging, although not for any distro.

> it isn't that hard and is how all distro's do it. Look at Fedora or
> SuSE's packages and you will see a lot of patch files fixing single
> bugs.

adding patches to the packages and releasing them instead of waiting
for a new upstream release is different from having the policy to
stick with whatever release was used when releasing the distro and
then only apply fixes via patches.

I'm not saying that you must not use patches to fix bugs. There are
cases where a bug is homegrown/specific to the distro and thus not
suitable for fixing upstream, there are cases where development cylce
is too slow/it is not sensible to wait for upstream.

> It's a matter of following upstream bugzilla reports and see
> which commit fixes the issue in question, create a patch from it and
> apply it to the package. Most of the time you can get the patches to
> fix single bugs from other distros packages.

It is not a question whether it is possible. It is a question whether
it makes sense in the first place.
And no doubt it creates a lot more work for package maintainers.
Both for initially hunting for the commit that fixes the bug, and
later when patches conflict, and later when a package is updated to a
new release.

> Because as I said earlier, we backport the "commit" that fixes that
> single issue,

Every change, also those that introduce a regression is a "commit".
So implicitly you're saying that you will only fix the "easy" bugs,
but anything that involves more than touching 10lines of code will not
be chosen, since it might introduce regressions.

ciao
Christian

Re: [Mageia-dev] please stop doing "bugs" for updating magia 1

[Christian Lohmaier]

On Wed, Jan 11, 2012 at 4:51 PM, Guillaume Rousse
 wrote:
> Le 11/01/2012 16:09, Antoine Pitrou a écrit :
>
>> As a Mageia user I would expect Mageia to package significant *bugfix
>> releases* and ship them in the updates for the stable distro.
>
> You'd rather read the current update policy, rather than expect blind
> assertions:
> https://wiki.mageia.org/en/Updates_policy

Whoa - this is a rather stupid policy. (my opinion, yours obviously differs).
"For the most part, an update should consist of a patched build
of the same version of the package released with the
distribution,"

Welcome to distro-isolation, putting burden on maintainers, giving
them all the reason to deny a reasonable request for a bugfix release
because it just is too much work to hunt for a specific commit that
fixed bug x.

>> For example, it would be nice if an up-to-date Mageia 1 system had
>> Python 2.7.2 rather than Python 2.7.1 (not a deal-breaker, of course,
>> but nice). There's more than a hundred bug fixes between the two
>> versions and I don't expect Mageia to have independently fixed many of
>> these bugs.
>
> A bug may vary from a typo in a man page to a critical security update,

And a typo-fix is not worthwhile to have?

> which make the number of claimed bugfix a poor decision metric. A
> non-regression ensurance would be a better one, but it's quite difficult to
> assert.

Don't assume all upstream projects are a bunch of clueless idiots.

For upstream releases that have a clear version/release scheme, with
micro releases being compatible bugfixes only, the above mentioned
policy is completely nonsense, same for your fear of regressions, etc.

Sure, you cannot be save of regressions, but what makes you think you
are smarter than upstream? What makes you so sure that not the one
commit you add as a patch to your package is the one that causes the
regressions?

Regressions have the nice habit of being triggered by changes in
apparently unrelated code...

My 0.02€ only, but I strongly suggest for that update policy to be clarified.
When there is no dedicated bugfix release procedure in the upstream
package, an update is a rebuild of the same version with a
corresponding patch. That's reasonable (as opposed to using a newer
minor or even major release, those are backports).
But once again: if upstream has a major.minor.micro scheme with micro
versions being bugfix releases, I really don't see any sane reason for
not "allowing" those updates.

ciao
Christian

Re: [Mageia-dev] please stop doing "bugs" for updating magia 1

[Christian Lohmaier]

Hi Luis, *,

On Mon, Jan 9, 2012 at 5:47 AM, Luis Daniel Lucio Quiroz
 wrote:
> AS i understand
> we are not a rolling distribution, so i dont get why i'm getting tickets to
> update release.
>
> What I mean, if you consider an update, like the one i did squid 3.1.12 to
> 3.1.15 please explain why.

No knowing squid's release-numbering-scheme, but update in micro
version usually are (fully compatible) bugfix releases, so why is an
explanation necessary? The explanation is "fixed bugs"

And using a fixed upstream release surely is preferable over adding
patches manually, isn't it?

> Otherwhise i gues it is better you cand use Mageia
> cauldron SRPM and do backport for  your self.

I understand a backport as adding a version with new features, usually
signalled by an update in either major or minor version. Those might
come with break in backwards or forwad-compatibility, so giving clear
reason why it should be backported surely is justified.

The lower in the stack (the more other packages depend on the package
in question), the more thought needs to be put into it. But if a
package that no other package depends on is concerned, then I'd say it
is up to the  packager to decide whether he/she will go through the
trouble of backporting it. If the spec is well written, and
configuring the package is "sane", then it is easy, if it is a
hacked-together spec/build-system it is hard.

But bugfixreleases (i.e. just micro version changed for most package
versioning schemes) should just consist of updating the source-tarball
(and maybe dropping some patches that found their way upstream and
rediff the remaining ones) and I don't understand your request to
"stop" those requests.

ciao
Christian

Re: [Mageia-dev] Call for translators

[Christian Lohmaier]

HI *,

On Sun, Dec 18, 2011 at 7:25 AM, andre999  wrote:
> Oliver Burger a écrit :
> [...]
> A third option could be that some enthusiastic documenters/translators just
> change Mandriva to Mageia in all the places where the English has Mageia.
>  (Where translators for the language in question haven't responded.)
>>
>> If you are interested in helping us, have a look at
>> https://wiki.mageia.org/en/Internationalisation_Team_(i18n)
>> and do contact me.

just FYI: Mageia's transifex site is rather hard to find/stumble upon.
https://wiki.mageia.org/en/Internationalisation_Team_(i18n) for
example talks about a "self-hosted transifex instance" -
but the link doesn't point to that self-hosted instance, but to the
transifex homepage.

It links to the short guide
(https://wiki.mageia.org/en/Short_guide_to_transifex - all images
broken btw) and that page once again doesn't tell where that transifex
instance is in the first place.
only when stumpling about the mapping
https://wiki.mageia.org/en/List_of_Mageia_transifex_projects you
actually get links to Mageia's transifex installation.

ciao
Christian