Re: [Mageia-dev] Proposal for bug statuses and workflow

[andre999]

Samuel Verschelde a écrit :

Here is a workflow proposal for bug reports in bugzilla.
   

[...]

Best regards

Samuel Verschelde
   


I think it is really well thought out.
Especially renaming certain statuses, to better coincide with their usage.
The resolutions as well.

Only one question :
The "NEW + triaged keyword" status seems ok, but I can see Marja's point 
that it might be better to have an explicit "TRIAGED" status.

What happens if the bug is not ACCEPTED, or there is no maintainer ?
The bug is just left in this state ?

(Looks like you're making good use of the Libreoffice Draw flowcharting.)

In sum, "WORKS_FOR_ME" :)

--
André

Re: [Mageia-dev] Proposal for bug statuses and workflow

[Marja van Waes]

Op 19-10-11 23:45, Marja van Waes schreef:

Op 19-10-11 23:30, Samuel Verschelde schreef:

Here is a workflow proposal for bug reports in bugzilla.


I think it looks great, it solves several of the Bug Squad's problems :)



BTW, replacing "status NEW + keyword Triaged" by status "TRIAGED", and 
leaving all the rest the same, would solve another problem and save time ;)

Re: [Mageia-dev] udev in initrd and/or using dracut (LVM root fs related)

[Colin Guthrie]

'Twas brillig, and David W. Hodgins at 19/10/11 22:13 did gyre and gimble:
> On Wed, 19 Oct 2011 09:20:35 -0400, Colin Guthrie
>  wrote:
> 
>> In testing a more extensive use of systemd (i.e. using it to mount
>> filesystems etc. rather than using rc.sysinit) I've run into a few
>> problems regarding the fact that my LVM is activated in the initrd.
> 
> I'm using lvm in my cauldron and Mandriva 2011 installs.
> 
> I have / on a primary partition, with /usr, /var, /home, /opt, and
> /tmp on lvm volumes.
> 
> I previously had /var/log on a primary partition, but that did give
> me a problem with /var/log getting mounted before /var.  Once I
> moved /var/log back into /var, mounting is ok. I have to kill
> plymouth for a run level 3 boot, and have run into problems with
> systemd timing out a mount, when an fsck has to run due to the
> filesystem mount count, but haven't taken the time to file bug
> reports on those yet.
> 
> My cauldron install started out as a Mandriva 2009.1 install, updated
> via urpmi to 2010.2, then to Mageia 1, then to Cauldron.
> 
> Any info you think would be useful to figure out why it's working for
> me, and not on your system?

Because as I said at the top: "In testing a more extensive use of
systemd (i.e. using it to mount filesystems etc. rather than using
rc.sysinit)..." i.e. At the moment all the mounts are handled by
rc.sysinit which do not try to do anything fancy whereas systemd takes a
more in depth look at devices and waits for udev to tell it they exist
before it tries mounting them and it's this bit that is broken (i.e. it
doesn't know the lvm drives exist due to the missing info in the udev db).

Col


-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

Re: [Mageia-dev] ANN: glibc-2.14.1 landing...

[Thierry Vignaud]

On 19 October 2011 23:42, Thomas Backlund  wrote:
>> I've seen several programs segfaulting on dlopen(), eg: mplayer
>> See attached trace
>> Once rollbacking to 2.12, everything is OK again
>
>
> On a fully updated cauldron ?

Yes

Re: [Mageia-dev] require help to understand stage1/stage2/rescue source files

[Pascal Terjan]

On Wed, Oct 19, 2011 at 21:36, Maarten Vanraes  wrote:
> Hi,
>
> is there someone who can help me understand the stage1/stage2/rescue system?
> or point to some docs? i've looked at it, but it seems to be sometimes one
> source file used for both... it's really confusing me.

Sources in mdk-stage1/ are used to build several binaries (including
init, stage1 and rescue-gui)

images/make_boot_img is used to generate the boot images which will
include stage1 and busybox

rescue/ is used to make rescue.sqfs image which contains a
/etc/rc.sysinit which will prepare things and then run rescue-gui

At the end stage1, if in rescue mode, the rescue image get loaded
(from local cd, ftp, http, ...), mounted and the code is run (else
same happens to stage2)

Re: [Mageia-dev] Proposal for bug statuses and workflow

[Marja van Waes]

Op 19-10-11 23:30, Samuel Verschelde schreef:

Here is a workflow proposal for bug reports in bugzilla.


I think it looks great, it solves several of the Bug Squad's problems :)

Re: [Mageia-dev] ANN: glibc-2.14.1 landing...

[Thomas Backlund]

Thierry Vignaud skrev 20.10.2011 00:34:

On 18 October 2011 18:48, Thomas Backlund  wrote:

I have updated glibc&  locales-* from 2.12.1 to 2.14.1 and I'll push
them to core/updates_testing so people can test it out but have a
fallback if needed in case of regressions

They seem to work ok here, but you never know...

So for those brave of you, please test them out...

If no (big/real) issues are found with them I'll push them to core/release
by the end of this week.


I've seen several programs segfaulting on dlopen(), eg: mplayer
See attached trace
Once rollbacking to 2.12, everything is OK again



On a fully updated cauldron ?

I'll recheck the buildlogs, and see if I can reproduce here.

--
Thomas

Re: [Mageia-dev] Proposal for bug statuses and workflow

[Maarten Vanraes]

Op woensdag 19 oktober 2011 23:30:05 schreef Samuel Verschelde:
> Here is a workflow proposal for bug reports in bugzilla.
[...]

This is ok for me, i like the resolutions as well.

Re: [Mageia-dev] ANN: glibc-2.14.1 landing...

[Thierry Vignaud]

On 18 October 2011 18:48, Thomas Backlund  wrote:
> I have updated glibc & locales-* from 2.12.1 to 2.14.1 and I'll push
> them to core/updates_testing so people can test it out but have a
> fallback if needed in case of regressions
>
> They seem to work ok here, but you never know...
>
> So for those brave of you, please test them out...
>
> If no (big/real) issues are found with them I'll push them to core/release
> by the end of this week.

