Re: [Mageia-dev] Perl MIDI:ALSA module (package suggestion for Mageia)
On Sun, 9 Dec 2012, Remy CLOUARD wrote: On Sat, Dec 08, 2012 at 02:43:47PM +0100, tux99-...@uridium.org wrote: Hi, If you are curious to see what can be done with the MIDI::ALSA Perl module have a look at a program I wrote with it: http://www.yamahaforums.co.uk/forum/viewtopic.php?f=9t=5915 Awesome ! Up until now I used to use simple sysexxer to transfer sysex to my DX7. Editing patches on the DX7 is a major pain, because there is only one slider to adjust each parameter for all oscillators. Seems to me that this library will make it way easier to build apps that do what this app does for the RM50. (maybe you have plans to support other hardware ?) Yes, IMHO this library together with Perl/Tk (or GTK2-Perl if you prefer) for the GUI makes it very easy to write apps like this one, I have very little programming experience and I still managed to write this in a few weeks in my spare time (I did have basic Perl scripting experience but had never written such large GUI based app before). I might write similar apps for other synths I own in future but I don't own a DX7 (great synth!) so can't support that one. Regards, Andy
[Mageia-dev] Perl MIDI:ALSA module (package suggestion for Mageia)
Hi, Thanks to Peter Billam there is now a Perl module that gives Perl complete access to the ALSA MIDI library therefore allowing to easily create programs in Perl that inteface with MIDI capable synthesizers. I have packaged up this Perl module for Centos 6 and I think it should be straightforward to port the Centos 6 spec-file to Mageia, but since I'm not a Mageia packager (and can't be due to lack of time) I wanted to bring this to your attention with the hope that a Mageia packager picks this up and adds this very useful package to Mageia. Here are the Centos 6 files: Spec-file: http://pkgrepo.linuxtech.net/el6/testing/spec-files/perl-MIDI-ALSA.spec Source RPM: http://pkgrepo.linuxtech.net/el6/testing/source/perl-MIDI-ALSA-1.16-1.el6.src.rpm Binary RPMS: http://pkgrepo.linuxtech.net/el6/testing/i686/perl-MIDI-ALSA-1.16-1.el6.i686.rpm http://pkgrepo.linuxtech.net/el6/testing/x86_64/perl-MIDI-ALSA-1.16-1.el6.x86_64.rpm If you are curious to see what can be done with the MIDI::ALSA Perl module have a look at a program I wrote with it: http://www.yamahaforums.co.uk/forum/viewtopic.php?f=9t=5915 Regards, Andy
Re: [Mageia-dev] Perl MIDI:ALSA module (package suggestion for Mageia)
On Sat, 8 Dec 2012, Shlomi Fish wrote: I now packaged your perl-MIDI-ALSA for Mageia Linux 3/Cauldron after some Mageiaisation of the .spec file. Thanks! That's great, thanks! If you wish to return the favour you can package Freecell Solver ( http://fc-solve.shlomifish.org/ ) for Fedora/CentOS. The .tar.bz2 already has a built-in .spec and .spec.in and there's also a Mageia package for it here: Unfortunately I'm not a Fedora user or packager at all, I only run a personal repo for EL6 (RHEL6/Centos6/SL6) specialised in Audio/Video packages which is quite popular among EL6 desktop users due to the fact that it has several A/V related packages no other EL6 repo has. If you like I could add Freecell-Solver to my personal EL6 repo, but I don't think that would help much, it would probably get more attention in one of the large EL6 repos like EPEL. Regards, Andy
Re: [Mageia-dev] Mageia support for GMA 3600 (Cedar Trail Atom)
On Sun, 11 Mar 2012 tux99-...@uridium.org wrote: On Fri, 9 Mar 2012 tux99-...@uridium.org wrote: On Fri, 9 Mar 2012, Thomas Backlund wrote: tux99-...@uridium.org skrev 8.3.2012 02:18: Hi, I just tried Mageia 2 beta 1 on a Intel DN2800MT board hoping that it would have framebuffer support for the GMA 3600, but the attached monitor goes into standby (no signal) as soon as the frame buffer gets activated during boot. As far as I understand there is frame buffer support in the 3.3 kernel for the GMA 3600 so in theory it should work. Are you aware of this issue or should I do a bug report? Yes. There is a bug with Cedar Trail that got fixed upstream a few days after 3.3-rc6 was released, so the fix is not in our current kernel-3.3.0-0.rc6.1.mga2, but it will be fixed in the next build. Thanks, that's great, I will test the next build and then report back how that works with my Cedar Trail board. Hi, I noticed a new kernel packages showed up in the cauldron repo (3.3rc7) so I tried it immediately (reinstalled cauldron from scratch as I had overwritten the previous install with other distro tests) using the boot.iso image, but the video behaviour at boot is still the same, the monitor still goes into no-signal standby as soon as the drm stuff is started. Just for future reference for anyone who might come across this thread in the ML archives facing the same issue: I solved this, the GMA 3600 kernel DRM driver in 3.3.0 (as included in Mageia) always assumes a LVDS panel is present (as would be the case on netbooks but not on mini-ITX boards) and for some reason it defaults to a 1920x1080 panel. To avoid this and therefore to be able to use the other video outputs (VGA, hdmi) at other resolutions the following kernel parameter needs to be appended on the grub kernel line: video=LVDS-1:d This will force disable the LVDS port and with that parameter Mageia 2 works fine on a Cedarview Atom DN2800MT board. This is a shortcoming of the kernel module (not specific to Mageia), Alan Cox is aware of it and I guess it will eventually be fixed. For anyone interested the xorg.conf I used is here (the monitor section is specific to my monitor, hence will need adapting): http://pastebin.com/X7mpEF3x Also for anyone interested I have done some power draw measurements of the Intel DN2800MT Cedarview Atom board comparing Mageia 2 beta with some other distros (and Win 7), the results are here: http://www.linuxtech.net/reviews/intel_DN2800MT_cedarview_atom_power_draw.html
Re: [Mageia-dev] Mageia 2 Beta 2 is available
On Fri, 16 Mar 2012, Sander Lepik wrote: 16.03.2012 03:07, tux99-...@uridium.org kirjutas: On Thu, 15 Mar 2012, Anne nicolas wrote: Hi there Beta 2 is available now for tests. Here is the announcement: http://blog.mageia.org/en/2012/03/15/mageia-2-beta-2-near-the-goal/ We need your tests and reports more than ever! Hi Anne, I gave feedback with regards to serious issues when trying beta 1 on a Cedarview Atom system, but apart from a couple of isolated replies (thanks to those who did reply) that unfortunately didn't solve the issues I got no further interest. And the bug number is? Does your post mean you looked at the info I provided in the previous emails and you concluded that I'm hitting a bug? As I said before I don't know if I'm hitting a bug or if it's a configuration issue, that's what I was trying to find out here. My main problem is I don't really understand how the GMA3600 needs to be configured, I don't know what this DRM kernel driver that's included in 3.3.7rc7 is, is it equivalent to a framebuffer driver, or do I still have to use the generic vesa framebuffer? Regardless of that, out of the box I'm not getting any picture with this GPU (the screen goes into stand-by once the DRM kernel module is activated at boot). I did manage to manually configure xorg to use the generic vesa framebuffer but this way I don't seem to get any DRI capability which I thought the GMA3600 DRM kernel module was supposed to provide. There don't seem to be any docs anywhere with regards to this, neither in the kernel docs nor on the internet, at least I didn't find anything. As it stands Mageia is unusable on a Cedarview Atom for a normal user, and even I'm quite at loss here as I only managed to get generic vesa xorg working (after a lot of trial and error). At least with other distros (Centos 6.2 or Fedora 17 alpha) xorg with the generic vesa driver works out of the box (but those distros don't have the latest kernel with the GMA3600 DRM kernel module).
Re: [Mageia-dev] Mageia 2 Beta 2 is available
On Thu, 15 Mar 2012, Anne nicolas wrote: Hi there Beta 2 is available now for tests. Here is the announcement: http://blog.mageia.org/en/2012/03/15/mageia-2-beta-2-near-the-goal/ We need your tests and reports more than ever! Hi Anne, I gave feedback with regards to serious issues when trying beta 1 on a Cedarview Atom system, but apart from a couple of isolated replies (thanks to those who did reply) that unfortunately didn't solve the issues I got no further interest. Given that Cedarview Atom will be on most Netbooks this year I would have expected more interest in getting Mageia to work on them. Therefore I say it again, I'm available to do any reasonable tests you want me to do or provide any logs you need to get this solved (see my previous mails for details I already provided so far). Regards, tux99
Re: [Mageia-dev] Mageia support for GMA 3600 (Cedar Trail Atom)
On Mon, 12 Mar 2012, zezinho wrote: Le lundi 12 mars 2012 00:38:00, tux99-...@uridium.org a �crit : Sorry ignore the previous pastebins, those were without vga=795 on the kernel line, here are the correct ones: Please, maybe this could go only into the bug report? There is no bug report because I don't even know if this is a bug or a simple configuration issue, that's what I'm trying to find out.
Re: [Mageia-dev] Mageia support for GMA 3600 (Cedar Trail Atom)
On Fri, 9 Mar 2012 tux99-...@uridium.org wrote: On Fri, 9 Mar 2012, Thomas Backlund wrote: tux99-...@uridium.org skrev 8.3.2012 02:18: Hi, I just tried Mageia 2 beta 1 on a Intel DN2800MT board hoping that it would have framebuffer support for the GMA 3600, but the attached monitor goes into standby (no signal) as soon as the frame buffer gets activated during boot. As far as I understand there is frame buffer support in the 3.3 kernel for the GMA 3600 so in theory it should work. Are you aware of this issue or should I do a bug report? Yes. There is a bug with Cedar Trail that got fixed upstream a few days after 3.3-rc6 was released, so the fix is not in our current kernel-3.3.0-0.rc6.1.mga2, but it will be fixed in the next build. Thanks, that's great, I will test the next build and then report back how that works with my Cedar Trail board. Hi, I noticed a new kernel packages showed up in the cauldron repo (3.3rc7) so I tried it immediately (reinstalled cauldron from scratch as I had overwritten the previous install with other distro tests) using the boot.iso image, but the video behaviour at boot is still the same, the monitor still goes into no-signal standby as soon as the drm stuff is started. I have full access to the box via ssh so I have uploaded some logs that might help figure this out, it looks to like the kernel modules load fine but somehow they set a screen mode that the monitor doesn't like. Basically I don't really know how the drm kernel modules and xorg interact (and I can't find any useful recent docs about it), who is responsible for setting the screen mode and where can I manually configure it, on the kernel line or xorg.conf? (I have been spoiled by the binary nvidia drivers for too long :) ) dmesg: http://pastebin.com/SLBcgjXx lsmod output: # lsmod|grep gma gma500_gfx149940 0 drm_kms_helper 32743 1 gma500_gfx drm 207700 2 gma500_gfx,drm_kms_helper i2c_algo_bit 13080 1 gma500_gfx i2c_core 29836 5 i2c_i801,gma500_gfx,drm_kms_helper,drm,i2c_algo_bit video 18640 1 gma500_gfx /var/log/Xorg.0.log: http://pastebin.com/ypw0DAnz I'm unsure if this is only a config problem or if this is still due to some bug. Any pointers would be much appreciated.
Re: [Mageia-dev] Mageia support for GMA 3600 (Cedar Trail Atom)
On Sun, 11 Mar 2012 tux99-...@uridium.org wrote: On Fri, 9 Mar 2012 tux99-...@uridium.org wrote: On Fri, 9 Mar 2012, Thomas Backlund wrote: tux99-...@uridium.org skrev 8.3.2012 02:18: Hi, I just tried Mageia 2 beta 1 on a Intel DN2800MT board hoping that it would have framebuffer support for the GMA 3600, but the attached monitor goes into standby (no signal) as soon as the frame buffer gets activated during boot. As far as I understand there is frame buffer support in the 3.3 kernel for the GMA 3600 so in theory it should work. Are you aware of this issue or should I do a bug report? Yes. There is a bug with Cedar Trail that got fixed upstream a few days after 3.3-rc6 was released, so the fix is not in our current kernel-3.3.0-0.rc6.1.mga2, but it will be fixed in the next build. Thanks, that's great, I will test the next build and then report back how that works with my Cedar Trail board. Hi, I noticed a new kernel packages showed up in the cauldron repo (3.3rc7) so I tried it immediately (reinstalled cauldron from scratch as I had overwritten the previous install with other distro tests) using the boot.iso image, but the video behaviour at boot is still the same, the monitor still goes into no-signal standby as soon as the drm stuff is started. I have full access to the box via ssh so I have uploaded some logs that might help figure this out, it looks to like the kernel modules load fine but somehow they set a screen mode that the monitor doesn't like. Basically I don't really know how the drm kernel modules and xorg interact (and I can't find any useful recent docs about it), who is responsible for setting the screen mode and where can I manually configure it, on the kernel line or xorg.conf? (I have been spoiled by the binary nvidia drivers for too long :) ) dmesg: http://pastebin.com/SLBcgjXx lsmod output: # lsmod|grep gma gma500_gfx149940 0 drm_kms_helper 32743 1 gma500_gfx drm 207700 2 gma500_gfx,drm_kms_helper i2c_algo_bit 13080 1 gma500_gfx i2c_core 29836 5 i2c_i801,gma500_gfx,drm_kms_helper,drm,i2c_algo_bit video 18640 1 gma500_gfx /var/log/Xorg.0.log: http://pastebin.com/ypw0DAnz I'm unsure if this is only a config problem or if this is still due to some bug. Any pointers would be much appreciated. Sorry ignore the previous pastebins, those were without vga=795 on the kernel line, here are the correct ones: dmesg: http://pastebin.com/4t9L3GVm Xorg.0.log: http://pastebin.com/TsE4gUxW
Re: [Mageia-dev] Mageia support for GMA 3600 (Cedar Trail Atom)
On Wed, 7 Mar 2012, David W. Hodgins wrote: On Wed, 07 Mar 2012 21:00:38 -0500, tux99-...@uridium.org wrote: On Thu, 8 Mar 2012 tux99-...@uridium.org wrote: Hi, I just tried Mageia 2 beta 1 on a Intel DN2800MT board hoping that it would have framebuffer support for the GMA 3600, but the attached monitor goes into standby (no signal) as soon as the frame buffer gets activated during boot. Try disabling kms by adding either nokmsboot or modeset.i915=0 to the kernel options. Regards, Dave Hodgins Thanks but neither nokmsboot nor i915.modeset=0 make much of a difference. With nokmsboot I get the mageia splash screen for a second or too (I wasn't seeing that before), but after that the monitor still goes into standby. i915.modeset=0 has no effect. The following Meego ISO works fine with this mobo (both kms and xorg): http://repo.meego.com/MeeGo/updates/1.2.0/images/meego-netbook-ia32-cedartrail/ Also Centos 6.2 boots fine to runlevel 3 without disabling anything (probably because the Centos 6.2 kernel doesn't have any support for the GMA3600).
[Mageia-dev] Mageia support for GMA 3600 (Cedar Trail Atom)
Hi, I just tried Mageia 2 beta 1 on a Intel DN2800MT board hoping that it would have framebuffer support for the GMA 3600, but the attached monitor goes into standby (no signal) as soon as the frame buffer gets activated during boot. As far as I understand there is frame buffer support in the 3.3 kernel for the GMA 3600 so in theory it should work. Are you aware of this issue or should I do a bug report? Has anyone else tested a GMA 3600 (the GPU that's in all Cedar Trail Atom cpus) with Mageia so far? Regards, tux99
Re: [Mageia-dev] Mageia support for GMA 3600 (Cedar Trail Atom)
On Thu, 8 Mar 2012 tux99-...@uridium.org wrote: Hi, I just tried Mageia 2 beta 1 on a Intel DN2800MT board hoping that it would have framebuffer support for the GMA 3600, but the attached monitor goes into standby (no signal) as soon as the frame buffer gets activated during boot. As far as I understand there is frame buffer support in the 3.3 kernel for the GMA 3600 so in theory it should work. Are you aware of this issue or should I do a bug report? Has anyone else tested a GMA 3600 (the GPU that's in all Cedar Trail Atom cpus) with Mageia so far? Regards, tux99 Just to add: I have tried all grub opptions (normal, non-fb and failsafe) on each of them the same thing happens. with non-fb I can see the boot process until almost the end, I guess it's the start of the dm that triggers the loss of signal in that case. I tried editing the grub line adding a 3 at end hopeing to get it to boot to runlevel 3 but that doesn't seem to work as the behaviour doesn't change. Is 3 on the grub line still supposed to work? I imagine this GMA3600 issue needs solving before the final release as CedarTrail Atoms will be in most Netbooks sold this year, and even though netbooks are less popular then they used to be, they are still selling by the milions especially in Asia. Let me know what I could do to help debug this.
[Mageia-dev] dkms
Is there any specific reason (regressions, incompatibilites?) why Mageia (and Mandriva) still ships dkms 2.0.19 even though 2.1.1.2 is the latest upstream release, or is it simply because nobody has updated the package? -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Tainted build
I thought the core build of freetype2 already has the bytecode interpreter enabled (since the patent expired). Why is there still a need for a tainted version? -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Complete freeze coming soon
IMHO there should be an exception for tainted since the fact that the build system can't build dual target packages[1] yet, is blocking the submission of many packages that depend on these. I saw the build system issue has been elevated to release-blocker, IMHO it should be also freeze delaying (unless all the Audio/Video stuff is considered unimportant by the majority here). [1]https://bugs.mageia.org/show_bug.cgi?id=338 -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Suggestion: what to do with iso?
There is an easy to follow step by step user-contributed tutorial on how to use mandriva-seed in Windows on my website. It was written for Mandriva 2009.1 but I guess it should be usable for Mageia too. See here (in the right-hand column): http://www.linuxtech.net/news/mandriva_linux_2009.1_spring_is_out.html -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Non-free firmwares in installer
Quote: Frank Griffin wrote on Sun, 27 March 2011 15:03 On 03/26/2011 08:58 PM, Tux99 wrote: And why should all of us suffer the hassle of a DVD + a CD (how would that work for all those that use USB-sticks, do they now need two sticks? I guess you must have missed the six or so times I stated that I don't give a rat's whatever about whether there's one ISO or two. Personally, I'd say go with one, and if there's a space issue, go to a DL. But that's a flame war for some other day. No flame war, but since you were using colourful expressions such as bending over backwards I just wanted to point out that that's even more so the case with a separate firmware CD to please the more extreme free software fanatics. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Non-free firmwares in installer
Quote: Wolfgang Bornath wrote on Sun, 27 March 2011 17:11 Do you really think it will help to find a consent calling people who do not share your opinion ultra-orthodox software fanatics? Why? An 'orthodox' is a person who follows his beliefs very very strictly, 'fanatic' has a similar meaning (yeah I know those two words are sort of redundant but I just wanted to express how extreme the view appears). There is no negative connotation, in fact most 'fans' (=fanatics) or people with 'orthodox' beliefs are proud of it. Ultimately it was just a way of expressing how extreme I consider the idea that free and non-free software on the same physical media would be unacceptable to them, even if the installation procedure clearly asks the user whether to install the non-free software or not. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Non-free firmwares in installer
Quote: Oliver Burger wrote on Sun, 27 March 2011 17:40 By the way: I know, Debian are just a small group of ultra-orthodox software fanatics, but that's exactly, what they are doing... I'm aware that Debian does this now. While I don't think that all (or even most) Debian supporters are ultra-orthodox free-software fanatics I certainly believe the core that made that decision is. You should have added that that decision was quite controversial in the Debian community. But Debian is such an 'institution' that they can afford to go against the mainstream, I don't think Mageia can afford that, certainly not at this stage. (and personally I don't see the point) -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Non-free firmwares in installer
Quote: Frank Griffin wrote on Sun, 27 March 2011 00:34 For you to complain that because you have minimal network access, the rest of the Mageia community should bend over backwards to avoid your having to swap a few CDs during install is a pretty hollow argument, in my opinion. And why should all of us suffer the hassle of a DVD + a CD (how would that work for all those that use USB-sticks, do they now need two sticks? And do you expect magazines to include a DVD+CD to please Mageia? What about all the extra waste and pollution cause by dual media?) just to please the few ultra-orthodox free software fanatics that seemingly would get allergic reactions if the main media contained some non-free code (even if it's only installed upon an informed choice of the user)? Putting the non-free firmware on the main DVD should be a no brainer, since a clear install option is all that's needed to keep the systems of free software fanatics pure. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] qt3-devel needed for Trinitydesktop (KDE 3.5 successor)
Ok, can we get back on topic? Is there any compelling reason why we cannot reenable qt3-devel in the qt3 source package that is ALREADY part of Mageia? If not then I want to reenable it. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Non-free firmwares in installer
Quote: andr55 wrote on Fri, 25 March 2011 01:29 My though was essentially that firmware is so close to hardware that its actual free/non-free status shouldn't apply - we should treat it like (almost) part of the hardware. I agree with that. After all nobody (apart from R. Stallmann) questions the fact that the BIOS of their PC is non-free or all the other firmware or microcode on various chips on the motherboard and on expansion cards and peripherals. Firmware belongs into 'core', Nvidia/ATI drivers and the Flash plugin belong into 'non-free'. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] qt3-devel needed for Trinitydesktop (KDE 3.5 successor)
Quote: yves wrote on Fri, 25 March 2011 09:42 Hi, QT4 is released since 2005, about... 6 years ? So, why is it usefull to maintain a package that becomes depreciated ? You are missing the point. QT3 is already part of Mageia and it wasn't me who added it. All I'm asking is if there is any compelling reason not to enable qt3-devel in the existing qt3 source package that is part of Mageia. If there isn't any COMPELLING reason, then qt3-devel should be reenabled as long as someone wishes it. What everyone here seems to forget is that a community distro should be first and foremost about FREEDOM. Freedom to let others enjoy their preferred software, not ARTIFICIAL RESTRICTIONS imposed by personal preferences or unnecessarily restrictive ARBITRARY RULES made up along the way by a few of the core members. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] qt3-devel needed for Trinitydesktop (KDE 3.5 successor)
Quote: Oliver Burger wrote on Fri, 25 March 2011 10:21 A community distro is first and formost about community. Every time one of your ideas, suggestions, questions is answered by anyone with a no you begin to blame a few of the core members, no matter how many people said no and who they were. You completely missed the point. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] qt3-devel needed for Trinitydesktop (KDE 3.5 successor)
Quote: xi wrote on Fri, 25 March 2011 10:32 As always, please don't drop too fast the packages that you find useless. There are still some users like me who may use QT3. I still use some not so common applications (eg tools for electronic) which needs QT3 and it is always much more convenient to simply do a urpmi libqt3-devel than downloading and compiling qt3 ... especially if libqt3 is already included in Mageia ! Exactly my point, thanks Xavier. This is about not restricting other people's freedoms. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] qt3-devel needed for Trinitydesktop (KDE 3.5 successor)
Quote: rdalverny wrote on Fri, 25 March 2011 10:53 You can't force a maintainer to do something you want and that she judges not right for her set of packages. We seem to be having a communication issue. Where did I force a maintainer to do anything? I asked if there is any COMPELLING reason for me not to reenable qt3-devel. If there isn't, then of course I will reenable it. It wasn't me who then started a long off-topic discussion about imagined or otherwise risks of TDE. If you can't work here by that, or if you are not happy with how things go here, you are free to discuss this openly with members of the council or of the board to sort it out. Is there a procedure for that somewhere? I would think such discussions are supposed to happen on the MLs (rather than in private) and given that board/council members posted in this thread I would assume that this discussion is happening here. Are you saying that the members of the council that posted here in this thread would give a different answer if I contacted them formally (how?) as members of the council? TBH I didn't even want any grand discussion, to repeat myself I was just trying to find out if there is anything blocking the reenabling of qt3-devel. (I hope this point is finally clear enough by now) So why all the fuss? Take the maintainance of the package, make your changes, submit it and here you are. If you re-read the thread you will find that I didn't start the fuss, in fact it was started by people expressing fears about TDE and some board/council members putting preemptive vetos on TDE. I have no problem co-maintaining the package (with regards to the devel side of it) but I'm not aware of any formal procedure to take maintenance of a package. Is there such a procedure formalized somewhere? -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] qt3-devel needed for Trinitydesktop (KDE 3.5 successor)
Quote: nicolas vigier wrote on Fri, 25 March 2011 11:50 Having a qt3-devel packages does not automatically imply having packages based on it in the official repos. Why do you want to have a qt3-devel package on the official repos, if it's not to have other packages based on it ? Why do you NOT want to have it in the repo? Does it affect you if it's in the repo? Did you read Xavier's post? Nothing prevent you from building the package on your computer if you want it. But we don't want it on the repository for the reasons already explained ... I have only seen arbitrary reasons based on personal preferences, not an objective compelling reason. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] qt3-devel needed for Trinitydesktop (KDE 3.5 successor)
Quote: rdalverny wrote on Fri, 25 March 2011 11:56 A choice is arbitrary, always. It always says no to something. Implying that this would restrict freedoms of users would be laughable at best, offensive at worst, especially since this is an open source project. You seem to be confusing different concepts here, just because a project is based on open source software that doesn't automatically guarantee that the community based on it is a community that values freedom. My concerns here are exactly because I'm getting the feeling that freedom is being unnecessarily restricted in Mageia. And no a choice is definitely not always arbitrary. Choices can be forced by unsurmountable limitations or technical incompatibilities or they can be arbitrary (i.e. not objectively necessary). In the early days a 'contrib' repo was suggested for not officially supported packages (I was for that idea too), this would be a good situation where a 'contrib' repo would solve this matter for everyone. Please open a bug for that if you think it's worth discussing it again. Is that now the procedure for this? I would also appreciate it, if you could clarify the procedures with regards to the council I asked about in my last reply to you. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] qt3-devel needed for Trinitydesktop (KDE 3.5 successor)
Quote: Balcaen John wrote on Fri, 25 March 2011 12:30 As as already said earlier, if you want to compile TDE, you can also compile qt3 with devel enable because you 'll need to *patch* qt3 to be able to compile TDE =3.5.12 cf http://www.trinitydesktop.org/wiki/bin/view/Developers/Qt3 I'm aware of the patch needed for TDE =3.5.12, but my current interest is 3.5.12. After that when the patch is needed for future versions then I will look at applying the patch to the qt3 package. So i'll repeat myself once more : - enable qt3 with devel support on your box - patch it (because i expect you want to fix some TDE bugs available in 3.5.12 you'll need to patch for TDE from svn 1214094 - compile, test TDE on your computer with a prefix in /usr (not /opt) - if everything is ok, ask for a space online (i can help if it's really needed for that) to provide TDE in a contrib for more tests - than if it's ok we can start thinking about including some part of it As I said earlier in this thread I have of course already rebuilt the qt3 package on my box and started working on the TDE packages (thanks to work done by Tim for Mandriva it's far easier for me now). The point is with the overwhelmingly negative attitude directed towards me even 'thinking' about TDE in Mageia, I don't think my reaction is that surprising, or is it? At this point I don't think there is any chance that TDE ever goes into the Mageia repos, given the attitudes I have faced here. Also this is not really about my ideas as Xavier's post showed, there are others too that are affected by these arbitrary and unnecessary limitations (they are probably just less outspoken than I am). -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] qt3-devel needed for Trinitydesktop (KDE 3.5 successor)
Quote: tux99 wrote on Fri, 25 March 2011 12:47 Quote: Balcaen John wrote on Fri, 25 March 2011 12:30 As as already said earlier, if you want to compile TDE, you can also compile qt3 with devel enable because you 'll need to *patch* qt3 to be able to compile TDE =3.5.12 cf http://www.trinitydesktop.org/wiki/bin/view/Developers/Qt3 I'm aware of the patch needed for TDE =3.5.12, but my current interest is 3.5.12. After that when the patch is needed for future versions then I will look at applying the patch to the qt3 package. Correction: I meant to say the patch is needed for TDE 3.5.12, TDE 3.5.12 does not require it AFAIK. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] qt3-devel needed for Trinitydesktop (KDE 3.5 successor)
Quote: Colin Guthrie wrote on Fri, 25 March 2011 12:43 Freedom is in no way restricted. I see absolutely no problem with compiling a qt3 package yourself with the -devel package enabled if you want to use it. But isn't one of the reasons for participating in a community distro, wanting to share what each of us builds for ourselves? And if such sharing is being vetoed preemptively in advance without an objective reason based on facts but rather based on fears and personal opinions, isn't that an unnecessary restriction of freedom that doesn't suit a true community distro? -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] qt3-devel needed for Trinitydesktop (KDE 3.5 successor)
Quote: John Balcaen wrote on Fri, 25 March 2011 13:27 As I said earlier in this thread I have of course already rebuilt the qt3 package on my box and started working on the TDE packages (thanks to work done by Tim for Mandriva it's far easier for me now). So we can now work on next step ? I said I started working on the TDE packages, not that I have completed and fully debugged them. Right now I'm quite demotivated to continue with this since I don't see the point given that it won't be included in the repos. Xavier's post about qt3-devel are also being completely ignored and they have nothing to do with TDE, but are at least as valid. At this point I don't think there is any chance that TDE ever goes into the Mageia repos, given the attitudes I have faced here. I don't see why. Maybe because core members of Mageia have explicitly said they are against TDE being included in the Mageia repos earlier in this thread? We started a new distribution and we made choices, one of them was to not have Qt3 apps. Who is we? I don't recall any debate about this and even less a consensus being formed in the community. It's not like we were providing Qt3 others apps suddently someone decides to drop all of them from the distribution... This could be seen as arbitrary and unnecessary limitations because suddently you can loose functionnality, here we started *without* thoses because we decided to start like this. Mageia claims to be an upgrade for Mandriva, so yes, this is packages being dropped and loss of functionality for existing users, see also Xavier's posts. John, please don't get me wrong you and Blino have been some of the few voices of reason in this thread and I appreciate that. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] qt3-devel needed for Trinitydesktop (KDE 3.5 successor)
Quote: Robert Xu wrote on Fri, 25 March 2011 13:53 Hi, Based on all this conversation here, it is clear that we have gotten off topic. My suggestion would be to make a separate repository for Trinity. Beware, we also updated Qt to version 3.3.8c (just a few minor changes, no idea if bugs remain) while we finish the porting to Qt4. Thanks Robert, I might take up your offer of a repo on the Trinity servers if I decide to continue to build Trinty packages for Mageia. But right now I'm a bit demotivated to continue with this and in fact to continue with Mageia at all. Maybe I will rather help you to make some great Trinity packages for Redhat/Centos since I'm also a Redhat/Centos user, but right now I have to first make up my mind. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] qt3-devel needed for Trinitydesktop (KDE 3.5 successor)
Quote: Colin Guthrie wrote on Fri, 25 March 2011 14:36 It was Donald Knuth who said Premature optimization is the root of all evil, and the same can be said of Speculative Packaging IMO! Actually you just made my point here, excluding qt3-devel out of 'neatness' is quite clearly premature optimization, therefore the root of all evil as you wisely quote... :) -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] qt3-devel needed for Trinitydesktop (KDE 3.5 successor)
I think this thread is starting to derail from a simple technical question limted to a specific issue (reenabling qt-dev) to an ideological argument based greatly on fear and paranoia. Adding TrinityDE to Mageia, like adding any bigger software, is a gradual step by step process. I don't think anybody is planning an untested mass import of the whole load of TDE packages in one go. My idea is to first get the core TDE packages into Mageia cauldron (of course tested locally first) and then gradually look at the apps one by one (not necessarily me, any packager who is interested in TDE should of course participate). The core packages are quite limited in number (6-7 SRPMS), but already enable the use of TDE as desktop. I hope such an approach is agreeable for everyone. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Gstreamer pfl codecs/plugins
Quote: Balcaen John wrote on Thu, 10 March 2011 17:41 Le Thursday 10 March 2011 12:19:52, Tux99 a écrit : The same question also applies to mplayer, which I just noticed also doesn't include codecs like h.264 and aac. For the moment there's a work in progress regarding the BS so the package can be automatically build for core/release tainted/release on the same submission. Can you (or anyone) tell us when the build system will be ready to deal with source packages that generate both core and tainted binary packages? Is it something that's still far off (months) or will this be possible soon? -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Gstreamer pfl codecs/plugins
Quote: rdalverny wrote on Thu, 24 March 2011 14:45 On Thu, Mar 24, 2011 at 14:39, Frank Griffin f...@roadrunner.com wrote: On 03/24/2011 05:14 AM, Tux99 wrote: Can you (or anyone) tell us when the build system will be ready to deal with source packages that generate both core and tainted binary packages? Is it something that's still far off (months) or will this be possible soon? On a related issue, the wiki still states that we're not quite sure what will be in tainted. Is this supposed to be a complete replacement for PLF Mandriva, or will there be a need for a PLF Mageia as well ? http://mageia.org/wiki/doku.php?id=licensing_policy#acceptable_licenses The tainted section accepts software under a license that is might be free or open source and which cannot be redistributed publicly in certain areas in the world, or due to patents issues. and http://mageia.org/wiki/doku.php?id=mirrors_policy#tainted stuff we think we can redistribute, but that may have some patent issues or other restrictions in other countries look like consistent with each other, althought the what belongs / is allowed here must still be discussed indeed looks like it's not frozen yet. Actually I never noticed the second definition before, but the two definitions are certainly not consistent with each other, the second definition includes 'non-free' tainted software too since it only says that we can redistribute (non-free sw. is redistributable otherwise we can't have it in any repo at all). If the second definition is the valid one (I would prefer this one) then the whole recent thread about where to put tainted+non-free packages was moot, since it can go it tainted. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
[Mageia-dev] qt3-devel needed for Trinitydesktop (KDE 3.5 successor)
I noticed there is no qt-devel rpm in mageia. I looked into this further and noticed the following comment in the changelog of qt3: Revision 45543 - (view) (download) (annotate) - [select for diffs] Modified Mon Jan 31 23:32:27 2011 UTC (7 weeks, 1 day ago) by stewb Original Path: cauldron/qt3/current/SPECS/qt3.spec File length: 12804 byte(s) Diff to previous 45436 qt3 is blacklisted, build a stripped down version with no -devel (for LSB) http://svnweb.mageia.org/packages/cauldron/qt3/releases/3.3.8b/24.mga1/SPEC S/qt3.spec?view=log Can we please reenable the qt3-devel package as it's required to build the TrinityDE (www.trinitydesktop.org) Trinitydesktop is being ported to QT4 but current versions still rely on QT3 so dropping qt3-devel is premature. Thanks. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] qt3-devel needed for Trinitydesktop (KDE 3.5 successor)
Quote: tux99 wrote on Wed, 23 March 2011 13:18 Version 3.5.12 was just released a couple of weeks ago: http://www.trinitydesktop.org/releases.php Actually I confused the date :) the current version was released last October. Anyway that doesn't change the fact that QT4 support is still nowhere near (the roadmap has it for 2012) and in the meantime I would like to have the current version on Mageia. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] qt3-devel needed for Trinitydesktop (KDE 3.5 successor)
Quote: Robert Xu wrote on Wed, 23 March 2011 16:09 Trinity Qt4 support is experimental, you can see it in SVN.trinitydesktop.org I'm aware of that, that's why I said we need qt3-devel re-enabled in the QT3 package. I don't want to build the current version with experimental QT4 support. And truthfully, if you want to bring Trinity to Mageia, you should wait for release 3.5.13 - because with an autoconf 2.63, the build breaks. I'm aware of the autoconf issue but I found a workaround [1] and I have managed to build a libtqtinterface RPM so far with the workaround. Are you a TrinityDE developer? I saw your name on the trinity-dev ML. If yes then maybe you could be a great help for packaging up TrinityDE on Mageia, if you feel like helping with it. :) Do you know when 3.5.13 will be released? Is the release imminent? If it's imminent then I agree it's best to wait. [1] http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/~checkout~/packages/libtqtinter face/libtqtinterface.spec -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] qt3-devel needed for Trinitydesktop (KDE 3.5 successor)
Quote: Anne nicolas wrote on Wed, 23 March 2011 20:47 As explained by some guys before, we do not want to have both KDE3 and 4 in repository. This has been a big pain to make them live together for some months (even if it looks easy) and it has been a pain to clean repository. I know that KDE3/KDE4 coexistence was hard in the beginning in fact in Mdv 2009.0 it was a disaster, but from 2009.1 onwards it has worked perfectly. I have run a few installs (2009.1 and 2010.0) with both KDE3 and KDE4 on the same box without any issues. The existing Mandriva packages from Tim and tarakbumba are a continuation of the official Mandriva KDE3 packages so they don't have any conflicts with KDE4 anymore. Any Mageia TrinityDE packages would be derived from the Mandriva packages so just like the Mandriva packages there is no reason that there should be any problems. TrinityDE is a live FOSS project and is now completely separate from KDE, so excluding it would be like saying we don't include Gnome since we already provide KDE. Now one solution is to propose a repository dedicated to it on your side. I certainly don't have the web space and bandwidth resources for a repository and frankly I joined Mageia as a packager precisely because I thought Mageia would finally make confusing and conflicting third party repos (like Mandriva has) obsolete. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] qt3-devel needed for Trinitydesktop (KDE 3.5 successor)
Quote: Balcaen John wrote on Wed, 23 March 2011 22:05 But as i said before (like others), you should first try to build it locally, check it's working, intergrate nicely for menu,kdm then we'll start thinking about providing an alternative repository. It goes without saying that I would first build everything locally and test it, I always do that with every package I work on. But like I said, I think a separate/third party repo is a very bad idea, the whole point of Mageia was that (unlike with Mandriva) finally all contributors could join their efforts rather than having separate third party repos all over the place. If now this is no longer the case then I don't really see the point in participating in Mageia as packager. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] HALectomy on mageia ?
Quote: Thierry Vignaud wrote on Thu, 17 March 2011 08:49 On 17 March 2011 08:18, Tux99 tux99-...@uridium.org wrote: Mikala is John Balcaen (original poster) Ah ok thanks, people using sometimes real names and sometimes aliases is quite confusing... Actually you were the one sponsouring such usage :) ... Absolutely not, I always said people should be able to choose alias or real name, but use whatever they choose consistently! -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] HALectomy on mageia ?
Quote: Thierry Vignaud wrote on Thu, 17 March 2011 11:01 On 17 March 2011 09:15, Tux99 tux99-...@uridium.org wrote: Mikala is John Balcaen (original poster) Ah ok thanks, people using sometimes real names and sometimes aliases is quite confusing... Actually you were the one sponsouring such usage :) ... Absolutely not, I always said people should be able to choose alias or real name, but use whatever they choose consistently! You said you wanted to use one email for packaging and one for list. This is exactly what happens here... Huh? What has the email address got to do with the alias or real name? I don't identify people by email addresses (I doubt anyone does), but by the name that's in front of the email address and/or in the signature. to make it clear: john doe j...@dfgfgf.cg or with an alias: johnny99 j...@dfgfgf.cg It's the name that counts not the email address, I thought that's fairly obvious and it would be nice if people would always use either the nick name or the real name consistently everywhere (ML, IRC, bugtrack, forum, etc.) Email addresses are a commodity with little meaning. Anyway this is completely off-topic in this thread. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
Quote: Samuel Verschelde wrote on Thu, 17 March 2011 09:14 Well, that would be a real solution if we really wanted to flag those packages both as tainted and as non-free, as some people give more importance to the fact that it is tainted and others to the fact that it is non-free. Agreed. For now, I would propose either to put that package in non-free, explain to users that non-free packages may be tainted too, and envision after Mageia 1 to add a new media if the current solution really doesn't work, and maybe require a meta-package from tainted OR put it in tainted, explain that tainted can contain non-free packages, and require a dummy package from non- free, as Anssi proposed (on a second thought, I think that second option is better). Why a temporary solution? The longer we postpone a proper solution the messier things will get. Also I really don't like the use of a meta or dummy package, that is even messier and confusing for the users. Since tainted+non-free packages will most likely have dependencies in tainted from a practical POV that would be the best place. A dedicated tainted+non-free repo would be the cleanest solution. Putting tainted+non-free in non-free is the worst solution both because of dependency issues and because it will be messy for mirror admins. So IMHO the choice is really between putting them in tainted and then describing tainted in the policy as being for ALL tainted packages (regardless if free or non-free) or else creating the dedicated tainted+non-free repo. Can we reach a decision ? (add this question to the next packagers meeting ?) TBH I don't thing IRC is suitable for decisions where people have to spend some time thinking about the consequences of various options. Email (i.e. here on the ML) seems better to me. However, as the whole discussion seems to revolve around only one practical package, what would be even better would be convince and help upstream to solve the licensing issue (if that's feasible). This question was triggered by the first tainted+non-free package I came across (the 4th package I decided to work on). But so far I already found four tainted+non-free packages (even though two might be dropped if the FOSS replacement fully replaces them) and I don't think these will be the last ones. I haven't search for them, I only came acroos them as I wanted to package them up, and then discovered this repo issue. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] HALectomy on mageia ?
I thought there aren't supposed to be any major changes in Mageia 1? Removing HAL seem like a major change to me. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] HALectomy on mageia ?
You mean simply drop Gnome, Gimp, Gphoto, XFburn, Nut, etc. and probably not being able to build some other apps that aren't in the Mageia repos yet and might require HAL? -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] HALectomy on mageia ?
Quote: Ahmad Samir wrote on Thu, 17 March 2011 03:28 On 17 March 2011 04:08, Tux99 tux99-...@uridium.org wrote: You mean simply drop Gnome, Gimp, Gphoto, XFburn, Nut, etc. and probably not being able to build some other apps that aren't in the Mageia repos yet and might require HAL? First of all, where did mikala say anything about dropping right now? Mikala? Why do you mention him? All the apps you picked (from the Fedora page?) can probably work without hal, (e.g. I don't have haldaemon running for about 4-5 months now, and gimp works OK). I didn't pick anything, I simply listed the apps that appear as dependencies in Balcaen John's first post of this thread and asked if he meant dropping those. See here if you missed the earlier emails: http://mageia.linuxtech.net/forum/index.php?t=msgth=2540 The point is, other major distros have already gone through the halsectomy phase, which means we have very rich resources to draw on. True, but again IMHO this is a major structural change, which AFAIK isn't supposed to happen until after Mageia 1 has been released. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
Quote: Michael Scherer wrote on Tue, 15 March 2011 11:28 amrnb-7.0.0.2-2plf2011.0.src.rpm amrwb-7.0.0.3-2plf2011.0.src.rpm This one is interesting, because the whole code is free in the tarball, as this download the code from the internet at compile time. The resulting code is IMHO non-free. If you look closer you will find that the source rpm actually contains the zip file with the code that is supposed to be downloaded. It also contains a .doc that apparently is not distributable. I would suggest to drop it and to use http://sourceforge.net/projects/opencore-amr/ , which is more cleanly licensed ( Apache license ). Is opencore-amr a drop-in replacement for amrnb/amrwb for ALL packages that depend on it? A quick google search didn't turn up a lot, only that apparently gstreamer and ffmpeg can make use of opencore-amr. Is the audio quality comparable? I couldn't find any indication of that, but gstreamer has put opencore-amr into the ugly plugins, rather than bad where amrnb/amrwb are, I don't know if that's an indication of worse quality. With regards to facc there is no equivalent replacement for it and it's used by by a few projects so definitely can't be dropped. Also while the faac license is non-free, it's not a problem to distribute it, so the only problem we have is to decide where to put it (keeping in mind where packages that depend on it will go too). -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] default kde media player
Quote: Michael Scherer wrote on Tue, 15 March 2011 14:26 Good, so we are 2 in favor of dropping firefox. Now that would help a lot to get Mageia great reviews... -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] default kde media player
Quote: Maurice Batey wrote on Tue, 15 March 2011 18:54 On Tue, 15 Mar 2011 16:37:13 +0100, Tux99 wrote: so we are 2 in favor of dropping firefox. Now that would help a lot to get Mageia great reviews.. I do hope you're joking... Of course, it was pure sarcasm, as a Brit you should have spotted that. ;) -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
Quote: Michael Scherer wrote on Tue, 15 March 2011 20:21 Because some people do not care about patents and using tainted stuff, but do care about free licenses and do care about what it bring to them. I do. Stormi do ( or seems to do ). And I think that given we decided to split PLF for that precise reason, there is more than 2 of us to care. Putting tainted packages in nonfree just causes more confusion IMHO. As much as the reverse, it all depends on what you tell to people about the repository, what they expect and what you prefer to highlight. That's exactly why I suggested earlier in this thread that we need an additional repo for 'tainted+non-free' packages, that's the only solution that would satisfy every preference people might have and at the same time make things clear for everyone (packagers, mirror maintainers, users). Putting 'tainted+non-free' packages into 'non-free' is a messy unsatisfactory workaround, not a real solution. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
Quote: Michael Scherer wrote on Tue, 15 March 2011 21:30 Le mardi 15 mars 2011 à 20:34 +0100, Tux99 a écrit : Quote: Michael Scherer wrote on Tue, 15 March 2011 20:21 Because some people do not care about patents and using tainted stuff, but do care about free licenses and do care about what it bring to them. I do. Stormi do ( or seems to do ). And I think that given we decided to split PLF for that precise reason, there is more than 2 of us to care. Putting tainted packages in nonfree just causes more confusion IMHO. As much as the reverse, it all depends on what you tell to people about the repository, what they expect and what you prefer to highlight. That's exactly why I suggested earlier in this thread that we need an additional repo for 'tainted+non-free' packages, that's the only solution that would satisfy every preference people might have and at the same time make things clear for everyone (packagers, mirror maintainers, users). Instead of moving stuff in non-free, you move them in non-free + tainted. Nothing is being moved, these packages aren't in any repo yet. We are trying to decide what the best possible solution is. That just bring more headaches, and more complexity. That's not a solution. Sorry but your answer is not a proper argument, it only gives me the impression that you are summarily dismissing anything that you personally don't like and after dictating how things have to be done. Benefits of creating a separate 'tainted+non-free' as I mentioned in my previous post: - clear separation of packages based on free/no-free and tainted/no-tainted status - mirror maintainers can easily exclude tainted packages if the laws of their country require it - users can easily select packages according to their beliefs (free/non-free) or legal concerns (patent issues) Also I thought that in the debate about whether to separate 'tainted' packages that was held here on this ML in the early days, the main argument was that it should be easy for users and mirror maintainers to avoid packages with patent issues if they so wish. Your decision to put 'tainted+non-free' packages in 'non-free' completely undermines that, therefore I don't consider it a reasonable solution. From a packager point of view the best decision would be to put 'tainted+non-free' packages in 'tainted' since they are most likely to have dependencies in 'tainted'. If you don't want 'tainted+non-free' packages in 'tainted' then they might as well go in a separate 'tainted+non-free' repository, since the added complexity for the packager is the same regardless if they go in 'tainted+non-free' or 'non-free'. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
André, I agree with you, we never should have had the separation of 'tainted' (and I argued that in the early days too) but that decision was made a long time ago and is not up for debate here. With regards to open source but not FOSS, there are many types of licenses that source code can come with, not all of them meet the defintion of the free software foundation: http://www.gnu.org/philosophy/free-sw.html Those that don't meet that definition are considered non free, this is just a convention commonly used in the Linux world, personally I'm not too attached to this convention, but again this is not up for debate here. I hope this clarifies things for you! :) -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
Quote: Michael Scherer wrote on Mon, 14 March 2011 21:49 Le dimanche 13 mars 2011 à 21:09 +0100, Samuel Verschelde a écrit : Le dimanche 13 mars 2011 21:01:15, Thomas Backlund a écrit : sön 2011-03-13 klockan 21:55 +0200 skrev Tux99: During the review with my mentor Anssi of one of the packages I'm working on, the question came up what the appropriate repository for a package is that's both non-free (open source but not a FOSS license) and tainted (contains sw. that is covered by patents in some parts of the world). Should a non-free+tainted package go in tainted, i.e. is the tainted repo for all tainted packages, both free and non-free tainted, as thats a bigger issue than nonfree -- Thomas I would have said the opposite, so that using core + tainted you're sure to get free software :) The same. Ie, a non-free may have more stringent distribution requirements than a free software. I don't understand what you mean, the packages in 'non-free' are being distributed the same way as the ones in 'core' or 'tainted', i.e. on all mirrors and partially on ISOs/CDs/DVDs, otherwise we wouldn't even be able to include them in the repos at all. The issue with 'non-free' is generally one of limitations on the use of the software and/or source code not normally of distribution, in Mandriva the software with distribution restrictions normally ends up in 'restricted' not in 'non-free'. On the other hand a 'tainted+non-free' package has the bigger issue of containing patent issues (at least for some countries) so I would assume that it's a lot more important to keep 'tainted' packages clearly separate for people or mirrors that don't want to risk breaking patent laws in the affected countries. If we put 'tainted+non-free' software in 'non-free' then it will be very hard for a normal user or mirror admin to recognize it as being a potential patent liability. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
Quote: Michael Scherer wrote on Tue, 15 March 2011 00:18 Usually, people who do write non-free softwares on Linux ( like Adobe for flashplayer, Oracle for Java, etc ) are also those that do commercial business around it, and also pay the patent holder for usage, as seen when accepting the license on installation. I have the impression there is a misunderstanding, the sw you are talking about is a special case, and in the case of Adobe it's actually not open source software at all, I was talking about non-commercial open source software that has a FOSS incompatible license (and is 'tainted', i.e. with patent issues). As far as I can see most of the stuff in 'non-free' is like this, open source but with a FOSS incompatible license, not binary-only. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
I was looking at Mandriva non-free SRPM directory since Mageia doesn't have much in non-free yet. I haven't actually counted if the majority has source or not, so you might be right, but we are digressing here because like I said in the first post the question here in this thread is about a package that has code with a non-free license but is open source (and is 'tainted'). To quote my initial mail: ... what the appropriate repository for a package is that's both non-free (open source but not a FOSS license) and tainted (contains sw. that is covered by patents in some parts of the world). To complicate matters further this package will have dependencies to some other 'tainted' packages, which also a reason why 'tainted' seems more appropiate for this specifica package at least. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
[Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
During the review with my mentor Anssi of one of the packages I'm working on, the question came up what the appropriate repository for a package is that's both non-free (open source but not a FOSS license) and tainted (contains sw. that is covered by patents in some parts of the world). Should a non-free+tainted package go in tainted, i.e. is the tainted repo for all tainted packages, both free and non-free or should it go into non-free, i.e. non-free is for both unencumbered and tainted packages or do we need a separate tainted+non-free repository just like plf has? -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] [RPM] cauldron core/release playonlinux-3.8.8-2.mga1
Quote: Samuel Verschelde wrote on Sat, 12 March 2011 12:35 Then isn't the problem that wine and wine64 can't be both installed ? And isn't there a way to allow that ? but they can be, or at least the current Mageia packages allow it: $ rpm -qa|grep wine wine64-1.3.15-1.mga1 wine-gecko-1.1.0-2.mga1 wine32-1.3.15-1.mga1 lib64kwineffects1-4.6.1-1.mga1 $ I didn't force anything they both installed cleanly along each other. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] [RPM] cauldron core/release playonlinux-3.8.8-2.mga1
Quote: Ahmad Samir wrote on Sat, 12 March 2011 21:16 But you can't install 'wine' and 'wine64' at the same time. True I didn't even realise that there is also a 'wine' package in addition to 'wine64' and 'wine32'. 'wine32' seems to contain all that's needed to run win32 apps (at least I have used it here on my Mageia x86_64 box to run a few win32 apps without problems) so I haven't felt any need for this other 'wine' package so far. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
[Mageia-dev] Gstreamer pfl codecs/plugins
I noticed the gstreamer codecs included in Mageia so far are lacking all the codecs that in Mandriva are in plf, such as h.264, aac, etc. I'm aware that even in Mageia we still keep these separate in 'tainted', but I would have thought that the 'tainted' packages would be built at the same time from the same source RPMS as the 'core' ones (since the imported Mandriva SRPMs contain '%if %build_plf' for that purpose). I assume it would make most sense if the current maintainer of the gstreamer packages also submits the 'tainted' builds, or not? I'm asking this since I need the gstreamer plf/'tainted' codecs as dependencies for some other 'tainted' packages. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Gstreamer pfl codecs/plugins
The same question also applies to mplayer, which I just noticed also doesn't include codecs like h.264 and aac. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Yet another list of missing packages
Quote: Thierry Vignaud wrote on Thu, 10 March 2011 16:21 But ISApnp cards cannot be inserted in modern machines for ~8 years. Dunno until what years ISA sound chips got still implemented on motherboards. At least, I haven't seen any request for ISA support for 4-5 years. I still have an old PC with an ISA Sound Blaster AWE 64 sound card (with 12MB sample RAM expansion board) and an ISA Gravis Ultrasound PnP card (with 8MB sample RAM), currently mdv 2008.1 is installed on it and I still use it occasionally for specific purposes. I would assume that in 'poorer' countries this hardware is still common enough that we should include those packages. As long as it builds, why not? -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Yet another list of missing packages
Quote: Thierry Vignaud wrote on Thu, 10 March 2011 16:38 Indeed but that shouldn't block alpha2 Agreed And old Gravis is supposed to have better quality that quite a lot sound cards Very true, that why I'm still keeping it (it's a shame I can't use it in modern PCs anymore :( ). -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Seamonkey package
Quote: Christiaan Welvaart wrote on Thu, 10 March 2011 23:26 On Thu, 10 Mar 2011, nicolas vigier wrote: On Thu, 10 Mar 2011, Christiaan Welvaart wrote: Unfortunately the seamonkey name and logos are trademarked and the license terms are most likely not acceptable so it seems to me we'll have to rename/rebrand it. Is it different than firefox license terms ? Same rules AFAIK, see http://www.mozilla.org/foundation/trademarks/policy.html I don't see why we need to change the name. The policy says: If you compile Mozilla unmodified source code (including code and config files in the installer) and do not charge for it, you do not need additional permission from Mozilla to use the relevant Mozilla Mark(s) for your compiled version. So if you don't do any changes we can use the name Mozilla Seamonkey. Does Mandriva has an explicit permission from Mozilla? Does Mageia have an explicit permission for Firefox? -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] default kde media player
Quote: jamagallon wrote on Thu, 10 March 2011 23:38 All desktops have their own 'standard' or 'official' media players. I will talk about gnome, you can translate it to kde, for which I have no idea of which will be the equivalents. The 'offical' DE players are not necessarily the best choice. Often they are just an afterthought maintained by only few programmers without the same dedication as those people that maintain independent media players (like mplayer, vlc, xine). I have to say that vlc could be a good default choice as a video media player for Mageia (for all desktops), especially as it's well known in the Windows world too, so ideal for Linux newbies too. I also think it's best to have a default video player and a separate default audio player since IMHO there is no single player that is really good for both. My favourite audio player is Audacious. I think nowadays the default official players are capable of playing the main formats everybody will use (XVid, DiVX, h264, mpeg, mp3 or ac3 audio, etc...). It is very unlikely that Mageia will have all those codecs by default, since Mageia decided to only include codecs that are safe everywhere in the world. Personally I would have thought it would have been a great selling point for Mageia if it had included by default all codecs that are safe in France, taking advantage of the friendlier patent laws in Europe and therefore gained a competitive advantage compared to other US based/oriented distros. By the way aren't mpeg2 and ac3 covered by patents in the US too? I'm surprised these are included in Mageia. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Seamonkey package
I just downloaded the latest Seamonkey 2.0.12 SRPM from Mandriva cooker and rebuilt it on my Mageia VM and it built flawlessly, I only had to remove all the obsolete %if %mdkversion sections, but all dependecies are available in Mageia. So technically importing Seamonkey into Mageia seems straightforward, the only issue is licensing (as for Firefox). Christiaan I'm a newbie packager here at Mageia so personally I'd much prefer if you maintain this package for Mageia, it looks far too complex for me. :) -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] RPM5 AND MAGEIA
Per Øyvind, please learn the art of brevity, the more you go on and on the less people will read your writings... (no offense intended, but someone had to tell you) -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Contributors using real name/working email? or not? or maybe?
Quote: Oliver Burger wrote on Fri, 04 March 2011 12:30 Tux99 tux99-...@uridium.org schrieb am 2011-03-04 Forgot to add: the primary email address in the mageia-identity db should only be used for communication between mageia systems and the user, like bugtrack notifications, forum notifications, etc. It should not be displayed or made available to the public anywhere. Then we just kill all the efforts we made to have a single account for everything? I don't think so. I think you misunderstood me, I'm not talking about multiple accounts, just a second email address associated with the existing mageia account. After all: if you use an address in the mailing list, bugzilla etc. it is publicly displayed. So what's the matter of displaying the same adress in the changelog? I don't use the same email address on the ML as in my Mageia account (like I said I use separate email addresses for each purpose). I don't think I'm the only one here using a separate email addr for the MLs. AFAIK on bugzilla addresses are not publically displayed (they are only visible for logged in users which in my experience is enough to avoid email harvesters). -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Contributors using real name/working email? or not? or maybe?
Quote: Wolfgang Bornath wrote on Fri, 04 March 2011 13:57 My experience of the last 3 years shows that the spam I get is very low. Spam escaping Google's spam filter is around 3-4 per week. Spam in Google's spam folder is between 15-25 per day, but that does not bother me anyway. Well if you are happy with that then that's great for you. Here are the stats of my mail server for a single week: 122 received 126 delivered 0 forwarded 4 deferred (7 deferrals) 0 bounced 51124 rejected (99%) rejected is practically all spam and is a simple SMTP reject of blocked or non-existent email addresses, not content based spam filtering. Also I would not change mail addresses just because of spam. Nobody is changing email addresses, read the yahoo link it's just variations of the same address, your basic address stays the same. excessive spam I'd rather use other means like a good spam filter and/or a tar pit or whatever. I'm not used to let spammers rule my mail system. Exactly, spam filters use up plenty cpu cycles (which is a problem when you run your own server), delay mails (when using greylisting) and therefore would rule the mail system as you say (not to mention having to deal with false positives or false negatives), using multiple addresses is dead easy and much less hassle once you understand the system and get used to it. I don't have a spam folder or spam filter at all, since I get maybe 1 or 2 spam emails a week with this system. Anyway I have no intention of converting or convincing you of anything, just accept that there are other ways to deal with email that are equally good, that other people use. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Contributors using real name/working email? or not? or maybe?
Quote: Wolfgang Bornath wrote on Fri, 04 March 2011 15:49 Our mailserver (catering to @mandrivauser.de) does not show such figures. The percentage of our mailserver shows 56.16% accepted, 43.84 rejected. Of these accepted mails our spam filter shows 20% spam (average). Accordingly the server does not waste recognizable power on the mail system. Maybe with such a setup as yours and such results I may think about changing something, I'd not accept such a situation. Wobo you completely missread the situation, it's your server setup that could still be improved since yours is still accepting spam (which then has to be filtered out at a higher cpu cost later on), my server is rejecting pratically all spam at the initial SMTP stage, there is nothing more efficient than that. Anyway like you said this is OT here, if you want mail me privately to continue this. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Contributors using real name/working email? or not? or maybe?
Quote: Maarten Vanraes wrote on Fri, 04 March 2011 19:15 to be honest, i reread this thread a few times, and i have no idea... i clarified my point, but i donno why i was making such a point in the first place, cause it doesn't seem to make any sense... Hmmm, it's Friday evening, I guess the beer is starting to kick in ;)) -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
[Mageia-dev] Seamonkey package
I was wondering if any packager is planning to import and maintain Seamonkey for Mageia. If nobody wants to do it I might consider it, but since it's quite a complex package I'd prefer if someone with more experience than me does it! :) -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Contributors using real name/working email? or not? or maybe?
Romain you forgot to specify that currently aliases are used in the Mageia packages and no email addresses are included. So the discussion started because some people wanted to change this. Well, I repeat my point of view as posted in the other thread: - each packager should be free to decide his identity (i.e. whether to use his real name or alias) creating to many unnecessary rules will just alienate people and a don't think Mageia can afford that - while I'm rather against having an email address in the package changelog entries as it encourages users to contact packagers directly via private email rather than going through the proper support channels, I don't really mind too much as long as we can use a mageia.org forwarding email address (which would be the best anyway since it would make the package look more official) -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Contributors using real name/working email? or not? or maybe?
Quote: rdalverny wrote on Thu, 03 March 2011 15:27 So that's already a significant difference from the previous discussion... It's not, I said that in the other thread too but obviously you never read my posts: http://mageia.linuxtech.net/forum/index.php?t=msgth=2367goto=7691 S=afd88a4d2231b75d6972d47e8e8c5742#msg_7691 If the majority of packagers prefer that we have an email address in the changelog then i can live with that, but I would much prefer if I could use a separate email address for that (ideally a mageia.org address, BTW are we getting those?), not the primary one in mageia-identity. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Contributors using real name/working email? or not? or maybe?
Quote: Thomas Backlund wrote on Thu, 03 March 2011 17:21 Signed-off-by: Random J Developer ran...@developer.example.org using your real name (sorry, no pseudonyms or anonymous contributions.) The Linux kernel has more than enough contributors so it can afford to introduce hurdles that will stop some contributor from contributing, but I still consider this is against the spirit of FOSS which relies also in considerable part on spontaneous one-off contributions (especially for bug fixes). Do you think Mageia has more than enough packagers that it's ok to lose some due to unnecessary strict rules? -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] freedesktop spec and categories
Quote: Michael Scherer wrote on Thu, 24 February 2011 13:27 Le jeudi 24 février 2011 à 10:06 +0100, Samuel Verschelde a écrit : I don't think so. Several Mandriva releases ago, there was no such More entry, but real sub-categories in the menu. Then it changed for what we have now, but that wasn't a change in the .desktop files, rather a menu configuration. I guess that was a decision meant to bring simplicity, Yes, and that's a choice that can be backed by several studies on the subject, the working memory have been estimated to be 7 chunks of information ( between 5 and 9 is a wildly accepted range ). I remember having seen a studie saying that it was less than this, but I cannot find it ( and it was on slashdot, so this may have been wrong ). So presenting only ~7 chunks of information ( ie ~7 items in menu ) is better according to the current cognitive model used, such as this one : http://en.wikipedia.org/wiki/Human_information_processor_model The study that estimates the number of chunks of information a normal human can keep in working memory might be correct, but it's applied in a completely unfitting situation here. Scanning a list of program names has nothing to do keeping chunks of info in the brain. I'm pretty sure that if we make a survey among Mandriva users the majority will be saying they don't like apps hidden behind More as it currently happens, they would want them in the higher level with all the other apps of the same type. Every Mandriva user I know (regarless if a complete noob or an IT literate person) finds the More.. folder confusing and counterintuitive and without any benefit. I would actually think this is one of those things where a poll among users would make sense, since it doesn't really have technical implications either way. Another solution would be to make it a configurable user preference, but of course that would require someone to write the necessary code, so that's not such an immediate solution as changing the config. BTW: can anyone tell me where exactly this More folder behaviour is configured? -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
Quote: Thomas Backlund wrote on Sun, 20 February 2011 19:48 It is an abuse yes, but the great thing about it is we _know_ it works... so no surprises... (if it aint broken...) Agreed, the automatic preference of urpmi for plf when plf is enabled is something I have always appreciated on Mandriva, so I would prefer if we keep it similar in Mageia. The only plf package (and I make heavy use of plf packages) I ever had to put in skip.list was libfreetype since the mdv one rendered fonts better on my hardware. Well, the old simple logic works... lets say we abuse the release tag, for example changing mga to mgt then if the user enables tainted (meaning he/she wants the rpms) urpmi will automatically get the mgt ones, no questions asked... simple, and effective. mga / mgt seems the best solution to me, just like Thomas says: simple and effective! -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] freedesktop spec and categories
I have always hated that apps 'disappear' in the Other folders, can we not completely get rid of the Other folders, they don't make any sense (at least intuitively for a user). -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] freedesktop spec and categories
Quote: tux99 wrote on Thu, 24 February 2011 08:20 I have always hated that apps 'disappear' in the Other folders, can we not completely get rid of the Other folders, they don't make any sense (at least intuitively for a user). Sorry, forget my comment, I was confusing the Other subcategory with the More subcategories that keep getting spawned randomly without any logic (from a user point of view). It's the More subcategories that I think should be abolished. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Mageia ISO corrupted?
Quote: Marcello Anni wrote on Wed, 16 February 2011 19:27 so i think it is really corrupted. no other one downloaded the alpha from that mirror? do you know another fast mirror? i tried distrib-coffee.ipsl.jussieu.fr but it is very slow... I downloaded from ibiblio too and checksums are fine for me, so it must be a problem local to you. $ md5sum -c mageia-dvd-1-i586.iso.md5 mageia-dvd-1-i586.iso: OK $ md5sum -c mageia-dvd-1-x86_64.iso.md5 mageia-dvd-1-x86_64.iso: OK -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] mageia sound tasks
On Sun, 19 Dec 2010, andre999 wrote: Sascha Schneider a écrit : Would it be a idea to add this topic to the mageiauser.org http://mageiauser.org and alter the initial post with the inputs of the ML and irc's?? This way we could also include inputs from other irc's or forums, like linuxaudio.org http://linuxaudio.org, #linuxmao, #lau, #opensourcemusician etc ... regards, sascha Just a personal reaction ... There doesn't seem to be a place on the mageia wiki at the moment, which is focused on setting up and getting the first release out. However using the forum at mageiausers.org sounds like a good idea. (BTW, note that it is mageiauserS.org, with an S.) Developing ideas on a mailing list tends to get a bit complicated. I agree, I think too that we should make use of the mageiausers.org forum at least until the official Mageia forum is up and running.
Re: [Mageia-dev] mageia sound tasks
Just to add: I don't like the idea of a spin-off or separate ISO as those usually end up as unmaintained dead-ends and also most people don't have separate dedicated PC for audio/video tasks but would rather do it on their 'normal' PC. Of course anyone is free to do a spin-off or ISO, but personally I won't be contributing to that, my interest lies in the development of one or more dedicated task rpms. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] mageia sound tasks
Quote: Ahmad Samir wrote on Sat, 18 December 2010 15:30 That's exactly what a ML is for, parallel discussions each ideally contained in a thread of its own; that's what I was pointing out. Sure, I was just suggesting an alternative in case this ML becomes too high-traffic, I guess we all know that high traffic MLs are not very efficient, posts get lost in the noise. To put things in perspective, here's what Michael said: And secondary, I think we should also try to avoid having too much task- rpms. Their values is in the fact they allow to quickly install a set of rpm without searching in the whole set of rpm. If there is too much of them, people while end searching in the various task-* rpms, and that seems counter productive at best. ( ie, searching the task rpm they want to avoid searching rpm they want directly ... ). Doesn't look dismissive to me, he stated rather clearly why he's against having too many task/meta packages. I consider it very dismissive and furthermore the argument that too many task-rpms are confusing is pointless (one more task rpm doesn't mean too many and who is to decide what's too many, how long is a piece of string?) and very dismissive (a volunteer and new poster offering to do something that other users will appreciate immediately get's confronted with the exagerated argument that what he wants to do will cause too much clutter...). Anyway, like I said I think we should be following more the principle of 'live and let live' rather than 'lowest common denominator' here. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] First packagers meeting
Could these meetings in the future please be announced with a bit more notice? One day before is not enough time, I wasn't able to read ML mail in the past two days, only saw this now and already missed it... :-( Thanks in advance! On Tue, 14 Dec 2010, Anne nicolas wrote: Hi there! As you may have noticed, Mageia teams creation is in progress. i18n has just started last week. It's now packagers turn. You have registered on wiki: http://mageia.org/wiki/doku.php?id=packaging. Please have a look on this page. You will find very first items to setup this team. mageia-dev will be the official mailing-list for packagers. So if you know people who want to become packagers and who are not registered, please inform them about it. First packagers meeting will happen on 15, december 19h30 UTC on #mageia-dev. Here are the topics to start with: - quick introduction of people attending meeting - setup internal organization: meetings planning, representatives, relations with other Mageia teams to synchronize work - setup mentoring for incoming packagers (who, when, how...) - work on packaging policies, starting from Mandriva Linux policies - work on mentoring process to make life easier for mentors - organize work for packages import in Mageia svn Feel free to comment before meeting. We will have a bot to log our meeting. See you on Wednesday
Re: [Mageia-dev] Mirror tree structure
On Wed, 20 Oct 2010, Olivier Thauvin wrote: Hi, You can find here: http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/ the current mirror tree proposal. We now have to discuss it, I think. Looks great to me and I agree with all points you made in your email. I especially like the provision of the people (no 's'!) and software directory, seem like a good idea to me.
Re: [Mageia-dev] How will be the realese cycle?
On Wed, 20 Oct 2010, Robert Xu wrote: On Wed, Oct 20, 2010 at 12:25, Wolfgang Bornath molc...@googlemail.com wrote: 2010/10/20 Robert Xu rob...@gmail.com: Maybe you could modify it to give a personal UUID for each computer, so that the user is not forced to register? OMG! I would have gathered at least 10 UUIDs over the last 2 years. Depends on what piece of hardware you want to attach the UUID to :) Reminds me of the Windows registration system. haha, same. :) Er, I guess that could become a problem later... Maybe one month every year you refresh the UUIDs by having the software send their UUID? That way any inactive UUIDs could be deleted. I hope you are not serious about this. Creepy unique identifiers (or any other tracking method) have absolutely no place in a FOSS community OS.
Re: [Mageia-dev] How will be the realese cycle?
On Sun, 17 Oct 2010, David W. Hodgins wrote: I know enough c, perl, python, etc., that I can sometimes figure out where the problem is, (when submitting bug reports), but I don't know enough to put together rpm packages, or where to start, to learn how to do so. Making rpm packages is actually a lot easier than writing C, Perl or Python code, so with your background it would be very easy for you to learn how to make a package. Have a look here, these instructions explain it well, I learnt it from there: http://wiki.mandriva.com/en/Development/Howto/RPM
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
On Fri, 15 Oct 2010, yvan munoz wrote: I think all non-free could be supported directly by users and accessibles through users repo. Not in (only one please) Mageia Repo. And Users Repo could contains drivers, patent-troll techno, flash, etc, in additon with more classicals softwares into users repo. Mageia is a community distro which means made by users for users. Therefore a separate 'user' repo makes no sense at all, all Mageia repos are user repos. And if you are such a freedom advocate then you should respect freedom OF CHOICE for other users too, you don't have to install the non-libre software that might be in the repos or on the isos.
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
On Fri, 15 Oct 2010, Wolfgang Bornath wrote: As mirror maintainer/owner of Mandriva Linux and future Mageia (ftp.mandrivauser.de) I discussed this problem with my friends and we decided not to mirror PLF although a German university does (ftp.gwdg.de). The point is that our mirror is hosted on a private server where just one person is liable (me, unfortunately). But we also decided to mirror the non-free branch of Mandriva Linux. There is non-free and there is patented and/or legally unclear software - we will definitely stay away from the latter when mirroring Mageia. Making a difference between such software on the parent mirror will make it easy for mirrors such as ours. Distributing such software in the same branches as normal software will make it impossible to mirror Mageia. wobo, I perfectly understand your reasons especially since as you say the server is privately owned by you, not an association or a company. OTOH I think your worry is unfounded, the patent issues are mostly US issues, not so much European issues. Also separating out packages will be very difficult (I would say impossible) since not even lawyers can know for sure which software has patent issues and which one not. It's not just a problem with codecs, ANY software could have patent issues (in the US at least). For example Microsoft is claiming that the Linux kernel is in breach of several patents help by Microsoft. Do you want to not mirror the kernel?
Re: [Mageia-dev] How will be the realese cycle?
Quote: Buchan Milne wrote on Thu, 14 October 2010 15:27 What aspects of the Mandriva backports solution are not satisfactory? -The fact that not everything is available as a backport? Yes, more packages should be available (and as future packager I will do my part to make that happen) -That users don't know how to request a backport? It certainly could help publicizing backports and giving the user an easy way to request specific packages -That users doing network installs by default don't get the backport on initial installation? That would be very useful as it reduces bandwidth and speed up installation. -That users aren't aware of backports? Yes, backports should be promoted better in drakrpm and in the web site. -Something else? backports should be supported for security patches and bug fixes just like the main packages (if not instead of the main packages). Of course the security patch could be simply provided by backporting a newer version of the package, no need to make patches for each version. The end users need to do less than now for to get new versions of their favourites applications. Less than 'urpmi --searchmedia Backports chromium' ? CLI is not ideal for 'normal' users. Or, should it be more obvious in rpmdrake or similar? I think they should be enabled by default, since it's my impression that the majority of 'normal' users wants new versions of apps, those users who DON'T want them can still always disable them. Backports shouldn't be second choice, it should be the default, since that would make Mageia stand out from other distros as being the distro were users get the latest versions of apps before any other major distro provides them. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] How will be the realese cycle?
Just to add to my last post: It would be useful if users could disable specifc packages from being updated via the update GUI. What I mean is basically when new updates get presented (which would include new backports) the user could untick specific packages (as is possible now) but also have a second tick-box to store the choice permanently in the skip.list. This would give the user more choice of which packages he wants to always update to the newest version and wich ones he/she prefers to keep frozen at the same version. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] How will be the realese cycle?
Quote: marc wrote on Thu, 14 October 2010 15:49 Is it me or is the poll different? The overall feeling on the Spanish Blogdrake is to like Mandriva a stable system with upgrades and backports at 58%. I imagine this means keeping to Mandriva release cycle with no changes. Wouldn't it make sense to have the same poll? I guess, this way we still get the results of a poll and a sense of the community feeling anyway. I guess the old rule of polls applies: depending on how you formulate the poll question and the description of the options you can hugely influence the results... Personally I think a poll without educating everyone about what exactly each choice would mean is useless. We first need to elaborate detailed alternatives before anyone can make an informed choice. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] How will be the realese cycle?
Quote: Ahmad Samir wrote on Thu, 14 October 2010 16:00 I've seen, too many times, trigger-happy packagers backporting packages that're not maintained by them (so they know it less than those package maintainer(s)), breaking those packages and annoying the maintainers of said packages. It's usually irresponsible to backport a package without taking that package maintainer's opinion into account. (an infamous example on that is gwibber being backported to 2010.1). I agree it should be preferably the maintainer doing the backport, or he should at least be consulted. New users who frequented the forums always got to know what backports are pretty fast. And bugzilla is the perfect system for asking for a backport, that worked pretty good. The wast majority of 'normal' users never uses the forum. Backports shouldn't be something that only users who frequent the forum find out about. That's they way backports has always worked, no specific patches, just the latest cooker package pushed to backports as is with no official support, that's reasonable, packagers shouldn't promise to support backports when they can't due to various reasons (time, effort.. etc). But IMHO that should change in Mageia, we should promise support by the way of timely updates, especially when security issues are present. Backports shouldn't be second choice, it should be the default, since that would make Mageia stand out from other distros as being the distro were users get the latest versions of apps before any other major distro provides them. Enabling them by default defies the purpose of having backports at all; it's not for new users, it's more for slightly experienced users or power users who want the latest versions of apps. That's exactly the crucial bit that IMHO needs to change, backports are very interesting for 'normal' users so we should make sure normal users can use them. Don't you see how attractive it is especially for 'normal' users to have access to the latest versions all the time? Sure, not everyone wants them, but by integrating the skip.list in the update GUI we could keep 'conservative' users happy too. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] How will be the realese cycle?
Quote: Ahmad Samir wrote on Thu, 14 October 2010 16:21 Then you're not talking about new users any more... I don't know what you mean by new users, but I was talking about 'normal' user by which I mean general users without technical background (like my wife for example :) ), people that have used a computer before, but not necessarily with Linux, just an average Windows user for example. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] How will be the realese cycle?
On Thu, 14 Oct 2010, nicolas vigier wrote: On Thu, 14 Oct 2010, Tux99 wrote: I think they should be enabled by default, since it's my impression that the majority of 'normal' users wants new versions of apps, those users who DON'T want them can still always disable them. If backports repository is enabled by default, it should be stable. How do you garantee that backports will never break ? Nicolas, please re-read old posts of this thread we discussed this already, the conclusion was that there are no guarantees in life. Experience tells us backports don't normally break any more than the regular security/bugfix updates. Backports shouldn't be second choice, it should be the default, since that would make Mageia stand out from other distros as being the distro were users get the latest versions of apps before any other major distro provides them. Just providing the latest version of apps is not enough to stand out from other distros. I didn't say this should be the ONLY unique feature of Mageia. All distros could do it, and they usually already do it in their developement version. But the problem is always the same: adding new versions create instability. All distros COULD do it but they don't, the dev version doesn't count as that is obviously much more unstable, since it's meant for experimenting. Providing new versions usually gives MORE stability since newer version normally include loads of bug fixes too, but again we debated this already, see old posts in this thread.
Re: [Mageia-dev] How will be the realese cycle?
On Thu, 14 Oct 2010, Maurice Batey wrote: However, I then found that the new version of VLC had problems with DVD menus, and the new CUPS introduced problems (not just in my installation but at least one other Mandriva user). I would put this down to the fact that currently in Mandriva backports are given little attention by the packagers (as has been mentioned by the Mandriva packagers here themselves). Of course if we make them more central to the Mageia strategy then more care and testing is needed before a backport is pushed out. So I wouldn't consider that a fundamental issue with backports, just a procedural issue. Also personally I would consider CUPS a core app so I wouldn't have included that in backports at all.
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
Quote: Ahmad Samir wrote on Tue, 12 October 2010 18:07 Mageia won't be installed only in France; those patents still apply in other countries so not all patent restrictions can be dropped. Nobody know the laws of every country in the world. Just because some software might be covered by patents in a FEW countries, you want to make users in the rest of the world suffer the inconvenience of not having proper multimedia support out of the box? I think Mageia should include as much multimedia codecs as possible, it the user's responsibility to know the laws of his/her country and if necessary uninstall anything unlicensed/illegal in his/her country. -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
Quote: marc wrote on Tue, 12 October 2010 18:42 Unfortunately, if this is done, I will no longer be able to install legally any Mageia due to our laws. I think it is best if these are not installed but let users know where to get them, mostly through PLF. How do you expect Mageia to verify each single package to make sure it complies with the laws in ALL countries of the world? Mageia should make sure that the packages comply with French law, but that's it. You can still install Mageia and then remove the packages that are problematic in your country, I very much doubt your laws are that draconian that you can't even do that. Mageia could include an option during install to exclude the well-known problematic packages from installation to make this easier for people that live in countries with restrictive laws. When I install Mandriva Free for people, I will let them know where the PLF repos are and the files needed and they install these themselves. This is a major hassle for new/inexperienced users and IMHO should be avoided. If Mageia packages include unlicensed software and codecs, the Mageia brand may be held legally responsible for marketing software in countries where the laws do not permit this. This is nonsense, Mageia can only be held responsible in France based on French law (as long as Mageia isn't planning subsidiaries in outher countries, which IMHO is unlikely and completely unnecessary for a non-profit association). -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
Quote: Ahmad Samir wrote on Tue, 12 October 2010 19:08 How do you think packages were done in Mandriva (and other distros) all those years? Mandriva was a commercial company with ambitions to sell it's products commercial all over the world, that's a completely different situation to Mageia. Sure, Mageia won't be held responsible, only the users deploying it in other countries where those laws apply. You also have to bear in mind school/university labs, companies.. etc. Like I suggested earlier, during install there can be an option to include/exclude well known problematic packages. And yes, end users will ALWAYS be responsible for what they install/use, regardless what Mageia includes in the default install, Mageia (or anyone else) cannot take that responsibility away from the user. Besides that I have never heard of a private person being sued for using unlicensed patented codecs, not even in the US and most US Linux users install them anyway from plf (or similar repos of other distros). Regardless of that no company/school/university will just do a default install (regardless if we include plf packages), they will always have to do their own custom selection based on their on internal regulations anyway (in addition to local laws). -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
