Re: [Mageia-dev] Flash player 11
On Thu, 14 Jul 2011 20:09:18 -0400, Charles A Edwards c...@eslrahc.com wrote: Flash Player 11 Beta 1 is now available. http://labs.adobe.com/downloads/flashplayer11.html This release offers Both 32 and 64 bit support. Already raised as a bug report https://bugs.mageia.org/show_bug.cgi?id=2146 Regards, Dave Hodgins
Re: [Mageia-dev] [Mageia 2 specifications] Systemd or not systemd
On Thu, 14 Jul 2011, Eugeni Dodonov wrote: On Thu, Jul 14, 2011 at 20:08, Olivier Blin mag...@blino.org wrote: Option 2 seems good as well, but does it really have to uninstall sysvinit? Isn't it enough to put some alternatives symlinks for /sbin/init? This is actually a great idea! A perfect candidate for update-alternatives, thanks, I haven't thought on that! Alternatives is not the most reliable system so it should not be used for /sbin/init. You could make 2 conflicting packages that only contain a /sbin/init symlink and provide something which basesystem depends on. Christiaan
Re: [Mageia-dev] proposal regarding (packager) mentoring program coordinator
In data mercoledì 29 giugno 2011 23:27:08, andre999 ha scritto: Any suggestions are welcome. Hi, I speak for myself, one silly suggestion, can you add links of wiki pages you talk about in the bottom of your mails? For one who reads mail when he/she can, like me, it could be easier to check the state of the art by clicking the links especially if he/she reads the thread some days later and the discussion has been almost to the end. Thanks -- Angelo signature.asc Description: This is a digitally signed message part.
[Mageia-dev] Adobe Flash player 11 Beta 1 in Cauldron
Hello. As you've seen the thread, posted by Charles A Edwards, there's a new version of flash which has native 64bit support, it's still in beta but seems to work well, some questions: - Any objections about offering it in mga1? on x86_64 only and keeping the 32bit stable one as is for now; not having to install nspluginwrapper or a 32bit browser on a 64bit system is an improvement, IMHO. - For Cauldron: o Do we ship the 11 beta1 for both arch? o Just x86_64 and keep the 32bit stable flash for now o Keep the 32bit stable and create another spec (Name: flash-player-pluing11) for 11 beta1? this way 32bit users will have a choice to install the version they want. WDYT? -- Ahmad Samir
Re: [Mageia-dev] new mgarepo version
On 13 July 2011 00:30, nicolas vigier bo...@mars-attacks.org wrote: Hello. mgarepo version 1.9.11 adds maintdb command : $ mgarepo maintdb --help Usage: Take maintainership of one package : mgarepo maintdb set [package] [login] Remove yourself from maintainer of a package : mgarepo maintdb set [package] nobody See who is maintainer of a package : mgarepo maintdb get [package] See the list of all packages with their maintainer : mgarepo maintdb get Works OK, thanks. -- Ahmad Samir
Re: [Mageia-dev] Adobe Flash player 11 Beta 1 in Cauldron
'Twas brillig, and Ahmad Samir at 15/07/11 09:10 did gyre and gimble: Hello. As you've seen the thread, posted by Charles A Edwards, there's a new version of flash which has native 64bit support, it's still in beta but seems to work well, some questions: - Any objections about offering it in mga1? on x86_64 only and keeping the 32bit stable one as is for now; not having to install nspluginwrapper or a 32bit browser on a 64bit system is an improvement, IMHO. I'd offer it in main/testing for both arches personally... breaking the rules somewhat but it does at least make life easier for debugging and triaging anyway to keep things consistent on both arches. - For Cauldron: o Do we ship the 11 beta1 for both arch? Yes (IMO) Col -- Colin Guthrie mageia(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
Re: [Mageia-dev] Adobe Flash player 11 Beta 1 in Cauldron
On 15 July 2011 11:34, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and Ahmad Samir at 15/07/11 09:10 did gyre and gimble: Hello. As you've seen the thread, posted by Charles A Edwards, there's a new version of flash which has native 64bit support, it's still in beta but seems to work well, some questions: - Any objections about offering it in mga1? on x86_64 only and keeping the 32bit stable one as is for now; not having to install nspluginwrapper or a 32bit browser on a 64bit system is an improvement, IMHO. I'd offer it in main/testing for both arches personally... breaking the rules somewhat but it does at least make life easier for debugging and triaging anyway to keep things consistent on both arches. But it's still a beta, with a it'll be release before the end of 2011 which is pretty elastic in terms of ETA - For Cauldron: o Do we ship the 11 beta1 for both arch? Yes (IMO) Col -- Colin Guthrie mageia(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] -- Ahmad Samir
Re: [Mageia-dev] Adobe Flash player 11 Beta 1 in Cauldron
venerdì 15 luglio 2011 alle 10:10, Ahmad Samir ha scritto: Hello. As you've seen the thread, posted by Charles A Edwards, there's a new version of flash which has native 64bit support, it's still in beta but seems to work well, some questions: - Any objections about offering it in mga1? on x86_64 only and keeping the 32bit stable one as is for now; not having to install nspluginwrapper or a 32bit browser on a 64bit system is an improvement, IMHO. I'm in favour with some doubts though. Some people think mageia is quiet... so maybe we should start to increase updates/backports and improving people feelings... I say that without using that much mga1, but some days ago updates were so little... The big problem with this package though is that if it is buggy and moreover for security reasons, it isn't so upstream responsive, at least for x86_64 till now... - For Cauldron: o Do we ship the 11 beta1 for both arch? i vote for that, cauldron is cauldron and we can revert or change things before freeze time, some months of testing will show us upstream movements also... Angelo signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] [Mageia 2 specifications] Systemd or not systemd
'Twas brillig, and Eugeni Dodonov at 14/07/11 23:40 did gyre and gimble: On Thu, Jul 14, 2011 at 18:26, Colin Guthrie mag...@colin.guthr.ie mailto:mag...@colin.guthr.ie wrote: Systemd 30 is out, with lots of nice changes, so I think we should use it now as we are quite early in the release cycle. It is working on my machine, but before doing something about it, I prefer to hear opinions :). Well, IMO (for what it matters) I'm massive for using it ASAP! Ok, systemd 30 is in svn, and (apparently) working, at least on my machine. However, as I will have a limited Internet connection between tomorrow and next week, I am not feeling that safe to send it to cooker. So if someone (colin?) would be able to do some additional testing with it before submitting, it would be great :). OK, I tried to compile it up locally, but it didn't build: checking for m4... /usr/bin/m4 configure: creating ./config.status config.status: creating Makefile config.status: creating po/Makefile.in config.status: creating config.h config.status: executing depfiles commands config.status: executing libtool commands config.status: executing po/stamp-it commands configure: WARNING: unrecognized options: --with-syslog-service systemd 30 Distribution:mageia SysV compatibility: yes SysV init scripts: /etc/rc.d/init.d SysV rc?.d directories: /etc/rc.d Gtk: yes libcryptsetup: no tcpwrap: yes PAM: yes AUDIT: yes SELinux: no ACL: yes binfmt: yes plymouth:yes prefix: /usr root dir: udev rules dir: /lib/udev/rules.d pam modules dir: /lib/../lib64/security dbus policy dir: /etc/dbus-1/system.d dbus session dir:/usr/share/dbus-1/services dbus system dir: /usr/share/dbus-1/services/../system-services dbus interfaces dir: /usr/share/dbus-1/services/../interfaces + make -j2 Makefile:7228: *** missing separator. Stop. error: Bad exit status from /home/colin/rpm/tmp/rpm-tmp.vn9NeJ (%build) RPM build errors: Bad exit status from /home/colin/rpm/tmp/rpm-tmp.vn9NeJ (%build) This appears to be the result of some tab/spaces mixup in the Makefile.am patch, so I've fixed that up. Next problem as a TARGET_MANDRIVA define rather than a TARGET_MAGEIA one (easily done), so I tweaked that too. Then there was a syntax error with an #ifndef line in service.c so fixed that up. Now that it's compiled, I need to test it :D (I've pushed the updated patch back to SVN, but you probably want to update your git checkout before regenerating and posting the patch upstream) Col -- Colin Guthrie mageia(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
Re: [Mageia-dev] Adobe Flash player 11 Beta 1 in Cauldron
2011/7/15 Ahmad Samir ahmadsamir3...@gmail.com Hello. - Any objections about offering it in mga1? No I agree. - For Cauldron: o Do we ship the 11 beta1 for both arch? I vote for that. WDYT? -- Ahmad Samir I think, as Angelo wrote, that the updates for mga1 should be increased, and that's why I'll start to help the QA team to test packages. -- Thanks Stblack
Re: [Mageia-dev] Adobe Flash player 11 Beta 1 in Cauldron
On 15 July 2011 11:55, Angelo Naselli anase...@linux.it wrote: venerdì 15 luglio 2011 alle 10:10, Ahmad Samir ha scritto: Hello. As you've seen the thread, posted by Charles A Edwards, there's a new version of flash which has native 64bit support, it's still in beta but seems to work well, some questions: - Any objections about offering it in mga1? on x86_64 only and keeping the 32bit stable one as is for now; not having to install nspluginwrapper or a 32bit browser on a 64bit system is an improvement, IMHO. I'm in favour with some doubts though. Some people think mageia is quiet... so maybe we should start to increase updates/backports and improving people feelings... You mean create hype with updates? just updating for updating's sake is not useful, for me at least, unless an update fixes a bug in a package I am using. I say that without using that much mga1, but some days ago updates were so little... The big problem with this package though is that if it is buggy and moreover for security reasons, it isn't so upstream responsive, at least for x86_64 till now... I don't have hard numbers, but my guess would be that a lot of x86_64 users are already using the 11 beta1. adding it in the repos is just a convenience sort of thing (the same with packaging a binary blob that doesn't need compiling... even more so if the package in question is a skeleton package that downloads a tarball/rpm from upstream when the user installs a package). - For Cauldron: o Do we ship the 11 beta1 for both arch? i vote for that, cauldron is cauldron and we can revert or change things before freeze time, some months of testing will show us upstream movements also... [] Angelo -- Ahmad Samir
Re: [Mageia-dev] Adobe Flash player 11 Beta 1 in Cauldron
venerdì 15 luglio 2011 alle 12:37, Ahmad Samir ha scritto: Some people think mageia is quiet... so maybe we should start to increase updates/backports and improving people feelings... You mean create hype with updates? just updating for updating's sake is not useful, for me at least, unless an update fixes a bug in a package I am using. agree with that, what i meant is just improving our update process we're focusing on packaging mentoring maybe we should do more on QA... don't know, what i mean is let's see we're alive... Note that i know we are... ;) Angelo signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] Adobe Flash player 11 Beta 1 in Cauldron
On Fri, 15 Jul 2011 13:37:49 +0300 Ahmad Samir ahmadsamir3...@gmail.com wrote: On 15 July 2011 11:55, Angelo Naselli anase...@linux.it wrote: venerdì 15 luglio 2011 alle 10:10, Ahmad Samir ha scritto: Hello. As you've seen the thread, posted by Charles A Edwards, there's a new version of flash which has native 64bit support, it's still in beta but seems to work well, some questions: - Any objections about offering it in mga1? on x86_64 only and keeping the 32bit stable one as is for now; not having to install nspluginwrapper or a 32bit browser on a 64bit system is an improvement, IMHO. I'm in favour with some doubts though. Some people think mageia is quiet... so maybe we should start to increase updates/backports and improving people feelings... You mean create hype with updates? just updating for updating's sake is not useful, for me at least, unless an update fixes a bug in a package I am using. Quiet is good! As long as all bugs and security issues are fixed, why make unnecessary noise? -- Margot ~~ **Otford Ducks Computers** We teach, you learn... ...and, if you don't do your homework, we set the cat on you! ~~
Re: [Mageia-dev] Adobe Flash player 11 Beta 1 in Cauldron
Ahmad Samir skrev 15.7.2011 12:43: On 15 July 2011 11:34, Colin Guthriemag...@colin.guthr.ie wrote: I'd offer it in main/testing for both arches personally... breaking the rules somewhat but it does at least make life easier for debugging and triaging anyway to keep things consistent on both arches. But it's still a beta, with a it'll be release before the end of 2011 which is pretty elastic in terms of ETA _if_ we provide it for mageia 1, it belongs in backports(_testing), not updates(_testing) -- Thomas
Re: [Mageia-dev] Adobe Flash player 11 Beta 1 in Cauldron
On 15 July 2011 14:17, Thomas Backlund t...@mageia.org wrote: Ahmad Samir skrev 15.7.2011 12:43: On 15 July 2011 11:34, Colin Guthriemag...@colin.guthr.ie wrote: I'd offer it in main/testing for both arches personally... breaking the rules somewhat but it does at least make life easier for debugging and triaging anyway to keep things consistent on both arches. But it's still a beta, with a it'll be release before the end of 2011 which is pretty elastic in terms of ETA _if_ we provide it for mageia 1, it belongs in backports(_testing), not updates(_testing) Good point, I didn't say where I'd submit it (but somehow I was thinking updates_testing...), you're right, should be backports. -- Thomas -- Ahmad Samir
[Mageia-dev] Broken BS
hi, the BS is currently broken, i will in some seconds work to fix it.
[Mageia-dev] BS fixed
Hello, the BS is now fixed, you can work and push again new stuffs
Re: [Mageia-dev] [Mageia 2 specifications] Systemd or not systemd
'Twas brillig, and Colin Guthrie at 15/07/11 11:01 did gyre and gimble: Now that it's compiled, I need to test it :D Well it boots. And I have network connections! I have a problem where bluetoothd does not start but I'll solve that one at some point (it was a problem when I last used systemd too!) The various issues can now be solved as we go! Col -- Colin Guthrie mageia(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
Re: [Mageia-dev] BS fixed
Thanks :) --Message d'origine-- De: D.Morgan Expéditeur : mageia-dev-boun...@mageia.org À: Mageia development mailing-list Répondre à: Mageia development mailing-list Objet: [Mageia-dev] BS fixed Envoyé: 15 juil. 2011 15:22 Hello, the BS is now fixed, you can work and push again new stuffs Sandro Cazzaniga
Re: [Mageia-dev] [Mageia 2 specifications] Systemd or not systemd
On Fri, Jul 15, 2011 at 3:23 PM, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and Colin Guthrie at 15/07/11 11:01 did gyre and gimble: Now that it's compiled, I need to test it :D Well it boots. And I have network connections! I have a problem where bluetoothd does not start but I'll solve that one at some point (it was a problem when I last used systemd too!) The various issues can now be solved as we go! Col Now that we have latest systemd rpm, is it OK to enable the systemd switches in the other rpms ? udev, ...
[Mageia-dev] broken libwordsexportfilters rpm
I just noticed this package during sync: libwordsexportfilters%wordsexportfilters_major-2.4-0.alpha3.1.mga2 -- Thomas
Re: [Mageia-dev] broken libwordsexportfilters rpm
On Fri, Jul 15, 2011 at 4:35 PM, Thomas Backlund t...@mageia.org wrote: I just noticed this package during sync: libwordsexportfilters%wordsexportfilters_major-2.4-0.alpha3.1.mga2 -- Thomas i was working on valstar when i saw you mail, so i am removing the file from the repos and fixing calligra
[Mageia-dev] %apply_patches
Should I report as a bug the fact that using %apply_patches (from /usr/lib/rpm/macros) instead of the list of patches, one per line, makes rpmlint complain that W: patch-not-applied ? Thx, R-C aka beranger
Re: [Mageia-dev] broken libwordsexportfilters rpm
On Fri, Jul 15, 2011 at 4:55 PM, D.Morgan dmorga...@gmail.com wrote: On Fri, Jul 15, 2011 at 4:35 PM, Thomas Backlund t...@mageia.org wrote: I just noticed this package during sync: libwordsexportfilters%wordsexportfilters_major-2.4-0.alpha3.1.mga2 -- Thomas i was working on valstar when i saw you mail, so i am removing the file from the repos and fixing calligra This should be fixed now. thanks for your mail
Re: [Mageia-dev] %apply_patches
'Twas brillig, and Radu-Cristian FOTESCU at 15/07/11 15:55 did gyre and gimble: Should I report as a bug the fact that using %apply_patches (from /usr/lib/rpm/macros) instead of the list of patches, one per line, makes rpmlint complain that W: patch-not-applied ? Smells like a valid reason to open a bug IMO. Col -- Colin Guthrie mageia(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
[Mageia-dev] Where is the KDE WM ?
Has anyone else noticed that as of updating yesterday or today, the windows in KDE have no titlebars, and cannot be moved or closed (except through the individual app) ? I used to see this occasionally under GNOME 2.32, but logging out/in again usually put it right. That doesn't work in the current KDE. All windows open in the top left of the screen with no enclosing frame, i.e. the MenuBar is the topmost thing you see.
Re: [Mageia-dev] Where is the KDE WM ?
On 07/15/2011 02:28 PM, Frank Griffin wrote: Has anyone else noticed that as of updating yesterday or today, the windows in KDE have no titlebars, and cannot be moved or closed (except through the individual app) ? I used to see this occasionally under GNOME 2.32, but logging out/in again usually put it right. That doesn't work in the current KDE. All windows open in the top left of the screen with no enclosing frame, i.e. the MenuBar is the topmost thing you see. Turning Compiz off gets the titlebars back, but I've had Compiz on for a week or more without this problem. Googling shows that there is some conflict between Compiz and KDE, and other distro forums mentioned a compiz-kde package. Has something similar not been rebuilt for the new KDE ?
Re: [Mageia-dev] Where is the KDE WM ?
On Friday 15 July 2011 15:06:11 Frank Griffin wrote: On 07/15/2011 02:28 PM, Frank Griffin wrote: Has anyone else noticed that as of updating yesterday or today, the windows in KDE have no titlebars, and cannot be moved or closed (except through the individual app) ? I used to see this occasionally under GNOME 2.32, but logging out/in again usually put it right. That doesn't work in the current KDE. All windows open in the top left of the screen with no enclosing frame, i.e. the MenuBar is the topmost thing you see. Turning Compiz off gets the titlebars back, but I've had Compiz on for a week or more without this problem. Googling shows that there is some conflict between Compiz and KDE, and other distro forums mentioned a compiz-kde package. Has something similar not been rebuilt for the new KDE ? I just finished to push compiz 0.8.8 (works is done by julien) everything is working here. How do you configure compiz ? Here it's simply working by selecting compiz as the default windows manager using systemsettings ( kcmshell4 componentchooser in konsole) Regards, -- Balcaen John
Re: [Mageia-dev] Where is the KDE WM ?
'Twas brillig, and Balcaen John at 15/07/11 20:16 did gyre and gimble: On Friday 15 July 2011 15:06:11 Frank Griffin wrote: On 07/15/2011 02:28 PM, Frank Griffin wrote: Has anyone else noticed that as of updating yesterday or today, the windows in KDE have no titlebars, and cannot be moved or closed (except through the individual app) ? I used to see this occasionally under GNOME 2.32, but logging out/in again usually put it right. That doesn't work in the current KDE. All windows open in the top left of the screen with no enclosing frame, i.e. the MenuBar is the topmost thing you see. Turning Compiz off gets the titlebars back, but I've had Compiz on for a week or more without this problem. Googling shows that there is some conflict between Compiz and KDE, and other distro forums mentioned a compiz-kde package. Has something similar not been rebuilt for the new KDE ? I just finished to push compiz 0.8.8 (works is done by julien) everything is working here. How do you configure compiz ? Here it's simply working by selecting compiz as the default windows manager using systemsettings ( kcmshell4 componentchooser in konsole) Interesting, that method never really worked before (or at least I never tested it). Normally, you pick compiz via drak3d Col -- Colin Guthrie mageia(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
Re: [Mageia-dev] Where is the KDE WM ?
On Friday 15 July 2011 22:20:40 Colin Guthrie wrote: [...] Interesting, that method never really worked before (or at least I never tested it). It was not working for mageia 1. Normally, you pick compiz via drak3d The last time i used drak3d was during the launch of Metisse :) -- Balcaen John
Re: [Mageia-dev] proposal regarding (packager) mentoring program coordinator
Angelo Naselli a écrit : In data mercoledì 29 giugno 2011 23:27:08, andre999 ha scritto: Any suggestions are welcome. Hi, I speak for myself, one silly suggestion, can you add links of wiki pages you talk about in the bottom of your mails? For one who reads mail when he/she can, like me, it could be easier to check the state of the art by clicking the links especially if he/she reads the thread some days later and the discussion has been almost to the end. Thanks Very good idea. I'll do my best to remember :) The page this thread refers to is here : http://www.mageia.org/wiki/doku.php?id=packages_mentoring Hopefully the simplified table of contents is clear. (It's been rearranged somewhat since I started the thread.) Regards -- André
[Mageia-dev] How to forbid submission of some tainted packages to core ?
Some packages must be submitted only to tainted. Is there already a way to prevent a wrong submit to the core section, when a package builds without buildrequires in tainted ? If yes, what is the way, and if not, shouldn't we define a standard way to do that in the spec files ? Best regards Samuel
Re: [Mageia-dev] Ownership of /usr/share/man/XX, %find_lang --with-man
Le samedi 9 juillet 2011 14:46:14, Samuel Verschelde a écrit : I used the --with-man option of the %find_lang RPM macro, but noticed that it adds all /usr/share/man/XX and /usr/share/man/XX/manX directories to the package, which, it seems, is bad. Spturtle noticed that for example /usr/share/man/sr belongs to no other package and prefers that it belongs to too much packages than to no package at all. I looked at what fedora does, and it looks like they added all those translated manpages dirs to the filesystem package ( see http://sophie.zarb.org/explorer/usr/share/man/sr and select fedora ) It would solve the problem at hand and we could start cleaning wrong ownerships, such as those : http://sophie.zarb.org/explorer/usr/share/man/fr (select mageia) What do you think ? Samuel No opinion, or did I ask when everybody was at the Libre Software Meeting ? Samuel
Re: [Mageia-dev] How to forbid submission of some tainted packages to core ?
Le samedi 16 juillet 2011 à 01:17 +0200, Samuel Verschelde a écrit : Some packages must be submitted only to tainted. Is there already a way to prevent a wrong submit to the core section, when a package builds without buildrequires in tainted ? If yes, what is the way, and if not, shouldn't we define a standard way to do that in the spec files ? We could add a requies to some dummy rpm that is present in tainted only. But I think this problem would not occurs often. If someone push it without saying where to go, it should go to the proper repository. And if someone push it to core, we should assume that he know what he does. There is no way to push by error to core, as you would need to add specific option ( iirc ). -- Michael Scherer
Re: [Mageia-dev] [Mageia 2 specifications] Systemd or not systemd
Le mercredi 13 juillet 2011 à 22:47 -0300, Eugeni Dodonov a écrit :
Almost finally, should the systemd files belong to the main package, the
same way as they do with initscripts-based one (e.g., the package would
provide /lib/systemd/system/%{name}.service together with
%_sysconfig/rc.d/init.d/%{name} for example), with no extra subpackages or
flags - or should all systemd-specific files go into %{name}-systemd package
for example? What do you think?
Everything in 1 package.
And finally, what does seems to be the best way of starting to use systemd
in cauldron? I have thought on 3 alternatives:
- easy way, only having it packaged, but not
providing/obsoleting/conflicting with sysvinit. This way, it will work when
kernel is booted with init=/bin/systemd (the least invasive way)
- compatible way (like in Mandriva) - it is available, systemd-sysvinit
conflicts with sysvinit, so if someone installs systemd-sysvinit, sysvinit
goes away and systemd is run by default. This seems to be the most sane way
to me (but I could be biased), and it is easiest one for testing
- ultimate way - systemd provides and obsoletes sysvinit and its goodies.
This way, systemd will be the only one (e.g., highlander style). This is how
fedora did it if I am not mistaken, but I am not sure if it the best way.
Option 2 for Mageia 2, and option 3 for Mageia 3.
People on Fedora list were quite reluctant to changes ( to say the least
), and I am pretty sure that someone will hit a unrelated corner case in
the last minute. Rtp was not really fond of systemd on arm and embedded
system either.
So we should keep the possibility of letting people choose for Mageia 2.
Also, systemd was reverted for f14, and while it was working fine for
me, I would rather make sure we have a reputation of being cautious and
choosing the quality rather than trying to steal the reputation of
Fedora.
--
Michael Scherer
Re: [Mageia-dev] Adobe Flash player 11 Beta 1 in Cauldron
Le vendredi 15 juillet 2011 à 11:10 +0300, Ahmad Samir a écrit : Hello. As you've seen the thread, posted by Charles A Edwards, there's a new version of flash which has native 64bit support, it's still in beta but seems to work well, some questions: - Any objections about offering it in mga1? Yes, I do. That's a beta, and stable is not a dumping ground for that. -- Michael Scherer
Re: [Mageia-dev] new mgarepo version
Le mercredi 13 juillet 2011 à 00:30 +0200, nicolas vigier a écrit : Hello. mgarepo version 1.9.11 adds maintdb command : It was not uploaded to the mirrors. ie, nothing on : http://distrib-coffee.ipsl.jussieu.fr:/pub/linux/Mageia/software/mgarepo -- Michael Scherer
Re: [Mageia-dev] new mgarepo version
Le mercredi 13 juillet 2011 à 12:11 +0200, nicolas vigier a écrit : On Wed, 13 Jul 2011, Samuel Verschelde wrote: Le mercredi 13 juillet 2011 00:30:41, nicolas vigier a écrit : Hello. mgarepo version 1.9.11 adds maintdb command : $ mgarepo maintdb --help Usage: Take maintainership of one package : mgarepo maintdb set [package] [login] Remove yourself from maintainer of a package : mgarepo maintdb set [package] nobody See who is maintainer of a package : mgarepo maintdb get [package] See the list of all packages with their maintainer : mgarepo maintdb get I used in in Mageia 1 using the package in updates_testing and it works well. Ok, it's moved to updates now. Wasn't it against the policy ( ie, this is neither a bugfix, this is a version update, providing feature ) ? -- Michael Scherer
Re: [Mageia-dev] new mgarepo version
Le mercredi 13 juillet 2011 à 21:31 +0200, Maarten Vanraes a écrit : Op woensdag 13 juli 2011 20:46:30 schreef nicolas vigier: [...] Is this process also available for novice packagers? Novice packagers cannot be maintainer. But content of maintdb is also available at this url : http://pkgsubmit.mageia.org/data/maintdb.txt I would like novices to be allowed to grab maintainership as well for the following 3 reasons: - easier as a padawan to check your packages and followup to see which have to be updated/backported Then we should not use maintainership as the only source for such informations. The tool written by stormi ( madb ) should fill that gap. - the day a padawan gets full packager, he would have to set all the packages, and it might not be easy to find them, or even alot of work, if the mentor has alot of them If there is lots of packages, then either the packages are not good enough, and the mentor should not accept them so the problem should not exist in practice, or they are good enough, and then the novice should have become packager sooner. The goal of novice is not to add lots of packages to become packagers, but to demonstrate enough knowledge while maintaining them. So I would rather have a system that discourage adding lots of rpms. Ie, if there is a incentive to focus on existing rpms, I think we should use it. - bug reports would then be assigned to the mentor instead of the novice, which would perhaps give a bit more work towards mentor to notify his novice about it. If the novice disappear, then someone should take care of the packages, and it should be the mentor. This way, they will not accept random rpms thinking this is not my duty to take care. A novice is not responsible for a package, since he is novice. So the database should simply reflect that. And if restricting the access is a way to motivate a novice to finish his training, then we should simply do it. Also, having people being listed while not being able to submit will make the creation of re-assignation rules harder. ( ie, if for example we say that a package that was not touched by the original maintainer after X submit is reassigned to the current uploader, stuff like that ). -- Michael Scherer
Re: [Mageia-dev] [RPM] cauldron core/release unknown-horizons-2011-1.mga2
Le mercredi 13 juillet 2011 à 15:34 +0200, Dexter Morgan a écrit : On Wed, Jul 13, 2011 at 3:32 PM, Ahmad Samir ahmadsamir3...@gmail.com wrote: On 13 July 2011 13:53, Balcaen John mik...@mageia.org wrote: On Wednesday 13 July 2011 09:49:01 Samuel Verschelde wrote: [...] The group Amusements/Games/Strategy/Real Time doesn't exist in Mageia. 3 different packagers haven't seen this ? :) Maybe we should check it via rpmlint on package upload ? s/upload/submit/. yes this would prevent to build for nothing I think it wouldn't work for sub packages. And before enabling this, we need to have a way to keep rpmlint-mageia-policy in sync on valstar ( as the last time I restricted upload, people complained ). -- Michael Scherer
Re: [Mageia-dev] Python Packaging Policy
Le mercredi 13 juillet 2011 à 09:51 +0200, philippe makowski a écrit : 2011/7/13 Michael scherer m...@zarb.org: I would be in favor of treating python2 and python 3 as 2 differents languages. The rational is that : - we cannot garantee to have support for both - we will likely have some module who would be updated only on python 3 sooner or later - we will need to do upgrade of package at different time, since both python2 and python3 are released at different time. So rather than a complex scheme that will confuse packagers, just consider they are separate, and use the almost same policy ( with s/python/python3/ ) And how do you manage package that support both P2 and P3 ? (same source) Either 2 rpms with the same source, or 1 rpm that generate 2 sub rpms. I would rather use 2 separate rpms, as this seems to be easier. -- Michael Scherer
Re: [Mageia-dev] [Mageia 2 specifications ] Grub2
Le mercredi 13 juillet 2011 à 09:55 +0200, Wolfgang Bornath a écrit : 2011/7/13 JA Magallón jamagal...@ono.com: On Tue, 12 Jul 2011 16:29:31 +0200, José Jorge jjo...@free.fr wrote: Le mardi 12 juillet 2011 15:12:52, Anne nicolas a écrit : Yet another burning subject that needs time to think about it and eventually migrate to. https://bugs.mageia.org/show_bug.cgi?id=2121 Grub 2 is coming now regularly in proposals. What should we do about it : - Stay with Grub 1 - pb ? maintainance ? restrictions ? - Switch to Grub 2 : smooth migration, tests, integration... SWITCH! +1 We can switch Cauldron now, to get massive tests, now that KDM knows it. I feel it is specially important that drakboot, gdm and kdm work nicely with it (ie. no regression). - Test also multiboot with Ubuntu and Fedora (auto-detection) And still keep GRUB1 till Mageia 3, to have a simple go back avalaible for people who will have problems with GRUB2. What for ? Any day from now everybody will be using btrfs to boot and then GRUB 1 is useless... How many percent of $ALL is your everybody? Most not-so-experienced users will not use btrfs until it is the standard filesystem in the installer. People who will not install Mageia2 but upgrade Mageia1 will continue with their current filesystem. There are more reasons to keep Grub1 for a while as an option. Grub 2 is also able to boot ext4 without trouble since several years. So keeping grub 1 for a while doesn't make sense at all if this is related to file system. And grub 2 also support reading grub 1 configuration file since September 2010. -- Michael Scherer
Re: [Mageia-dev] Ownership of /usr/share/man/XX, %find_lang --with-man
Samuel Verschelde a écrit :
I used the --with-man option of the %find_lang RPM macro, but noticed that it
adds all /usr/share/man/XX and /usr/share/man/XX/manX directories to the
package, which, it seems, is bad.
Spturtle noticed that for example /usr/share/man/sr belongs to no other
package and prefers that it belongs to too much packages than to no package at
all.
I looked at what fedora does, and it looks like they added all those
translated manpages dirs to the filesystem package ( see
http://sophie.zarb.org/explorer/usr/share/man/sr and select fedora )
It would solve the problem at hand and we could start cleaning wrong
ownerships, such as those :
http://sophie.zarb.org/explorer/usr/share/man/fr (select mageia)
What do you think ?
Samuel
Just saw your post, and reflected a bit.
/usr/share/man/man* belongs to filesystem (of course)
On my system, most /usr/share/man/{lang}/man1/ belong to the same 2 packages
(or just one of them).
fr belongs to one more.
sv to none.
So most packages don't take ownership of /usr/share/man/{lang}/man*.
And some do, even after the directory already exists.
Having no owner seems fine to me, and belonging to the filesystem package seems
the only reasonable alternative.
Whatever everyone prefers, and is doable.
Maybe we should use the buildsystem to enforce the chosen option ?
Or just add it to rpmlint-mageia-policy ?
(I'm curious as to what controls this.)
--
André
Re: [Mageia-dev] new mgarepo version
Michael Scherer a écrit : Le mercredi 13 juillet 2011 à 00:30 +0200, nicolas vigier a écrit : Hello. mgarepo version 1.9.11 adds maintdb command : It was not uploaded to the mirrors. ie, nothing on : http://distrib-coffee.ipsl.jussieu.fr:/pub/linux/Mageia/software/mgarepo Strange ... it's in core/updates on my local mirror (in Canada). I've already updated. -- André
[Mageia-dev] util-linux vs util-linux-ng
Hi, just wondering, is the switch from util-linux-ng 2.18 to util-linux 2.19+ planned? -- Eugeni Dodonov http://eugeni.dodonov.net/