I've seen several programs segfaulting on dlopen(), eg: mplayer
See attached trace
Once rollbacking to 2.12, everything is OK again
Program received signal SIGSEGV, Segmentation fault.
do_lookup_x (new_hash=1590579055, old_hash=, 
result=0x7fffa5f0, scope=, i=0, flags=2, skip=0x0, 
undef_map=0x77fd59b8) at dl-lookup.c:98
98  dl-lookup.c: Aucun fichier ou dossier de ce type.
in dl-lookup.c
(gdb) bt
#0  do_lookup_x (new_hash=1590579055, old_hash=, 
result=0x7fffa5f0, scope=, i=0, flags=2, skip=0x0, 
undef_map=0x77fd59b8) at dl-lookup.c:98
#1  0x77de72d2 in _dl_lookup_symbol_x (undef_name=0x7fffa8f0 
"__snd_timer_hw_open_dlsym_timer_001", undef_map=0x77fd59b8, 
ref=0x7fffa700, symbol_scope=
0x77fd5d40, version=0x0, type_class=0, flags=2, skip_map=0x0) at 
dl-lookup.c:739
#2  0x741ba245 in do_sym () from /lib64/libc.so.6
#3  0x772c8014 in dlsym_doit (a=0x7fffa8b0) at dlsym.c:51
#4  0x77deb6d6 in _dl_catch_error (objname=0x163fea0, 
errstring=0x163fea8, mallocedp=0x163fe98, operate=0x772c8000 , 
args=0x7fffa8b0) at dl-error.c:178
#5  0x772c84fc in _dlerror_run (operate=0x772c8000 , 
args=0x7fffa8b0) at dlerror.c:164
#6  0x772c806a in __dlsym (handle=, name=) at dlsym.c:71
#7  0x0032ed038cb3 in snd_dlsym_verify (handle=0x77fd59b8, 
name=0x7fffaa20 "_snd_timer_hw_open", version=) at 
dlmisc.c:121
#8  0x0032ed038dad in snd_dlsym (handle=0x77fd59b8, name=0x7fffaa20 
"_snd_timer_hw_open", version=) at dlmisc.c:163
#9  0x0032ed0960c5 in snd_timer_open_conf (timer=, 
name=0x7fffad00 "hw:CLASS=3,SCLASS=0,CARD=0,DEV=0,SUBDEV=0", 
timer_root=0x1d1d6d0, timer_conf=0x2123b20, 
mode=) at timer.c:160
#10 0x0032ed096479 in snd_timer_open_noupdate (timer=0x21243d0, 
root=0x1d1d6d0, name=0x7fffad00 
"hw:CLASS=3,SCLASS=0,CARD=0,DEV=0,SUBDEV=0", mode=3) at timer.c:192
#11 0x0032ed08ddaf in snd1_pcm_direct_initialize_poll_fd (dmix=0x2124300) 
at pcm_direct.c:1113
#12 0x0032ed087973 in snd_pcm_dmix_open (pcmp=0x7fffb228, 
name=, opts=0x7fffaf50, params=0x7fffaf20, 
root=0x1d1d6d0, sconf=0x21220a0, stream=
SND_PCM_STREAM_PLAYBACK, mode=0) at pcm_dmix.c:1093
#13 0x0032ed087f9a in _snd_pcm_dmix_open (pcmp=0x7fffb228, 
name=0x21224b0 "dmix:0", root=0x1d1d6d0, conf=, 
stream=SND_PCM_STREAM_PLAYBACK, mode=0)
at pcm_dmix.c:1319
#14 0x0032ed04fa78 in snd_pcm_open_conf (pcmp=, 
name=0x21224b0 "dmix:0", pcm_root=0x1d1d6d0, pcm_conf=, 
stream=SND_PCM_STREAM_PLAYBACK, 
mode=) at pcm.c:2166
#15 0x0032ed050090 in snd_pcm_open_noupdate (pcmp=0x7fffb228, 
root=0x1d1d6d0, name=0x21224b0 "dmix:0", stream=SND_PCM_STREAM_PLAYBACK, 
mode=0, hop=1) at pcm.c:2220
#16 0x0032ed051f79 in snd1_pcm_open_named_slave (pcmp=0x7fffb228, 
name=0x0, root=0x1d1d6d0, conf=0x1bcf810, stream=SND_PCM_STREAM_PLAYBACK, 
mode=0, parent_conf=0x1bcf430)
at pcm.c:2306
#17 0x0032ed072bb5 in snd_pcm_open_slave (parent_conf=0x1bcf430, mode=0, 
stream=SND_PCM_STREAM_PLAYBACK, conf=, root=0x1d1d6d0, 
pcmp=0x7fffb228)
at pcm_local.h:864
#18 _snd_pcm_plug_open (pcmp=0xfda3c8, name=0x7fffb830 "default", 
root=0x1d1d6d0, conf=0x1bcf430, stream=SND_PCM_STREAM_PLAYBACK, mode=0) at 
pcm_plug.c:1311
#19 0x0032ed04fa78 in snd_pcm_open_conf (pcmp=, 
name=0x7fffb830 "default", pcm_root=0x1d1d6d0, pcm_conf=, 
stream=SND_PCM_STREAM_PLAYBACK, 
mode=) at pcm.c:2166
#20 0x0032ed051fbf in snd1_pcm_open_named_slave (pcmp=0xfda3c8, 
name=0x7fffb830 "default", root=0x1d1d6d0, conf=0x1bcf430, 
stream=SND_PCM_STREAM_PLAYBACK, mode=0, parent_conf=
0x1bcf1c0) at pcm.c:2308
#21 0x0032ed08ee2b in _snd_pcm_asym_open (pcmp=0xfda3c8, 
name=0x7fffb830 "default", root=0x1d1d6d0, conf=0x1bcf1c0, 
stream=SND_PCM_STREAM_PLAYBACK, mode=0) at pcm_asym.c:112
#22 0x0032ed04fa78 in snd_pcm_open_conf (pcmp=, 
name=0x7fffb830 "default", pcm_root=0x1d1d6d0, pcm_conf=, 
stream=SND_PCM_STREAM_PLAYBACK, 
mode=) at pcm.c:2166
#23 0x0032ed051fbf in snd1_pcm_open_named_slave (pcmp=0xfda3c8, 
name=0x7fffb830 "default", root=0x1d1d6d0, conf=0x1bcf1c0, 
stream=SND_PCM_STREAM_PLAYBACK, mode=0, parent_conf=
0x1bcfaa0) at pcm.c:2308
#24 0x0032ed07916b in _snd_pcm_empty_open (pcmp=0xfda3c8, 
name=0x7fffb830 "default", root=0x1d1d6d0, conf=0x1bcfaa0, 
stream=SND_PCM_STREAM_PLAYBACK, mode=0) at pcm_empty.c:103
#25 0x0032ed04fa78 in snd_pcm_open_conf (pcmp=, 
name=0x7fffb830 "default", pc

[Mageia-dev] Proposal for bug statuses and workflow

[Samuel Verschelde]

Here is a workflow proposal for bug reports in bugzilla.

See the flowchart (link below) and the explanations below. Not all statuses 
will be used in every bug report, but the flowchart more or less gives the 
standard flow for bugs reported against a stable release of Mageia.

http://stormi.lautre.net/fichiers/mageia/triage.png

NEW: as currently, bugs are set to this status when created

NEW (+ NEEDINFO keyword): more input needed

