Re: [Mageia-dev] Proposal for Gstreamer 1.0 packaging: tainted version should require the tainted specific plugins
On Tue, Jan 29, 2013 at 12:18:25AM +0100, Manuel Hiebel wrote: It should not be automatically with packagekit ? Does not seem to work reliably at all. Sometimes it can only detect the plugin it needs after you installed it. I've noticed it installing the video codec and forgetting about the audio. -- Regards, Olav
Re: [Mageia-dev] Proposal for Gstreamer 1.0 packaging: tainted version should require the tainted specific plugins
On Mon, Jan 28, 2013 at 06:30:51PM -0500, Charles A Edwards wrote: On Mon, 28 Jan 2013 22:57:14 +0100 Olav Vitters wrote: I think #2 is the best option. If someone enables tainted, then likely they just want video playing to work. Furthermore, this avoids changing all the video players which could use GStreamer. No, it should be 1 done as both tainted and Core just as is done with mplayer, xine, vlc, gstreamer-plugins-bad and others apps. But Totem is not something which is tainted. The software is all ok. -- Regards, Olav
Re: [Mageia-dev] Latest update borked my x server
Wolfgang Bornath skrev 29.1.2013 10:26: Installed MGA3 Beta2 including proprietary nvidia driver, working nicely. After doing updates including kernel 3.8.0-desktop-0.rc5.1.mga3 the startup process stopped and showed a message that a display driver module is loaded which conflicts with the current setup (translation from German) and so x server may not start correctly. And so it was: after Started LSB: Nameserver information manager the start process hangs. Switching to VT2 and logging in, giviong the command 'startx' fails: modprobe: ERROR: could not insert 'nvidia_current': No such device modprobe: ERROR: Error running install command for nvidia modprobe: ERROR: could not insert 'nvidia'; Operation not permitted (EE) Server termibnated with error (1) xinit: giving up xinit: unable to connect to X server: Connection refused xinit: server error That's it. Seems nouveau blacklisting is being ignored :/ So it blocks the nvidia driver from loading properly https://bugs.mageia.org/show_bug.cgi?id=8863 -- Thomas
Re: [Mageia-dev] Proposal for Gstreamer 1.0 packaging: tainted version should require the tainted specific plugins
On Tue, Jan 29, 2013 at 12:27:26AM +0100, Christiaan Welvaart wrote: Have you noticed gstreamer0.10-decoders and gstreamer0.10-decoders-audio ? Those can do the same as your point 2. but for all plugins independent of the source packages. So basically task- packages for gstreamer plugins that totem, other players and transcoders/editors can use. Never noticed them! So unfortunate, think this should always have been a Totem Requires (but then for GStreamer 1.0). That way you get meta packages for demuxers, muxers, audio-decoders, audio-encoders, video-decoders, and video-encoders which depend on the standard/typical plugins. So it is ok if I make a 1.0 version out of this, as well as making a tainted version as well? -- Regards, Olav
Re: [Mageia-dev] [council] *ping* Media query: secure boot support
On Sun, Jan 27, 2013 at 01:43:25PM +0100, Marja van Waes wrote: From: Sam Vargheses...@gnubies.com [..] I would like to know what Mageia plans to do about secure boot - when you will have a release that supports booting on hardware on which this feature is enabled. I'm wondering as well. I've been thinking to upgrade my system somewhere this year. This means secure boot, UEFI, etc. It would be nice if Mageia supports that nicely. e.g. I see a whole thread about Grub 1.x. But I think it is more important if you can still install Mageia on a new computer. -- Regards, Olav
Re: [Mageia-dev] [council] *ping* Media query: secure boot support
Olav Vitters skrev 29.1.2013 10:43: On Sun, Jan 27, 2013 at 01:43:25PM +0100, Marja van Waes wrote: From: Sam Vargheses...@gnubies.com [..] I would like to know what Mageia plans to do about secure boot - when you will have a release that supports booting on hardware on which this feature is enabled. I'm wondering as well. I've been thinking to upgrade my system somewhere this year. This means secure boot, UEFI, etc. It would be nice if Mageia supports that nicely. Supporting (U)EFI does not require SecureBoot support... we wont support SecureBoot for Mga3, and there is no rush considering a lot of changes is still happening on several fronts... I will try to see if I can fix the UEFI part for ~beta3, but no promises yet And for people thinking of Windows 8 dual boot... Win8 does not _require_ SecureBoot either... (only the overprized RT does) And personally, I dont think we should ever bother with the SecureBoot crap as its flawed in so many ways... -- Thomas
Re: [Mageia-dev] Latest update borked my x server
2013/1/29 Thomas Backlund t...@mageia.org: Wolfgang Bornath skrev 29.1.2013 10:26: Installed MGA3 Beta2 including proprietary nvidia driver, working nicely. After doing updates including kernel 3.8.0-desktop-0.rc5.1.mga3 the startup process stopped and showed a message that a display driver module is loaded which conflicts with the current setup (translation from German) and so x server may not start correctly. And so it was: after Started LSB: Nameserver information manager the start process hangs. Switching to VT2 and logging in, giviong the command 'startx' fails: modprobe: ERROR: could not insert 'nvidia_current': No such device modprobe: ERROR: Error running install command for nvidia modprobe: ERROR: could not insert 'nvidia'; Operation not permitted (EE) Server termibnated with error (1) xinit: giving up xinit: unable to connect to X server: Connection refused xinit: server error That's it. Seems nouveau blacklisting is being ignored :/ So it blocks the nvidia driver from loading properly https://bugs.mageia.org/show_bug.cgi?id=8863 Yes, bug report describes exactly what's happening here (in better English). I added 64-bit platform. -- wobo
Re: [Mageia-dev] Cleaning up init
'Twas brillig, and JA Magallón at 29/01/13 00:03 did gyre and gimble: Hi... After a test with symlinks -r, I discovered I had /etc/rc.d full of dangling symlinks, due to services moved to systemd. Should an update of initscripts clean them (symlinks -rd /etd/rc.d) ? I suppose this will also happen when people updates mga2 to mga3... I also discovered what seem like leftovers from previous conversions in /etc/rc.d/init.d: - dm (native prefdm exists) - irqbalance (package includes both, native and sysv) - linux_logo (same, native+sysv) - lm_sensors (idem) - mpd (idem) - mysqld (idem) - portreserve (idem) - netconsole (package is not even in the repos) - partmon (idem) Are we in time to correct these for Mageia 3 ? And to switch the remins to systemd, like resolvconf or postfix ? The fact that both exist is a minor annoyance at the moment I think. Would certainly be nice to remove them if the maintainers have the time/inclination, but it shouldn't affect the system. As for the dangling symlinks, yeah we should really fix that. I guess a generic file trigger would maybe work? You have to be somewhat careful as the symlinks can sometimes be broken when on a chroot (although 99% of the time, they are all relative). 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] [council] *ping* Media query: secure boot support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 29.01.2013 11:11, Thomas Backlund kirjutas: And for people thinking of Windows 8 dual boot... Win8 does not _require_ SecureBoot either... (only the overprized RT does) And personally, I dont think we should ever bother with the SecureBoot crap as its flawed in so many ways... Well, the problem with SecureBoot is in the systems that are sold with W8 sticker on them. AFAIK, if manufacturer wants to have windows hardware sertification it has to enable secure boot by default. And I'm not sure how many systems allow to disable it or how easy it will be for normal user. - -- Sander -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRB5XNAAoJECMkkFJIyHr8D64H/AqdTMOOdd/xbjgHUESDLsDo GAmg86vQL/7c845uE7LYzteDxCbaBJDaI+Xpirn0RARdKL7jvRcrhAYJSB6V3EI5 i0gfkFlz4u5j0YD+NAyTz9RBxijp2St4Tvaw1nND3BQmKGcV+kUmNwCZj/Fg9w5Z RSfJzV+0qHk5Bw/tWyzH703vaUbqbBSgdu/pl86Bg9kf0yhCe8dnINFkIfv0Nx19 JmaJ7dpdplYdgEFRhNaMzpIa5g6Xy+w95S1xGAnrH5A6P30DKUT7C0BUbS1wl/i7 veiqBXFtRFQCErga7cFHaK1b/9ZWmtHZE3edp8LRBUsDacNOhsd3j7kVPxC8qdw= =FaR/ -END PGP SIGNATURE-
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
On 29/01/13 00:26, Felix Miata wrote: Does M2 have current Grub2 in backports, or would it be simple enough to install from Cauldron repos? If so, maybe if needed and pressed I could find time to try installing Grub2 to its PBR. I'm not of a mind to replace M2 there yet, and it doesn't have space for a new installation of anything until I figure out what if anything I want to do about its crowded HD. I keep my own backports of stuff that I am interested in, so I have just re-built the current grub2 packages against the current Mageia2 repos for you, you will find them here: http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/2/i586/grub2-2.00-16.mga2.i586.rpm http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/2/x86_64/grub2-2.00-16.mga2.x86_64.rpm I did try to address your question to the lead grub2 dev last night on irc, but he decided to go to bed at that point and suggested that I email it instead ;) Maybe you would like to mail him directly, as you understand the issue better than I do. He is Vladimir Serbinenko: mailto:phcoder!~phco...@60-124.62-81.cust.bluewin.ch Barry
Re: [Mageia-dev] [council] *ping* Media query: secure boot support
'Twas brillig, and Thomas Backlund at 29/01/13 09:11 did gyre and gimble: Olav Vitters skrev 29.1.2013 10:43: On Sun, Jan 27, 2013 at 01:43:25PM +0100, Marja van Waes wrote: From: Sam Vargheses...@gnubies.com [..] I would like to know what Mageia plans to do about secure boot - when you will have a release that supports booting on hardware on which this feature is enabled. I'm wondering as well. I've been thinking to upgrade my system somewhere this year. This means secure boot, UEFI, etc. It would be nice if Mageia supports that nicely. Supporting (U)EFI does not require SecureBoot support... we wont support SecureBoot for Mga3, and there is no rush considering a lot of changes is still happening on several fronts... I will try to see if I can fix the UEFI part for ~beta3, but no promises yet And for people thinking of Windows 8 dual boot... Win8 does not _require_ SecureBoot either... (only the overprized RT does) And personally, I dont think we should ever bother with the SecureBoot crap as its flawed in so many ways... On a semi-related note, it would be nice to package gummiboot although I have no h/w to test it on. For mga4 it might make sense to integrate it (assuming it's still a good solution) properly into our tools. Personally, I'm going to avoid grub2. It seems insane to me to implement all kinds of exotic filesystem supoort and even md stuff in a bootloader... 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] [council] *ping* Media query: secure boot support
2013/1/29 Sander Lepik sander.le...@eesti.ee: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 29.01.2013 11:11, Thomas Backlund kirjutas: And for people thinking of Windows 8 dual boot... Win8 does not _require_ SecureBoot either... (only the overprized RT does) And personally, I dont think we should ever bother with the SecureBoot crap as its flawed in so many ways... Well, the problem with SecureBoot is in the systems that are sold with W8 sticker on them. AFAIK, if manufacturer wants to have windows hardware sertification it has to enable secure boot by default. And I'm not sure how many systems allow to disable it or how easy it will be for normal user. As for now Microsoft requires all W8 certified systems with secure boot to allow secure boot to be switched off by user/sysadmin. One reason why I do not understand the reason why all these people (Garret et all) are stumbling all over themselves to solve a problem which is not even sure to ever come by. IMHO Mageia is good to send out the signal that Mageia will face that issue when it's due time. -- wobo
Re: [Mageia-dev] Mageia 3 observations
Hi Olav, I downloaded the beta1 64-bit dvd image, dd'ed it successfully to a 4G USB stick and installed from there. Reinout 2013/1/28 Olav Vitters o...@vitters.nl On Mon, Jan 28, 2013 at 11:09:32PM +0100, Reinout van Schouwen wrote: Size restrictions? I doubt it, I have 26G free on /. Note that I did a clean install so there must be something else that went wrong. I meant size restrictions on whatever you downloaded, the DVD or maybe the USB version. Did you install the package from the DVD / USB stick, or install it via internet? Please also give a link to what you downloaded so I can take a look at the packages are on there. -- Regards, Olav -- Reinout van Schouwen http://vanschouwen.info/
Re: [Mageia-dev] [council] *ping* Media query: secure boot support
Le 29/01/2013 10:37, Wolfgang Bornath a écrit : As for now Microsoft requires all W8 certified systems with secure boot to allow secure boot to be switched off by user/sysadmin. One reason why I do not understand the reason why all these people (Garret et all) are stumbling all over themselves to solve a problem which is not even sure to ever come by. I guess that's because secure boot may be considered useful, if you're in control of it, of course. And because something working out of the box is probably better when targetting non-experts. -- BOFH excuse #37: heavy gravity fluctuation, move computer to floor rapidly
[Mageia-dev] FOSDEM - friday evening
Hi there, I will arrive in Buxelles on Friday evening. So anyone of you would like to have some beer and pizza with me, just tell me... Oliver
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
On 2013-01-29 09:29 (GMT) Barry Jackson composed: Felix Miata wrote: Does M2 have current Grub2 in backports, or would it be simple enough to install from Cauldron repos? If so, maybe if needed and pressed I could find time to try installing Grub2 to its PBR. I'm not of a mind to replace M2 there yet, and it doesn't have space for a new installation of anything until I figure out what if anything I want to do about its crowded HD. I keep my own backports of stuff that I am interested in, so I have just re-built the current grub2 packages against the current Mageia2 repos for you, you will find them here: http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/2/i586/grub2-2.00-16.mga2.i586.rpm http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/2/x86_64/grub2-2.00-16.mga2.x86_64.rpm I did try to address your question to the lead grub2 dev last night on irc, but he decided to go to bed at that point and suggested that I email it instead ;) Maybe you would like to mail him directly, as you understand the issue better than I do. He is Vladimir Serbinenko: mailto:phcoder!~phco...@60-124.62-81.cust.bluewin.ch I just reread all my posts in this thread having this same exact subject line as this, and see no question I posed other than the one you just answered, so I don't know what you think I ought to ask him. Note that I have a grub-de...@gnu.org subscription, so if you were to pose the question there I would automatically get a copy and be able to follow any ensuing dialog. Since my last post, I learned that the M2 on host t2240 I was referring to possibly installing Grub2 on is actually only reporting as M2, as its urpmi.cfg is pointing to Cauldron. So, I suppose I could just go ahead and install from Cauldron if and when time permits - after deciding whether to keep it as is WRT installed packages, switch repos to M2, or update it to Cauldron (or M3 if it's been forked already). -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: [Mageia-dev] [council] *ping* Media query: secure boot support
On Tue, Jan 29, 2013 at 10:02 AM, Guillaume Rousse guillomovi...@gmail.com wrote: Le 29/01/2013 10:37, Wolfgang Bornath a écrit : As for now Microsoft requires all W8 certified systems with secure boot to allow secure boot to be switched off by user/sysadmin. One reason why I do not understand the reason why all these people (Garret et all) are stumbling all over themselves to solve a problem which is not even sure to ever come by. I guess that's because secure boot may be considered useful, if you're in control of it, of course. And because something working out of the box is probably better when targetting non-experts. Yes I think the main problem is that for probably 10 years it had became easy for someone non technical to test/install linux, now they would need to change setup in the bios and would probably give up (or be scared).
Re: [Mageia-dev] Cleaning up init
'Twas brillig, and JA Magallón at 29/01/13 00:03 did gyre and gimble:
After a test with symlinks -r, I discovered I had /etc/rc.d full of
dangling symlinks, due to services moved to systemd.
Should an update of initscripts clean them (symlinks -rd /etd/rc.d) ?
I suppose this will also happen when people updates mga2 to mga3...
I've added a filetrigger to initscripts package to clean up the dangling
symlinks.
I didn't use the symlinks tool as it's not a required package.
find /etc/rc.d/rc{0,1,2,3,4,5,6,7}.d -type l -exec sh -c 'if [ ! -e {}
]; then rm -f {}; fi' \;
This does much the same job, but find is already used in multiple
places so probably a better solution even if the command is more convoluted!
If anyone spots any issues with this, please shout.
It'll be in the next initscripts package and it cleaned up all the
dangling symlinks in /etc/rc.d for me.
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] Cleaning up init
Le 29/01/2013 11:19, Colin Guthrie a écrit :
I've added a filetrigger to initscripts package to clean up the dangling
symlinks.
I didn't use the symlinks tool as it's not a required package.
find /etc/rc.d/rc{0,1,2,3,4,5,6,7}.d -type l -exec sh -c 'if [ ! -e {}
]; then rm -f {}; fi' \;
This does much the same job, but find is already used in multiple
places so probably a better solution even if the command is more convoluted!
If anyone spots any issues with this, please shout.
It'll be in the next initscripts package and it cleaned up all the
dangling symlinks in /etc/rc.d for me.
I'd rather modify the del-service rpm helper to remove the link when the
init script is removed.
--
BOFH excuse #54:
Evil dogs hypnotised the night shift
Re: [Mageia-dev] Packagers meeting
Hi there We will have our weekly meeting tomorrow, 20h UTC: - quick beta 2 review - release critical bugs review (this one should take most of our time) As usual feel free to propose a topic. QA and bug triage team, could you please be around? if possible, i would like to have some kind of status (planning) of bug 2317: - iinm it was decided to fix (was there a timeframe set?) - is there something anyone can help with, do we commit some patches? - or is it now only on tv to actually have the time to do the work? (preferably in the beginning of the meeting)
Re: [Mageia-dev] [council] *ping* Media query: secure boot support
On Tue, Jan 29, 2013 at 10:02 AM, Guillaume Rousse guillomovi...@gmail.com wrote: Le 29/01/2013 10:37, Wolfgang Bornath a écrit : As for now Microsoft requires all W8 certified systems with secure boot to allow secure boot to be switched off by user/sysadmin. One reason why I do not understand the reason why all these people (Garret et all) are stumbling all over themselves to solve a problem which is not even sure to ever come by. I guess that's because secure boot may be considered useful, if you're in control of it, of course. And because something working out of the box is probably better when targetting non-experts. Yes I think the main problem is that for probably 10 years it had became easy for someone non technical to test/install linux, now they would need to change setup in the bios and would probably give up (or be scared). no 100% sure, but some time ago, i remember someone looking into this with motherboard/PC manufacturers and it seemed like most manufacturers weren't even planning on having secure boot / let alone enable it by default. I suspect that most PC manufacturers are putting the win8 sticker on it regardless of it using secure boot. and i think that most win8 preinstalled PCs won't even be able to use secure boot. in other words... is this REALLY gonna be an issue? (except for ARM platforms)? i'm not 100% sure on this, but i'm not really that worried atm...
Re: [Mageia-dev] FOSDEM - friday evening
Hi there, I will arrive in Buxelles on Friday evening. So anyone of you would like to have some beer and pizza with me, just tell me... Oliver well, i'm picking up sebsebseb and coling at the airport, so i think us three are up for that... :-) at what time are you arriving?
Re: [Mageia-dev] [council] *ping* Media query: secure boot support
On Tue, Jan 29, 2013 at 11:11:55AM +0200, Thomas Backlund wrote: Olav Vitters skrev 29.1.2013 10:43: On Sun, Jan 27, 2013 at 01:43:25PM +0100, Marja van Waes wrote: From: Sam Vargheses...@gnubies.com [..] I would like to know what Mageia plans to do about secure boot - when you will have a release that supports booting on hardware on which this feature is enabled. I'm wondering as well. I've been thinking to upgrade my system somewhere this year. This means secure boot, UEFI, etc. It would be nice if Mageia supports that nicely. Supporting (U)EFI does not require SecureBoot support... Technically no, but I am not sure how what options there will be on the motherboard. I've been trying to read up on it, but though you should be able to only disable SecureBoot, it seems it sometimes also disables more. My current motherboard is from Gigabyte. Probably will buy from this company again as I don't have any issues with it. PSU wise it is another story though :P (but don't think I need to replace the PSU) And personally, I dont think we should ever bother with the SecureBoot crap as its flawed in so many ways... I quite like SecureBoot. This way you can avoid attacks on the boot sector. -- Regards, Olav
Re: [Mageia-dev] Freeze push: fetchyahoo-2.14.9
On Mon, 28 Jan 2013, Sandro CAZZANIGA wrote: Le 28/01/2013 09:59, Sandro CAZZANIGA a écrit : Le 27/01/2013 22:40, Sandro CAZZANIGA a écrit : Hi, Can someone push fetchyahoo? It fixes #8374: https://bugs.mageia.org/show_bug.cgi?id=8374 Thanks :) ping? thanks :) ping #2 ? Submitted by guillomovitch yesterday.
Re: [Mageia-dev] Freeze push: fetchyahoo-2.14.9
Le 29/01/2013 12:16, nicolas vigier a écrit : On Mon, 28 Jan 2013, Sandro CAZZANIGA wrote: Le 28/01/2013 09:59, Sandro CAZZANIGA a écrit : Le 27/01/2013 22:40, Sandro CAZZANIGA a écrit : Hi, Can someone push fetchyahoo? It fixes #8374: https://bugs.mageia.org/show_bug.cgi?id=8374 Thanks :) ping? thanks :) ping #2 ? Submitted by guillomovitch yesterday. Yep I've seen, thanks for your feedback :) signature.asc Description: OpenPGP digital signature
Re: [Mageia-dev] Freeze push : weboob
Le 28/01/2013 22:01, zezinho a écrit : Please push weboob which as a tool that follows websites versions must be often updated : - added a requires for python-cssselect which is needed by some modules - new version 0.e is required by at least the arte module : Unable to load module arte: Module requires Weboob 0.e, but you use Weboob 0.c Submitted. -- BOFH excuse #276: U.S. Postal Service
Re: [Mageia-dev] Freeze push: gtksourceview 3.6.3
On Sun, 27 Jan 2013, Olav Vitters wrote: Bugfix release. Submitted.
Re: [Mageia-dev] [council] *ping* Media query: secure boot support
Olav Vitters skrev 29.1.2013 13:12: On Tue, Jan 29, 2013 at 11:11:55AM +0200, Thomas Backlund wrote: And personally, I dont think we should ever bother with the SecureBoot crap as its flawed in so many ways... I quite like SecureBoot. This way you can avoid attacks on the boot sector. Yeah, and when MS screws up with one of the master keys (or some hw wendor) think about the dual-booters Microsft pushes revocation key through windowsupdate, and you suddenly find out your linux wont boot anymore, beacuse the signature that is supposed to validate your boot has been revoked... Or a local dos: just add a single byte to the end of some of the signed files/images and the signature checks fail, ending up with non-bootable system you dont even need to exploit it further Or MS alters license rules around key signing, so when your key expires, guess what... and ms wont be in a hurry to fix it look at the time it has taken so far for linux foundation to try and get proper signatre key or... There is so many fun ways to screw up this security illusion, that it should be buried forgotten already... this secure boot pushed by ms is also in reality a ms-restricted boot... -- Thomas
Re: [Mageia-dev] Cleaning up init
'Twas brillig, and Guillaume Rousse at 29/01/13 10:40 did gyre and gimble:
Le 29/01/2013 11:19, Colin Guthrie a écrit :
I've added a filetrigger to initscripts package to clean up the dangling
symlinks.
I didn't use the symlinks tool as it's not a required package.
find /etc/rc.d/rc{0,1,2,3,4,5,6,7}.d -type l -exec sh -c 'if [ ! -e {}
]; then rm -f {}; fi' \;
This does much the same job, but find is already used in multiple
places so probably a better solution even if the command is more
convoluted!
If anyone spots any issues with this, please shout.
It'll be in the next initscripts package and it cleaned up all the
dangling symlinks in /etc/rc.d for me.
I'd rather modify the del-service rpm helper to remove the link when the
init script is removed.
That would mean a very laborious version bump of the required rpm-helper
version in lots and lots of packages, again like was done last time.
While I agree that, in theory, it may be a nicer approach, I'm not
personally willing to do the donkey work it would entail in order to get
a smooth upgrade.
If someone wants to undertake this, this, then I'd recommend using a
macro for the version of rpm-helper that's needed which would at least
make doing the same task next time a lot easier (actually I suspect that
the rpm-helper service stuff will be cleaned up a lot for mga4, so it'll
likely be needed at some point anyway - but hopefully before beta stages!!)
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] Freeze Push: bootsplash
On Sun, 27 Jan 2013, David Walser wrote: Colin Guthrie wrote: 'Twas brillig, and David Walser at 27/01/13 20:26 did gyre and gimble: Colin Guthrie wrote: This is one of our packages thus semi-exempt from freeze rules. But either way it fixes a potential security issue. Care to elaborate? Mageia 2 also has 3.3.9. I already sent a mail to security@ (as per https://wiki.mageia.org/en/Packagers_Security_Team) to discuss it initially. I've updated the mga2 package in preparation already, but just wanted to discuss the process (i.e. order of certain actions) first. Does anyone get the mails sent to that list? I updated the mga-security ldap group to put you and Oden. You should now receive emails sent to secur...@group.mageia.org.
Re: [Mageia-dev] [council] *ping* Media query: secure boot support
Colin Guthrie skrev 29.1.2013 11:30: 'Twas brillig, and Thomas Backlund at 29/01/13 09:11 did gyre and gimble: Olav Vitters skrev 29.1.2013 10:43: On Sun, Jan 27, 2013 at 01:43:25PM +0100, Marja van Waes wrote: From: Sam Vargheses...@gnubies.com [..] I would like to know what Mageia plans to do about secure boot - when you will have a release that supports booting on hardware on which this feature is enabled. I'm wondering as well. I've been thinking to upgrade my system somewhere this year. This means secure boot, UEFI, etc. It would be nice if Mageia supports that nicely. Supporting (U)EFI does not require SecureBoot support... we wont support SecureBoot for Mga3, and there is no rush considering a lot of changes is still happening on several fronts... I will try to see if I can fix the UEFI part for ~beta3, but no promises yet And for people thinking of Windows 8 dual boot... Win8 does not _require_ SecureBoot either... (only the overprized RT does) And personally, I dont think we should ever bother with the SecureBoot crap as its flawed in so many ways... On a semi-related note, it would be nice to package gummiboot although I have no h/w to test it on. Yep, that is one of the things I'm looking at... For mga4 it might make sense to integrate it (assuming it's still a good solution) properly into our tools. Personally, I'm going to avoid grub2. It seems insane to me to implement all kinds of exotic filesystem supoort and even md stuff in a bootloader... Well, I think for next 3.8 kernel build I think I will make ahci, ext4 and btrfs builtin so you can boot without initrd on new hw, and if you install the kernel in correct place on the efi partition, you can boot the kernel directly without bootloader... :) -- Thomas
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release makedev-4.4-14.mga3
On Mon, Jan 14, 2013 at 5:37 PM, Pascal Terjan pter...@gmail.com wrote: On Sun, Jan 13, 2013 at 8:19 PM, tv buildsystem-dae...@mageia.org wrote: Name: makedev Relocations: (not relocatable) Version : 4.4 Vendor: Mageia.Org Release : 14.mga3 Build Date: Sun Jan 13 21:06:51 2013 Install Date: (not installed) Build Host: ecosse.mageia.org Group : System/Kernel and hardwareSource RPM: (none) Size: 58419License: GPLv2+ Signature : (none) Packager: tv tv URL : http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/soft/makedev/ Summary : A program used for creating the device files in /dev Description : This package contains the makedev program, which makes it easier to create and maintain the files in the /dev directory. /dev directory files correspond to a particular device supported by Linux (serial or printer ports, scanners, sound cards, tape drives, CD-ROM drives, hard drives, etc.) and interface with the drivers in the kernel. The makedev package is a basic part of your Mageia system and it needs to be installed. tv tv 4.4-14.mga3: + Revision: 378420 - fix upgrading (not corrupting devtmpfs) - devfs is dead for nearly a decade This package causes /usr/lib/root-mirror being in mounted in chroots on the build system (and not being umounted) during clean chroot creation sucuk had 65 mounted, oldest one being /home/iurt/chroot_tmp/iurt/chroot_cauldron.i586.0.20130113202409/usr/lib/root-mirror just after this package was uploaded Can someone have a look? [root@jonund ~]# mount | wc -l 277 This is annoying to cleanup on the build machines... (and at home when running iurt)
Re: [Mageia-dev] Freeze Push: bootsplash
'Twas brillig, and nicolas vigier at 29/01/13 11:47 did gyre and gimble: On Sun, 27 Jan 2013, David Walser wrote: Colin Guthrie wrote: 'Twas brillig, and David Walser at 27/01/13 20:26 did gyre and gimble: Colin Guthrie wrote: This is one of our packages thus semi-exempt from freeze rules. But either way it fixes a potential security issue. Care to elaborate? Mageia 2 also has 3.3.9. I already sent a mail to security@ (as per https://wiki.mageia.org/en/Packagers_Security_Team) to discuss it initially. I've updated the mga2 package in preparation already, but just wanted to discuss the process (i.e. order of certain actions) first. Does anyone get the mails sent to that list? I updated the mga-security ldap group to put you and Oden. You should now receive emails sent to secur...@group.mageia.org. Thanks, I'm sure David will be happy :) Quick question tho': is secur...@mageia.org just an alias for secur...@group.mageia.org? It is the former address that was listed on https://wiki.mageia.org/en/Packagers_Security_Team before you updated it. It would be interesting to know where that when before... :) 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] [council] *ping* Media query: secure boot support
'Twas brillig, and Thomas Backlund at 29/01/13 11:50 did gyre and gimble: Colin Guthrie skrev 29.1.2013 11:30: 'Twas brillig, and Thomas Backlund at 29/01/13 09:11 did gyre and gimble: Olav Vitters skrev 29.1.2013 10:43: On Sun, Jan 27, 2013 at 01:43:25PM +0100, Marja van Waes wrote: From: Sam Vargheses...@gnubies.com [..] I would like to know what Mageia plans to do about secure boot - when you will have a release that supports booting on hardware on which this feature is enabled. I'm wondering as well. I've been thinking to upgrade my system somewhere this year. This means secure boot, UEFI, etc. It would be nice if Mageia supports that nicely. Supporting (U)EFI does not require SecureBoot support... we wont support SecureBoot for Mga3, and there is no rush considering a lot of changes is still happening on several fronts... I will try to see if I can fix the UEFI part for ~beta3, but no promises yet And for people thinking of Windows 8 dual boot... Win8 does not _require_ SecureBoot either... (only the overprized RT does) And personally, I dont think we should ever bother with the SecureBoot crap as its flawed in so many ways... On a semi-related note, it would be nice to package gummiboot although I have no h/w to test it on. Yep, that is one of the things I'm looking at... Cool :) For mga4 it might make sense to integrate it (assuming it's still a good solution) properly into our tools. Personally, I'm going to avoid grub2. It seems insane to me to implement all kinds of exotic filesystem supoort and even md stuff in a bootloader... Well, I think for next 3.8 kernel build I think I will make ahci, ext4 and btrfs builtin so you can boot without initrd on new hw, and if you install the kernel in correct place on the efi partition, you can boot the kernel directly without bootloader... :) Yup, with newer systemds (not yet in mga - think it's probably best to wait for mga4, but I could backport those bits if there is sufficient interest), if you have an EFI partition and you have an empty /boot folder with no other /boot mounts defined, it'll automatically mount the efi partition there. This is where I think our tools would need updating to realise this was the case and use the correct vendor subdir for kernel (and optional initrd) installation. Will likely take a bit of fiddling to get right, hence why I think this is really an mga4 thing for the most part. 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] Packagers meeting
On 01/28/2013 12:38 PM, Anne Nicolas wrote: Hi there We will have our weekly meeting tomorrow, 20h UTC: - quick beta 2 review - release critical bugs review (this one should take most of our time) As usual feel free to propose a topic. QA and bug triage team, could you please be around? Cheers Can you please discuss a new step in the installer to select locale (to solve bug 3723) https://bugs.mageia.org/show_bug.cgi?id=3723 It exists since 2011
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release makedev-4.4-14.mga3
'Twas brillig, and Pascal Terjan at 29/01/13 11:51 did gyre and gimble: On Mon, Jan 14, 2013 at 5:37 PM, Pascal Terjan pter...@gmail.com wrote: On Sun, Jan 13, 2013 at 8:19 PM, tv buildsystem-dae...@mageia.org wrote: Name: makedev Relocations: (not relocatable) Version : 4.4 Vendor: Mageia.Org Release : 14.mga3 Build Date: Sun Jan 13 21:06:51 2013 Install Date: (not installed) Build Host: ecosse.mageia.org Group : System/Kernel and hardwareSource RPM: (none) Size: 58419License: GPLv2+ Signature : (none) Packager: tv tv URL : http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/soft/makedev/ Summary : A program used for creating the device files in /dev Description : This package contains the makedev program, which makes it easier to create and maintain the files in the /dev directory. /dev directory files correspond to a particular device supported by Linux (serial or printer ports, scanners, sound cards, tape drives, CD-ROM drives, hard drives, etc.) and interface with the drivers in the kernel. The makedev package is a basic part of your Mageia system and it needs to be installed. tv tv 4.4-14.mga3: + Revision: 378420 - fix upgrading (not corrupting devtmpfs) - devfs is dead for nearly a decade This package causes /usr/lib/root-mirror being in mounted in chroots on the build system (and not being umounted) during clean chroot creation sucuk had 65 mounted, oldest one being /home/iurt/chroot_tmp/iurt/chroot_cauldron.i586.0.20130113202409/usr/lib/root-mirror just after this package was uploaded Can someone have a look? [root@jonund ~]# mount | wc -l 277 This is annoying to cleanup on the build machines... (and at home when running iurt) Do we really need makedev these days? Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release makedev-4.4-14.mga3
On Tue, Jan 29, 2013 at 12:04 PM, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and Pascal Terjan at 29/01/13 11:51 did gyre and gimble: On Mon, Jan 14, 2013 at 5:37 PM, Pascal Terjan pter...@gmail.com wrote: On Sun, Jan 13, 2013 at 8:19 PM, tv buildsystem-dae...@mageia.org wrote: Name: makedev Relocations: (not relocatable) Version : 4.4 Vendor: Mageia.Org Release : 14.mga3 Build Date: Sun Jan 13 21:06:51 2013 Install Date: (not installed) Build Host: ecosse.mageia.org Group : System/Kernel and hardwareSource RPM: (none) Size: 58419License: GPLv2+ Signature : (none) Packager: tv tv URL : http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/soft/makedev/ Summary : A program used for creating the device files in /dev Description : This package contains the makedev program, which makes it easier to create and maintain the files in the /dev directory. /dev directory files correspond to a particular device supported by Linux (serial or printer ports, scanners, sound cards, tape drives, CD-ROM drives, hard drives, etc.) and interface with the drivers in the kernel. The makedev package is a basic part of your Mageia system and it needs to be installed. tv tv 4.4-14.mga3: + Revision: 378420 - fix upgrading (not corrupting devtmpfs) - devfs is dead for nearly a decade This package causes /usr/lib/root-mirror being in mounted in chroots on the build system (and not being umounted) during clean chroot creation sucuk had 65 mounted, oldest one being /home/iurt/chroot_tmp/iurt/chroot_cauldron.i586.0.20130113202409/usr/lib/root-mirror just after this package was uploaded Can someone have a look? [root@jonund ~]# mount | wc -l 277 This is annoying to cleanup on the build machines... (and at home when running iurt) Do we really need makedev these days? That's a good question :) iurt needs it because I still haven't fixed it to mount /dev but as a general thing I don't think so.
Re: [Mageia-dev] [council] *ping* Media query: secure boot support
On Tue, Jan 29, 2013 at 01:38:56PM +0200, Thomas Backlund wrote: Olav Vitters skrev 29.1.2013 13:12: On Tue, Jan 29, 2013 at 11:11:55AM +0200, Thomas Backlund wrote: And personally, I dont think we should ever bother with the SecureBoot crap as its flawed in so many ways... I quite like SecureBoot. This way you can avoid attacks on the boot sector. Yeah, and when MS screws up with one of the master keys (or some hw wendor) think about the dual-booters Microsft pushes revocation key through windowsupdate, and you suddenly find out your linux wont boot anymore, beacuse the signature that is supposed to validate your boot has been revoked... In which case I'd just turn secure boot off? Same for all the other examples. Maybe it at one point it has to be disabled, but at the moment that is not the case and it provides something useful. -- Regards, Olav
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
On 01/28/2013 06:44 PM, Barry Jackson wrote: My limited understanding is that the code in the 512 byte PBR has to use block lists to find the core image in /boot, since it is too small to understand filesystems. This is fragile in that filesystems and file utilities may move files around on disk invalidating the block lists, and for this reason the method is discouraged. A far as I know the same potential problem exists with grub legacy. OK, we've come full circle. This is why I was used to rerunning install.sh, because historically this has been true of most bootloaders. They all have to fit in 512 bytes, and they all have to load the next stage of the boot without support for filesystems. That's why I stick with chainloading. PBRs don't move around at the whim of a filesystem, and if you do something to a root partition that repositions something critical, you just rebuild the PBR as part of it. I wasn't aware of the MBR gap. I guess you're saying that the core.img that fits in it *is* filesystem-aware ? Otherwise, it seems like you've just pushed the locate-the-next-stage vulnerability from the MBR to the MBR gap, as chainloading pushes it from the MBR to the PBR. Anyway, my point still stands: for anyone who just wants to have grub and grub2 partitons coexist on the same disk with either one in the MBR, chainloading will accomplish this without any downside that isn't already present in grub legacy. Grub2 may be the way of the future, but to *require* it to own the MBR is just misleading.
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
On 29/01/13 12:48, Frank Griffin wrote: I wasn't aware of the MBR gap. I guess you're saying that the core.img that fits in it *is* filesystem-aware ? Yes, depending on the modules built into it, which are normally correct for our purposes. Anyway, my point still stands: for anyone who just wants to have grub and grub2 partitons coexist on the same disk with either one in the MBR, chainloading will accomplish this without any downside that isn't already present in grub legacy. Yes Grub2 may be the way of the future, but to *require* it to own the MBR is just misleading. Yes, it only gives that impression. It does not need to be the primary bootloader. To demonstrate this I made a fresh install of Mageia3 with only grub legacy installed and booted from MBR. I then installed the grub2 package (nothing more) and added an entry for the grub2 bootloader to the grub legacy menu.lst. (as in the README) I then re-booted and selected the grub2 entry from the legacy menu. The grub2 menu launched and contained all my systems - including the new Mageia3. Selecting Mageia3 launched the OS. Likewise selecting Mageia2 (found automatically during install of grub2) launched that correctly. The MBR has not been touched at all since the installation of grub legacy by the Mageia installer. Note that I do not advocate this as a sensible route to multi-booting, since it takes no account of kernel updates - it is just a demonstration. Barry
Re: [Mageia-dev] Freeze Push: bootsplash
On Tue, 29 Jan 2013, Colin Guthrie wrote: 'Twas brillig, and nicolas vigier at 29/01/13 11:47 did gyre and gimble: On Sun, 27 Jan 2013, David Walser wrote: Colin Guthrie wrote: 'Twas brillig, and David Walser at 27/01/13 20:26 did gyre and gimble: Colin Guthrie wrote: This is one of our packages thus semi-exempt from freeze rules. But either way it fixes a potential security issue. Care to elaborate? Mageia 2 also has 3.3.9. I already sent a mail to security@ (as per https://wiki.mageia.org/en/Packagers_Security_Team) to discuss it initially. I've updated the mga2 package in preparation already, but just wanted to discuss the process (i.e. order of certain actions) first. Does anyone get the mails sent to that list? I updated the mga-security ldap group to put you and Oden. You should now receive emails sent to secur...@group.mageia.org. Thanks, I'm sure David will be happy :) Quick question tho': is secur...@mageia.org just an alias for secur...@group.mageia.org? It is the former address that was listed on https://wiki.mageia.org/en/Packagers_Security_Team before you updated it. It would be interesting to know where that when before... :) Yes, that's an alias to secur...@group.mageia.org. Before the changes in the ldap group, it was going to stewb, he should have received your email.
Re: [Mageia-dev] python-distribute / python-pkg-resources again
On Tuesday, January 29, 2013 02:06:54 AM Pascal Terjan wrote: file /usr/lib/python2.7/site-packages/pkg_resources.py from install of python-distribute-0.6.34-3.mga3.noarch conflicts with file from package python-pkg-resources-0.6.28-4.mga3.noarch Maybe I should add a conflicts to the package. -- Best regards Thomas Spuhler signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] python-distribute / python-pkg-resources again
On Tue, Jan 29, 2013 at 2:36 PM, Thomas Spuhler tho...@btspuhler.com wrote: On Tuesday, January 29, 2013 02:06:54 AM Pascal Terjan wrote: file /usr/lib/python2.7/site-packages/pkg_resources.py from install of python-distribute-0.6.34-3.mga3.noarch conflicts with file from package python-pkg-resources-0.6.28-4.mga3.noarch Maybe I should add a conflicts to the package. What is the difference, why do they provide the same files?
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
On Mon, 28 Jan 2013 20:08:21 +, Barry Jackson wrote: Create a partition preferably near the start of the drive and label it maingrub then: Is there any technical reason why 'preferably near the start of the drive'? (Or perhaps simpy advisable in case of re-partitioning?) Does it e.g. have to be a primary partition? Well, I suppose I could give up Mga3-cauldron in /dev/sda and install Beta2 further along the drive, so as to make /dev/sda available, but it would be simpler to add 'maingrub' after the highest existing partition. mkdir -p /maingrub \ mount -L maingrub /maingrub \ grub2-install --root-directory=/maingrub /dev/sda Executed in any running Mageia-3-Cauldron system (with GRUB2 package installed presumably)? Looks dodgy to make MBR point to 'maingrub' before latter has a boot menu... (Presumably the thing to do is put that menu there first.) All sounds a bit nail-biting, with high risk of a boot failure! -- /\/\aurice
[Mageia-dev] Issue affecting several packages that will break upgrades from Mageia 2 to Mageia 3
A behavior change in rpm 4.11 that affects several packages will cause upgrades from Mageia 2 to Mageia 3 to fail. It considers two additional cases to be file conflicts, although they are actually issues with directories. We will need to fix the affected packages to prevent this from being an issue for upgrades. The first case is if any directories in a package have been changed to symlinks, or vise versa. While that has always been a problem, the fix for it had always been to have a %pre script to remove what the old package had, so that the upgraded package would install cleanly. This no longer works, as rpm now detects the conflict before %pre scripts are run. Now the removal needs to happen in a %pretrans script instead. Thierry compiled a list of packages that remove things in %pre scripts, so these are the ones that might be affected. In some cases, what the actual %pre script is doing may be unrelated to this issue. In other cases, the %pre script may be there for a packaging change made far in the past, and no longer be needed. The list is here: https://bugs.mageia.org/attachment.cgi?id=3378 The second case is when two different packages own the same directory, but differ in the ownership and/or permissions for that directory. It used to be that the directory's ownership/permissions would just get changed every time one of these packages were installed, now it is a conflict. Luc wrote a script to find directories owned by multiple packages with differing ownership and permissions. Unless the packages already explicitly conflict, all of these should be changed. Ideally, we should drop the ownership in all but one package. When that's not appropriate, the ownership and permissions should match in both/all packages. Here are the script, and the list of packages it produced: https://bugs.mageia.org/attachment.cgi?id=3448 https://bugs.mageia.org/attachment.cgi?id=3451 As you can see, almost all of those are man page directories, which IMO should only be owned by the man-pages-* packages.
Re: [Mageia-dev] freeze push: libroffice
On 29 January 2013 08:57, Thomas Backlund t...@mageia.org wrote: Please let in freeze push: libroffice-4.0.0.2 This is RC2, we have RC1. Submitted. http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20130129043512.tmb.valstar.7406/log/libreoffice-4.0.0.2-1.mga3/build.0.20130129043609.log Please submit again. Thx
Re: [Mageia-dev] [soft-commits] [7213] Check-in debuginfo-install
On 26 January 2013 22:33, Thierry Vignaud thierry.vign...@gmail.com wrote: Check-in debuginfo-install I think we should check if Core Release Debug is enabled (same for core testing/updates debug ones as well non-free/tainted if enabled) If those debug media are not enabled, then update them and use them temporary also, I think there's another script already existing in packagekit See /usr/bin/abrt-debuginfo-install /usr/bin/pk-debuginfo-install
Re: [Mageia-dev] freeze push: libroffice
On Tue, 29 Jan 2013, Thierry Vignaud wrote: On 29 January 2013 08:57, Thomas Backlund t...@mageia.org wrote: Please let in freeze push: libroffice-4.0.0.2 This is RC2, we have RC1. Submitted. http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20130129043512.tmb.valstar.7406/log/libreoffice-4.0.0.2-1.mga3/build.0.20130129043609.log Please submit again. Submitted.
Re: [Mageia-dev] Packagers meeting
Le 29/01/2013 13:01, Mustafa Muhammad a écrit : Can you please discuss a new step in the installer to select locale (to solve bug 3723) https://bugs.mageia.org/show_bug.cgi?id=3723 It exists since 2011 It is not one more step which is needed, we already have it. This bug is about timezone changes affecting locale.
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
Le 29/01/2013 17:57, Maurice Batey a écrit : Is there any technical reason why 'preferably near the start of the drive'? (Or perhaps simpy advisable in case of re-partitioning?) Does it e.g. have to be a primary partition? No, but some BIOS cannot access the whole drive, and GRUB uses the BIOS to access stage1_5 files. Last time I saw this on a 2006 laptop, I had to install Lilo to be able to boot 8^[
Re: [Mageia-dev] [council] *ping* Media query: secure boot support
Olav Vitters skrev 29.1.2013 14:40: On Tue, Jan 29, 2013 at 01:38:56PM +0200, Thomas Backlund wrote: Olav Vitters skrev 29.1.2013 13:12: On Tue, Jan 29, 2013 at 11:11:55AM +0200, Thomas Backlund wrote: And personally, I dont think we should ever bother with the SecureBoot crap as its flawed in so many ways... I quite like SecureBoot. This way you can avoid attacks on the boot sector. Yeah, and when MS screws up with one of the master keys (or some hw wendor) think about the dual-booters Microsft pushes revocation key through windowsupdate, and you suddenly find out your linux wont boot anymore, beacuse the signature that is supposed to validate your boot has been revoked... In which case I'd just turn secure boot off? Same for all the other examples. Maybe it at one point it has to be disabled, but at the moment that is not the case and it provides something useful. and if the hw vendor has not implemented a way to turn it off... -- Thomas
[Mageia-dev] Url of kscreen
As i looked arround in the newest pakcages in the bs, i saw the kscreen and i wanted to see what it is but the link in the url in the spec file is unreachable (not found).
[Mageia-dev] GNU Data Language
Just wondering if/where the GNU data language is being packaged with Mageia 3. It's listed as being in Mageia https://wiki.mageia.org/en/Science_SIG But the package gdl is something else.
Re: [Mageia-dev] GNU Data Language
Found it under gnudl On Wed, Jan 30, 2013 at 3:22 AM, Joseph Wang joequ...@gmail.com wrote: Just wondering if/where the GNU data language is being packaged with Mageia 3. It's listed as being in Mageia https://wiki.mageia.org/en/Science_SIG But the package gdl is something else.
Re: [Mageia-dev] [council] *ping* Media query: secure boot support
Le 29/01/2013 19:19, Thomas Backlund a écrit : and if the hw vendor has not implemented a way to turn it off... I experienced a Gateway system with a BIOS on which Windows 7 Pro refuses to activate. Then what? Customers were angry, they released a BIOS update that allows activation of any version. I think market goes the easy way. If people want to install Open Source, market will follow.
Re: [Mageia-dev] freeze push: firefox-ext-session_manager firefox-ext-noscript
Le 29/01/2013 22:00, Thierry Vignaud a écrit : Hi Please let in firefox-ext-session_manager firefox-ext-noscript. They're bug fixes only. They don't impact other packages and they're not on the install DVD anyway. Done. -- BOFH excuse #121: halon system went off and killed the operators.
[Mageia-dev] Power consumption disaster with AMD open source drivers
Hi, I reported a bug because open source driver for AMD cards reduced my laptops batter life to half: https://bugs.mageia.org/show_bug.cgi?id=8891 Please either implement the solution (shipping two xorg-server packages and choosing from them during install), or extend the life of Mageia 2 to 5 years (or at least 3), nobody can keep using Mageia to kill his battery life. I know I asked about this before but it is critical. Regards
Re: [Mageia-dev] Package drop request: more ruby packages
On Wed, Dec 19, 2012 at 9:41 PM, Remy CLOUARD shikam...@mageia.org wrote: Hi, Could someone remove the following RPMs from the repos: ruby-rcov-doc: ruby-rcov has been superseded by ruby-simplecov, has been removed from the mirrors, but the -doc package is still there ruby-oa-oauth and ruby-oa-oauth-doc ruby-oa-more and ruby-oa-more-doc ruby-oa-enterprise and ruby-oa-enterprise-doc ruby-oa-core and ruby-oa-core-doc ruby-oa-openid and ruby-oa-openid-doc ruby-oa-basic and ruby-oa-basic-doc the reason for dropping all these ruby-oa packages is because the omniauth framework is packaged very differently starting from 1.0. This break teambox but the package has many more broken dependencies and is rather outdated (there’s a rails 3 branch I should update it to) What is the plan with teambox? Should it be dropped?
Re: [Mageia-dev] Power consumption disaster with AMD open source drivers
Op woensdag 30 januari 2013 00:57:44 schreef Mustafa Muhammad: Hi, I reported a bug because open source driver for AMD cards reduced my laptops batter life to half: https://bugs.mageia.org/show_bug.cgi?id=8891 Please either implement the solution (shipping two xorg-server packages and choosing from them during install), or extend the life of Mageia 2 to 5 years (or at least 3), nobody can keep using Mageia to kill his battery life. I know I asked about this before but it is critical. Regards I might be mistaken, but i think there is work going on to make this happen... if it does, it'll need some manual intervention though... (but unsure on this), we'll have to see...
Re: [Mageia-dev] Power consumption disaster with AMD open source drivers
On 01/30/2013 02:01 AM, AL13N wrote: Op woensdag 30 januari 2013 00:57:44 schreef Mustafa Muhammad: Hi, I reported a bug because open source driver for AMD cards reduced my laptops batter life to half: https://bugs.mageia.org/show_bug.cgi?id=8891 Please either implement the solution (shipping two xorg-server packages and choosing from them during install), or extend the life of Mageia 2 to 5 years (or at least 3), nobody can keep using Mageia to kill his battery life. I know I asked about this before but it is critical. Regards I might be mistaken, but i think there is work going on to make this happen... if it does, it'll need some manual intervention though... (but unsure on this), we'll have to see... Anything is OK, manual intervention or completely manual setup is OK, just don't leave us in the cold by only supporting xorg 1.13
Re: [Mageia-dev] Power consumption disaster with AMD open source drivers
Op woensdag 30 januari 2013 06:29:08 schreef Mustafa Muhammad: On 01/30/2013 02:01 AM, AL13N wrote: Op woensdag 30 januari 2013 00:57:44 schreef Mustafa Muhammad: Hi, I reported a bug because open source driver for AMD cards reduced my laptops batter life to half: https://bugs.mageia.org/show_bug.cgi?id=8891 Please either implement the solution (shipping two xorg-server packages and choosing from them during install), or extend the life of Mageia 2 to 5 years (or at least 3), nobody can keep using Mageia to kill his battery life. I know I asked about this before but it is critical. Regards I might be mistaken, but i think there is work going on to make this happen... if it does, it'll need some manual intervention though... (but unsure on this), we'll have to see... Anything is OK, manual intervention or completely manual setup is OK, just don't leave us in the cold by only supporting xorg 1.13 i am not certain, but i believe i have heard this. I too suffer from this problem, even though the real problem is AMD/ATI behaving cruelly and not suppporting their slightly older hardware
Re: [Mageia-dev] Power consumption disaster with AMD open source drivers
On 01/30/2013 09:45 AM, AL13N wrote: Op woensdag 30 januari 2013 06:29:08 schreef Mustafa Muhammad: On 01/30/2013 02:01 AM, AL13N wrote: Op woensdag 30 januari 2013 00:57:44 schreef Mustafa Muhammad: Hi, I reported a bug because open source driver for AMD cards reduced my laptops batter life to half: https://bugs.mageia.org/show_bug.cgi?id=8891 Please either implement the solution (shipping two xorg-server packages and choosing from them during install), or extend the life of Mageia 2 to 5 years (or at least 3), nobody can keep using Mageia to kill his battery life. I know I asked about this before but it is critical. Regards I might be mistaken, but i think there is work going on to make this happen... if it does, it'll need some manual intervention though... (but unsure on this), we'll have to see... Anything is OK, manual intervention or completely manual setup is OK, just don't leave us in the cold by only supporting xorg 1.13 i am not certain, but i believe i have heard this. I too suffer from this problem, even though the real problem is AMD/ATI behaving cruelly and not suppporting their slightly older hardware I know the problem is AMD, but hoped the community can offer a solution to us (as it always do), I don't require a good VGA card so nowadays I only buy laptops with integrated Intel graphic chip, and for heavy gamers I think NVidia is better (but I don't recommend it, I still have a feeling to AMD, they were always better in Performance/Price)
[Mageia-dev] Freeze push : mlt and kdenlive
Please push mlt and kdenlive : 124 bugs have been fixed with this bugfix release that is the last one before a huge code refactor. http://www.kdenlive.org/discover/0.9.4 mlt 0.8.8 is recommended by upstream projects as some bug fixes need it, and is only required by kdenlive as far as urpmi --requires mlt tells me. I tested locally both in x86_64, editing, and rendering are ok.
Re: [Mageia-dev] Power consumption disaster with AMD open source drivers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 30.01.2013 08:55, Mustafa Muhammad kirjutas: ... I still have a feeling to AMD, they were always better in Performance/Price) And they have never really cared about open source users.. We as a community can't do much about non-free drivers. - -- Sander -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRCM5JAAoJECMkkFJIyHr8RVIH/1DjsFHEIjad6N5s1W979Wgv WB6tLjODuEcGqKFPd9JWQjLNXAkGIPQ+Yj9RbwbHEv5mrC1XDGN10grwf2qpKQ0f hbwOg/BGjSnNtgYfg9VC5SBZmn+yCtTkmqZPJIb3k/pqnQlK8XZUtdxSuMpMBWAb E35lJ5048D+qvNtdfpqC5KxpW5ipcPmAuodbyF3z37YSQIGmWLn85FfOwFKW+9Nm /IfcC4FJbNCw2F/saysUAMUd4uxv6nTDIdicSM0PO7I9QNI5I6jL7FIELXM2LhLj Kg05Q0VfJQU2xXaxAmOLYc/31O5xaMXlyexDhkE+XNy6UlUqRBz9qgDK/l/t9jw= =aM3p -END PGP SIGNATURE-
