Re: [Mageia-dev] Mageia Cauldron: Bad RPM's while update via urpmi
Wolfgang Bornath wrote: This explains it! Change the mirror, you are using ibiblio which has been reported numerous times in the forum and the mailing lists to be syncing very badly. I don't know about badly, but I found it to be a little bit behind. If you are located in north america, use mirrors.kernel.org which is fast and reliable. Has anyone had success using rsync with mirrors.kernel.org? When I tried it, the path to mageia kept toggling between mirrors/pub/mageia and mirrors/pub/pub/mageia every time I used it. It's like it's behind a load balancer where one of the machines behind it has the wrong rsync path configured.
[Mageia-dev] Import request: apache-mod_suexec
https://bugs.mageia.org/show_bug.cgi?id=1466 Just wanted to make sure this one didn't fall through the cracks. The apache maintainer should probably take care of this since it builds right from the apache source. It's a simple import and rebuild. Thanks!
[Mageia-dev] Import request: apcupsd
https://bugs.mageia.org/show_bug.cgi?id=1462 I also wanted to make sure this wasn't missed, as it's an important package (for monitoring APC brand UPSs). It's also a simple import and rebuild. Thanks!
Re: [Mageia-dev] ANN: X11 now starts on tty1
Anssi Hannula wrote: On 16.12.2011 20:16, Colin Guthrie wrote: Hi Just in case you didn't notice, X11 now starts on tty1 by default. So if you want a text login shell, make sure you go to tty2! I've not actually updated it for sysvinit now I think about it, so I'll have to update the default inittab, but the principle is the same. We want X there, not a login. I wonder why that is needed... If it is to prevent flickering when switching tty1-tty7, can't we just e.g. make the kernel use tty7 by default if needed? +1 Also, what happens when you boot to multi-user.target instead of graphical.target?
Re: [Mageia-dev] boot-nonfree.iso ?
Thomas Backlund wrote: Now this does not fix the radeon-firmware issue, as this is only to get installer running on all hw. (I probably will remove radeon-firmware again as it's not needed/used by the installer) For the radeon-firmware (and other nonfree firmware) issue, we still need to fix stage2 installer. Do you have a reference for this issue?
Re: [Mageia-dev] Conflicts between kde 4.7.90 and laptop-mode-tools
Frank Griffin wrote: On 12/28/2011 11:36 AM, Balcaen John wrote: Le mercredi 28 décembre 2011 11:34:08 Frank Griffin a écrit : [...] But the question still stands in modified form: is anything else on a Mageia system using laptop-mode-tools, or has everything moved to pm-utils ? If I rip out laptop-mode-tools to avoid blocking the KDE packages, what happens to non-KDE stuff ? I would say nothing since i doubt that ahmad would add a conflicts just for that. Also if it was stricly requires (like it is for kde) i guess a urpme laptop- mode-tools should answer the question. urpme removes laptop-mode-tools without a whimper. So we should probably do the same. This is causing a problem with upgrades from MDV 2010.2. laptop-mode-tools gets upgraded to the mga version, but pm-utils does not because of the conflict. You need to manually urpme laptop-mode-tools and then upgrade the pm-utils. I know the conflict is mentioned on the Mageia 1 errata, but it would be nice if there was a better solution for this (that doesn't require manual intervention).
Re: [Mageia-dev] php-5.4RC3
Thomas Spuhler wrote: php-5.4RC3 will hit the mirrors soon. It may beak a few things. Hello Thomas, I was just wondering if you'd seen this since you hadn't changed it to ASSIGNED status: https://bugs.mageia.org/show_bug.cgi?id=3895 I was also curious if you are on the IRC.
Re: [Mageia-dev] boot-nonfree.iso ?
David Walser wrote: Thomas Backlund wrote: Now this does not fix the radeon-firmware issue, as this is only to get installer running on all hw. (I probably will remove radeon-firmware again as it's not needed/used by the installer) For the radeon-firmware (and other nonfree firmware) issue, we still need to fix stage2 installer. Do you have a reference for this issue? Is it https://bugs.mageia.org/show_bug.cgi?id=1471 or something else?
Re: [Mageia-dev] boot-nonfree.iso ?
Thomas Backlund wrote: 29.12.2011 22:39, David Walser skrev: David Walser wrote: Thomas Backlund wrote: Now this does not fix the radeon-firmware issue, as this is only to get installer running on all hw. (I probably will remove radeon-firmware again as it's not needed/used by the installer) For the radeon-firmware (and other nonfree firmware) issue, we still need to fix stage2 installer. Do you have a reference for this issue? Is it https://bugs.mageia.org/show_bug.cgi?id=1471 or something else? Yes, it's exactly that. the free DVD does not contain anything from nonfree, so radeon fails to load until the firmware gets installed. So we are trying to solve this issue cleanly. One thing I'm working on is a separate firmware iso to burn (or put contents on usb stick) to satisfy this need. The other option for radeon users is to install using livecds. I want to make sure I understand you correctly, as I'm planning to upgrade a MDV 2010.2 machine with a Radeon HD 4650 to Mageia 1 tomorrow. The referenced bug makes it sound like the installer works fine, but since it doesn't have access to the nonfree firmware, the initrds it generates in the bootloader installation part doesn't contain them, so booting the installed system is problematic if you don't do radeon.modeset=0. Listening to you in this thread I'm getting worried DrakX itself may not work without access to the firmware. Did I misread you?
Re: [Mageia-dev] mentors + apprentices
andre999 wrote: Hi everyone, Happy new year, and I hope that everyone has made a resolution to help Mageia to be a better distro. So qualified packagers, if you haven't already, would you like to mentor one of our eager apprentice candidates ? luigiwalser (David Walser), who was a Mandrake packager (before the current build system), currently working as a Linux instructor and sysadmin, interested in importing some packages to Mageia that he uses. dmorgan has adopted me :D
Re: [Mageia-dev] references to outside web sites/wiki
Wolfgang Bornath wrote: 2012/1/5 Buchan Milne bgmi...@zarb.org: -Possibly considering contacting large mirror sites (e.g. mirrors.kernel.org) who currently mirror Mandriva, but not Mageia? Just for the records: mirrors.kernel.org mirror Mageia. But surely there are more large sites to be contacted. carroll.aset.psu.edu is one of the major mirrors in the USA that's missing Mageia still.
Re: [Mageia-dev] references to outside web sites/wiki
Glen Ogilvie wrote: On Wednesday, 4 January 2012 23:56:01 Romain d'Alverny wrote: On Wed, Jan 4, 2012 at 22:36, Johnny A. Solbu coo...@solbu.net wrote: On Wednesday 04 January 2012 21:06, Romain d'Alverny wrote: wiki.mandriva.com may be shut down for good in just a few days What? Are Mandriva serisouly considering closing down the Wiki? Mandriva is on the path to filing for bankruptcy on January 16th. Does anyone have a complete mirror / copy of the Mandriva svn repository, or a complete set of SRPMs from cooker? I would be concerned this becomes unavailable, as it's a valuable resource for packages not yet imported into Mageia and contains a history of the package that Mageia does not have. I asked about this on IRC and was directed to http://rsvndump.sourceforge.net/ as a tool that can be used to download their SVN repository. I'd *really* like to see this happen and be somewhere that everyone has access to (i.e. not have me try to do it myself). If there's anything needed to help make this happen, I'm willing to help however I can. I'd really hate for us to lose MDV's SVN packages repository.
[Mageia-dev] Security updates needing testing (please help)
There are a number of needed security updates for Mageia 1 that have already been built and just need QA testing so that they can be released. Most of them have testcases already described in the comments. Please help test these if you can so we can get these updates released. Needs testing on i586: https://bugs.mageia.org/show_bug.cgi?id=2950 cifs-utils https://bugs.mageia.org/show_bug.cgi?id=3311 proftpd https://bugs.mageia.org/show_bug.cgi?id=3980 samba Needs testing on x86_64: https://bugs.mageia.org/show_bug.cgi?id=3902 jasper https://bugs.mageia.org/show_bug.cgi?id=3937 dhcp https://bugs.mageia.org/show_bug.cgi?id=3939 nfs-utils https://bugs.mageia.org/show_bug.cgi?id=3940 libxml2 https://bugs.mageia.org/show_bug.cgi?id=3942 icu https://bugs.mageia.org/show_bug.cgi?id=3982 libsndfile https://bugs.mageia.org/show_bug.cgi?id=3985 libtiff https://bugs.mageia.org/show_bug.cgi?id=3993 gif2png https://bugs.mageia.org/show_bug.cgi?id=3994 t1lib https://bugs.mageia.org/show_bug.cgi?id=3998 gimp https://bugs.mageia.org/show_bug.cgi?id=3999 libzip https://bugs.mageia.org/show_bug.cgi?id=2064 krb5-appl Needs testing on both: https://bugs.mageia.org/show_bug.cgi?id=3895 PHP (Thomas also needs to rebuild php-apc and php-eaccelerator) https://bugs.mageia.org/show_bug.cgi?id=3955 cyrus-imapd Already tested, needs pushed by sysadmins: https://bugs.mageia.org/show_bug.cgi?id=3941 libarchive https://bugs.mageia.org/show_bug.cgi?id=3995 libuser
Re: [Mageia-dev] Security updates needing testing (please help)
Thank you to Dave Hodgins, David Geiger, Claire Robinson, and Thomas Backlund for helping to get some of these cleared out! Updated status below. There are a number of needed security updates for Mageia 1 that have already been built and just need QA testing so that they can be released. Most of them have testcases already described in the comments. Please help test these if you can so we can get these updates released. Needs testing on i586: https://bugs.mageia.org/show_bug.cgi?id=4064 sqlitebrowser Needs testing on x86_64: https://bugs.mageia.org/show_bug.cgi?id=3937 dhcp https://bugs.mageia.org/show_bug.cgi?id=3939 nfs-utils https://bugs.mageia.org/show_bug.cgi?id=2064 krb5-appl https://bugs.mageia.org/show_bug.cgi?id=3284 msec https://bugs.mageia.org/show_bug.cgi?id=3955 cyrus-imapd https://bugs.mageia.org/show_bug.cgi?id=3997 mhonarc Needs testing on both: https://bugs.mageia.org/show_bug.cgi?id=3895 PHP (Thomas also needs to rebuild php-apc and php-eaccelerator) https://bugs.mageia.org/show_bug.cgi?id=3956 networkmanager
Re: [Mageia-dev] Security updates needing testing (please help)
Thank you to Dave Hodgins, David Geiger, Claire Robinson, Manuel Hiebel, and Thomas Backlund for helping to get some of these cleared out! Updated status below. There are a number of needed security updates for Mageia 1 that have already been built and just need QA testing so that they can be released. Most of them have testcases already described in the comments. Please help test these if you can so we can get these updates released. Needs testing on i586: https://bugs.mageia.org/show_bug.cgi?id=3956 networkmanager Needs testing on x86_64: https://bugs.mageia.org/show_bug.cgi?id=3937 dhcp https://bugs.mageia.org/show_bug.cgi?id=3939 nfs-utils https://bugs.mageia.org/show_bug.cgi?id=2064 krb5-appl https://bugs.mageia.org/show_bug.cgi?id=3955 cyrus-imapd Needs testing on both: https://bugs.mageia.org/show_bug.cgi?id=3895 PHP (Thomas also needs to rebuild php-apc and php-eaccelerator) Already tested, needs pushed by sysadmins: https://bugs.mageia.org/show_bug.cgi?id=4064 sqlitebrowser https://bugs.mageia.org/show_bug.cgi?id=3284 msec https://bugs.mageia.org/show_bug.cgi?id=3997 mhonarc And a reminder from your friendly QA team that all update candidates can be viewed at: https://bugs.mageia.org/buglist.cgi?cmdtype=doremremaction=runnamedcmd=waiting%20for%20QA%20testsharer_id=22
Re: [Mageia-dev] [RFC] Moving various packages/codecs to tainted
Anssi Hannula wrote: Hi all! As I've noted in some previous emails, our core/tainted media codec split-up is currently arbitrary without any specific logic. As far as I remember, the tainted policy is that codecs for formats that are claimed to be covered by patents should be there. Per that policy, at least the AC-3/DTS/MP3/MPEG-2/MPEG-4/H.264/VC-1 decoders and AC-3/MPEG-2/MPEG-4 encoders we have in core should be moved to tainted section. Note that this will make most current .mkv/.avi/.mp4/.mov/.wmv/.mp3 files unplayable without packages from tainted section. That's the absolute last thing I want to see happen. It's one of the reasons Fedora and others that do that are not viable options for a lot of non-technical users, and it just makes it so you have to jump through a lot of extra hoops just to have a reasonably working system (whether it's your own or for family members that you might be maintaining). Obvouisly just about every codec in use has patents relevant to it, but I think we're OK to stick with the ones Mandriva shipped for years in core (like mp3 decoding) and things that were in PLF in tainted (like mp3 encoding) even if it seems arbitrary. If anything, it'd be nice if more not-likely-to-be-problematic codecs could be moved to core.
Re: [Mageia-dev] [RFC] Moving various packages/codecs to tainted
Anssi Hannula wrote: On 10.01.2012 01:30, David Walser wrote: Anssi Hannula wrote: Hi all! As I've noted in some previous emails, our core/tainted media codec split-up is currently arbitrary without any specific logic. As far as I remember, the tainted policy is that codecs for formats that are claimed to be covered by patents should be there. Per that policy, at least the AC-3/DTS/MP3/MPEG-2/MPEG-4/H.264/VC-1 decoders and AC-3/MPEG-2/MPEG-4 encoders we have in core should be moved to tainted section. Note that this will make most current .mkv/.avi/.mp4/.mov/.wmv/.mp3 files unplayable without packages from tainted section. That's the absolute last thing I want to see happen. It's one of the reasons Fedora and others that do that are not viable options for a lot of non-technical users, and it just makes it so you have to jump through a lot of extra hoops just to have a reasonably working system (whether it's your own or for family members that you might be maintaining). Obvouisly just about every codec in use has patents relevant to it, but I think we're OK to stick with the ones Mandriva shipped for years in core (like mp3 decoding) and things that were in PLF in tainted (like mp3 encoding) even if it seems arbitrary. If anything, it'd be nice if more not-likely-to-be-problematic codecs could be moved to core. I'm absolutely fine with either moving codecs to core or tainted, as long as we are at least somewhat consistent in what is in core and what is in tainted. However, I do not really like the reasoning we do it like mandriva did no matter if it is sensible or not. I'd possibly understand we do it like mandriva did because they didn't apparently have problems with these pkgs, but it IMHO wouldn't really fly as we could just s/mandriva/ubuntu/ in that statement (and Ubuntu is much more prominent than mdv IMO) and then everything would be in core... Sure, I but I think Mandriva achieved a good balance between respecting patents and not being overly paranoid. I suppose you can't blame a US company like RedHat for being overly paranoid, but as you said, Mandriva hasn't had any problems. Are there any there examples out of there of distros trying to achieve this balance? Obviously we don't want to follow Ubuntu or ROSA in pretending patents don't exist.
Re: [Mageia-dev] Fwd: Re: [Kolab-devel] Supercolliding a PHP array - DoS Attacks
Thomas Spuhler wrote: I got this from the Kolab folks: -- Forwarded Message -- -Message original- De: ABBAS Alain alain.ab...@libertech.fr Envoyé: 9 janvier 2012 22:48:02 UTC A: kolab-us...@kolab.org Cc: kolab-de...@kolab.org Sujet : [Kolab-devel] Supercolliding a PHP array - DoS Attacks Hello There are a serious Dos Attack issue in PHP prior to 5.3.9 This attack is more than easy and serious. Thanks Thomas, it's good to know the seriousness of this. All the more reason to get the update for Mageia 1 pushed out. Anyone that can help QA the update is welcome. https://bugs.mageia.org/show_bug.cgi?id=3895 Thomas, I saw you rebuilt php-eaccelerator for Cauldron. That's good. Please remember to also rebuild it and php-apc as part of the PHP update for Mageia 1.
Re: [Mageia-dev] [RFC] Moving various packages/codecs to tainted
andre999 wrote: We're talking about codecs, essentially the decoders which are used to read encoded files. If the patent claims are valid/enforceable (and most aren't), it is up to the patent holder to decide if it is in their interest to enforce the patent claims. Since they will normally attempt to collect royalties from those using the encoders to generate encoded content, it is in their interest avoid enforcing claims against users of decoders, as the more such decoders are used, the more the demand for the corresponding encoders, and thus the more royalties they will collect. So it seems to me entirely logical to await notification that they indeed intend to collect royalties for these codec decoders. However I do agree that we should put encoders that seem to be covered by valid patents in some countries in tainted. If we really want a hard and fast rule, I agree that this makes the most sense.
Re: [Mageia-dev] Security updates needing testing (please help)
The QA team is doing a great job getting things tested. A lot of new packages have been pushed to updates_testing recently, so more help is still welcome to clear it out. Most of them are security updates. Just to highlight some... Needs testing on i586: https://bugs.mageia.org/show_bug.cgi?id=3956 networkmanager Needs testing on x86_64: https://bugs.mageia.org/show_bug.cgi?id=2064 krb5-appl https://bugs.mageia.org/show_bug.cgi?id=4158 libxml2 If anyone is curious about the status of the PHP update, it is being redone to update to 5.3.9. Already tested, needs pushed by sysadmins: https://bugs.mageia.org/show_bug.cgi?id=3955 cyrus-imapd And a reminder from your friendly QA team that all update candidates can be viewed at: https://bugs.mageia.org/buglist.cgi?cmdtype=doremremaction=runnamedcmd=waiting%20for%20QA%20testsharer_id=22
Re: [Mageia-dev] Over-zealous rpmlint policy (rejecting rt)
Michael Scherer wrote: Le jeudi 12 janvier 2012 à 11:12 +0200, Buchan Milne a écrit : I am trying to get rt (3.8.11) into the distro (a package that I am using on a different distro in a production environment), to be followed up with the rt (4.0.4) I have queued (which I am testing in preparation for upgrading our production environment). I would really like to get this package into the distro, but it is being rejected (http://pkgsubmit.mageia.org/uploads/rejected//cauldron/core/release/20120110140334.buchan.valstar.18287.youri) due to: Submission errors, aborting: - rt-3.8.11-1.mga2.noarch: - dir-or-file-in-usr-local /usr/local/lib/rt/plugins - dir-or-file-in-usr-local /usr/local/lib/rt - dir-or-file-in-usr-local /usr/local/lib/rt/po - dir-or-file-in-usr-local /usr/local/lib/rt/lib - dir-or-file-in-usr-local /usr/local/etc/rt - dir-or-file-in-usr-local /usr/local/lib/rt/html The documented way for extending RT is by installing files in this location. We can either: 1)Make it more difficult for users to extend RT with local plugins etc. 2)Fix rpmlint 3)Not have RT misc, you have experience of both rt and rpmlint, can you provide an opinion? Would it be possible to separate 'dir-or-file-usr-local' into separate rules (one for files, one for dirs)? While I agree we shouldn't ship files in /usr/local, I don't see why we shouldn't ship dirs in /usr/local ... We shouldn't ship directories for the same reason that we shouldn't ship file, ie FHS. See : http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRLOCALLOCALHIERARCHY More specifically : It needs to be safe from being overwritten when the system software is updated. So the question is whether someone who change directory permissions will see them overwritten or not when the software is updated, and wether that a FHS violation. Afaik, rpm would reset the permission ( the same goes for removal of the directory ). See also : No other directories, except those listed below, may be in /usr/local after first installing a FHS-compliant system. Again, that's not clear if we can modify it later or not ( ie, is instaling rt on installation part of first installing or not ). I guess we should get a opinion from FHS/LSB people on this. In the mean time, I guess the point 1 is the easiest way, it can be changed later once we clarified FHS (or if we decide that we do not care about following standards, but that's really something I would like to avoid ). Not to mention there may be installations where /usr/local is NFS shared across a network and having the package manager trying to write there could cause problems. Maybe another possible solution is to have the software create the needed directory at some point, but don't have the package itself create or own it. CUPS is already doing this with /usr/local/lib/printdriver and /usr/local/share/ppd (and equivalents in /opt).
Re: [Mageia-dev] Packagers meeting
Anne nicolas wrote: Hi there Could we have our weekly meeting tomorrow, same time, same place? Misc is not available at the moment and I will be in another meeting and late for sure. For tomorrow's meeting: - FOSDEM reminder - isos content: define DVD iso content - Define focus until end of Mageia 2 development cycle I skimmed the IRC log of the meeting and there was a lot of discussion on this last point. It looked like there is definitely a set of specific things you would like packagers to focus on between now and release, most of them with supporting URLs. It would be nice if someone would summarize with a your mission should you choose to accept it type post to mageia-dev with a summary and links.
Re: [Mageia-dev] OSS sound support
Colin Guthrie wrote: 'Twas brillig, and Thierry Vignaud at 08/10/11 20:05 did gyre and gimble: On 8 October 2011 19:35, Colin Guthrie mag...@colin.guthr.ie wrote: I've just pushed some changes that disable OSS sound under PulseAudio sound profile. If you want to use OSS apps with PulseAudio, please install ossp package which I've also just submitted. I think ultimately we'll disable ALSA OSS emulation completely and use ossp in both PA and non-PA modes but I hear that the non-PA usage isn't quite as nice, so I'm holding off doing this just yet. then task-pa should suggests ossp... I'm undecided about this. I'm not sure if the default setup should include OSS sound support or not. Perhaps it would be better left as something that users install if they need it. As we'll eventually have to go through all the packages that require soundwrapper, perhaps we could either: a) Replace the soundwrapper require with a ossp require. b) Patch soundwrapper such that it's a noop if osspd is running and make it require ossp. The latter would mean less churn on packages, but it's arguably just delaying the inevitable work of doing it eventually. Thoughts? Col I've released and uploaded a new version of soundwrapper (first one in 4 years :o) that is a no-op if osspd is running.
Re: [Mageia-dev] [RFE] Bundled copies of system libraries - call for participation
Florian Hubold wrote: I've just whipped up https://wiki.mageia.org/en/Packages_carrying_bundled_copies_of_system_libraries It's purpose is listing and maybe documenting the reasons why some packages carry bundled copies of system libraries. I've begun with ffmpeg, as it has a rather bad record for security updates on Mageia 1 IMHO, as some security updates would almost have been missed, some were delayed for a long time, and some wouldn't have been noticed unless by accident. Please, every packager participate, and list the packages you know about. Another good example would be xulrunner. PS: Maybe it should also be used to documented the packages which require some static linking, and the reasons, if there are any of these. Thanks Florian. Another thing that would be helpful related to this would be to have an install of rq in the Mageia infrastructure: https://fedorahosted.org/rq/ It can be used to see when some code is affected by a security vulnerability if any other packages contain the same code.
[Mageia-dev] urw-fonts
The urw-fonts package is a confusing mess with multiple copies of the same fonts, coming from different sources and different times. One of the things in the package is urw-fonts-1.0.7pre40. There is now a urw-fonts-1.0.7pre44 available: http://svn.ghostscript.com/ghostscript/tags/urw-fonts-1.0.7pre44/ which may obsolete some of the other copies of the fonts in that package. Also, RedHat has changed their version of the package to 2.4, instead of the 2.0 we have now (neither have any correspondence to anything). Gentoo, to add to the mess is using 2.4.9 to their version, as can be seen here: http://check.mageia.org/updates.html Could someone update the urw-fonts to pre44, change the version to (at least) 2.4, and try and sort out this mess?
[Mageia-dev] procps / procps-ng
There is a fork of procps called procps-ng, which I think lives here: http://www.ohloh.net/p/procps-ng Debian has switched to using it, as can be seen here: http://packages.debian.org/changelogs/pool/main/p/procps/procps_3.3.2-3/changelog Should we switch to it as well, or stick with procps?
[Mageia-dev] removal of .la from libxt breaks xpdf build
D Morgan asked us to say if removal of .la files broke anything. It breaks xpdf, and I don't know if it's fixable. xpdf needs libXt.la to build libxpdf.la, and the xpdf build is heavily dependent on libxpdf.la. See xpdf-3.03-shared.diff for example.
Re: [Mageia-dev] procps / procps-ng
Pascal Terjan wrote: On Sun, Feb 12, 2012 at 16:13, D.Morgan dmorga...@gmail.com wrote: On Sun, Feb 12, 2012 at 1:05 AM, David Walser luigiwal...@yahoo.com wrote: There is a fork of procps called procps-ng, which I think lives here: http://www.ohloh.net/p/procps-ng Debian has switched to using it, as can be seen here: http://packages.debian.org/changelogs/pool/main/p/procps/procps_3.3.2-3/changelog Should we switch to it as well, or stick with procps? i have not yet looked, but what fedora did ? https://gitorious.org/procps says Debian, Fedora and openSUSE fork of procps. Yes, and the Fedora git shows they have switched to it, although they forgot to update the version number.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release postfix-2.8.8-1.mga2
Guillaume Rousse wrote: Le 19/02/2012 01:08, luigiwalser a écrit : Name: postfix Relocations: (not relocatable) Version : 2.8.8 Vendor: Mageia.Org Release : 1.mga2Build Date: Sun Feb 19 01:05:54 2012 luigiwalserluigiwalser 1:2.8.8-1.mga2: + Revision: 210583 - 2.8.8 - fix creation of /etc/sysconfig/postfix on clean install (mdv #65025) - add openssl dependancy for certificate generation on install (from mdv) As certificate generation is done through rpm-helper scripts, the dependency should rather be in the latest package. What? - fix README.MGA filename Reverting previous change without reason can hardly be considered a fix. The reason is the package didn't build. You had the source file named .MGA, copied to a file called .mga in the buildroot, and listed as .MGA in the files list. The package didn't build due to the missing file. I checked other packages and the capitalized version seems to be the standard way to name it, so I fixed it.
Re: [Mageia-dev] printer-filter-utils
Pascal Terjan wrote: I was looking at that package, which is a collection of drivers for some printers, not updated for years It is one of the two packages requiring automake1.4, because of the included drv_z42 Looking on http://www.openprinting.org/driver/drv_z42/ original website no longer exist, and even if openprinting now hosts it they say This driver is obsolete. Recommended replacement driver: gutenprint Should we drop it? Does anyone has enough time to see if other drivers in this package may still be needed? And actually, if we install this package. Also from openprinting, there are security issues fixed in the newest foomatic-filters (needs updated in Mageia 1 and Cauldron, see Bug 3979). They also have a new CUPS filters set that probably needs to be packaged. Upstream notes on it: Apple decided to not continue to develop and maintain the CUPS filters and backends which are not used by Mac OS X and moved them to OpenPrinting. They also did not accept the new filters for the PDF-based printing workflow as they are also not used by Mac OS X. All these filters we continue to maintain now in one package, the OpenPrinting CUPS Filters and announce here the first stable release of this package, versionn 1.0.1.
Re: [Mageia-dev] removal of .la from libxt breaks xpdf build
Funda Wang wrote: ? 2012-2-12 ??12:08?David Walser luigiwal...@yahoo.com??? D Morgan asked us to say if removal of .la files broke anything. It breaks xpdf, and I don't know if it's fixable. xpdf needs libXt.la to build libxpdf.la, and the xpdf build is heavily dependent on libxpdf.la. See xpdf-3.03-shared.diff for example. The problem is xpdf depends on lesstif, it will bring libXt.la. But lesstif cannot be built now for some reasons. OK, I see that Funda synced lesstif with Mandriva and fixed the package. It now builds locally and I believe it is OK. On the build system, it always fails with gcc segfaulting, and it fails at a different place every time. I have seen this with other packages where eventually it will work, and it seems to be a resources issue that causes it. It appears not enough resources (probably RAM) are allocated to the VM (I'm assuming it's a VM) on the build system to build this package.
Re: [Mageia-dev] [changelog] cauldron core/release phpmyadmin-3.4.10-1.mga2
zezinho wrote: Name: phpmyadmin Relocations: (not relocatable) Version : 3.4.10Vendor: Mageia.Org Release : 1.mga2Build Date: Sun Feb 19 22:50:32 2012 zezinho zezinho 3.4.10-1.mga2: + Revision: 211010 - new version There was a 3.4.10.1 announced yesterday with a XSS security fix: http://www.phpmyadmin.net/home_page/security/PMASA-2012-1.php
Re: [Mageia-dev] removal of .la from libxt breaks xpdf build
Pascal Terjan wrote:
On Sun, Feb 19, 2012 at 17:23, Pascal Terjan pter...@gmail.com wrote:
On Sun, Feb 19, 2012 at 17:08, Pascal Terjan pter...@gmail.com wrote:
On Sun, Feb 19, 2012 at 16:29, Pascal Terjan pter...@gmail.com wrote:
On Sun, Feb 19, 2012 at 16:23, Pascal Terjan pter...@gmail.com wrote:
On Sun, Feb 19, 2012 at 15:55, David Walser luigiwal...@yahoo.com wrote:
Funda Wang wrote:
? 2012-2-12 ??12:08?David Walser luigiwal...@yahoo.com???
D Morgan asked us to say if removal of .la files broke anything. It
breaks xpdf, and I don't know if it's fixable. xpdf needs libXt.la to
build libxpdf.la, and the xpdf build is heavily dependent on
libxpdf.la.
See xpdf-3.03-shared.diff for example.
The problem is xpdf depends on lesstif, it will bring libXt.la. But
lesstif
cannot be built now for some reasons.
OK, I see that Funda synced lesstif with Mandriva and fixed the package.
It now builds locally and I believe it is OK. On the build
system,
it always fails with gcc segfaulting, and it fails at a different place
every time. I have seen this with other packages where
eventually it
will work, and it seems to be a resources issue that causes it. It
appears not enough resources (probably RAM) are allocated to the
VM (I'm
assuming it's a VM) on the build system to build this package.
It's not a vm and it has either 8GB of ram (ecosse) or 12GB (jonund)
+4GB swap...
Looking at the log, this is just a normal internal compiler error from gcc:
XmString.c: In function 'XmStringGetNextTriple':
XmString.c:5484:9: warning: cast from pointer to integer of different
size [-Wpointer-to-int-cast]
XmString.c: In function 'XmStringComponentCreate':
XmString.c:5520:33: warning: cast from pointer to integer of different
size [-Wpointer-to-int-cast]
{standard input}: Assembler messages:
{standard input}: Warning: end of file not at end of a line; newline
inserted
{standard input}:1840: Error: number of operands mismatch for `test'
{standard input}: Error: open CFI at the end of file; missing
.cfi_endproc directive
gcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugs.mageia.org/ for instructions.
make[2]: *** [XmString.lo] Error 1
It was reported at least on https://bugs.archlinux.org/task/27357 but
I din't find upstream (gcc) report. I'll try to have a look.
Crash happens when you build http://fasmz.org/~pterjan/tmp/XmStringE.c
with -O1 or -O2, I'll test on other arch/versions and report bug
upstream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52310
Duplicate of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51077 which
contains a patch for gcc
tmb added the patch to gcc to fix that issue (thanks Thomas!).
Now the build dies because libXext.la is missing[1] :o( What's the solution
for that?
[1] - https://bugs.mageia.org/show_bug.cgi?id=4492#c2
Re: [Mageia-dev] removal of .la from libxt breaks xpdf build
David Walser wrote:
Pascal Terjan wrote:
On Sun, Feb 19, 2012 at 17:23, Pascal Terjan pter...@gmail.com wrote:
On Sun, Feb 19, 2012 at 17:08, Pascal Terjan pter...@gmail.com wrote:
On Sun, Feb 19, 2012 at 16:29, Pascal Terjan pter...@gmail.com wrote:
On Sun, Feb 19, 2012 at 16:23, Pascal Terjan pter...@gmail.com wrote:
On Sun, Feb 19, 2012 at 15:55, David Walser luigiwal...@yahoo.com
wrote:
Funda Wang wrote:
? 2012-2-12 ??12:08?David Walser luigiwal...@yahoo.com???
D Morgan asked us to say if removal of .la files broke anything. It
breaks xpdf, and I don't know if it's fixable. xpdf needs libXt.la to
build libxpdf.la, and the xpdf build is heavily dependent on
libxpdf.la.
See xpdf-3.03-shared.diff for example.
The problem is xpdf depends on lesstif, it will bring libXt.la. But
lesstif
cannot be built now for some reasons.
OK, I see that Funda synced lesstif with Mandriva and fixed the
package. It now builds locally and I believe it is OK. On the build
system,
it always fails with gcc segfaulting, and it fails at a different place
every time. I have seen this with other packages where
eventually it
will work, and it seems to be a resources issue that causes it. It
appears not enough resources (probably RAM) are allocated to the
VM (I'm
assuming it's a VM) on the build system to build this package.
It's not a vm and it has either 8GB of ram (ecosse) or 12GB (jonund)
+4GB swap...
Looking at the log, this is just a normal internal compiler error from
gcc:
XmString.c: In function 'XmStringGetNextTriple':
XmString.c:5484:9: warning: cast from pointer to integer of different
size [-Wpointer-to-int-cast]
XmString.c: In function 'XmStringComponentCreate':
XmString.c:5520:33: warning: cast from pointer to integer of different
size [-Wpointer-to-int-cast]
{standard input}: Assembler messages:
{standard input}: Warning: end of file not at end of a line; newline
inserted
{standard input}:1840: Error: number of operands mismatch for `test'
{standard input}: Error: open CFI at the end of file; missing
.cfi_endproc directive
gcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugs.mageia.org/ for instructions.
make[2]: *** [XmString.lo] Error 1
It was reported at least on https://bugs.archlinux.org/task/27357 but
I din't find upstream (gcc) report. I'll try to have a look.
Crash happens when you build http://fasmz.org/~pterjan/tmp/XmStringE.c
with -O1 or -O2, I'll test on other arch/versions and report bug
upstream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52310
Duplicate of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51077 which
contains a patch for gcc
tmb added the patch to gcc to fix that issue (thanks Thomas!).
Now the build dies because libXext.la is missing[1] :o( What's the solution
for that?
[1] - https://bugs.mageia.org/show_bug.cgi?id=4492#c2
Funda Wang fixed lesstif (thanks Funda!). Now xpdf still won't build...
libxpdf.la -L../fofi -lfofi -L../goo -lGoo -L../splash -lsplash Annot.o Array.o
BuiltinFont.o BuiltinFontTables.o Catalog.o
CharCodeToUnicode.o CMap.o CoreOutputDev.o Decrypt.o Dict.o Error.o
FontEncodingTables.o Function.o Gfx.o GfxFont.o GfxState.o GlobalParams.o
JArithmeticDecoder.o JBIG2Stream.o JPXStream.o Lexer.o Link.o NameToCharCode.o
Object.o OptionalContent.o Outline.o OutputDev.o Page.o
Parser.o PDFCore.o PDFDoc.o PDFDocEncoding.o PreScanOutputDev.o PSOutputDev.o
PSTokenizer.o SecurityHandler.o SplashOutputDev.o Stream.o
TextOutputDev.o UnicodeMap.o UnicodeTypeTable.o XPDFApp.o XPDFCore.o XPDFTree.o
XPDFViewer.o XpdfPluginAPI.o XRef.o xpdf.o -lXm -lXt -lXp -
lXext -lXpm -lSM -lICE -L/usr/lib -lX11 -lXft -lXrender -lfontconfig -lz
*** Warning: Linking the shared library libxpdf.la against the non-libtool
*** objects Annot.o Array.o BuiltinFont.o BuiltinFontTables.o Catalog.o
CharCodeToUnicode.o CMap.o CoreOutputDev.o Decrypt.o Dict.o Error.o
FontEncodingTables.o Function.o Gfx.o GfxFont.o GfxState.o GlobalParams.o
JArithmeticDecoder.o JBIG2Stream.o JPXStream.o Lexer.o Link.o
NameToCharCode.o Object.o OptionalContent.o Outline.o OutputDev.o Page.o
Parser.o PDFCore.o PDFDoc.o PDFDocEncoding.o PreScanOutputDev.o
PSOutputDev.o PSTokenizer.o SecurityHandler.o SplashOutputDev.o Stream.o
TextOutputDev.o UnicodeMap.o UnicodeTypeTable.o XPDFApp.o XPDFCore.o
XPDFTree.o XPDFViewer.o XpdfPluginAPI.o XRef.o xpdf.o is not portable!
libtool: link: g++ -fPIC -DPIC -sharedAnnot.o Array.o BuiltinFont.o
BuiltinFontTables.o Catalog.o CharCodeToUnicode.o CMap.o
CoreOutputDev.o Decrypt.o Dict.o Error.o FontEncodingTables.o Function.o Gfx.o
GfxFont.o GfxState.o GlobalParams.o JArithmeticDecoder.o
JBIG2Stream.o JPXStream.o Lexer.o Link.o NameToCharCode.o Object.o
OptionalContent.o Outline.o OutputDev.o Page.o Parser.o PDFCore.o PDFDoc.o
PDFDocEncoding.o PreScanOutputDev.o PSOutputDev.o
Re: [Mageia-dev] removal of .la from libxt breaks xpdf build
D.Morgan wrote: On Mon, Feb 20, 2012 at 11:18 AM, Funda Wang fundaw...@gmail.com wrote: I guess it is another problem, which has no relationship with lesstif or gcc. a fixed xpdf is on the BS now Thank you D Morgan, Funda Wang, and everyone else that helped along the way. Sometimes it takes a community to raise a package :o)
Re: [Mageia-dev] printer-filter-utils
Florian Hubold wrote: Am 19.02.2012 15:59, schrieb David Walser: Pascal Terjan wrote: I was looking at that package, which is a collection of drivers for some printers, not updated for years It is one of the two packages requiring automake1.4, because of the includeddrv_z42 Looking on http://www.openprinting.org/driver/drv_z42/ original website no longer exist, and even if openprinting now hosts it they say This driver is obsolete. Recommended replacement driver: gutenprint Should we drop it? Does anyone has enough time to see if other drivers in this package may still be needed? And actually, if we install this package. Also from openprinting, there are security issues fixed in the newest foomatic-filters (needs updated in Mageia 1 and Cauldron, see Bug 3979). They also have a new CUPS filters set that probably needs to be packaged. Upstream notes on it: Apple decided to not continue to develop and maintain the CUPS filters and backends which are not used by Mac OS X and moved them to OpenPrinting. They also did not accept the new filters for the PDF-based printing workflow as they are also not used by Mac OS X. All these filters we continue to maintain now in one package, the OpenPrinting CUPS Filters and announce here the first stable release of this package, versionn 1.0.1. As you mentioned it, there are far bigger changes coming than just adding a new cups filter package (which is still in beta state AFAIK) as that is just smaller fallout from changes explained in below links. http://thread.gmane.org/gmane.linux.printing.fsg/2020 http://cyberelk.net/tim/2012/02/06/cups-1-6-changes-ahead/ Yikes, thanks for the links Florian. The future removal of browsing and requirement of avahi is really unfortunate. So this work will be needed for when we move to CUPS 1.6, which will be after Mageia 2. Here's a good page that details the work we as a distro will need to do: http://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdf_as_standard_print_job_format
Re: [Mageia-dev] check on mga1 may needs some changes
Thomas Spuhler wrote: http://check.mageia.org/1/spuhler/updates_mandriva_2010_2.html Shows that Mandriva has a newer version, 0.97.3. We have the same version in upgrade. Yes, this page is mostly working, but there are still a few issues. See https://bugs.mageia.org/show_bug.cgi?id=3930
[Mageia-dev] Build system broken
For some reason, the build system is trying to install libnss3 into every chroot. I don't know why. It is also trying to install the current version in Cauldron, rather than a known good version. The issue was introduced when nspr was updated to version 4.9, because the package provides version 4.9, but the pkg-config file says 4.9.0 is the version. The breakage happened when updating the nss package, and it has a macro in it that generates the version of libnspr4 it requires from the pkg- config file in nspr. So basically, we have libnspr4-4.9, but libnss3 is requiring libnspr4-4.9.0 and doesn't think it exists. I committed a change in svn for nspr that I believe will fix this, but nspr needs to be able to be rebuilt, so that nss can be rebuilt against it. For anything to be built, the build system needs to either stop trying to install libnss3, or it needs to install the previous version of the package.
Re: [Mageia-dev] OSS sound support
Kamil Rytarowski wrote: On 06.02.2012 11:11, EatDirt wrote: On 10/10/11 11:20, Guillaume Rousse wrote: Just for curiosity, where is OSS support needed nowadays ? Quake and co ? At least for wmix and wmsmixer too :) chris. I have found a walkaroud for this - use psdsp from pulseaudio-utils. If a program needs OSS sound, if it's a graphical program, its menu entry should use soundwrapper before the command. It will use padsp if pulseaudio is active or aoss if it's not.
Re: [Mageia-dev] [packages-commits] [215093] SILENT: Fix install
Luc Menut wrote:
Le 26/02/2012 10:12, r...@mageia.org a écrit :
Revision
215093
Author
dmorgan
Date
2012-02-26 10:12:36 +0100 (Sun, 26 Feb 2012)
[...]
@@ -75,7 +74,7 @@
Requires(post):nss
Requires(post):rpm-helper
Requires: %{mklibname sqlite3_ 0}= %{sqlite3_version}
-Requires: %{nspr_libname}= 2:%{nspr_version}
+Requires: %{nspr_libname}= %{nspr_version}
I think epoch is needed here.
with lib64nss3-3.13.3-3.mga2
rpm -q --requires lib64nss3
nss
rpm-helper
lib64sqlite3_0 = 3.7.10
lib64nspr4 = 4.9
but lib64nspr4-4.9-3.mga2 provides
rpm -q --provides lib64nspr4
nspr = 2:4.9-3.mga2
mozilla-nspr = 2:4.9-3.mga2
...
lib64nspr4 = 2:4.9-3.mga2
lib64nspr4(x86-64) = 2:4.9-3.mga2
Yes, that change looked incorrect to me too. I don't believe anything in nss
was actually wrong/broken. It was just relying on nspr
reporting the correct version through pkg-config, which it was not. It looks
like my fix for that was successful.
Re: [Mageia-dev] Build system broken
David Walser wrote: For some reason, the build system is trying to install libnss3 into every chroot. I don't know why. It is also trying to install the current version in Cauldron, rather than a known good version. The issue was introduced when nspr was updated to version 4.9, because the package provides version 4.9, but the pkg-config file says 4.9.0 is the version. The breakage happened when updating the nss package, and it has a macro in it that generates the version of libnspr4 it requires from the pkg- config file in nspr. So basically, we have libnspr4-4.9, but libnss3 is requiring libnspr4-4.9.0 and doesn't think it exists. I committed a change in svn for nspr that I believe will fix this, but nspr needs to be able to be rebuilt, so that nss can be rebuilt against it. For anything to be built, the build system needs to either stop trying to install libnss3, or it needs to install the previous version of the package. Thank you to D Morgan for fixing it. I apologize for making sure that nss not only built, but also installed correctly before uploading it. This got me to thinking, however, that something like this should not have broken the build system. There's no reason for iurt to be setting up the chroot with packages from Cauldron, unless they are part of the BuildRequires (including recursively) for the package being built. In this situation, once a package needed in the base of the chroot is broken, there is no way to fix it without sysadmin intervention. This would be true for a broken package in Cauldron, or stable/updates_testing. I believe a better way for iurt to work would be this. It would set up the initial chroot from the newest stable release of Mageia that is the same version of Mageia the package is being built for, or older. So right now, that would mean Mageia 1 in all cases. Once Mageia 2 is out, it would mean Mageia 2 for packages being built for 2 or Cauldron, and Mageia 1 for packages being built for 1. Also, when the initial chroot was being installed, release and updates would be enabled only. Then, when it gets to the BuildRequires stage, first enable either updates_testing if it's being built for a stable relase, or Cauldron if it's being built for that, and then install the BuildRequires and build the package.
Re: [Mageia-dev] [packages-commits] [215093] SILENT: Fix install
D.Morgan wrote:
On Sun, Feb 26, 2012 at 1:50 PM, David Walser luigiwal...@yahoo.com wrote:
Luc Menut wrote:
Le 26/02/2012 10:12, r...@mageia.org a écrit :
Revision
215093
Author
dmorgan
Date
2012-02-26 10:12:36 +0100 (Sun, 26 Feb 2012)
[...]
@@ -75,7 +74,7 @@
Requires(post):nss
Requires(post):rpm-helper
Requires: %{mklibname sqlite3_ 0}= %{sqlite3_version}
-Requires: %{nspr_libname}= 2:%{nspr_version}
+Requires: %{nspr_libname}= %{nspr_version}
I think epoch is needed here.
with lib64nss3-3.13.3-3.mga2
rpm -q --requires lib64nss3
nss
rpm-helper
lib64sqlite3_0 = 3.7.10
lib64nspr4 = 4.9
but lib64nspr4-4.9-3.mga2 provides
rpm -q --provides lib64nspr4
nspr = 2:4.9-3.mga2
mozilla-nspr = 2:4.9-3.mga2
...
lib64nspr4 = 2:4.9-3.mga2
lib64nspr4(x86-64) = 2:4.9-3.mga2
Yes, that change looked incorrect to me too. I don't believe anything in
nss was actually wrong/broken. It was just relying on nspr
reporting the correct version through pkg-config, which it was not. It
looks like my fix for that was successful.
no your fix BROKE the BS. so i workarounded here to allow to push and nss.
Please next time before updating core packages, build and install in
your machine or in a chroot.
No it didn't. The update to nspr 4.9 (which I didn't do) caused the breakage,
which was seen as soon as nss was rebuilt (which I did). I
didn't make any functional changes to nss. The fix I put into nspr (after the
BS got broken), did seem to work, as nss rebuilt against it
successfully and was installable again afterward. And yes, I acknowleged that
I should have installed it locally first and apologize.
The pb here that i didn't passed to fix ( and was early in the night
for me ) so i didn't had time to fix.
But this morning if i added the epoch i obtained :
$ rpmbuild -ba SPECS/nss.spec
error: Failed build dependencies:
pkgconfig(nspr) = 2:4.9 is needed by nss-2:3.13.3-3.mga2.i586
But in nspr if i look to the provides i can see:
pkgconfig(nspr) = 4.9 so seems this is wrong here.
Any hint ?
The epoch shouldn't be needed with the pkgconfig Require that you switched to,
since it's provided virtually without an Epoch. The libnspr4
require that Luc commented on should have the Epoch still (although I don't
think removing it technically breaks anything, but it does
basically make it so that the version of the require isn't enforced).
[Mageia-dev] package update request: gif2png
Reason for update: Security update, CVE-2009-5018, filename buffer overflow. Update is in SVN. Package builds, installs, and works fine locally.
[Mageia-dev] lm_sensors update for newer kernels
lm_sensors 3.3.2 just came out last week with this in the ChangeLog [1]: Change sysfs detection to survive upcoming kernel changes I'm not sure if that means kernel 3.3 or newer, but just a heads up (mainly to tmb) that we might need this. [1] - http://www.lm-sensors.org/browser/lm-sensors/tags/V3-3-2/CHANGES
[Mageia-dev] Freeze push: foomatic-filters
Minor foomatic-filters update (4.0.14) contains just one change, should be safe to go in: * foomaticrip.c: If the input data is PDF but the driver requires PostScript, use the pdftops CUPS filter when CUPS is the spooler. This way we always use the same method to convert PDF to PostScript in the whole system, including any workarounds applied in the CUPS filter. Confirmed that it builds and installs fine locally.
[Mageia-dev] Freeze push: libdvdcss
libdvdcss update (1.2.12) contains just one change, which is a regression fix: * fix regression on RPC-I drives handling. If unsure, assume the drive is of RPC-I type This can happen when patched drives do not answer to ioctl_ReportRPC correctly Confirmed it builds and installs fine locally.
[Mageia-dev] printer-applet update for KDE 4.8.1
I'm not sure who is in charge of updating KDE stuff, but could someone check that printer-applet 4.8.1 builds and then get it submitted (I can't at the moment). It's in SVN. Thanks.
Re: [Mageia-dev] [changelog] cauldron core/release java-1.6.0-openjdk-1.6.0.0-24.b24.12.mga2
dmorgan wrote: Name: java-1.6.0-openjdk Relocations: (not relocatable) Version : 1.6.0.0 Vendor: Mageia.Org Release : 24.b24.12.mga2Build Date: Tue Mar 20 22:51:34 2012 Please don't forget that Mandriva updated this in a security update for 2010.2 and changed the first 24 in the Release string to a 26 which makes our package not update theirs, so this needs to be fixed in Mageia 1, and because of that, in Mageia 2 as well. More info is in bugzilla: https://bugs.mageia.org/show_bug.cgi?id=4563
Re: [Mageia-dev] lighttpd and others now require apache
Guillaume Rousse wrote: Le 17/03/2012 03:22, Anssi Hannula a écrit : Hence I suggest a single user id to be used. (I'm fine with any other solution which works as well) My main concern is the fuzziness of the current situation where we have - one virtual package 'webserver' corresponding to four implementations (apache, lightpd, nginx, cherooke) - one common base (webserver-base) only used by the two first ones - all our web applications packages using 'apache' as mandatory dependency If the main concern is file ownership, I'd propose for the next release to have each of these servers use a distinct uid, document root and index page, but use a shared 'webserver' or 'www' gid, and ensure all of those applications use group-based permission, instead of user-based. I'd find this setup a bit clearer. I also noticed two of the php subpackages adding the apache user in %post. Should they be doing this, should they Requires(post): webserver-base, or should this be handled some other way?
Re: [Mageia-dev] lm_sensors update for newer kernels (tmb)
David Walser wrote: lm_sensors 3.3.2 just came out last week with this in the ChangeLog [1]: Change sysfs detection to survive upcoming kernel changes I'm not sure if that means kernel 3.3 or newer, but just a heads up (mainly to tmb) that we might need this. [1] - http://www.lm-sensors.org/browser/lm-sensors/tags/V3-3-2/CHANGES Thomas, you're our kernel guru :o) Did you make a determination about this one?
Re: [Mageia-dev] Freeze push: foomatic-filters
Florian Hubold doktor5000@... writes: Am 20.03.2012 10:36, schrieb David Walser: Minor foomatic-filters update (4.0.14) contains just one change, should be safe to go in: * foomaticrip.c: If the input data is PDF but the driver requires PostScript, use the pdftops CUPS filter when CUPS is the spooler. This way we always use the same method to convert PDF to PostScript in the whole system, including any workarounds applied in the CUPS filter. Confirmed that it builds and installs fine locally. Well, does it also work just fine? Yes. Thanks for asking and sorry I didn't mention it earlier. I tested this at work printing PDFs to a printer configured to use PostScript and it works fine.
[Mageia-dev] New security issues affect libzip and php (freeze push will be needed)
New vulnerabilities CVE-2012-1162 (heap overflow) and CVE-2012-1163 (integer overflow) in libzip, which also affect PHP (probably the php-zip subpackage) were recently announced. libzip 0.10.1 has been released to fix these. I have updated it in SVN and confirmed it builds, but I have not tested it yet. PHP has not yet issued an update for this. References: https://bugs.mageia.org/show_bug.cgi?id=5063 http://seclists.org/oss-sec/2012/q1/710 https://bugzilla.redhat.com/show_bug.cgi?id=802564 https://bugzilla.redhat.com/show_bug.cgi?id=803028
Re: [Mageia-dev] Please push
Maarten Vanraes wrote: Op donderdag 22 maart 2012 05:36:47 schreef Thomas Spuhler: Please push php-apacheaccessor I upgraded it in svn to 0.1.1 in Dec. 2011, but it either didn't build or I forgot to submit it. i'm pretty sure the requirements for freeze pushes are also at least that you must know it builds and works perfectly, on top of that it usually needs to be only bugfixes, or due to client/server changes that it is required... plz add more info to this request There is a bug fix in it, actually. The manual httpd restart has been removed in favor of filetriggers. At this particular time, if these manual restarts are left in, there can be breaking of httpd for people doing live upgrades with urpmi. Please let this one go through.
Re: [Mageia-dev] Freeze push: foomatic-filters
David Walser wrote: Florian Hubold doktor5000@... writes: Am 20.03.2012 10:36, schrieb David Walser: Minor foomatic-filters update (4.0.14) contains just one change, should be safe to go in: * foomaticrip.c: If the input data is PDF but the driver requires PostScript, use the pdftops CUPS filter when CUPS is the spooler. This way we always use the same method to convert PDF to PostScript in the whole system, including any workarounds applied in the CUPS filter. Confirmed that it builds and installs fine locally. Well, does it also work just fine? Yes. Thanks for asking and sorry I didn't mention it earlier. I tested this at work printing PDFs to a printer configured to use PostScript and it works fine. Ping?
Re: [Mageia-dev] MariaDB: problem: final estimated release date
Colin Guthrie wrote: 'Twas brillig, and Maarten Vanraes at 23/03/12 17:39 did gyre and gimble: ( see https://mariadb.atlassian.net/secure/Dashboard.jspa , look at road map ) MariaDB RC 5.5.2229/Mar/12 MariaDB GA 5.5.2309/Apr/12 that means that the GA (final release) is 2 days after release freeze :-( (not counting any possible extra delays) however, i would like to have the final release and not the release candidate. any thoughts on this? Well, sh1t happens... We'll just have to go with the RC and we can always issue an update to the final release afterwards. I don't think this is a huge problem. If there happen to be delays for other reasons we can maybe push it in, but I wouldn't bank on it! Col As a matter of fact, I've noticed lately Mandriva issuing updates to newer versions of mysql for non-security reasons. Apparently they make an exception to the no version updates policy for this package now (obviously they keep the updates within the same stable branch). Perhaps we could too for mariadb. Not saying we definitely should, I don't follow mysql/mariadb development.
Re: [Mageia-dev] mass rebuild for Mga 2 ?
Kamil Rytarowski wrote: On 25.03.2012 17:20, Pascal Terjan wrote: On Sun, Mar 25, 2012 at 15:51, Angelo Naselli anase...@linux.it mailto:anase...@linux.it wrote: In data domenica 25 marzo 2012 14:48:01, Julien ha scritto: Hello, Is there a mass rebuild planned before mageia 2 ? And if not, is there a value in rebuilding a package without update since 1 year ? Can you point us the list? Maybe we can consider if they can go, or have to be rebuild, or removed... That's one third of the packages [schedbot@valstar ~]$ ls /distrib/mirror/distrib/cauldron/SRPMS/core/release/*.mga1.src.rpm | wc -l 3420 [schedbot@valstar ~]$ ls /distrib/mirror/distrib/cauldron/SRPMS/core/release/*.mga2.src.rpm | wc -l 6479 I have got a semi-automated script to do it. It's too late to do a mass rebuilding, of course, but if you have a script that does it, it would be useful if you ran it locally and report which packages now fail to build. Those ones should be fixed.
Re: [Mageia-dev] Freeze push: udisks2
Colin Guthrie wrote: Primary reason for requesting this is a fix for MMC/SD cards. http://cgit.freedesktop.org/udisks/commit/?id=3b277903af128fb632897d8932fe300f216ead38 Misc small fixes also included. This is really a part of the infrastructure needed by GNOME3, so I presume it's covered by the same version freeze escaping policy, but if not, please shout and I'll revert and cherry-pick patches instead. Col Ping?
Re: [Mageia-dev] New security issues affect libzip and php (freeze push will be needed)
Anne Nicolas ennael1@... writes: Le 23/03/2012 01:31, David Walser a écrit : New vulnerabilities CVE-2012-1162 (heap overflow) and CVE-2012-1163 (integer overflow) in libzip, which also affect PHP (probably the php-zip subpackage) were recently announced. libzip 0.10.1 has been released to fix these. I have updated it in SVN and confirmed it builds, but I have not tested it yet. References: https://bugs.mageia.org/show_bug.cgi?id=5063 http://seclists.org/oss-sec/2012/q1/710 https://bugzilla.redhat.com/show_bug.cgi?id=802564 https://bugzilla.redhat.com/show_bug.cgi?id=803028 http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20120323073855.ennael.valstar.7406/log I just tried building it on Cauldron again, and it builds fine. Can you try resubmitting? Maybe it was a transient issue on the build system.
[Mageia-dev] Freeze push: printer-applet
This is part of KDE 4.8.1 and was missed in the update. It builds, installs, and works fine. printer-applet-4.8.1-1.mga2
[Mageia-dev] Freeze push: libmbfl
It was updated for a security update in Mageia 1 but was not updated in Cauldron, so it won't currently be updated when upgrading to Mageia 2. The new version fixes usage with PHP 5.3.9 and newer. I confirmed locally that it builds, installs, and works properly.
Re: [Mageia-dev] Freeze push: printer-applet
David Walser wrote: This is part of KDE 4.8.1 and was missed in the update. It builds, installs, and works fine. printer-applet-4.8.1-1.mga2 To be clear, this is part of mainline KDE (which we're supposed to be updating to 4.8.1 for Mageia 2). It is not some third-party app. It lives here with the rest of KDE: ftp://ftp.kde.org/pub/kde/stable/4.8.1/src/
Re: [Mageia-dev] Freeze push: libmbfl
--- On Wed, 3/28/12, Colin Guthrie mag...@colin.guthr.ie wrote: From: Colin Guthrie mag...@colin.guthr.ie Subject: Re: [Mageia-dev] Freeze push: libmbfl To: Mageia development mailing-list mageia-dev@mageia.org Cc: David Walser luigiwal...@yahoo.com Date: Wednesday, March 28, 2012, 8:46 AM 'Twas brillig, and David Walser at 27/03/12 19:47 did gyre and gimble: It was updated for a security update in Mageia 1 but was not updated in Cauldron, so it won't currently be updated when upgrading to Mageia 2. The new version fixes usage with PHP 5.3.9 and newer. I confirmed locally that it builds, installs, and works properly. It also contains ABI breakage: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/extensions/mbstring.so' - /usr/lib64/php/extensions/mbstring.so: undefined symbol: mbfl_identify_encoding_no in Unknown on line 0 I will try rebuilding PHP, but really this is a broken update! Col You should have seen the state the SVN for it was in, it was a real mess. Rebuilding PHP should be sufficient.
Re: [Mageia-dev] Freeze push: libmbfl
Colin Guthrie mageia@... writes: Rebuilding PHP did not help. We need to revert this ASAP or find a way to fix PHP to be compatible and find out which other packages may be broken as a result. It's quite a mess upstream too. Apparently there was a 1.0.1 version (with a security bug), and then it was fixed in a 1.1.0 version, but the tarball was still called 1.0.1, replacing the old copy upstream. We can't just revert this, because that's not right either, but what we can do is sync it with the version from Mageia 1 updates. This will require sysadmin assistance because of downgrading the version. I'll fix this in SVN when I get back to my apartment, since mgarepo sync interactions with the binrepo don't work through a proxy, so I can't quite do it from work. Sorry for not noticing the breakage, I forgot to install php-mbstring when testing this. We'll get it fixed though :o)
Re: [Mageia-dev] freeze push: wireshark
nicolas vigier boklm@... writes: On Wed, 28 Mar 2012, Guillaume Rousse wrote: 1.6.6 is a bugfix release. Submitted. Should we update this for Mageia 1? Version 1.4.12 fixes the same vulnerabilities. They don't look too serious to me, but who am I to judge?
[Mageia-dev] Old library packages left on system after upgrade
We know that urpme --auto-orphans doesn't remove all orphaned libraries, and there are reasons for that. Manually you generally should be able to get rid of them, and generally urpmi_rpm-find-leaves will show them. There are three I noticed in my upgrade tests that aren't being shown, so they only way I found them was diffing the installed package list against the list of RPMS from my mirror. They are: libxulrunner9.0.1 libhunspell1.2_0 libnotify1 Also not being shown is libvpx0, which is still on the mirror, but has been replaced by libvpx1, so the script should be removing libvpx0 from the tree pretty soon. I'm guessing these don't show in up in find-leaves because of some inter- dependencies between them. Is there anything we can do to fix this? Of course it's also a bit unfortunate to be leaving behind these old libraries that contain security vulnerabilities...
[Mageia-dev] Freeze push: libzip (security update)
New vulnerabilities CVE-2012-1162 (heap overflow) and CVE-2012-1163 (integer overflow) in libzip were recently announced. libzip 0.10.1 has been released to fix these. I have updated it in SVN and confirmed it builds on current Cauldron. I mentioned this earlier and Anne submitted it to the build system, and it built, but one of the make check tests failed. I can't reproduce this, even on a stripped-down VM with no extra -devel packages installed, so I'm thinking it was a transient issue on the build system (as I've seen this happen before). Can we please try submitting it again? References: https://bugs.mageia.org/show_bug.cgi?id=5063 http://seclists.org/oss-sec/2012/q1/710 https://bugzilla.redhat.com/show_bug.cgi?id=802564 https://bugzilla.redhat.com/show_bug.cgi?id=803028
[Mageia-dev] KDE requires creep and other minimal installation issues
I have a server VM that does not have KDE installed, but it has KDM, ark, and konsole installed. IceWM is the default window manager. I've tested upgrading it to Mageia 2, and all kinds of extra KDE stuff gets pulled in in the upgrade, including task-kde4-minimal, leaving a broken KDE as the default window manager. I'm not 100% sure, but I think at least some of the reason all kinds of extra stuff gets pulled in is because Default-kde4-config and mageia-kde4-config-common both have added dependencies on plasma applets (plasma-applet-icontasks and plasma-applet-battery, respectively), which certainly seems wrong. I don't know if this accounts for all of the extra stuff getting pulled in. If I knew for sure, I'd file a bug. Also, as I alluded to, KDE installed with task-kde4-minimal is a bit broken. Some issues include no showdesktop widget being installed, and as soon as you log in, an error message: Warning: Cannot open ConsoleKit session: Unable to open session: Failed to connect to socket /var/run/dbus/system_bus Not sure if this is related, but when you don't have a sound device, Kmix in the system tray has a missing icon. Finally, even on a workstation installation with full KDE, there is some error message that briefly displays at the top of the screen after you log in, but not long enough to read it. It looks like something about power management.
Re: [Mageia-dev] Freeze push: libzip (security update)
David Walser luigiwalser@... writes: New vulnerabilities CVE-2012-1162 (heap overflow) and CVE-2012-1163 (integer overflow) in libzip were recently announced. libzip 0.10.1 has been released to fix these. I have updated it in SVN and confirmed it builds on current Cauldron. I mentioned this earlier and Anne submitted it to the build system, and it built, but one of the make check tests failed. I can't reproduce this, even on a stripped-down VM with no extra -devel packages installed, so I'm thinking it was a transient issue on the build system (as I've seen this happen before). Can we please try submitting it again? References: https://bugs.mageia.org/show_bug.cgi?id=5063 http://seclists.org/oss-sec/2012/q1/710 https://bugzilla.redhat.com/show_bug.cgi?id=802564 https://bugzilla.redhat.com/show_bug.cgi?id=803028 boklm tried submitting this again (thanks for trying), and it failed on fread.test again. As I said, I can't reproduce the problem, and I welcome any help in solving it.
[Mageia-dev] Freeze push: foomatic-filters
foomatic-filters has a minor change to fix a bug reported by an Ubuntu user that was discovered when using a slightly buggy proprietary PPD file for a Canon printer. I've confirmed that it still works, printing through it to a Xerox printer at work (which system-config-printer did a much better job setting up in Cauldron than it does in Mageia 1, nice!).
Re: [Mageia-dev] KDE requires creep and other minimal installation issues
John Balcaen mikala@... writes: What is wrong here ? That's the default config *requires* iconstasks package ? As said earlier currently the default config ( not the vanilla one or netbook) use the iconstasks plasmoid, how are you going to ensure that this plasmoid is installed when using the default configuration and then don't have a broken panel for the default mageia panel ? (i'm not sure ennael will be agree to add yet another package in rpmstrate/bcd config just for that when it could be done in the spec ) If the problem is that the « default » config package are wrongly required that's something else and we need to narrow here the wrong requires. Then why not have the package that contains the panel require it? How about putting the requires into kdebase4-workspace? Again, I'm not 100% sure this is why all the extra stuff got installed on upgrade, so it's just a thought. The bigger problem is now I can't uninstall kdebase4-workspace (which I didn't have installed before the upgrade, and which contains the wmsession file to make KDE the default window manager and a login option, and pulls in most of the remaining dependencies) without it forcing me to uninstall ark, kdebase4-runtime, kdelibs4-core, kdm, and konsole, which I did have installed before the upgrade and would like to keep.
Re: [Mageia-dev] lm_sensors update for newer kernels (tmb)
David Walser wrote: David Walser wrote: lm_sensors 3.3.2 just came out last week with this in the ChangeLog [1]: Change sysfs detection to survive upcoming kernel changes I'm not sure if that means kernel 3.3 or newer, but just a heads up (mainly to tmb) that we might need this. [1] - http://www.lm-sensors.org/browser/lm-sensors/tags/V3-3-2/CHANGES Thomas, you're our kernel guru :o) Did you make a determination about this one? Has anyone seen Thomas Backlund? I tried e-mailing him and he hasn't been on IRC.
Re: [Mageia-dev] Freeze push: libmbfl
Colin Guthrie wrote: Rebuilding PHP did not help. We need to revert this ASAP or find a way to fix PHP to be compatible and find out which other packages may be broken as a result. Col OK, I synced it with the version in Mageia 1 updates, so this is ready to go. I need a sysadmin to push it because of downgrading the version. Now it will be: libmbfl-1.1.0-6.mga2 Sorry again for the mistake.
Re: [Mageia-dev] KDE requires creep and other minimal installation issues
Luc Menut lmenut@... writes: Le 28/03/2012 18:40, David Walser a écrit : [...] I'm not 100% sure, but I think at least some of the reason all kinds of extra stuff gets pulled in is because Default-kde4-config and mageia-kde4-config-common both have added dependencies on plasma applets (plasma-applet-icontasks and plasma-applet-battery, respectively), kdm requires some config files provided by kde4-config-file, that's mean either Default-kde4-config, vanilla-kde4-config or netbook-kde4-config. urpmq --requires kdm kdebase4-runtime kde4-config-file[= 2] [...] urpmq --whatprovides kde4-config-file vanilla-kde4-config|Default-kde4-config|netbook-kde4-config so, you can use vanilla-kde4-config instead of Default-kde4-config, and you will remove the requires on plasma-applet-icontasks and all its dependencies. As previously said by John and Thierry, logs could help a lot to narrow an eventually wrong requires. btw, on a server, perhaps you could replace kdm by a lighter login manager. regards, Luc Thanks Luc. Installing vanilla-kde4-config allows kdebase4-workspace to be removed. So basically ark/konsole/kdm require libkdecore5, which requires kde4-config-file, and the packages that satisfy that dependency require a ton of stuff, especially Default-kde4-config, which requires a lot more than it did in Mageia 1. It shouldn't be terribly difficult to suss this out, just by testing uninstalling the KDE packages and then installing one of the config packages and seeing what it pulls in. If you still think you need anything from me, let me know, but I don't see that you will. Just a note to tv, I did the upgrade with the installer and not urpmi, so I don't have urpmi logs but I do have drakx logs.
Re: [Mageia-dev] Removal of sun java
D.Morgan dmorganec@... writes: Hi, i removed java sun from non free repository as now we are not able to provide it anymore. Should we have openjdk obsolete it so this insecure thing gets removed from users systems who already have it installed?
Re: [Mageia-dev] Removal of sun java
Guillaume Rousse guillomovitch@... writes: If I want to keep a proprietary JRE on my computers, because I trust it more to run crap proprietary applications (also called corporate-compliants), than marvelous free-licensed environment they have never been tested with, that is my choice, not yours. If they really want to keep Sun Java, shouldn't they just download the installer from Sun and install it themselves, rather than using some obsolete Mageia 1 package of it?
Re: [Mageia-dev] Freeze push: libmbfl
Thomas Spuhler wrote: David, can you please look at this again, it will not upgrade the way it is (downgrade) Thomas, it is my understanding that this is how it should work? That is, downgrades should not be handled automatically in Cauldron. In the stable release, you'd increase the epoch. In Cauldron, everyone affected has to handle this manually as there we don't want to increase the epoch (which would eventually trickle down into stable, and we want to avoid using an epoch unless absolutely necessary). Just one of the downsides of running the development version on your machine as I understand it. Remmy Yes, sorry if that wasn't clear. You need to install the libmbfl1-1.1.0-6.mga2 manually. It fixed the libmbfl problem. I still get this warning. Google only shows it for php-5.4 RC # pear list-upgrades PHP Warning: can't find symbol in Unknown on line 0 Do we know where that is coming from? Also, Thomas, I just saw in the changelog of the php update Oden just made in Cooker a message about patching it to use system libzip (from fedora). Since libzip currently has a security vulnerability, can you add this patch if we don't already have it?
Re: [Mageia-dev] lighttpd and others now require apache
Guillaume Rousse wrote: Le 22/03/2012 02:51, David Walser a écrit : Guillaume Rousse wrote: Le 17/03/2012 03:22, Anssi Hannula a écrit : Hence I suggest a single user id to be used. (I'm fine with any other solution which works as well) My main concern is the fuzziness of the current situation where we have - one virtual package 'webserver' corresponding to four implementations (apache, lightpd, nginx, cherooke) - one common base (webserver-base) only used by the two first ones - all our web applications packages using 'apache' as mandatory dependency If the main concern is file ownership, I'd propose for the next release to have each of these servers use a distinct uid, document root and index page, but use a shared 'webserver' or 'www' gid, and ensure all of those applications use group-based permission, instead of user-based. I'd find this setup a bit clearer. I also noticed two of the php subpackages adding the apache user in %post. Should they be doing this, should they Requires(post): webserver-base, or should this be handled some other way? Sure, that's wrong. Either they need apache itself, in this case this dependency is already ensured. Either they can be used without a web server, in this case they shouldn't use apache server anyway. Well a dependency on apache wouldn't be ensured unless they required apache-mod_php, so for now I added Requires(pre): webserver-base and removed their manually adding (and deleting!) of the apache user. One of the packages puts a log file with the httpd logs, so it should probably require apache. I'm not sure the exact semantics of those two (php-fpm and php-session if you're interested). There's another problem, however, since the expat update. Since libexpat.la was removed, php won't rebuild.
Re: [Mageia-dev] lighttpd and others now require apache
David Walser wrote: There's another problem, however, since the expat update. Since libexpat.la was removed, php won't rebuild. Pascal Terjan has fixed this problem.
Re: [Mageia-dev] Release_blocker bugs
Anne nicolas wrote: Security updates = To be closed after RC 5046 bugsq...@mageia.org [Tracker] Security updates for Mageia 2 I could really use some help with Bug 5063 (libzip security update). It sounds serious, but I can't reproduce the make check error on the build system.
Re: [Mageia-dev] painful discussion n°1: debloating
Wolfgang Bornath wrote: 2012/4/7 Sander Lepik sander.le...@eesti.ee: 07.04.2012 19:18, Thomas Spuhler kirjutas: On Saturday, April 07, 2012 08:38:39 AM Guillaume Rousse wrote: To summarize it: - has anyone any opposition to remove the totem-mozilla - KDE relationship in the installer ? I'd go for this. I'm not so sure about that. Are there any other alternatives for that? Firefox may be gtk app but most people still use it under KDE too. If you remove those plugins then i would say usability will be hit. totem-mozilla does not seem to be a dependency for Firefox. I'm using Firefox but totem-mozilla is one of those packages I unmark everytime in individual package selection without any regression for Firefox. I was under the impression talking to ennael on IRC a few weeks ago that this was already going to happen. totem is not needed and is the first thing I uninstall on new installations as well. If you need FF plugins, gecko-mediaplayer should have you covered. If you need a video player, kmplayer, dragon player, or VLC do the job (I'm not sure which was decided to use by default in KDE Mageia, that's where the discussion with ennael left off).
Re: [Mageia-dev] Release_blocker bugs
Pascal Terjan wrote: On Sun, Apr 8, 2012 at 15:57, David Walser luigiwal...@yahoo.com wrote: Anne nicolas wrote: Security updates = To be closed after RC 5046 bugsq...@mageia.org [Tracker] Security updates for Mageia 2 I could really use some help with Bug 5063 (libzip security update). It sounds serious, but I can't reproduce the make check error on the build system. I submitted it and it succeeded Just in case it wasn't clear to anyone else, the one in Cauldron is the one with the problem. It builds, but fails in make check.
Re: [Mageia-dev] painful discussion n°1: debloating
Pierre Jarillon wrote: Le dimanche 8 avril 2012 21:02:48, Anne Nicolas a écrit : totem was proposed in Mandriva as there was no stable enough video player in KDE. Then we had Codeina managing codecs using only gstreamer. That's all. :) Totem don't work out the the box. I have a set of videos with different formats. With totem, few of them work without a lot a install (sometimes conflicting). Dragon is not better out the box. Only VLC works with all my samples. To make the best distro, working in any case, VLC succeeds, Totem sucks... Totem has never quite worked for me either. I have KMPlayer set as the default on my Dad's machine, and that works well. VLC does as well.
[Mageia-dev] Freeze push: taglib
taglib 1.7.1 is a bugfix release that fixes three CVEs: CVE-2012-1107 - https://bugzilla.redhat.com/show_bug.cgi?id=800553 CVE-2012-1108 - https://bugzilla.redhat.com/show_bug.cgi?id=800559 CVE-2012-1584 - https://bugzilla.redhat.com/show_bug.cgi?id=810009 Confirmed that it builds, installs, and works locally.
[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.
[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
[Mageia-dev] Change in libx11 broke xscreensaver
This is explained in Bug 4742:
https://bugs.mageia.org/show_bug.cgi?id=4742
But to summarize, xscreensaver-demo in Cauldron does not work, it comes up with
an empty list of screensavers. This list comes from reading the programs
entry of the /etc/X11/app-defaults/XScreenSaver file, which is read using the
XrmGetResource API of libX11.
XrmGetResource calls XrmQGetResource (in src/Xrm.c) which starts by doing:
if (db db-linfo.lock *names) {
and if that is false, it refuses to even try to read the entry from the
app-defaults file. I ran xscreensaver-demo in gdb, and db-linfo.lock is 0, so
this doesn't work. In Mageia 1, XrmQGetResource starts with:
if (db *names) {
and although db-linfo.lock is still 0, it doesn't matter and it works.
Can we patch our libx11 to go back to the old way, or is there a better way to
fix this? I don't have a deep understanding of the meaning of this code.
Maybe Thierry or someone else does?
Re: [Mageia-dev] minor systemd-related issues
Colin Guthrie mageia@... writes: 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 at 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? I am sure. The only symlink in /etc/systemd/system is default.target, everything else there is directories. Is that the right place to put that symlink anyway? I hadn't thought of the possibility that systemd not being installed is the problem, but I guess that's the only logical explanation (unless systemd somehow swept that directory and deleted it for some reason). I guess maybe the mpm packages just need Requires(pre): systemd-units
Re: [Mageia-dev] minor systemd-related issues
Colin Guthrie mageia@... writes: Thinking about it, I reckon rpm-helper especially should be something that is always installed first on a big upgrade. There could be multiple files running e.g. %_post_service etc. in their post scripts but we certainly want the latest rpm-helper for that. Yes, if rpm-helper Requires systemd-units, that should take care of it.
Re: [Mageia-dev] mysql CVE's in mga1 = have it update to mariadb
AL13N alien@... writes: 5. someone has a better idea? considering the response i got, now i'll default to letting someone else handle it, which might mean it never gets fixed. that would also mean for me that mageia1 would be a bad version to get LTS on. The objections to this have been quite unwarranted. It sounds like some people want to institute a new policy that MySQL security bugs won't be fixed. Upgrading to newer versions of things isn't ideal, but sometimes it's what has to be done, because there's no other way, and we already do it sometimes in other cases. There's no reason this should be any more controversial. In researching this, it appears that for the security bugs in MySQL (and there are many, at least one of which is remotely exploitable without authentication), only the Oracle MySQL developers really know what the vulnerabilities are and how they were fixed, and they're not telling. The most recent MySQL changelog that referenced security vulnerabilities had no details, and just mentioned two bug numbers. One of those bug numbers doesn't exist. The other is not publicly viewable. At this point, upgrading is the only solution to these security problems, and other distros have already realized this and updated to one of the newest releases. Here are some examples. RHEL6: https://rhn.redhat.com/errata/RHSA-2012-0105.html https://rhn.redhat.com/errata/RHSA-2011-0164.html Fedora 15: https://admin.fedoraproject.org/updates/FEDORA-2012-0987/mysql-5.5.20-1.fc15 Fedora 16: https://admin.fedoraproject.org/updates/FEDORA-2012-0972/mysql-5.5.20-1.fc16 Mandriva Enterprise Server 5, Mandriva 2011, Mandriva 2010.2: http://www.mandriva.com/en/support/security/advisories/?name=MDVA-2012:031 Mandriva 2010.0, Mandriva 2010.1: http://www.mandriva.com/en/support/security/advisories/?name=MDVSA-2011:012 For us, upgrading to MariaDB instead of MySQL 5.5.22 isn't any different than what those other distros have done. MariaDB is as much a newer version of what we have now as MySQL 5.5.22 is. They are both derived from the same code base. Furthermore, the other distros have been able to upgrade it apparently without even having to rebuild anything else, so the potential for damage seems to not be so great after all. Finally, someone made a comment about our reputation in this thread. If we just ignore this and don't issue any security updates because it's too hard or too scary, that will hurt our reputation more than anything else.
[Mageia-dev] Freeze push: egroupware
Fixes XSS security flaw. See https://bugs.mageia.org/show_bug.cgi?id=5384
Re: [Mageia-dev] Change in libx11 broke xscreensaver
David Walser luigiwalser@... writes: Can we patch our libx11 to go back to the old way, or is there a better way to fix this? I don't have a deep understanding of the meaning of this code. Turns out the broken line I pointed out was from our own patch. This has now been fixed by rtp. Thanks.
Re: [Mageia-dev] Mageia 2 security updates: help needed with Java and Tomcat
Can anyone help with these? One of the tomcat6 packages is installed on almost every system as it's required by LibreOffice. David Walser wrote: 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: openjpeg 1.5.0
Funda Wang wrote: 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. Funda, does a patch exist for this? Mageia 1 should be vulnerable to this.
[Mageia-dev] Freeze push: rsyslog
Just contains 3 bugfixes, 2 for segfaults, and the other for a memory leak. I also fixed a missing BuildRequires in the package. Confirmed it builds, installs, and works locally.
[Mageia-dev] Freeze push: mpg123
The only change is fixes for the ARM architecture (so it won't hurt anything). Confirmed it builds, installs, and works locally.
[Mageia-dev] Freeze push: timezone
We usually try to keep this up to date. Updated in SVN to 2012c.
[Mageia-dev] Freeze push: rsvndump
This package was imported right before the freeze, but some more bugs have been fixed upstream. I'd like to have this up to date just in case we need to use it later (like copying a certain other distro's SVN before it possibly goes away). Confirmed it builds and installs locally.
[Mageia-dev] Freeze push: audacious, audacious-plugins
This one looks like minor bugfixes and translation updates. Confirmed they build, install, and work locally.
[Mageia-dev] Freeze push: dhcpcd
Several bugs were fixed upstream. Confirmed it builds, installs, and works locally.
[Mageia-dev] New artwork glitches
I love the new artwork, but I noticed a few minor issues. Not sure what to assign it to on Bugzilla, so I'll mention them here. The image during boot/shutdown has a cauldron in the middle, but it's squeezed horizontally, it's not wide enough. Its aspect ratio is off. When you start Mageia Control Center, there's a Mageia logo in the background that's a bit too far up, and it bleeds under the text just a little bit. The Mageia logo on the desktop background in the bottom right isn't in the same position it was before, it's a little further up and left. I had Plasma widgets placed so as not to cover it before, and now it's partially obscured. It'd be nice if the logo wouldn't move around.