NEW (+ Triaged keyword): bug report has been triaged by a triager or 
maintainer, and should have been assigned to the right maintainer (when 
there's one), but there's no guarantee about this.

ACCEPTED must be set by the maintainer, or a packager who decides to fix the 
bug for the maintainer. It doesn't mean that the packager is actively working 
on the fix, but shows that he/she is willing to whenever possible. Setting a 
bug report to accepted acknowledges that the triager assigned to the right 
person AND that this person saw that the bug report was assigned to him/her. 
In case of a bug assigned to a maintainer group (when there will be), setting 
the status to ACCEPTED means that the group is OK to handle the bug report, 
but it does not mean that someone from the group is already working on it. See 
the next status for that.

IN_PROGRESS can be set by the packager who is working on the bug. It is not 
mandatory, this status can be skipped. However, it is advised to use it to 
give better feedback to both triagers and bug reporters.

TESTING is set when assigning to QA Team (ideally bugzilla would automatically 
assign to QA when someone puts the TESTING status in a stable release).

VALIDATED is set by QA team once testing ends. It means that the update can be 
pushed (replaces the validated_update keyword)

CLOSED replaces RESOLVED, because I think it's nicer for the bug reporter if 
we "close" bugs rather than consider them "resolved" when the reason for 
closing is WONT-FIX, DUPLICATE, OLD, etc., statuses that obviously don't match 
the meaning of "RESOLVED".

ASSIGNED status disappears, because it was ambiguous. UNCONFIRMED disappears, 
it was unused already.

Here are the proposed Resolutions:
FIXED
NOT_A_BUG (replaces INVALID with a more neutral term)
INSUFFICIENT_DATA (new resolution for bugs closed due to lack of data)
CANT_FIX (it's too difficult to fix it, or there's a reason why we can't fix it)
WONT_FIX (we don't *want* to fix it)
DUPLICATE
WORKS_FOR_ME

Best regards

Samuel Verschelde

Re: [Mageia-dev] udev in initrd and/or using dracut (LVM root fs related)

[David W. Hodgins]

On Wed, 19 Oct 2011 09:20:35 -0400, Colin Guthrie  wrote:


In testing a more extensive use of systemd (i.e. using it to mount
filesystems etc. rather than using rc.sysinit) I've run into a few
problems regarding the fact that my LVM is activated in the initrd.


I'm using lvm in my cauldron and Mandriva 2011 installs.

I have / on a primary partition, with /usr, /var, /home, /opt, and
/tmp on lvm volumes.

I previously had /var/log on a primary partition, but that did give
me a problem with /var/log getting mounted before /var.  Once I
moved /var/log back into /var, mounting is ok. I have to kill
plymouth for a run level 3 boot, and have run into problems with
systemd timing out a mount, when an fsck has to run due to the
filesystem mount count, but haven't taken the time to file bug
reports on those yet.

My cauldron install started out as a Mandriva 2009.1 install, updated
via urpmi to 2010.2, then to Mageia 1, then to Cauldron.

Any info you think would be useful to figure out why it's working for
me, and not on your system?

Regards, Dave Hodgins

[Mageia-dev] require help to understand stage1/stage2/rescue source files

[Maarten Vanraes]

Hi,

is there someone who can help me understand the stage1/stage2/rescue system? 
or point to some docs? i've looked at it, but it seems to be sometimes one 
source file used for both... it's really confusing me.

I need to do some modifications for files and busybox option and i need to 
build 
these stage1/rescue to actually be able to test sshd (actually dropbear)

Thanks in advance for any help.

AL13N

Re: [Mageia-dev] udev in initrd and/or using dracut (LVM root fs related)

[Maarten Vanraes]

Op woensdag 19 oktober 2011 16:00:09 schreef Thierry Vignaud:
[...]
> I think we shall not support the mkinitrd burden only by ourselves
> If all other are switching to dracut, we may have to too
> At some point, we'd extensive changes (by Luca?) for detecting MD/DM/LV,
> dunno if drakcut is ready to replace?

i agree, however, my last brush with dracut, i don't think it's ready yet. and 
on top of that, it produces huge initrds (initramfs'es), which imho slows down 
the booting processes (especially on PXE network installs)

furthermore, i may be wrong, but wasn't udev actually started in the initrd? i 
thought i only saw an udev-post service after initrd.

but i have no perfect solution, and mkinitrd is not maintained upstream afaict

Re: [Mageia-dev] missing deps, lash rebuilt for texi2html

[Philippe DIDIER]

Funda Wang a écrit :
> 2011/10/16 Thomas Spuhler :
>> Thanks Funda. I will look it up just to learn how you did it.
> The problem comes from the upgrading of swig, it tends to have such
> problems when doing major upgrades.
> 

Does it mean that  packages having "BuildRequires: swig" in the spec
file, must be rebuilt since swig has been updated ???
And that lot of them will need patches ? ...

Sophies says that 40 srpms have Builrequires: swig !

Must we ask their maintainers try to rebuild each of them, and look for
a patch if it can't be rebuilt ?

Must we open a tracker in bugzilla with the list of "packages needing to
be rebuilt and perhaps patched since swig has been updated " ?
and open a bug report for each of them ?

Re: [Mageia-dev] [changelog] cauldron core/release gdm-3.2.1-1.mga2

[Balcaen John]

Le mercredi 19 octobre 2011 19:35:39 Jani Välimaa a écrit :
[...]
> 
> There's already new version 3.2.1.1 available, but I'm not going to
> touch (read: broke) it. (:
You're waiting for friday ? :)

-- 
Balcaen John
Jabber-id: mik...@jabber.littleboboy.net

Re: [Mageia-dev] [changelog] cauldron core/release gdm-3.2.1-1.mga2

[Jani Välimaa]

2011/10/19 Colin Guthrie :
> 'Twas brillig, and Colin Guthrie at 19/10/11 13:45 did gyre and gimble:
>> 'Twas brillig, and Jani Välimaa at 19/10/11 10:38 did gyre and gimble:
>>> 2011/10/19 Colin Guthrie :
 'Twas brillig, and Mageia Team at 19/10/11 07:26 did gyre and gimble:
> Name        : gdm                          Relocations: (not relocatable)
> Version     : 3.2.1                             Vendor: Mageia.Org
> Release     : 1.mga2                        Build Date: Wed Oct 19 
> 08:18:14 2011
> Install Date: (not installed)               Build Host: ecosse
> Group       : Graphical desktop/GNOME       Source RPM: (none)
> Size        : 1702567                          License: GPLv2+
> Signature   : (none)
> Packager    : Mageia Team 
> URL         : http://www.gnome.org/projects/gdm/
> Summary     : The GNOME Display Manager
> Description :
> Gdm (the GNOME Display Manager) is a highly configurable
> reimplementation of xdm, the X Display Manager. Gdm allows you to log
> into your system with the X Window System running and supports running
> several different X sessions on your local machine at the same time.
>
> wally  3.2.1-1.mga2:
> + Revision: 156474
> - new version 3.2.1
> - create own subpackage for gir .typelib
> - clean .spec a bit

 For packages that have a pretty high impact, you probably should test it
 before updating.

 In this case 3.2.1 introduces a new dconf system which totally breaks if
 you don't do some %post stuff to update the actual data file.

 These instructions were clearly documented and if you'd tested the
 package even minimally, you'd have seen the problem and no doubt found
 this commit quickly (I saw the problem, did a temporary fix), logged in,
 looked in git and found the commit immediately and then fixed the spec
 accordingly).

 http://git.gnome.org/browse/gdm/commit/?h=gnome-3-2&id=25004e4d11bbd2e8a22d5bcf49f294e9f63d2ce5


 So please in future, be considerate and test these packages before
 pushing otherwise you'll get a lot of unhappy users who cannot log in!

>>>
>>> Sorry, my bad. I'll do more thorough testing next time. I did read
>>> NEWS and all, but didn't notice anything "abnormal" so I didn't test
>>> the pkg enough.
>>>
>>> Luckily you were awake and fixed package pretty fast. Thx for that.
>>
>> Yeah I've asked Ray on IRC to add a bit more info about that change  (it
>> should have been in NEWS IMO)...
>
> Just for reference, I spoke to Ray a bit and it seems the whole
> mechanism is a bit rubbish (he says so himself) and will change soon, so
> we should keep our eyes open for the next release and any changes it brings.
>
> Discussion on the matter here:
> https://bugzilla.gnome.org/show_bug.cgi?id=662168
>

There's already new version 3.2.1.1 available, but I'm not going to
touch (read: broke) it. (:

Re: [Mageia-dev] Tonight's meeting

[Samuel Verschelde]

Le mercredi 19 octobre 2011 17:56:24, Anne nicolas a écrit :
> Hi there
> 
> We will have our meeting tonight. Here are proposed topics
> 
> - Status on "ASSIGNED" tag in Bugzilla (see discussion on ML about this)
> - Quick  review of action plan for bs hardware
> - Start thinking about organization for first alpha release
> - Review of QA, triage, secteam and mentoring
> 
> Cheers

I will probably not be able to attend tonight, so I can't do the QA review.

About the ASSIGNED status, I would advise to not lose too much time discussing 
it, as the question should be answered in a broader way by triage team (and 
those interested) by proposing a revised workflow, including but not limited 
to, the use of the ASSIGNED status (TRIAGED status, reasons for closing a bug, 
etc.).

The Fedora workflow is probably a could basis that we could adapt to our 
organization (less the bodhi step):
https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow

Discussing the ASSIGNED status alone will not lead very far, and it's not 
blocking for now: currently triage team simply doesn't touch it at all, 
leaving it for the maintainer to choose), which is not far from what we did in 
Mandriva and what they do in Fedora.

Best regards

Samuel Verschelde

[Mageia-dev] Tonight's meeting

[Anne nicolas]

Hi there

We will have our meeting tonight. Here are proposed topics

- Status on "ASSIGNED" tag in Bugzilla (see discussion on ML about this)
- Quick  review of action plan for bs hardware
- Start thinking about organization for first alpha release
- Review of QA, triage, secteam and mentoring

Cheers

-- 
Anne
http://www.mageia.org

Re: [Mageia-dev] [RFC] msec (nail) can't send reports to local users accounts - require an MTA?

[Anne nicolas]

2011/10/19 Florian Hubold :
> Am 19.10.2011 11:01, schrieb nicolas vigier:
>>
>> On Wed, 19 Oct 2011, andre999 wrote:
>>
>>> nicolas vigier a écrit :

 On Tue, 18 Oct 2011, andre999 wrote:

> Balcaen John a écrit :
>
>> Le lundi 17 octobre 2011 16:39:14 nicolas vigier a écrit :
>> [...]
>>
>>
>>> I think that :
>>>    - changing the default configuration in an update is wrong. If
>>> it's
>>>      better that msec do not send emails by default, I think this
>>> change
>>>      should be done in cauldron only, maybe with some note about this
>>> change
>>>      in the release notes for Mageia 2.
>>>
>>>
>> Agree.
>>
> A question : wouldn't changing the default in _both_ cauldron and an
> update
> to mga1 be acceptable ?
>
 I think stable updates should not change defaults.


> Since I really think that sending messages silently to dead.letter,
> gradually filling up the disk is a bug.  (When I first discovered the
> problem on my system a few years ago, dead.letter used about 1G of disk
> space in my root partition.)
> That is what happens with the default setting, if an MTA is not
> installed.
> At the default settings with an MTA installed, the root mailbox
> gradually
> fills up the disk, if it is not emptied.  And a less informed user is
> unlikely to realise this.
>
> So it seems to me that as a minimum, the default should be changed to
> _not_
> send alert emails.  Since the status is visible on the main msec
> screen,
> informed users should have no problem appropriately adjusting the
> setting.
>
> To deal with the potential problem of users who use the email alert
> feature
> having it deactivated by the update, we only need a warning in the
> update,
> as often occurs for other packages.
>
 Updates should not require manual changes. And not everybody read the
 update logs from urpmi. People can expect important changes when
 upgrading
 to a new version of the distribution, and that's why there is release
 notes to explain the important changes, but not for stable updates.

>>> Personally I am much more likely to notice the update log message from
>>> urpmi than everything in the release notes.  I make a point of reading
>>> the
>>> former, which necessarily affect an application that I have installed.
>>> Most of the release notes comments are either painfully obvious, or
>>> affect
>>> something that I don't have installed or don't care about, so I tend to
>>> miss many details until I run into a problem.
>>> In this particular case, the problem would be not getting msec
>>> notifications.
>>
>> People should not expect an update to change something that has been the
>> default for years. This kind of change should be done for a new release
>> of the distribution, not in updates. If you don't read the release
>> notes when doing upgrade changing important things, but always read
>> urpmi logs of updates that are supposed to have minimal changes, then
>> you're doing something wrong, but I hope not everybody does that.
>>
>>> Although I realise that in general it would be better to avoid
>>> significant
>>> changes in updates, in this case I think that most users would be better
>>> served by this change being introduced in an update, rather than in a
>>> release.
>>
>> So you want to break something for some user, to improve it for some
>> others ?
>>
>> This has been the default for years. I don't see any reason to urgently
>> change this with an update.
>>
> Something like "If you use the msec alert emails, please verify that
> the
> alerts are still active."  Note that if the user has ever explicitly
> set
> alerts, they would be still active.
>
>>> I was mistaken.  But editing /etc/security/msec/security.conf to add the
>>> line "MAIL_WARN=yes" will protect from a default of "MAIL_WARN=no".
>>> (Tested.)
>>>
> This potential problem would exist even if the next update for the user
> is
> mga2.
> However, if the update is on mga2 (from changes in cauldron), wouldn't
> the
> change in defaults be less visible ?
>
>>> [...]
>
> According to documentation, dma is only active if no other MTA is
> installed.
> (I don't know if the priority is what causes this.)
> So at worst dma would be a (very small) harmless extra install, at best
> it
> would ensure the ability for local delivery.
>
 Then dma could be installed by default on mageia 2, this would fix the
 problem for all programs using the sendmail command, not only msec,
 without adding a require on dma.

>>> That would work, as long as it is a "require" of Mageia 2.
>>
>> Not a require, but installed by default. And msec should have a require
>> on sendmail-command.
>>
>>
> So to make this clear for Mageia 1 we keep m

Re: [Mageia-dev] [changelog] cauldron core/release gdm-3.2.1-1.mga2

[Colin Guthrie]

'Twas brillig, and Colin Guthrie at 19/10/11 13:45 did gyre and gimble:
> 'Twas brillig, and Jani Välimaa at 19/10/11 10:38 did gyre and gimble:
>> 2011/10/19 Colin Guthrie :
>>> 'Twas brillig, and Mageia Team at 19/10/11 07:26 did gyre and gimble:
 Name: gdm  Relocations: (not relocatable)
 Version : 3.2.1 Vendor: Mageia.Org
 Release : 1.mga2Build Date: Wed Oct 19 
 08:18:14 2011
 Install Date: (not installed)   Build Host: ecosse
 Group   : Graphical desktop/GNOME   Source RPM: (none)
 Size: 1702567  License: GPLv2+
 Signature   : (none)
 Packager: Mageia Team 
 URL : http://www.gnome.org/projects/gdm/
 Summary : The GNOME Display Manager
 Description :
 Gdm (the GNOME Display Manager) is a highly configurable
 reimplementation of xdm, the X Display Manager. Gdm allows you to log
 into your system with the X Window System running and supports running
 several different X sessions on your local machine at the same time.

 wally  3.2.1-1.mga2:
 + Revision: 156474
 - new version 3.2.1
 - create own subpackage for gir .typelib
 - clean .spec a bit
>>>
>>> For packages that have a pretty high impact, you probably should test it
>>> before updating.
>>>
>>> In this case 3.2.1 introduces a new dconf system which totally breaks if
>>> you don't do some %post stuff to update the actual data file.
>>>
>>> These instructions were clearly documented and if you'd tested the
>>> package even minimally, you'd have seen the problem and no doubt found
>>> this commit quickly (I saw the problem, did a temporary fix), logged in,
>>> looked in git and found the commit immediately and then fixed the spec
>>> accordingly).
>>>
>>> http://git.gnome.org/browse/gdm/commit/?h=gnome-3-2&id=25004e4d11bbd2e8a22d5bcf49f294e9f63d2ce5
>>>
>>>
>>> So please in future, be considerate and test these packages before
>>> pushing otherwise you'll get a lot of unhappy users who cannot log in!
>>>
>>
>> Sorry, my bad. I'll do more thorough testing next time. I did read
>> NEWS and all, but didn't notice anything "abnormal" so I didn't test
>> the pkg enough.
>>
>> Luckily you were awake and fixed package pretty fast. Thx for that.
> 
> Yeah I've asked Ray on IRC to add a bit more info about that change  (it
> should have been in NEWS IMO)...

Just for reference, I spoke to Ray a bit and it seems the whole
mechanism is a bit rubbish (he says so himself) and will change soon, so
we should keep our eyes open for the next release and any changes it brings.

Discussion on the matter here:
https://bugzilla.gnome.org/show_bug.cgi?id=662168

Col

-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

Re: [Mageia-dev] [RFC] msec (nail) can't send reports to local users accounts - require an MTA?

[Florian Hubold]

Am 19.10.2011 11:01, schrieb nicolas vigier:

On Wed, 19 Oct 2011, andre999 wrote:


nicolas vigier a écrit :

On Tue, 18 Oct 2011, andre999 wrote:


Balcaen John a écrit :


Le lundi 17 octobre 2011 16:39:14 nicolas vigier a écrit :
[...]



I think that :
- changing the default configuration in an update is wrong. If it's
  better that msec do not send emails by default, I think this change
  should be done in cauldron only, maybe with some note about this change
  in the release notes for Mageia 2.



Agree.


A question : wouldn't changing the default in _both_ cauldron and an update
to mga1 be acceptable ?


I think stable updates should not change defaults.



Since I really think that sending messages silently to dead.letter,
gradually filling up the disk is a bug.  (When I first discovered the
problem on my system a few years ago, dead.letter used about 1G of disk
space in my root partition.)
That is what happens with the default setting, if an MTA is not installed.
At the default settings with an MTA installed, the root mailbox gradually
fills up the disk, if it is not emptied.  And a less informed user is
unlikely to realise this.

So it seems to me that as a minimum, the default should be changed to _not_
send alert emails.  Since the status is visible on the main msec screen,
informed users should have no problem appropriately adjusting the setting.

To deal with the potential problem of users who use the email alert feature
having it deactivated by the update, we only need a warning in the update,
as often occurs for other packages.


Updates should not require manual changes. And not everybody read the
update logs from urpmi. People can expect important changes when upgrading
to a new version of the distribution, and that's why there is release
notes to explain the important changes, but not for stable updates.


Personally I am much more likely to notice the update log message from
urpmi than everything in the release notes.  I make a point of reading the
former, which necessarily affect an application that I have installed.
Most of the release notes comments are either painfully obvious, or affect
something that I don't have installed or don't care about, so I tend to
miss many details until I run into a problem.
In this particular case, the problem would be not getting msec
notifications.

People should not expect an update to change something that has been the
default for years. This kind of change should be done for a new release
of the distribution, not in updates. If you don't read the release
notes when doing upgrade changing important things, but always read
urpmi logs of updates that are supposed to have minimal changes, then
you're doing something wrong, but I hope not everybody does that.


Although I realise that in general it would be better to avoid significant
changes in updates, in this case I think that most users would be better
served by this change being introduced in an update, rather than in a
release.

So you want to break something for some user, to improve it for some
others ?

This has been the default for years. I don't see any reason to urgently
change this with an update.


Something like "If you use the msec alert emails, please verify that the
alerts are still active."  Note that if the user has ever explicitly set
alerts, they would be still active.


I was mistaken.  But editing /etc/security/msec/security.conf to add the
line "MAIL_WARN=yes" will protect from a default of "MAIL_WARN=no".
(Tested.)


This potential problem would exist even if the next update for the user is
mga2.
However, if the update is on mga2 (from changes in cauldron), wouldn't the
change in defaults be less visible ?


[...]

According to documentation, dma is only active if no other MTA is installed.
(I don't know if the priority is what causes this.)
So at worst dma would be a (very small) harmless extra install, at best it
would ensure the ability for local delivery.


Then dma could be installed by default on mageia 2, this would fix the
problem for all programs using the sendmail command, not only msec,
without adding a require on dma.


That would work, as long as it is a "require" of Mageia 2.

Not a require, but installed by default. And msec should have a require
on sendmail-command.



So to make this clear for Mageia 1 we keep msec as it currently is, not changing
anything and for Cauldron should i already add Requires: sendmail-command?


BTW: Would have been nice if you would have dropped your opinion earlier in the
thread, that would have saved much email noise and you would have prevented
quite some investigative work which got in there IMHO ...

Re: [Mageia-dev] udev in initrd and/or using dracut (LVM root fs related)

[Thierry Vignaud]

On 19 October 2011 15:20, Colin Guthrie  wrote:
> In testing a more extensive use of systemd (i.e. using it to mount
> filesystems etc. rather than using rc.sysinit) I've run into a few
> problems regarding the fact that my LVM is activated in the initrd.
>
> Due to this, various entries in the udev db are not set. systemd uses
> these missing bits to launch the local-fs.target and thus fails (even if
> it's just my /home that is broken which won't really be needed).
>
> I've been told in various discussions with upstream that ultimately we
> need to use udev in the initrd. It seems that fedora and suse at least
> do this.
>
> I can work around it of course (we do so just now) but I'd like to get
> things working as "natively" as possible with systemd if possible.
>
> So should we:
>
>  a) Try to incorporate udev into our mkinitrd?
>  b) Switch to dracut
>
> I'm not an expert at this stuff, but I know that Mandriva has started
> using dracut more and I think it's likely the best solution overall
> seeing as it's Fedora's preferred mechanism too.
>
> But I didn't want to start looking at it until there is some consensus
> on this - hence this email.

I think we shall not support the mkinitrd burden only by ourselves
If all other are switching to dracut, we may have to too
At some point, we'd extensive changes (by Luca?) for detecting MD/DM/LV,
dunno if drakcut is ready to replace?

[Mageia-dev] udev in initrd and/or using dracut (LVM root fs related)

[Colin Guthrie]

Hi,

In testing a more extensive use of systemd (i.e. using it to mount
filesystems etc. rather than using rc.sysinit) I've run into a few
problems regarding the fact that my LVM is activated in the initrd.

Due to this, various entries in the udev db are not set. systemd uses
these missing bits to launch the local-fs.target and thus fails (even if
it's just my /home that is broken which won't really be needed).

I've been told in various discussions with upstream that ultimately we
need to use udev in the initrd. It seems that fedora and suse at least
do this.

I can work around it of course (we do so just now) but I'd like to get
things working as "natively" as possible with systemd if possible.

So should we:

 a) Try to incorporate udev into our mkinitrd?
 b) Switch to dracut

