Re: [Mageia-dev] painful discussion n°1: debloating
On Tue, Apr 10, 2012 at 05:14:53PM +0800, You-Cheng Hsieh wrote: > I suppose you agreed to move the suggests if it does affect minimal install: > https://www.mageia.org/pipermail/mageia-dev/2012-March/013365.html Not really. If you select a minimal install no suggests should be installed. However, seems that in almost every install seahorse might be installed (tv saying that we go from something like glib -> gio -> .. -> seahorse). Almost every install might have glib going to seahorse. That bit is the concern. I don't care about minimal; in a minimal, it just should not install suggests and I really don't care if that currently works in the installer or not. Currently almost every install might end up having gnome-keyring. Even if often it isn't used. That's a concern. Around GNOME 3.6 gnome-keyring will be replaced with libsecret. So although gnomekeyring->seahorse currently makes sense, in future we'd need to do things differently anyway. So, yeah, move the suggests and remove totem-mozilla from CAT_KDE. But not because of the minimal install. This might result in some users not having seahorse anymore though. -- Regards, Olav
[Mageia-dev] Help: Please find me initscripts without LSB headers!
Hi, I need to find all initscripts we ship that do not contain LSB header information! Ideally you should find them and fix the scripts, but if in doubt ask me! This is the result of debug work on: https://bugs.mageia.org/show_bug.cgi?id=5262#c19 Where overzealous use of priorities from non-LSB compatible scripts has resulted in ordering cycle deadlocks. We need to nuke these problems. This can be fixed by providing proper LSB headers in initscripts (likely easier) or native systemd units (better if you can do it). Here is a document that tracks all packages we provide which provide sysvinit scripts. Please can people go through the list and fill in the blanks. I've started it off. The only cells to free edit are either your name, or notes about things. The others have data validation - i.e. a drop down. I've provided links to subversion which in many cases is sufficient to verify the initscripts as they are often just included in the SOURCES folder, not packaged upstream. For some however you will need to check a bit. https://docs.google.com/spreadsheet/ccc?key=0AjumKqYMRG9WdHdkRWM3dUhEYms5T1BkR05KRnp6V1E Many thanks!! Go! -- 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] Help: Please find me initscripts without LSB headers!
On Wed, Apr 11, 2012 at 11:07, Colin Guthrie wrote: > Hi, > > I need to find all initscripts we ship that do not contain LSB header > information! > > Ideally you should find them and fix the scripts, but if in doubt ask me! > > This is the result of debug work on: > https://bugs.mageia.org/show_bug.cgi?id=5262#c19 > > Where overzealous use of priorities from non-LSB compatible scripts has > resulted in ordering cycle deadlocks. We need to nuke these problems. > > This can be fixed by providing proper LSB headers in initscripts (likely > easier) or native systemd units (better if you can do it). > > Here is a document that tracks all packages we provide which provide > sysvinit scripts. Please can people go through the list and fill in the > blanks. I've started it off. The only cells to free edit are either your > name, or notes about things. The others have data validation - i.e. a > drop down. I've provided links to subversion which in many cases is > sufficient to verify the initscripts as they are often just included in > the SOURCES folder, not packaged upstream. For some however you will > need to check a bit. Can't this be automated? Get the list of binary rpms containing initscripts with urpmf (I guess that's what you did), extract the initiscripts from a local mirror, grep to see if they have LSB Headers?
Re: [Mageia-dev] Help: Please find me initscripts without LSB headers!
'Twas brillig, and Pascal Terjan at 11/04/12 11:24 did gyre and gimble: > On Wed, Apr 11, 2012 at 11:07, Colin Guthrie wrote: >> Hi, >> >> I need to find all initscripts we ship that do not contain LSB header >> information! >> >> Ideally you should find them and fix the scripts, but if in doubt ask me! >> >> This is the result of debug work on: >> https://bugs.mageia.org/show_bug.cgi?id=5262#c19 >> >> Where overzealous use of priorities from non-LSB compatible scripts has >> resulted in ordering cycle deadlocks. We need to nuke these problems. >> >> This can be fixed by providing proper LSB headers in initscripts (likely >> easier) or native systemd units (better if you can do it). >> >> Here is a document that tracks all packages we provide which provide >> sysvinit scripts. Please can people go through the list and fill in the >> blanks. I've started it off. The only cells to free edit are either your >> name, or notes about things. The others have data validation - i.e. a >> drop down. I've provided links to subversion which in many cases is >> sufficient to verify the initscripts as they are often just included in >> the SOURCES folder, not packaged upstream. For some however you will >> need to check a bit. > > Can't this be automated? > Get the list of binary rpms containing initscripts with urpmf (I guess > that's what you did), extract the initiscripts from a local mirror, > grep to see if they have LSB Headers? That part can be automated I guess. I don't have a handy mirror tho'. Also if the script has native systemd it might be a false negative, but I guess they would be suitably small to be checked by hand. That said, the list isn't super long :) 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] Help: Please find me initscripts without LSB headers!
On Wed, Apr 11, 2012 at 11:30, Colin Guthrie wrote: > 'Twas brillig, and Pascal Terjan at 11/04/12 11:24 did gyre and gimble: >> On Wed, Apr 11, 2012 at 11:07, Colin Guthrie wrote: >>> Hi, >>> >>> I need to find all initscripts we ship that do not contain LSB header >>> information! >>> >>> Ideally you should find them and fix the scripts, but if in doubt ask me! >>> >>> This is the result of debug work on: >>> https://bugs.mageia.org/show_bug.cgi?id=5262#c19 >>> >>> Where overzealous use of priorities from non-LSB compatible scripts has >>> resulted in ordering cycle deadlocks. We need to nuke these problems. >>> >>> This can be fixed by providing proper LSB headers in initscripts (likely >>> easier) or native systemd units (better if you can do it). >>> >>> Here is a document that tracks all packages we provide which provide >>> sysvinit scripts. Please can people go through the list and fill in the >>> blanks. I've started it off. The only cells to free edit are either your >>> name, or notes about things. The others have data validation - i.e. a >>> drop down. I've provided links to subversion which in many cases is >>> sufficient to verify the initscripts as they are often just included in >>> the SOURCES folder, not packaged upstream. For some however you will >>> need to check a bit. >> >> Can't this be automated? >> Get the list of binary rpms containing initscripts with urpmf (I guess >> that's what you did), extract the initiscripts from a local mirror, >> grep to see if they have LSB Headers? > > That part can be automated I guess. I don't have a handy mirror tho'. > Also if the script has native systemd it might be a false negative, but > I guess they would be suitably small to be checked by hand. > > That said, the list isn't super long :) Just did a quick try, packages with initscripts not containing LSB headers. 92 initscripts in 67 packages, but there a few false positives like initscripts containing /etc/init.d/functions afbackup arpwatch bip bootparamd bpalogin canna clusterscripts-client cpqarrayd dhcp-forwarder dnotify dropbear ebtables fcron firestarter freepops ganglia-script gkrellm-server gnokii-smsd haveged hostapd hylafax-server ices initscripts ip-sentinel ipvsadm ircd-hybrid isdn4k-utils-eurofile jetty keepalived kolab lcdproc lighttpd maradns mongodb-server mrepo nginx nvidia-cuda-toolkit omniorb perl-kolab prboom-server prelude-lml pure-ftpd quagga quake2-ctf quake2-server rear redis routed rp-pppoe rrdcollect siproxd spread suricata torque torque-client udftools unfs3 unimrcp usermode-consoleonly ushare util-vserver-legacy vtun watchdog xymon xymon-client yum zoneminder
Re: [Mageia-dev] Problems with flash 11.2
Le mercredi 11 avril 2012 07:37:48, Dimitrios Glentadakis a écrit : > > > And to confirm, you fixed it by setting it to 0 ? > > > > I disabled the hw accel. by right click and i deleted the > /etc/adobe/mms.cfg See http://comments.gmane.org/gmane.linux.mageia.devel/13644 I have no problem with Mageia 1 i586 and ati radeon 9000. The problem seems occur only on x86_64. > Ps: I use only konqueror It is the same problem with Firefox -- Pierre Jarillon - http://pjarillon.free.fr/ Vice-président de l'ABUL : http://abul.org Microsoft est à l'informatique ce que McDonald est à la gastronomie
Re: [Mageia-dev] Problems with flash 11.2
Στις 11 Απριλίου 2012 7:37 π.μ., ο χρήστης Dimitrios Glentadakis < dgl...@gmail.com> έγραψε: > > Le 11 avr. 2012 07:20, "Dimitrios Glentadakis" a > écrit : > > > > > Στις 11/04/2012 02:37:50 Anssi Hannula γράψατε: > > > 31.03.2012 09:43, Dimitrios Glentadakis kirjoitti: > > > > Στις 31/03/2012 08:38:19 γράψατε: > > > >> Στις 31/03/2012 02:38:24 JA Magallón γράψατε: > > > >>> And, btw, to get hw video decoding I had to write a file in > /etc/adobe/mms.cfg > > > >>> with > > > >>> > > > >>> EnableLinuxHWVideoDecode=1 > > > >> > > > >> Thanks, this solved the problem for me > > > >> > > > >> > > > >> > > > > > > > > i had to reverse to disable hw acceleration because the embedded > youtube videos in konqueror are invisible (in youtube it is ok) > > > > > > > > > > So this issue happens only when EnableLinuxHWVideoDecode=1 ? > > > > > > Or does it happen when you remove the line completely as well? > > > > > > > > > > > > > Initialy i did nt have any file /etc/adobe/mms.cfg > > > > - Without the file mms.cfg, if i have hw accel. enabled (by right > click), i have the blue peoples in youtube but not in embedded videos > > - Without the file mms.cfg, if i disabled hw accel (by right click), i > dont have the blue peoples in youtube, and no problem in embedded videos > > - With the mms.cfg and EnableLinuxHWVideoDecode=1, and hw accel. enabled > (by right click), i dont have blue peoples in youtube but embedded videos > dont shown and sometimes with crash of the nssplugginviewer > > - With the mms.cfg and EnableLinuxHWVideoDecode=1, and hw accel. > disabled (by right click), i dont have blue peoples in youtube and no > problem in embedded videos > > - With the mms.cfg and EnableLinuxHWVideoDecode=0 and hw accel. enabled > (by right click), i have blue peoples in youtube and no problem in embedded > videos > > - With the mms.cfg and EnableLinuxHWVideoDecode=0 and hw accel. > disabled (by right click), i dont have the blue peoples in youtube, and no > problem in embedded videos > > > > > > > And to confirm, you fixed it by setting it to 0 ? > > > > I disabled the hw accel. by right click and i deleted the > /etc/adobe/mms.cfg > > > > Ps: I use only konqueror > Ps: i have Mageia 1, 64bit, nvidia 290.10 driver -- Dimitrios Glentadakis
Re: [Mageia-dev] freeze push request: scite
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/04/2012 20:59, Matteo wrote: > On 09/04/2012 19:53, Thomas Backlund wrote: >>> Pushed. >> Or not... > >> http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20120409174534.tmb.valstar.31214/log/scite-3.0.4-1.mga2/build.0.20120409174535.log > >> > -- Thomas I don't receive this error locally. I made a patch to the > desktop file and then I made validation using > desktop-file-validate. Can you push it again, please? Thank You. ping? - -- Matteo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPhYclAAoJED3LowjDDWbNlDwIAKRnc7TyxLcWwAV4SU2lG0F1 uSFNcq8kfgsrSR7qpkzD0nO/ixnLhZ41Lu0EulQXXiOIz8wIfzL8gONxJATPfNoX J7bqCDrJBIsrRjrQQ+nPEidqmAMpvJeVqTnGAZvQ7Sr4+70xN7CuLHCJTOfoECPz HakjgKSklI9WAGm+Yyr3zjisPs8DQe6fBXcA2HH1RR4/vmxlmLkuRwjjQuXzykBS hGJ2cNfZCKrQTS9kRWdpWj4mZ3EX8THiyx6juVYPRz2DY/zyYDdNP4c9n2D4bCu3 hHtFnnI+RTUG5RdEniKDQrX0bwmkOH/ps3peCkkJacWu1eNg3CVWUqj/5Xkk2G8= =C+N8 -END PGP SIGNATURE-
[Mageia-dev] NVIDIA CVE, mga1: update driver, or patch and break CUDA debugger?
Hi all!
We'll have to apply a patch for CVE-2012-0946 (access to arbitrary
system memory by any user) for cauldron and mga1.
However, the security fix (patch to the nvidia kernel interface layer)
will break CUDA debugger using libcuda older than 295.40.
While I can upgrade cauldron driver (which contains libcuda) to 295.40,
mga1 will be left with two options:
a) Apply patch, informing users that CUDA debugger will cease to
function unless they upgrade their NVIDIA driver. However, as we have
no backports, the remaining (non-system-breaking) option to upgrade
their driver is to use http://onse.fi/nvidia-mgabuild/ , but I don't
think it is very nice to link to non-official page from an advisory,
right?
b) Upgrade our MGA1 driver from 275.09.07 to 295.40 ("long-lived branch
release") as well. We have
previously shipped an update from 270.41.19 to 275.09.07 for MGA1
(that was due to an important stability bugfix). I'm not aware of
any blockers for this.
I'd probably prefer (a), but since we don't have any official way for
users to update their driver, that makes me lean to (b) instead.
WDYT?
A relatively quick decision needs to be made...
--
Anssi Hannula
Re: [Mageia-dev] nvidia
07.04.2012 14:17, Thomas Backlund kirjoitti: > 07.04.2012 03:41, Pascal Terjan skrev: >> Hi, >> >> regarding http://check.mageia.org/cauldron/tmb/dependencies.html do you >> know if nvidia173/kmod-nvidia173 and nvidia-96xx/kmod-nvidia96xx should >> be obsoleted by something (nouveau?)? >> > > Well, > > kmod-nvidia96xx/173 and the matching nvidia*kernel*latest can simply be > nuked from the repos as they are Cauldron only packages > > So it leaves theese: > dkms-nvidia96xx > nvidia96xx-devel > nvidia96xx-doc-html > x11-driver-video-nvidia96xx > > dkms-nvidia173 > nvidia173-cuda > nvidia173-devel > nvidia173-doc-html > x11-driver-video-nvidia173 > > I guess the dkms-nvidia96xx/173 packages should be obsoleted by kernel, > and the x11-driver-video-nvidia96xx/173 should be obsoleted by > x11-driver-video-nouveau. Either that or add conflicts to X11 server, I guess. > Hmmm, do we need triggers to handle gl.conf for nvidia like we need for > fglrx ? > > Anssi, wdyt ? harddrake_service should already change the driver if ldetect-lst indicates so. >> I don't know anything about nvidia but internet says 173 and 96xx are >> not compatible with x11-server 1.11 >> Compatibility with 1.10 was added in the latest version, in August last >> year, 6 months after 1.10 was released, and a week before 1.11 was >> released. It has now been more than 6 months since 1.11 was released, >> 1.12 was released last month, so should we still expect 1.11 (and recent >> kernels) support to happen? > > It does not really seem like nVidia will support them, but I can be wrong... > > Anssi ? I don't have any additional information, but I wouldn't rule new releases out, there have been long delays previously as well... -- Anssi Hannula
Re: [Mageia-dev] NVIDIA CVE, mga1: update driver, or patch and break CUDA debugger?
On Wed, Apr 11, 2012 at 15:27, Anssi Hannula wrote:
> Hi all!
>
> We'll have to apply a patch for CVE-2012-0946 (access to arbitrary
> system memory by any user) for cauldron and mga1.
>
> However, the security fix (patch to the nvidia kernel interface layer)
> will break CUDA debugger using libcuda older than 295.40.
>
> While I can upgrade cauldron driver (which contains libcuda) to 295.40,
> mga1 will be left with two options:
> a) Apply patch, informing users that CUDA debugger will cease to
> function unless they upgrade their NVIDIA driver. However, as we have
> no backports, the remaining (non-system-breaking) option to upgrade
> their driver is to use http://onse.fi/nvidia-mgabuild/ , but I don't
> think it is very nice to link to non-official page from an advisory,
> right?
>
> b) Upgrade our MGA1 driver from 275.09.07 to 295.40 ("long-lived branch
> release") as well. We have
> previously shipped an update from 270.41.19 to 275.09.07 for MGA1
> (that was due to an important stability bugfix). I'm not aware of
> any blockers for this.
I would vote for b provided more research about known regressions from
275 to 295 (like dropping support for some devices)
Re: [Mageia-dev] NVIDIA CVE, mga1: update driver, or patch and break CUDA debugger?
11.04.2012 17:47, Pascal Terjan kirjoitti:
> On Wed, Apr 11, 2012 at 15:27, Anssi Hannula wrote:
>> Hi all!
>>
>> We'll have to apply a patch for CVE-2012-0946 (access to arbitrary
>> system memory by any user) for cauldron and mga1.
>>
>> However, the security fix (patch to the nvidia kernel interface layer)
>> will break CUDA debugger using libcuda older than 295.40.
>>
>> While I can upgrade cauldron driver (which contains libcuda) to 295.40,
>> mga1 will be left with two options:
>> a) Apply patch, informing users that CUDA debugger will cease to
>> function unless they upgrade their NVIDIA driver. However, as we have
>> no backports, the remaining (non-system-breaking) option to upgrade
>> their driver is to use http://onse.fi/nvidia-mgabuild/ , but I don't
>> think it is very nice to link to non-official page from an advisory,
>> right?
>>
>> b) Upgrade our MGA1 driver from 275.09.07 to 295.40 ("long-lived branch
>> release") as well. We have
>> previously shipped an update from 270.41.19 to 275.09.07 for MGA1
>> (that was due to an important stability bugfix). I'm not aware of
>> any blockers for this.
>
> I would vote for b provided more research about known regressions from
> 275 to 295 (like dropping support for some devices)
>
No device have been dropped support for there.
And if there were any big regressions, one'd think we would've heard of
them in cauldron.
Hmm.. Actually, there is at least one regression: When in XBMC one has
enabled "sync playback to display", XBMC will try to spawn a
nvidia-settings instance to detect the refresh rate - however with
295.20+ the forked process will simply block on a mutex. This is handled
gracefully and XBMC fallbacks to using RANDR, however that only works
for integer refresh rates (and when twinview isn't enabled; we default
to disabled), otherwise playback won't be synced properly (AFAIU)
Argh, checking more, the older XBMC 10.1 we have on mga1 apparently
won't handle this gracefully, but will just get stuck. I guess we could
patch it, but the feature wouldn't still work properly for non-integer
rates...
This is reported as
http://www.nvnews.net/vbulletin/showthread.php?t=177596
--
Anssi Hannula
[Mageia-dev] Tonight's meeting
Hi there, As usual at 19h UTC - vote result for packagers representatives - review of planning for mageia 2 + release_blocker bugs - review of mentoring Cheers -- Anne http://www.mageia.org
[Mageia-dev] freeze push f2c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, can someone push f2c? It is the latest stable release and it fixes these bugs (from f2c changelog): - - format.c: make sizeof(buf) depend on MAXNAMELEN to fix a bug with long names. Update mswin/f2c.exe.gz accordingly. - - fc: have "-m ..." modify CC rather than CFLAGS (to affect linking). - - README, README in libf2c.zip: update some netlib pointers. Regards - -- Matteo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPhaY0AAoJED3LowjDDWbNjAkIAKuwXPwdxLE0upXRAusV4NRq 69Q226YQOFWC5WxpeZxe0WEQpKinHt+z6dBeTv8OWjAjoGagzpkWopzmxg93XVDf +7bLnzW6qV6CjdYWZt+Efqr9QZHvVhxct7/4O9N2fjJepW4tdyFrnv1HNWfml4GL GaIzmCYkCLkJ54QORUsdAfWoBuWsZGLxzqGTX7CgNCYZL9LAK+micXBHXwIUiIv1 4mNnNvdmxrMUYKTIpq1Rqau+MFXwkGdPIBnd9ZBYqAzd1tqAL+Za5mZ2iwVQtt88 OYFPmCn0wkXoasis78E6iv1Q7uCHvLxTXl99/aWpq1fo7bfgksoZ/TBQfFylyPo= =1Y66 -END PGP SIGNATURE-
Re: [Mageia-dev] Tonight's meeting
'Twas brillig, and Anne nicolas at 11/04/12 16:31 did gyre and gimble: > Hi there, > > As usual at 19h UTC > > - vote result for packagers representatives > - review of planning for mageia 2 + release_blocker bugs > - review of mentoring As with most Wednesdays, I sadly won't be able to make it tonight. I've been hard at work now tho'. Biggest remaining problem for me is now the LSB headers in old initscripts which I've mailed the list about. Once this is solved it should mostly prevent any ordering deadlocks that have prevented X from starting. There are also a few medium-ish issues that are all currently in hand and then the only real problem is the drakxservices systemd stuff. Assuming no-one else does, I'll look at the drakx code fairly soon (i.e. between beta and rc) Cheers 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] [Mageia-discuss] Handbooks - the lot
Στις 11/04/2012 16:05:23 γράψατε: > * I am not at home, actually how much space they take ? For what kind of > size we are talking about ? The /usr/share/doc/HTML/en folder has a size of 43.5 MiB, which even now if it takes a lot of place anyone can delete this folder from his system. -- Dimitrios Glentadakis
Re: [Mageia-dev] [Mageia-discuss] Handbooks - the lot
2012/4/11 Dimitrios Glentadakis : > Στις 11/04/2012 16:05:23 γράψατε: >> * I am not at home, actually how much space they take ? For what kind of >> size we are talking about ? > > The /usr/share/doc/HTML/en folder has a size of 43.5 MiB, which even now if > it takes a lot of place anyone can delete this folder from his system. We are not talking about deleting data from the harddisk. We are talking about installing and uninstalling, not just deleting. The issue is to avoid the installation (if not wanted) and consequently avoid updates. I expected the discussion about the technical options to be quite long and not at all trivial, I did not expect such a discussion about the "why". There are valid use cases which answer the "why" quite clear and simple. -- wobo
Re: [Mageia-dev] Help: Please find me initscripts without LSB headers!
On Wed, Apr 11, 2012 at 11:07:00AM +0100, Colin wrote in <4f8557c4.4010...@colin.guthr.ie>: Hi, I need to find all initscripts we ship that do not contain LSB header information! Ideally you should find them and fix the scripts, but if in doubt ask me! This is the result of debug work on: https://bugs.mageia.org/show_bug.cgi?id=5262#c19 Where overzealous use of priorities from non-LSB compatible scripts has resulted in ordering cycle deadlocks. We need to nuke these problems. This can be fixed by providing proper LSB headers in initscripts (likely easier) or native systemd units (better if you can do it). Hi Colin, Noticing at least one of "my" packages on the list, I am left with a few questions: 1) What happens if it doesn't get fixed? 2) Do you have a link where I / we can read up on the proper LSB headers? 3) Do you have an example fix we can refer to? Thanks, Remmy pgpbTeo7dS3os.pgp Description: PGP signature
Re: [Mageia-dev] Help: Please find me initscripts without LSB headers!
On 11/04/12 18:50, Remco Rijnders wrote: > On Wed, Apr 11, 2012 at 11:07:00AM +0100, Colin wrote in > <4f8557c4.4010...@colin.guthr.ie>: >> Hi, >> >> I need to find all initscripts we ship that do not contain LSB header >> information! >> >> Ideally you should find them and fix the scripts, but if in doubt ask me! >> >> This is the result of debug work on: >> https://bugs.mageia.org/show_bug.cgi?id=5262#c19 >> >> Where overzealous use of priorities from non-LSB compatible scripts has >> resulted in ordering cycle deadlocks. We need to nuke these problems. >> >> This can be fixed by providing proper LSB headers in initscripts (likely >> easier) or native systemd units (better if you can do it). > > Hi Colin, > > Noticing at least one of "my" packages on the list, I am left with a few > questions: > > 1) What happens if it doesn't get fixed? > 2) Do you have a link where I / we can read up on the proper LSB headers? > 3) Do you have an example fix we can refer to? > > Thanks, > > Remmy Have a look at: http://svnweb.mageia.org/packages/cauldron/siproxd/current/SOURCES/siproxd.init?r1=230226&r2=230225&pathrev=230226 Cheers, -- Malo
[Mageia-dev] minor systemd-related issues
There are a few things I noticed from a new upgrade test I just did with a server VM. In systemctl --all I have two things failed for unknown reasons: - dev-sda2.swap, even though the swap partition looks to be mounted - fedora-loadmodules.service, even though the modules look to be loaded systemctl status doesn't really give any information and I don't see a way to debug this. During the upgrade (done using the installer), I told the cups and named services not to run, but they are enabled. httpd is running, but it is using the LSB init script instead of systemd units. I believe Colin's intention was to have apache-mpm-prefork install a symlink to httpd-prefork.service called httpd.service, but this symlink does not exist. Other than that, things look pretty good.
Re: [Mageia-dev] [Mageia-discuss] Handbooks - the lot
Στις 11/04/2012 19:11:55 Wolfgang Bornath γράψατε: > 2012/4/11 Dimitrios Glentadakis : > > Στις 11/04/2012 16:05:23 γράψατε: > >> * I am not at home, actually how much space they take ? For what kind of > >> size we are talking about ? > > > > The /usr/share/doc/HTML/en folder has a size of 43.5 MiB, which even now if > > it takes a lot of place anyone can delete this folder from his system. > > We are not talking about deleting data from the harddisk. We are > talking about installing and uninstalling, not just deleting. The > issue is to avoid the installation (if not wanted) and consequently > avoid updates. > > I expected the discussion about the technical options to be quite long > and not at all trivial, I did not expect such a discussion about the > "why". There are valid use cases which answer the "why" quite clear > and simple. > > I dont understand very well. - We dont have a lot of space so we want to be able to uninstall some software and it has to be the documentation as the most unwanted ? - We want for a question of free choice to be able to choose if we want the documentation to be installed or not ? but this has to be the same for all kde software and dependencies, why is the documentation the problem. Dont forget that is a part of KDE and it has a global shortcut F1 to access it. If there is a case that it will be not available until the user install it in a additionally way, it breaks the upstream software. It is truth that i spend a lot of time to translate documentation, and i do it with love, so it is normal that i have a preference in their existence in the system; certainly i cannot use this argument here. -- Dimitrios Glentadakis
Re: [Mageia-dev] [changelog] cauldron core/release telepathy-gabble-0.16.0-1.mga2
11.04.2012 00:43, ovitters skrev: > Name: telepathy-gabble Relocations: (not relocatable) > Version : 0.16.0Vendor: Mageia.Org > Release : 1.mga2Build Date: Tue Apr 10 23:42:02 > 2012 This one now requires devel libs :( [tmb@tmb-laptop ~]$ rpm -q --requires telepathy-gabble |grep devel devel(libcrypto(64bit)) devel(libgio-2.0(64bit)) devel(libglib-2.0(64bit)) devel(libgobject-2.0(64bit)) devel(libgthread-2.0(64bit)) devel(libsqlite3(64bit)) devel(libssl(64bit)) devel(libtelepathy-glib(64bit)) devel(libwocky-telepathy-gabble-0.16.0(64bit)) devel(libxml2(64bit)) and messes with livecd builds... please fix fast. -- Thomas
Re: [Mageia-dev] Tonight's meeting
2012/4/11 Anne nicolas : > Hi there, > > As usual at 19h UTC > > - vote result for packagers representatives > - review of planning for mageia 2 + release_blocker bugs > - review of mentoring And here are the logs http://meetbot.mageia.org/mageia-dev/2012/mageia-dev.2012-04-11-19.17.html Cheers -- Anne http://www.mageia.org
[Mageia-dev] Result of packagers representatives vote
Hi Here are the results https://epoll.mageia.org/vote/5RcQj4Ij Welcome in hell guys :) Cheers -- Anne http://www.mageia.org
Re: [Mageia-dev] Freeze push mariadb 5.5 GA release
Op woensdag 11 april 2012 01:56:04 schreef Maarten Vanraes: > Please push mariadb: > > This updates to the 5.5 GA release (it's not announced yet, but they are > waiting for it to hit all the mirrors) ping
Re: [Mageia-dev] freeze push request: scite
2012/3/25 Matteo : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello, > can somebody push scite 3.0.4? > It fixes a lot of bugs (since our last version was 2.29, > http://www.scintilla.org/ScintillaHistory.html). > Now it works fine even with gtk3 (version 3.0.3 fixed a gtk3 related bug > about printing). > This package is owned by anaselli cause it was built while he was > mentoring me. > Regards submitted > - -- > Matteo > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJPbv7SAAoJED3LowjDDWbNknsH/341vZMxTSkpyYqrP20J6rca > QGc3LFKAfQpFupDq7LjGrA1ZlzqGWSImm+rd73kQ/op3cvjtch+aly1db8y9tcCE > QDfbBdRc+PSfA39XPhrz6/EPuY76Kmja1XWA3YPmm0J1jy//nLN2Icu3SG3T5HoP > J8G8FBECisO06AQSup8bAmCqZN2rjRZKmIFk1Olu5ZOp7HC2ENCZfKeDPuXXm/GS > DuvneXc1mOrRW666x2m6+WEkEGiUJ3JSQAWYlEorxA887EuR2x8nXNtww3dF7uCK > XYF30Ei4DOn2DqzxKReCOnhKbybln6Y9xmuyZXLn5GFzAQYjbHeCU8/b3orN+SI= > =pxA4 > -END PGP SIGNATURE- -- Anne http://www.mageia.org
Re: [Mageia-dev] Freeze push: gwibber 3.4.0
2012/4/11 Funda Wang : > Hello, > > Could somebody pushing gwibber 3.4.0 into cauldron? We currently have > 3.3.2 unstable in cauldron, while aim at 3.4.0 stable for mga2. And, > 3.3.2 is co-using gtk3 and gtk2, which is a mess for users, 3.4.0 is a > plain gtk3 applications. > > Thanks. submitted -- Anne http://www.mageia.org
Re: [Mageia-dev] Freeze push request monodevelop 2.8.8.4
2012/4/10 Angelo Naselli : > Please let monodevelop pass first > and then > monodevelop-debugger-gdb > monodevelop-python > monodevelop-java > monodevelop-database > > They are the last stable release, according to > http://monodevelop.com/Download/Release_Notes/Release_Notes_for_MonoDevelop_2.8.8 > they improved the the debugging engine, and fix some bugs. > > I've tested here for a while without issues. > > Thanks in advance. > -- > Angelo in progress -- Anne http://www.mageia.org
[Mageia-dev] freeze push - drakx-installer-help 2.5
Hello! - new tarball 2.5 * update README and COPYING (new help is not based on the Mandriva one) - update license (it's now CC-BY-SA) - small edit of the summary
Re: [Mageia-dev] freeze push - drakx-installer-help 2.5
Le 11/04/2012 23:02, Kamil Rytarowski a écrit : > Hello! > > - new tarball 2.5 > * update README and COPYING (new help is not based on the Mandriva one) > - update license (it's now CC-BY-SA) > - small edit of the summary submitted -- http://mageia.org
[Mageia-dev] Mageia 2 security updates: help needed with Java and Tomcat
The only remaining known security issues with Mageia 2 packages concern Java and Tomcat, and some expertise is needed to help close these. The vulnerable Java package is java-1.7.0-openjdk. It is vulnerable to a large set of CVEs which have also affected java 1.6.0, and I believe are the same ones behind the recent compromise of Mac OS X machines as well as the Windows version of Firefox automatically disabling vulnerable Java plugins. We have just issued an update for this in Mageia 1 today, and java-1.6.0-openjdk in Cauldron was fixed on Sunday. Since our Java plugin uses 1.6.0 instead of 1.7.0, our exposure to these vulnerabilities is reduced, but they are still there. At the very least the "IcedTea" in the package needs updated to either 2.0.1 or 2.1. The "OpenJDK" in the package may need to be updated as well. D Morgan has done a really nice job maintaining this package, but has been really busy lately, so if anyone else has the ability to assist with it, it would be good. Bugzilla reference: https://bugs.mageia.org/show_bug.cgi?id=5300 Our tomcat5 and tomcat6 packages are unmaintained and have not been updated since before Mageia 1, and contain several vulnerabilities (both in Mageia 1 and Cauldron) that have been fixed by other distros. There are so many CVEs I can't say off the top of my head how many, and I'm not even sure I found them all. Hopefully just updating these packages to the newest versions would be enough to close them all. Bugzilla references: tomcat5 - https://bugs.mageia.org/show_bug.cgi?id=3099 tomcat6 - https://bugs.mageia.org/show_bug.cgi?id=5261 Finally, there are a number of security issues affecting Firefox in Mageia 1, and some help may be needed closing this one. All but one of the bugs blocking this update have recently been fixed. There are apparently some issues with Eclipse that still need to be solved, as well as a couple other packages that may still need to be rebuilt. An update candidate for Firefox itself already exists in updates_testing. Bugzilla reference: https://bugs.mageia.org/show_bug.cgi?id=4405
Re: [Mageia-dev] Freeze push request monodevelop 2.8.8.4
In data mercoledì 11 aprile 2012 22:29:32, Anne nicolas ha scritto: > in progress Thanks Anne they are uploaded now :) -- Angelo signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] [changelog] cauldron core/release telepathy-gabble-0.16.0-1.mga2
On Wed, Apr 11, 2012 at 09:48:26PM +0300, Thomas Backlund wrote: > [tmb@tmb-laptop ~]$ rpm -q --requires telepathy-gabble |grep devel > devel(libcrypto(64bit)) > devel(libgio-2.0(64bit)) > devel(libglib-2.0(64bit)) > devel(libgobject-2.0(64bit)) > devel(libgthread-2.0(64bit)) > devel(libsqlite3(64bit)) > devel(libssl(64bit)) > devel(libtelepathy-glib(64bit)) > devel(libwocky-telepathy-gabble-0.16.0(64bit)) > devel(libxml2(64bit)) > > and messes with livecd builds... > > please fix fast. I make it ignore the required from the .so files. Those were adding the devel requirements. This is correct fix right? Strangely, should've happened with previous release. -- Regards, Olav
Re: [Mageia-dev] Help: Please find me initscripts without LSB headers!
Le 11/04/2012 19:50, Remco Rijnders a écrit : On Wed, Apr 11, 2012 at 11:07:00AM +0100, Colin wrote in <4f8557c4.4010...@colin.guthr.ie>: Hi, I need to find all initscripts we ship that do not contain LSB header information! Ideally you should find them and fix the scripts, but if in doubt ask me! This is the result of debug work on: https://bugs.mageia.org/show_bug.cgi?id=5262#c19 Where overzealous use of priorities from non-LSB compatible scripts has resulted in ordering cycle deadlocks. We need to nuke these problems. This can be fixed by providing proper LSB headers in initscripts (likely easier) or native systemd units (better if you can do it). Hi Colin, Noticing at least one of "my" packages on the list, I am left with a few questions: 1) What happens if it doesn't get fixed? 2) Do you have a link where I / we can read up on the proper LSB headers? https://wiki.mageia.org/en/Initscripts_policy 3) Do you have an example fix we can refer to? Before rushing into LSB compliance, first check in fedora git (http://pkgs.fedoraproject.org/gitweb/?p=YOURPACKAGE.git) if they don't have a native systemd service. -- Why are cigarettes sold in gas stations when smoking is prohibited there? -- Why Why Why n°21
[Mageia-dev] Freeze Push: drakx-net
Just a single patch: - ensure /etc/hostname has a newline as per upstream specs (#4672) 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] minor systemd-related issues
'Twas brillig, and David Walser at 11/04/12 19:09 did gyre and gimble: > There are a few things I noticed from a new upgrade test I just did > with a server VM. > > In systemctl --all I have two things failed for unknown reasons: - > dev-sda2.swap, even though the swap partition looks to be mounted I've noticed this too with a couple of other users systems. Not quite sure what causes it - likely udev. > - fedora-loadmodules.service, even though the modules look to be > loaded Yeah this does happen from time to time. It's typically /etc/rc.modules that actually fails. Again it really depends on the contents of modprobe.preload.d folder. > systemctl status doesn't really give any information and I don't see > a way to debug this. No neither would likely give you any hints in this case. > During the upgrade (done using the installer), I told the cups and > named services not to run, but they are enabled. This is likely due to that simply not working yet (drakxservers is not systemd aware yet). There are bugs open for this. > httpd is running, but it is using the LSB init script instead of > systemd units. I believe Colin's intention was to have > apache-mpm-prefork install a symlink to httpd-prefork.service called > httpd.service, but this symlink does not exist. Are you sure? The %post script should certainly have done that [colin@jimmy ~]$ rpm -q --scripts apache-mpm-prefork postinstall scriptlet (using /bin/sh): ln -s /lib/systemd/system/httpd-prefork.service /etc/systemd/system/httpd.service 2>/dev/null || : I guess the only possible explanation I can think of here is that somehow, apache-mpm-prefork was upgraded before systemd was installed! Perhaps we need to make sure system is installed early in the process? 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] Help: Please find me initscripts without LSB headers!
Hiya, Others have answered your other points, so that just leaves me with 'Twas brillig, and Remco Rijnders at 11/04/12 18:50 did gyre and gimble: > Noticing at least one of "my" packages on the list, I am left with a few > questions: > > 1) What happens if it doesn't get fixed? Bad things! Kittens will cry and puppies noses will go dry. Basically, it complicates things. Rather than using "real" dependency info found in LSB headers to determine any transaction ordering requirements (e.g. when starting all services needed at boot), all we have to go on are the priority numbers in the chkconfig line or the nn values in the /etc/rc?.d/S[nn]script symlink. This is OK for something, but it imposes far too strict (and 99% bogus) set of ordering requirements for the boot transaction. This overly strict ordering imposed can lead to cycles in the transaction requirements. systemd will break the cycle but it will do so rather brutally by dropping jobs - on more than one occasion, this has resulted in prefdm.service's start job getting dropped. i.e. no graphical display. Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
[Mageia-dev] Freeze push: shotwell
Please push shotwell 0.12.2. It's a bug fix version: - Improved handling of and robustness against corrupted tag data. - Correction of a major UI glitch that could occur if the user switched away from the camera page while the application was retrieving image thumbnails from the camera. - Various other bugfixes. Thanks. -- Damien Lallement twitter: damsweb - IRC: damsweb/coincoin
Re: [Mageia-dev] painful discussion n°1: debloating
2012/4/11 Olav Vitters : > However, seems that in almost every install seahorse might be installed > (tv saying that we go from something like glib -> gio -> .. -> > seahorse). Almost every install might have glib going to seahorse. That > bit is the concern. I don't care about minimal; in a minimal, it just > should not install suggests and I really don't care if that currently > works in the installer or not. > Currently almost every install might end up having gnome-keyring. Even > if often it isn't used. That's a concern. > So, yeah, move the suggests and remove totem-mozilla from CAT_KDE. But > not because of the minimal install. > > This might result in some users not having seahorse anymore though. OK. So I have some conclusion: - A minimal install should not install any Suggests, if it does, please report a bug (bug #5209). -> The Suggests don't need to be moved. - Instead, Requires will affect minimal install. -> Change Requires: gnome-keyring in libgnome-keyring to Suggests. - remove totem-mozilla (and other gnome stuff, if neecessary) from CAT_KDE. Olav, I've committed the change of libgnome-keyring to svn. Please review and submit it if it's acceptable to you. (You are still the maintainer of libgnome-keyring.) I don't know how to change CAT_KDE in rpmstrate, so that should be done by someone else. Thanks.
[Mageia-dev] rpm lies to bcond_with{out} usage
Hi,
In /usr/lib/rpm/macros it does say:
# Handle conditional builds. %bcond_with is for case when feature is
# default off and needs to be activated with --with ... command line
# switch. %bcond_without is for the dual case.
#
# %bcond_with foo defines symbol with_foo if --with foo was specified on
# command line.
# %bcond_without foo defines symbol with_foo if --without foo was *not*
# specified on command line.
#
# For example (spec file):
#
# (at the beginning)
# %bcond_with extra_fonts
# %bcond_without static
# (and later)
# %if %{with extra_fonts}
# ...
# %else
# ...
# %endif
# %if ! %{with static}
# ...
# %endif
# %ifdef %{with static}
# ...
# %endif
But seams this is NO longer true, i have add in a spec "%bcond_with foo"
so if i want to deny it (following the explained usage) i would have
to do: %if ! %{with foo}
but seams its not denying, rpm is lying!
So far the only way i found to deny and that does in fact deny is to
use: %if %{!with foo}
Surprised? Well so am i!
Seams that rpm behaviour goes very confusing, since also "rpmquery"
no longer does what is expected i.e. "rpmquery -i foo" doesn not show
any info about the package.
Can this be fixed with a patch?
Maybe would be better for the rpm maintainer report these problems upstream?
Re: [Mageia-dev] [Mageia-discuss] Handbooks - the lot
2012/4/11 Dimitrios Glentadakis : > Στις 11/04/2012 19:11:55 Wolfgang Bornath γράψατε: >> 2012/4/11 Dimitrios Glentadakis : >> > Στις 11/04/2012 16:05:23 γράψατε: >> >> * I am not at home, actually how much space they take ? For what kind of >> >> size we are talking about ? >> > >> > The /usr/share/doc/HTML/en folder has a size of 43.5 MiB, which even now >> > if it takes a lot of place anyone can delete this folder from his system. >> >> We are not talking about deleting data from the harddisk. We are >> talking about installing and uninstalling, not just deleting. The >> issue is to avoid the installation (if not wanted) and consequently >> avoid updates. >> >> I expected the discussion about the technical options to be quite long >> and not at all trivial, I did not expect such a discussion about the >> "why". There are valid use cases which answer the "why" quite clear >> and simple. >> >> > > I dont understand very well. Yes, I see. > - We dont have a lot of space so we want to be able to uninstall some > software and it has to be the documentation as the most unwanted ? > - We want for a question of free choice to be able to choose if we want the > documentation to be installed or not ? but this has to be the same for all > kde software and dependencies, why is the documentation the problem. We have been talking about handbooks because they are single packages (not included in the software package) which are not needed/wanted by everybody and they are not necessary to run the software. > Dont forget that is a part of KDE and it has a global shortcut F1 to access > it. If there is a case that it will be not available until the user install > it in a additionally way, it breaks the upstream software. The important word in your sentence is "if". This does not apply to simple applications like kcalc or some simple games or whatever you may regard as "simple apps". And as said before: it does not break the upstream software. > It is truth that i spend a lot of time to translate documentation, and i do > it with love, so it is normal that i have a preference in their existence in > the system; certainly i cannot use this argument here. Yes, you have to live with that like we all have to. I already said that. -- wobo
[Mageia-dev] Freeze push: openjpeg 1.5.0
Hello, Could somebody push openjpeg 1.5.0 into cauldron? It fixed CVE-2012-1499: The JPEG 2000 codec in OpenJPEG before 1.5 does not properly allocate memory during file parsing, which allows remote attackers to execute arbitrary code via a crafted file. Thanks.
Re: [Mageia-dev] Freeze push: shotwell
Le 12/04/2012 01:19, Damien Lallement a écrit : > Please push shotwell 0.12.2. > It's a bug fix version: > - Improved handling of and robustness against corrupted tag data. > - Correction of a major UI glitch that could occur if the user switched > away from the camera page while the application was retrieving image > thumbnails from the camera. > - Various other bugfixes. > > Thanks. Submitted -- http://mageia.org
Re: [Mageia-dev] Freeze Push: drakx-net
Le 12/04/2012 01:33, Colin Guthrie a écrit : > Just a single patch: > > - ensure /etc/hostname has a newline as per upstream specs (#4672) > > Col > submitted -- http://mageia.org