I'm not an expert at this stuff, but I know that Mandriva has started
using dracut more and I think it's likely the best solution overall
seeing as it's Fedora's preferred mechanism too.

But I didn't want to start looking at it until there is some consensus
on this - hence this email.


FWIW, I've put some detailed info on an Mdv bug concerning this same
issue here:
https://qa.mandriva.com/show_bug.cgi?id=63471

Col

PS I've CC'ed a couple of specifically interested/clued up people so
they don't miss this mail, but of course comments from anyone are
appreciated:)

-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

Re: [Mageia-dev] [changelog] cauldron core/release gdm-3.2.1-1.mga2

[Colin Guthrie]

'Twas brillig, and Jani Välimaa at 19/10/11 10:38 did gyre and gimble:
> 2011/10/19 Colin Guthrie :
>> 'Twas brillig, and Mageia Team at 19/10/11 07:26 did gyre and gimble:
>>> Name: gdm  Relocations: (not relocatable)
>>> Version : 3.2.1 Vendor: Mageia.Org
>>> Release : 1.mga2Build Date: Wed Oct 19 08:18:14 
>>> 2011
>>> Install Date: (not installed)   Build Host: ecosse
>>> Group   : Graphical desktop/GNOME   Source RPM: (none)
>>> Size: 1702567  License: GPLv2+
>>> Signature   : (none)
>>> Packager: Mageia Team 
>>> URL : http://www.gnome.org/projects/gdm/
>>> Summary : The GNOME Display Manager
>>> Description :
>>> Gdm (the GNOME Display Manager) is a highly configurable
>>> reimplementation of xdm, the X Display Manager. Gdm allows you to log
>>> into your system with the X Window System running and supports running
>>> several different X sessions on your local machine at the same time.
>>>
>>> wally  3.2.1-1.mga2:
>>> + Revision: 156474
>>> - new version 3.2.1
>>> - create own subpackage for gir .typelib
>>> - clean .spec a bit
>>
>> For packages that have a pretty high impact, you probably should test it
>> before updating.
>>
>> In this case 3.2.1 introduces a new dconf system which totally breaks if
>> you don't do some %post stuff to update the actual data file.
>>
>> These instructions were clearly documented and if you'd tested the
>> package even minimally, you'd have seen the problem and no doubt found
>> this commit quickly (I saw the problem, did a temporary fix), logged in,
>> looked in git and found the commit immediately and then fixed the spec
>> accordingly).
>>
>> http://git.gnome.org/browse/gdm/commit/?h=gnome-3-2&id=25004e4d11bbd2e8a22d5bcf49f294e9f63d2ce5
>>
>>
>> So please in future, be considerate and test these packages before
>> pushing otherwise you'll get a lot of unhappy users who cannot log in!
>>
> 
> Sorry, my bad. I'll do more thorough testing next time. I did read
> NEWS and all, but didn't notice anything "abnormal" so I didn't test
> the pkg enough.
> 
> Luckily you were awake and fixed package pretty fast. Thx for that.

Yeah I've asked Ray on IRC to add a bit more info about that change  (it
should have been in NEWS IMO)...

Anyway, no biggie but gdm in particular is probably one to always test
first :)

Col


-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

Re: [Mageia-dev] [changelog] cauldron core/release gdm-3.2.1-1.mga2

[Thomas Backlund]

Thierry Vignaud skrev 19.10.2011 13:41:

On 19 October 2011 11:19, Colin Guthrie  wrote:

Yeah true, but that still doesn't excuse the lack of testing, especially
in a package as complex a gdm (I've spent a lot of time updating it ot
the latest gnome-shell version and integrating with systemd permissions
etc, so I know it's a somewhat "temperamental" package that shouldn't be
updated blindly).


We could use sg like fedora's bodhi.
uploaded packages would be in a temp repo for a week pending
ACK by testers...


Well, we also have updates_testing ...

--
Thomas

Re: [Mageia-dev] [changelog] cauldron core/release gdm-3.2.1-1.mga2

[Thierry Vignaud]

On 19 October 2011 11:19, Colin Guthrie  wrote:
> Yeah true, but that still doesn't excuse the lack of testing, especially
> in a package as complex a gdm (I've spent a lot of time updating it ot
> the latest gnome-shell version and integrating with systemd permissions
> etc, so I know it's a somewhat "temperamental" package that shouldn't be
> updated blindly).

We could use sg like fedora's bodhi.
uploaded packages would be in a temp repo for a week pending
ACK by testers...

Re: [Mageia-dev] [changelog] cauldron core/release gdm-3.2.1-1.mga2

[Jani Välimaa]

2011/10/19 Colin Guthrie :
> 'Twas brillig, and Mageia Team at 19/10/11 07:26 did gyre and gimble:
>> Name        : gdm                          Relocations: (not relocatable)
>> Version     : 3.2.1                             Vendor: Mageia.Org
>> Release     : 1.mga2                        Build Date: Wed Oct 19 08:18:14 
>> 2011
>> Install Date: (not installed)               Build Host: ecosse
>> Group       : Graphical desktop/GNOME       Source RPM: (none)
>> Size        : 1702567                          License: GPLv2+
>> Signature   : (none)
>> Packager    : Mageia Team 
>> URL         : http://www.gnome.org/projects/gdm/
>> Summary     : The GNOME Display Manager
>> Description :
>> Gdm (the GNOME Display Manager) is a highly configurable
>> reimplementation of xdm, the X Display Manager. Gdm allows you to log
>> into your system with the X Window System running and supports running
>> several different X sessions on your local machine at the same time.
>>
>> wally  3.2.1-1.mga2:
>> + Revision: 156474
>> - new version 3.2.1
>> - create own subpackage for gir .typelib
>> - clean .spec a bit
>
> For packages that have a pretty high impact, you probably should test it
> before updating.
>
> In this case 3.2.1 introduces a new dconf system which totally breaks if
> you don't do some %post stuff to update the actual data file.
>
> These instructions were clearly documented and if you'd tested the
> package even minimally, you'd have seen the problem and no doubt found
> this commit quickly (I saw the problem, did a temporary fix), logged in,
> looked in git and found the commit immediately and then fixed the spec
> accordingly).
>
> http://git.gnome.org/browse/gdm/commit/?h=gnome-3-2&id=25004e4d11bbd2e8a22d5bcf49f294e9f63d2ce5
>
>
> So please in future, be considerate and test these packages before
> pushing otherwise you'll get a lot of unhappy users who cannot log in!
>

Sorry, my bad. I'll do more thorough testing next time. I did read
NEWS and all, but didn't notice anything "abnormal" so I didn't test
the pkg enough.

Luckily you were awake and fixed package pretty fast. Thx for that.

Re: [Mageia-dev] virtualbox 4.0.14 update for Mageia 1?

[Colin Guthrie]

'Twas brillig, and Samuel Verschelde at 19/10/11 09:47 did gyre and gimble:
> Le mercredi 19 octobre 2011 10:28:21, Colin Guthrie a écrit :
>> I think there were some in updates_testing (pretty sure I pushed it
>> there but then forgot about it :s)
>>
> 
> You will be hung to a tall tree for forgetting to pass this update to QA!

It was pushed long before QA existed! But I've no doubt already been
hung drawn and quartered for various other transgressions!

Col


-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

Re: [Mageia-dev] [changelog] cauldron core/release gdm-3.2.1-1.mga2

[Colin Guthrie]

'Twas brillig, and Olav Vitters at 19/10/11 10:16 did gyre and gimble:
> On Wed, Oct 19, 2011 at 09:39:50AM +0100, Colin Guthrie wrote:
>> These instructions were clearly documented and if you'd tested the
> 
> I actually think this should've been communicated better from
> upstream... asked the maintainer to send a msg to
> distributor-l...@gnome.org + put clearer warnings in the NEWS file.

Yeah true, but that still doesn't excuse the lack of testing, especially
in a package as complex a gdm (I've spent a lot of time updating it ot
the latest gnome-shell version and integrating with systemd permissions
etc, so I know it's a somewhat "temperamental" package that shouldn't be
updated blindly).

But perhaps Ray will send that email - the git tag for 3.2.1 is not even
pushed yet so I figure we're very quick of the mark grabbing the
tarballs here.

Col

-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

Re: [Mageia-dev] virtualbox 4.0.14 update for Mageia 1?

[Thomas Backlund]

Samuel Verschelde skrev 19.10.2011 11:46:

Le mercredi 19 octobre 2011 04:45:40, You-Cheng Hsieh a écrit :

Hello,

Out of surprise, Oracle released a 4.0.14 update for old 4.0 series of
virtualbox:
https://www.virtualbox.org/wiki/Download_Old_Builds_4_0
(Last version of 4.0 series, 4.0.12, was released in Jul 15. For
virtualbox, usually when a new major version released, e.g. 4.1, the
old version series will not be updated.)

Will it be packed as a core update for Mageia 1? We don't have any
virtualbox in Mageia 1's updates or backports.

Thanks,

You-Cheng Hsieh


It's hard to answer because virtualbox currently has no maintainer. What do
the changelogs say, are the changes from 4.0.6 to 4.0.14 only bugfixes ?



From what I read, there are several important fixes, so I'd suggest to 
push it as an update...

https://www.virtualbox.org/wiki/Changelog-4.0

--
Thomas

Re: [Mageia-dev] [changelog] cauldron core/release gdm-3.2.1-1.mga2

[Olav Vitters]

On Wed, Oct 19, 2011 at 09:39:50AM +0100, Colin Guthrie wrote:
> These instructions were clearly documented and if you'd tested the

I actually think this should've been communicated better from
upstream... asked the maintainer to send a msg to
distributor-l...@gnome.org + put clearer warnings in the NEWS file.
-- 
Regards,
Olav

Re: [Mageia-dev] [RFC] msec (nail) can't send reports to local users accounts - require an MTA?

[nicolas vigier]

On Wed, 19 Oct 2011, andre999 wrote:

> nicolas vigier a écrit :
>> On Tue, 18 Oct 2011, andre999 wrote:
>>
>>> Balcaen John a écrit :
>>>  
 Le lundi 17 octobre 2011 16:39:14 nicolas vigier a écrit :
 [...]


> I think that :
>- changing the default configuration in an update is wrong. If it's
>  better that msec do not send emails by default, I think this change
>  should be done in cauldron only, maybe with some note about this 
> change
>  in the release notes for Mageia 2.
>
>  
 Agree.

>>> A question : wouldn't changing the default in _both_ cauldron and an update
>>> to mga1 be acceptable ?
>>>  
>> I think stable updates should not change defaults.
>>
>>
>>> Since I really think that sending messages silently to dead.letter,
>>> gradually filling up the disk is a bug.  (When I first discovered the
>>> problem on my system a few years ago, dead.letter used about 1G of disk
>>> space in my root partition.)
>>> That is what happens with the default setting, if an MTA is not installed.
>>> At the default settings with an MTA installed, the root mailbox gradually
>>> fills up the disk, if it is not emptied.  And a less informed user is
>>> unlikely to realise this.
>>>
>>> So it seems to me that as a minimum, the default should be changed to _not_
>>> send alert emails.  Since the status is visible on the main msec screen,
>>> informed users should have no problem appropriately adjusting the setting.
>>>
>>> To deal with the potential problem of users who use the email alert feature
>>> having it deactivated by the update, we only need a warning in the update,
>>> as often occurs for other packages.
>>>  
>> Updates should not require manual changes. And not everybody read the
>> update logs from urpmi. People can expect important changes when upgrading
>> to a new version of the distribution, and that's why there is release
>> notes to explain the important changes, but not for stable updates.
>>
> Personally I am much more likely to notice the update log message from 
> urpmi than everything in the release notes.  I make a point of reading the 
> former, which necessarily affect an application that I have installed.
> Most of the release notes comments are either painfully obvious, or affect 
> something that I don't have installed or don't care about, so I tend to 
> miss many details until I run into a problem.
> In this particular case, the problem would be not getting msec 
> notifications.

People should not expect an update to change something that has been the
default for years. This kind of change should be done for a new release
of the distribution, not in updates. If you don't read the release
notes when doing upgrade changing important things, but always read
urpmi logs of updates that are supposed to have minimal changes, then
you're doing something wrong, but I hope not everybody does that.

>
> Although I realise that in general it would be better to avoid significant 
> changes in updates, in this case I think that most users would be better 
> served by this change being introduced in an update, rather than in a 
> release.

So you want to break something for some user, to improve it for some
others ?

This has been the default for years. I don't see any reason to urgently
change this with an update.

>
>>> Something like "If you use the msec alert emails, please verify that the
>>> alerts are still active."  Note that if the user has ever explicitly set
>>> alerts, they would be still active.
>>>  
> I was mistaken.  But editing /etc/security/msec/security.conf to add the 
> line "MAIL_WARN=yes" will protect from a default of "MAIL_WARN=no".  
> (Tested.)
>
>>> This potential problem would exist even if the next update for the user is
>>> mga2.
>>> However, if the update is on mga2 (from changes in cauldron), wouldn't the
>>> change in defaults be less visible ?
>>>  
> [...]
>>> According to documentation, dma is only active if no other MTA is installed.
>>> (I don't know if the priority is what causes this.)
>>> So at worst dma would be a (very small) harmless extra install, at best it
>>> would ensure the ability for local delivery.
>>>  
>> Then dma could be installed by default on mageia 2, this would fix the
>> problem for all programs using the sendmail command, not only msec,
>> without adding a require on dma.
>>
>
> That would work, as long as it is a "require" of Mageia 2.

Not a require, but installed by default. And msec should have a require
on sendmail-command.

Re: [Mageia-dev] virtualbox 4.0.14 update for Mageia 1?

[Samuel Verschelde]

Le mercredi 19 octobre 2011 10:28:21, Colin Guthrie a écrit :
> I think there were some in updates_testing (pretty sure I pushed it
> there but then forgot about it :s)
> 

You will be hung to a tall tree for forgetting to pass this update to QA!

Samuel

Re: [Mageia-dev] virtualbox 4.0.14 update for Mageia 1?

[Samuel Verschelde]

Le mercredi 19 octobre 2011 04:45:40, You-Cheng Hsieh a écrit :
> Hello,
> 
> Out of surprise, Oracle released a 4.0.14 update for old 4.0 series of
> virtualbox:
> https://www.virtualbox.org/wiki/Download_Old_Builds_4_0
> (Last version of 4.0 series, 4.0.12, was released in Jul 15. For
> virtualbox, usually when a new major version released, e.g. 4.1, the
> old version series will not be updated.)
> 
> Will it be packed as a core update for Mageia 1? We don't have any
> virtualbox in Mageia 1's updates or backports.
> 
> Thanks,
> 
> You-Cheng Hsieh

It's hard to answer because virtualbox currently has no maintainer. What do 
the changelogs say, are the changes from 4.0.6 to 4.0.14 only bugfixes ?

Samuel

Re: [Mageia-dev] [changelog] cauldron core/release gdm-3.2.1-1.mga2

[Colin Guthrie]

'Twas brillig, and Mageia Team at 19/10/11 07:26 did gyre and gimble:
> Name: gdm  Relocations: (not relocatable)
> Version : 3.2.1 Vendor: Mageia.Org
> Release : 1.mga2Build Date: Wed Oct 19 08:18:14 
> 2011
> Install Date: (not installed)   Build Host: ecosse
> Group   : Graphical desktop/GNOME   Source RPM: (none)
> Size: 1702567  License: GPLv2+
> Signature   : (none)
> Packager: Mageia Team 
> URL : http://www.gnome.org/projects/gdm/
> Summary : The GNOME Display Manager
> Description :
> Gdm (the GNOME Display Manager) is a highly configurable
> reimplementation of xdm, the X Display Manager. Gdm allows you to log
> into your system with the X Window System running and supports running
> several different X sessions on your local machine at the same time.
> 
> wally  3.2.1-1.mga2:
> + Revision: 156474
> - new version 3.2.1
> - create own subpackage for gir .typelib
> - clean .spec a bit

For packages that have a pretty high impact, you probably should test it
before updating.

In this case 3.2.1 introduces a new dconf system which totally breaks if
you don't do some %post stuff to update the actual data file.

These instructions were clearly documented and if you'd tested the
package even minimally, you'd have seen the problem and no doubt found
this commit quickly (I saw the problem, did a temporary fix), logged in,
looked in git and found the commit immediately and then fixed the spec
accordingly).

http://git.gnome.org/browse/gdm/commit/?h=gnome-3-2&id=25004e4d11bbd2e8a22d5bcf49f294e9f63d2ce5


So please in future, be considerate and test these packages before
pushing otherwise you'll get a lot of unhappy users who cannot log in!

Col


-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

Re: [Mageia-dev] ANN: glibc-2.14.1 landing...

[Olav Vitters]

On Tue, Oct 18, 2011 at 07:48:32PM +0300, Thomas Backlund wrote:
> I have updated glibc & locales-* from 2.12.1 to 2.14.1 and I'll push
> them to core/updates_testing so people can test it out but have a
> fallback if needed in case of regressions

Cool :)
-- 
Regards,
Olav

Re: [Mageia-dev] virtualbox 4.0.14 update for Mageia 1?

[Colin Guthrie]

'Twas brillig, and You-Cheng Hsieh at 19/10/11 03:45 did gyre and gimble:
> Hello,
> 
> Out of surprise, Oracle released a 4.0.14 update for old 4.0 series of
> virtualbox:
> https://www.virtualbox.org/wiki/Download_Old_Builds_4_0
> (Last version of 4.0 series, 4.0.12, was released in Jul 15. For
> virtualbox, usually when a new major version released, e.g. 4.1, the
> old version series will not be updated.)
> 
> Will it be packed as a core update for Mageia 1? We don't have any
> virtualbox in Mageia 1's updates or backports.

I think there were some in updates_testing (pretty sure I pushed it
there but then forgot about it :s)

If there are good reasons to update then I personally don't have a
problem with it.

Col



-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

Re: [Mageia-dev] ANN: glibc-2.14.1 landing...

[JA Magallon]

On Tue, 18 Oct 2011 19:48:32 +0300
Thomas Backlund  wrote:

> Hi,
> 
> I have updated glibc & locales-* from 2.12.1 to 2.14.1 and I'll push
> them to core/updates_testing so people can test it out but have a
> fallback if needed in case of regressions
> 
> They seem to work ok here, but you never know...
> 
> So for those brave of you, please test them out...
> 

No apparent problem so far in several boxes (netbook, 3 desktops...).

> If no (big/real) issues are found with them I'll push them to 
> core/release by the end of this week.
> 

Re: [Mageia-dev] [changelog] [RPM] cauldron core/release ldetect-lst-0.1.292-2.1.mga2

[Thomas Backlund]

Zézinho skrev 19.10.2011 10:04:

Em 18-10-2011 23:28, Thomas Backlund escreveu:


There are several ids that are listed as supported by wl,
but their b43 counterpart states either "untested", "partially in
2.6.39+" and so on...

And since Mageia 1 ships 2.6.38, it means switching driver in drakx
can/will break something that worked in the release tests.


So it is OK : this change in drakx is not a switch from wl to b43.
The change is using b43-openfwwf when b43 driver is loaded, instead of
asking for an external firmware file.



Ah, OK, then I dont have any problem with it.
Thanks for clarifying it.

--
Thomas

Re: [Mageia-dev] [changelog] [RPM] cauldron core/release ldetect-lst-0.1.292-2.1.mga2

[Zézinho]

Em 18-10-2011 23:28, Thomas Backlund escreveu:


There are several ids that are listed as supported by wl,
but their b43 counterpart states either "untested", "partially in 
2.6.39+" and so on...


And since Mageia 1 ships 2.6.38, it means switching driver in drakx 
can/will break something that worked in the release tests.



So it is OK : this change in drakx is not a switch from wl to b43.
The change is using b43-openfwwf when b43 driver is loaded, instead of 
asking for an external firmware file.