Re: [Mageia-dev] New Dracut: Please test
On Tue, Feb 14, 2012 at 03:55:17PM +, Colin Guthrie wrote: Can everyone please test the new dracut please? Especially those of you who had issues previously that I was able to fix. I just want to make sure I didn't drop any patches that were still needed and make sure new regressions have not snuck in. Only ever had non-existent swap problem with Dracut. Tried dracut-015-1.mga2.. still booted. Didn't try the -2. -- Regards, Olav
Re: [Mageia-dev] New Dracut: Please test
Colin Guthrie skrev 15.2.2012 11:35: 'Twas brillig, and David W. Hodgins at 14/02/12 23:21 did gyre and gimble: On Tue, 14 Feb 2012 10:55:17 -0500, Colin Guthrie mag...@colin.guthr.ie wrote: Can everyone please test the new dracut please? Especially those of you I'll test it shortly. I think there is a slight problem when dracut gets updated at the same time as the kernel, udev, or anything else that is going to get installed in the initramfs. Rather then triggering the running of dracut when the kernel gets installed, I think it would be better to have something that runs at the end of urpmi or MageiaUpdate, that check to see if dracut or anything in the existing initramfs has been updated, and if so, then run dracut. The best I can do from kernel pov is to change %post into %posttrans so creating initrd would happend at end of install transaction Strangely enough I was thinking vaguely along the same lines. My issue was udev specifically. Sadly working out exactly when to rebuild the initramfs is pretty tricky, e.g. if lvm or dm tools are updated do we really need them in this particular setup's initramfs? Should we rebuild anyway (it should be safe) and accept the unnecessary work in those cases? Might be a reasonable thing to do... it should be safe - famous last words... :) I guess then a filetrigger could be written that checks for files certain locations and triggers an initrd rebuild. For the kernel it would only build one, but for udev, dm, lvm etc. it would rebuild all of them... We should _never_ rebuild all initrds. If/when one of the updated packaged has a critical systemcrashing bug, we render the whole system unbootable. Might confuse some people however and create cases working systems are hosed unnecessarily, and I'm not sure how much of real, practical problem it is to simply have a slightly outdated tools in the initram fs? Perhaps we just need to get ordering better on updates such that udev, lvm, dm etc. are all ordered before kernel during updates? Maybe that will solve 95% of the issues? That could be an option of we can get the tools to differentiate between high-priority (glibc/rpm/urpm*/...), priority (udev/lvm/dm/...) and the rest... Otoh, most of the issues we see now is Cauldron - Cauldron updates. in a stable release many of the packages wont change. Of course that still leaves distro upgrades, but maybe that can be handled in the installer or by adding versionated conflicts to kernel to help urpmi figure out the order to update... -- Thomas
Re: [Mageia-dev] New Dracut: Please test
Le 15/02/2012 09:36, Andres Kaaber a écrit : I dont know if its a dracut problem or new kernel but with latest kernel + dracut I cant boot - kernel panic ... couldn't mount something :) i can check it 2012/2/15 Olav Vitterso...@vitters.nl: On Tue, Feb 14, 2012 at 03:55:17PM +, Colin Guthrie wrote: Can everyone please test the new dracut please? Especially those of you who had issues previously that I was able to fix. I just want to make sure I didn't drop any patches that were still needed and make sure new regressions have not snuck in. Only ever had non-existent swap problem with Dracut. Tried dracut-015-1.mga2.. still booted. Didn't try the -2. -- Regards, Olav Same here. Cordialement, Paulo SANTOS
Re: [Mageia-dev] New Dracut: Please test
'Twas brillig, and Thomas Backlund at 15/02/12 10:09 did gyre and gimble: Colin Guthrie skrev 15.2.2012 11:35: 'Twas brillig, and David W. Hodgins at 14/02/12 23:21 did gyre and gimble: On Tue, 14 Feb 2012 10:55:17 -0500, Colin Guthrie mag...@colin.guthr.ie wrote: Can everyone please test the new dracut please? Especially those of you I'll test it shortly. I think there is a slight problem when dracut gets updated at the same time as the kernel, udev, or anything else that is going to get installed in the initramfs. Rather then triggering the running of dracut when the kernel gets installed, I think it would be better to have something that runs at the end of urpmi or MageiaUpdate, that check to see if dracut or anything in the existing initramfs has been updated, and if so, then run dracut. The best I can do from kernel pov is to change %post into %posttrans so creating initrd would happend at end of install transaction Strangely enough I was thinking vaguely along the same lines. My issue was udev specifically. Sadly working out exactly when to rebuild the initramfs is pretty tricky, e.g. if lvm or dm tools are updated do we really need them in this particular setup's initramfs? Should we rebuild anyway (it should be safe) and accept the unnecessary work in those cases? Might be a reasonable thing to do... it should be safe - famous last words... :) :) I guess then a filetrigger could be written that checks for files certain locations and triggers an initrd rebuild. For the kernel it would only build one, but for udev, dm, lvm etc. it would rebuild all of them... We should _never_ rebuild all initrds. If/when one of the updated packaged has a critical systemcrashing bug, we render the whole system unbootable. Did we not used to do it when e.g. the bootspash theme changed? I remember a while back I had a problem as my /boot was quite modest and it ended up getting filled up with lots of .old files for the initrds That said, I can't really disagree. Might confuse some people however and create cases working systems are hosed unnecessarily, and I'm not sure how much of real, practical problem it is to simply have a slightly outdated tools in the initram fs? Perhaps we just need to get ordering better on updates such that udev, lvm, dm etc. are all ordered before kernel during updates? Maybe that will solve 95% of the issues? That could be an option of we can get the tools to differentiate between high-priority (glibc/rpm/urpm*/...), priority (udev/lvm/dm/...) and the rest... Otoh, most of the issues we see now is Cauldron - Cauldron updates. in a stable release many of the packages wont change. Yeah I think overall Cauldron-Cauldron is not that important in the overall scheme of things. Users hear should be able to rebuild their initrd with a quick command or two easily enough when needed. Of course that still leaves distro upgrades, but maybe that can be handled in the installer or by adding versionated conflicts to kernel to help urpmi figure out the order to update... Yeah, that's probably a good shout. Just before release, we can put a Conflicts: udev $latest and similar stuff into the kernel... that would likely catch most potential problems. Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] meta-task update in cauldron
On 15 February 2012 10:39, Païou pai...@free.fr wrote: Is there any other modification to be added to this package (especially meta-task)? If not I will update it tonight for first set of isos. If it is not too late, I would wish that the relative clause in bug 3060 is also integrated in meta-task. I think that it would maybe allow to reduce the size of the packages of a dual-arch CD. With the proposed modification, the minimal installation, such as I make it (minimal installation + X server) + IceWM-light + urpmi) asks only env 580 packages, instead of 847 otherwise. 1) please quote only what's needed 2) kdm was selected because some packages suggested or required dm. now only xguest requires dm. let's just kill that requires and voila nothing related to meta-task...
Re: [Mageia-dev] New Dracut: Please test
On 15 February 2012 11:09, Thomas Backlund t...@mageia.org wrote: Of course that still leaves distro upgrades, but maybe that can be handled in the installer or by adding versionated conflicts to kernel to help urpmi figure out the order to update... I think the best thing would make kernel conflict with older drakcut/udev/lvm2/dm* Tradeoff is that we've to maintain those for all kernel flavors...
Re: [Mageia-dev] meta-task update in cauldron
Thierry Vignaud thierry.vignaud@... writes: 2) kdm was selected because some packages suggested or required dm. now only xguest requires dm. let's just kill that requires and voila nothing related to meta-task... Thank you for this very interesting answer. I thus have to look for which package asks xguest. At the level of a minimal installation, I do not think that xguest is necessary. And thus meta-task is not effectively concerned.
Re: [Mageia-dev] [changelog] [RPM] cauldron nonfree/release drakx-installer-images-1.64-3.mga2.nonfree
On 15 February 2012 09:55, Thomas Backlund t...@mageia.org wrote: And the correct fix needs more coding since arm does not support xz compressed modules so we need to adapt for that too, and not blindly recompress to .xz or search for .xz only... Well both stage1 stage2 now expect XZ compressed modules. What's the issue on ARM? The kernel decompressor?
Re: [Mageia-dev] meta-task update in cauldron
On 15 February 2012 13:32, Païou pai...@free.fr wrote: 2) kdm was selected because some packages suggested or required dm. now only xguest requires dm. let's just kill that requires and voila nothing related to meta-task... Thank you for this very interesting answer. I thus have to look for which package asks xguest. At the level of a minimal installation, I do not think that xguest is necessary. xguest is pulled by userdrake and also by drakx installer if Enable guest account is checked in
Re: [Mageia-dev] In need of a mentor
Le mercredi 15 février 2012 21:41:32, Steven Tucker a écrit : Kyle has indeed added his name to the list, however there are 5 people on the list before him, I have been on that list since mid January, and there is someone who has been waiting since late November. All things being equal, shouldn't preference be given to the top (longest waiting) of the list? You are right. The only reason for this not to work is of someone already knows a contributor. We should be carefull with that, as mentoring is about respect.
Re: [Mageia-dev] [changelog] [RPM] cauldron nonfree/release drakx-installer-images-1.64-3.mga2.nonfree
Thierry Vignaud skrev 15.2.2012 14:39: On 15 February 2012 09:55, Thomas Backlundt...@mageia.org wrote: And the correct fix needs more coding since arm does not support xz compressed modules so we need to adapt for that too, and not blindly recompress to .xz or search for .xz only... Well both stage1 stage2 now expect XZ compressed modules. What's the issue on ARM? The kernel decompressor? yes. There are patches suggested/queued for 3.4 to get full XZ support for arm so maybe we can backport them for 3.3 depending on how intrusive they are... Thinking some more about the issue, adding something like .[g,x]z to to the module detection wouldn't be much coding at all and would cover both compressions, wdyt ? -- Thomas
Re: [Mageia-dev] In need of a mentor
On 15/02/12 03:15, Kyle Fletcher wrote:
Hello all,
I've been looking for a distro to join for awhile now and finally
landed with mageia. I'm relatively new to it, but have enjoyed it so
far. I've started teaching myself how to package and have packaged
two things so far. (very unstable, but i'm working on it). I have
also put my name and info on the wiki
https://wiki.mageia.org/en/Becoming_a_Mageia_Packager so if there is
anyone out there that would like to mentor me please let me know.
I'm also usually in IRC all the time under the name vitamin{, tho afk alot :)
You did it!
Welcome to the club!
--
Malo
http://www.doc.ic.ac.uk/~malo/
Re: [Mageia-dev] In need of a mentor
On 15/02/12 20:41, Steven Tucker wrote: Hi all, I would like to make comment on the Mentoring system, and hopefully I will convey it, and be interpreted in the best possible spirit. I am glad Kyle has now had an offer to be mentored and by no means wish to stop this or interfere in anyway, however I felt quite deflated when I read the offer to mentor him, and I imagine others would too, so I feel obligated to comment. There is a list on the wiki of people looking for mentors https://wiki.mageia.org/en/Becoming_a_Mageia_Packager#Packaging_apprentice_candidates Kyle has indeed added his name to the list, however there are 5 people on the list before him, I have been on that list since mid January, and there is someone who has been waiting since late November. All things being equal, shouldn't preference be given to the top (longest waiting) of the list? Is there a reason why 5 people get overlooked, and someone who has been waiting 2 days is given a chance? If we are not as committed/capable/available/desirable can someone please let us know? I have already packaged a program I wrote and want added to Mageia, and I wait patiently for a Mentor, just to find the line has been cut. Do I need to constantly have IRC on to be chosen? is there some unwritten rules about how to gain a mentor? If so please let me know so I can do these things. I hope this is taken constructively, I don't wish for the mentoring offer to Kyle to be withdrawn, he sounds like he will be an asset to the packaging team, I do think though that you should consider the list first before making offers. If a person is not suitable, tell them so they can move on, perhaps package for another distro, whatever. Don't just leave them there to rot. Tuxta Hi Steven, I understand your frustration. this list on the wiki is not really working at the moment. You however need to understand that we are all volunteers and busy with other tasks (like mga2). So finding a mentor also supposes that potential mentors see (repeatedly) your will to participate. That's why coming to talk on IRC, (notably #mageia-mentoring where we can help you learn the first steps of packaging, even without a mentor), filling bugs or commenting on them, writing to the mailing-list (even if it's just a reminder that you are looking for a mentor) are all things that will make you known by the community and find a mentor. In a way, you message is the illustration of what you should do (although the long message you wrote is not that necessary :-) ). BTW, I can be your mentor if you're motivated and don't mind using IRC :-). Cheers, -- Malo http://www.doc.ic.ac.uk/~malo/
[Mageia-dev] Cleaning up GNOME spec files
In case people want to assist. I'm busy cleaning up all the GNOME
related spec files. If you want to do some simple work (instead of
beta1, general bug fixing, etc), then feel free to help out!
If you want to assist, do the following do download all GNOME spec files
in one go:
mkdir ~/src ~/bin ~/pkgs
cd ~/src
svn co svn+ssh://svn.mageia.org/svn/soft/mga-gnome/trunk mga-gnome
cd ~/bin
ln -s ~/src/mga-gnome mga-gnome
mga-gnome co
Then find spec files to work on using:
grep -r '^%clean$' --exclude='*~' --exclude-dir=.svn --exclude-dir=SOURCES
--exclude-dir=BUILD ~/pkgs
What I look at while cleaning up:
- remove BuildRoot:
- remove unneeded post/pre
- ensure everything uses tabs
- remove the default defattr
- remove default %clean section
- move any define name/release/version to Name:, Release:, Version:
- ensure Source: is similar to
http://download.gnome.org/sources/%{name}/%{url_ver}/%{name}-%{version}.tar.xz
thanks to: %define url_ver %(echo %{version}|cut -d. -f1,2)
There are loads of build failures, which needs to be looked at. But atm
just focussing on cleaning spec files only. If it fails to build, I only
check if that was a typo on my part or not. This as there are hundreds
of spec files to clean.
Build failures are various; missing buildrequires, lack of libm linking,
missing .la files, newer glib (not including just glib.h), etc, etc.
--
Regards,
Olav
Re: [Mageia-dev] New Dracut: Please test
'Twas brillig, and Thierry Vignaud at 15/02/12 12:30 did gyre and gimble: On 15 February 2012 11:09, Thomas Backlund t...@mageia.org wrote: Of course that still leaves distro upgrades, but maybe that can be handled in the installer or by adding versionated conflicts to kernel to help urpmi figure out the order to update... I think the best thing would make kernel conflict with older drakcut/udev/lvm2/dm* Aye. Tradeoff is that we've to maintain those for all kernel flavors... Time for a task-initramfs? Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] New Dracut: Please test
Colin Guthrie skrev 15.2.2012 16:31: 'Twas brillig, and Thierry Vignaud at 15/02/12 12:30 did gyre and gimble: On 15 February 2012 11:09, Thomas Backlundt...@mageia.org wrote: Of course that still leaves distro upgrades, but maybe that can be handled in the installer or by adding versionated conflicts to kernel to help urpmi figure out the order to update... I think the best thing would make kernel conflict with older drakcut/udev/lvm2/dm* Well, all kernels already requires(pre) a versioned dracut, so that is covered. I just bump that as needed... Aye. Tradeoff is that we've to maintain those for all kernel flavors... Time for a task-initramfs? Or maybe add the conflicts on dracut as that is the package we worry about... -- Thomas
Re: [Mageia-dev] New Dracut: Please test
'Twas brillig, and Thomas Backlund at 15/02/12 14:38 did gyre and gimble: Colin Guthrie skrev 15.2.2012 16:31: 'Twas brillig, and Thierry Vignaud at 15/02/12 12:30 did gyre and gimble: On 15 February 2012 11:09, Thomas Backlundt...@mageia.org wrote: Of course that still leaves distro upgrades, but maybe that can be handled in the installer or by adding versionated conflicts to kernel to help urpmi figure out the order to update... I think the best thing would make kernel conflict with older drakcut/udev/lvm2/dm* Well, all kernels already requires(pre) a versioned dracut, so that is covered. I just bump that as needed... Aye. Tradeoff is that we've to maintain those for all kernel flavors... Time for a task-initramfs? Or maybe add the conflicts on dracut as that is the package we worry about... Yeah that's probably neater than YATP :) COl -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
[Mageia-dev] Incorrect submission check: Unity desktop
I got the following submission error: Submission errors, aborting: - yelp-3.3.3-2.mga2.x86_64: - invalid-desktopfile /usr/share/applications/yelp.desktop value GNOME;Unity; for key OnlyShowIn in group Desktop - yelp-3.3.3-2.mga2.i586: - invalid-desktopfile /usr/share/applications/yelp.desktop value GNOME;Unity; for key OnlyShowIn in group Desktop Unity is a valid and registered desktop. Desktop-file-utils validates it as of version 0.19. Above submission check is outdated and wrong. Please fix the check so I can submit it again. -- Regards, Olav
Re: [Mageia-dev] Cleaning up GNOME spec files
Le 15/02/2012 15:05, Olav Vitters a écrit : What I look at while cleaning up: - remove BuildRoot: - remove unneeded post/pre - ensure everything uses tabs That's not really cleaning up, that's enforcing your own cosmetic preferences. Whereas you're perfectly legitimate to manage your own spec files the way you want, this is slightly more ennoying for files shipped in those packages, notably the one generated from spec files through herein documents (for instance, apache, logrotate, cron files, etc...) I'd rally prefer to have a bit more consistency here, not depending about individual maintainer preferences. Of course, if I'm reacting here, it's because everyone know than tab sucks :P -- BOFH excuse #382: Someone was smoking in the computer room and set off the halon systems.
Re: [Mageia-dev] Cleaning up GNOME spec files
On Wed, Feb 15, 2012 at 04:43:04PM +0100, Guillaume Rousse wrote: Le 15/02/2012 15:05, Olav Vitters a écrit : What I look at while cleaning up: - remove BuildRoot: - remove unneeded post/pre - ensure everything uses tabs That's not really cleaning up, that's enforcing your own cosmetic preferences. Whereas you're perfectly legitimate to manage your own spec files the way you want, this is slightly more ennoying for files shipped in those packages, notably the one generated from spec files through herein documents (for instance, apache, logrotate, cron files, etc...) I'd rally prefer to have a bit more consistency here, not depending about individual maintainer preferences. Of course, if I'm reacting here, it's because everyone know than tab sucks :P You only mean my tabs comment I assume? I remembered that everything should be tabs (during mentoring). If up to the maintainer, of course I won't change it anymore, except if inconsistent. I noticed some spec files have mostly tabs, except for a few lines. But have also changed whole spec files to use tabs. Most of the spec files I look at use tabs. -- Regards, Olav
Re: [Mageia-dev] Cleaning up GNOME spec files
On Wed, Feb 15, 2012 at 15:54, Olav Vitters o...@vitters.nl wrote: On Wed, Feb 15, 2012 at 04:43:04PM +0100, Guillaume Rousse wrote: Le 15/02/2012 15:05, Olav Vitters a écrit : What I look at while cleaning up: - remove BuildRoot: - remove unneeded post/pre - ensure everything uses tabs That's not really cleaning up, that's enforcing your own cosmetic preferences. Whereas you're perfectly legitimate to manage your own spec files the way you want, this is slightly more ennoying for files shipped in those packages, notably the one generated from spec files through herein documents (for instance, apache, logrotate, cron files, etc...) I'd rally prefer to have a bit more consistency here, not depending about individual maintainer preferences. Of course, if I'm reacting here, it's because everyone know than tab sucks :P You only mean my tabs comment I assume? I remembered that everything should be tabs (during mentoring). The current rule is only that you should not mix them inside one spec file. If up to the maintainer, of course I won't change it anymore, except if inconsistent. I noticed some spec files have mostly tabs, except for a few lines. But have also changed whole spec files to use tabs. Most of the spec files I look at use tabs.
Re: [Mageia-dev] Incorrect submission check: Unity desktop
On Wed, Feb 15, 2012 at 15:38, Olav Vitters o...@vitters.nl wrote: I got the following submission error: Submission errors, aborting: - yelp-3.3.3-2.mga2.x86_64: - invalid-desktopfile /usr/share/applications/yelp.desktop value GNOME;Unity; for key OnlyShowIn in group Desktop - yelp-3.3.3-2.mga2.i586: - invalid-desktopfile /usr/share/applications/yelp.desktop value GNOME;Unity; for key OnlyShowIn in group Desktop Unity is a valid and registered desktop. Desktop-file-utils validates it as of version 0.19. Above submission check is outdated and wrong. Please fix the check so I can submit it again. I think the test is run on the server, meaning Mageia 1, which has 0.18
Re: [Mageia-dev] mgarepo log regression? (was: c++-gtk-utils-2.0.4-1.mga2)
On 14.02.2012 22:44, Jani Välimaa wrote: 2012/2/14 barjac buildsystem-dae...@mageia.org: Name: c++-gtk-utilsRelocations: (not relocatable) Version : 2.0.4 Vendor: Mageia.Org Release : 1.mga2Build Date: Tue Feb 14 19:36:12 2012 Install Date: (not installed) Build Host: ecosse.mageia.org Group : System/Libraries Source RPM: (none) Size: 2000191 License: GPLv2 Signature : (none) Packager: barjac barjac URL : http://cxx-gtk-utils.sourceforge.net Summary : GTK+-based ISO image editor Description : c++-gtk-utils is a lightweight library containing a number of classes and functions for programming GTK+ programs using C++ in POSIX (Unix-like) environments, where the user does not want to use a full-on wrapper such as gtkmm or wxWidgets, or is concerned about exception safety or thread safety of the wrapper and their documentation. It is parallel installable for both GTK+2 and GTK+3. barjac barjac 2.0.4-1.mga2: + Revision: 208908 - .mga2- del *.a - imported package c++-gtk-utils You should avoid using macros in commit msgs or at least escape them (%mkrel - %%mkrel) or use mgarepo to commit changes which does it automatically. Commit msgs %mkrel spelling error and del *.a looks now in changelog like - .mga2- del *.a. Err no, this is an mgarepo regression. It should automatically escape the logs when it fetches the log from SVN, and double-checking confirms that mdv repsys does it correctly. Or has this been intentionally changed at some point?? -- Anssi Hannula
Re: [Mageia-dev] mgarepo log regression?
On 15.02.2012 18:38, Anssi Hannula wrote: On 14.02.2012 22:44, Jani Välimaa wrote: 2012/2/14 barjac buildsystem-dae...@mageia.org: Name: c++-gtk-utilsRelocations: (not relocatable) Version : 2.0.4 Vendor: Mageia.Org Release : 1.mga2Build Date: Tue Feb 14 19:36:12 2012 Install Date: (not installed) Build Host: ecosse.mageia.org Group : System/Libraries Source RPM: (none) Size: 2000191 License: GPLv2 Signature : (none) Packager: barjac barjac URL : http://cxx-gtk-utils.sourceforge.net Summary : GTK+-based ISO image editor Description : c++-gtk-utils is a lightweight library containing a number of classes and functions for programming GTK+ programs using C++ in POSIX (Unix-like) environments, where the user does not want to use a full-on wrapper such as gtkmm or wxWidgets, or is concerned about exception safety or thread safety of the wrapper and their documentation. It is parallel installable for both GTK+2 and GTK+3. barjac barjac 2.0.4-1.mga2: + Revision: 208908 - .mga2- del *.a - imported package c++-gtk-utils You should avoid using macros in commit msgs or at least escape them (%mkrel - %%mkrel) or use mgarepo to commit changes which does it automatically. Commit msgs %mkrel spelling error and del *.a looks now in changelog like - .mga2- del *.a. Err no, this is an mgarepo regression. It should automatically escape the logs when it fetches the log from SVN, and double-checking confirms that mdv repsys does it correctly. Or has this been intentionally changed at some point?? Actually, scratch that. There is just a bug that escaping isn't done correctly when '%' is the first character of an SVN log message line. MgaRepo/log.py: unescaped_macro_pat = re.compile(r([^%])%([^%])) This matches x%foo, but doesn't match %foo. -- Anssi Hannula
Re: [Mageia-dev] mgarepo log regression?
On Wed, 15 Feb 2012, Anssi Hannula wrote: Err no, this is an mgarepo regression. It should automatically escape the logs when it fetches the log from SVN, and double-checking confirms that mdv repsys does it correctly. Or has this been intentionally changed at some point?? Actually, scratch that. There is just a bug that escaping isn't done correctly when '%' is the first character of an SVN log message line. MgaRepo/log.py: unescaped_macro_pat = re.compile(r([^%])%([^%])) This matches x%foo, but doesn't match %foo. I have commited this change to fix the problem : http://svnweb.mageia.org/soft/build_system/mgarepo/trunk/MgaRepo/log.py?r1=265r2=2956view=patch
Re: [Mageia-dev] Can't switch to virtual consoles
Thomas Backlund a écrit : 14.02.2012 21:50, Juan Luis Baptiste skrev: On Tue, Feb 14, 2012 at 2:45 PM, Guillaume Rousse guillomovi...@gmail.com wrote: Le 14/02/2012 19:58, Juan Luis Baptiste a écrit : Can you check if systemd has forked mingetty for the text consoles yet? I'm using sysvinit not systemd. Try systemd then... But isn't sysvinit to be the default for mga 2 and the switch to systemd is going to be for mga 3 ? or I'm missing something ? systemd will be default for Mageia 2 sysvinit is only a fallback for systems that dont work with systemd yet... sysvinit (and mkinitrd) will be completely removed as soon as Cauldron opens up again after Mageia 2 release. -- Thomas As I understood it, it was explicitly decided that systemd was to be an option for mga2, with sysvinit remaining the default. And hopefully systemd was to be the default for mga3, with sysvinit removed. Also, cauldron switched temporarily to systemd as default in order to more fully test it. But to revert to sysvinit as the default for mga2 release. When did this change ? -- André
Re: [Mageia-dev] Can't switch to virtual consoles
On Wed, Feb 15, 2012 at 2:18 PM, andre999 andre999...@laposte.net wrote: As I understood it, it was explicitly decided that systemd was to be an option for mga2, with sysvinit remaining the default. And hopefully systemd was to be the default for mga3, with sysvinit removed. Also, cauldron switched temporarily to systemd as default in order to more fully test it. But to revert to sysvinit as the default for mga2 release. When did this change ? Exactly, that was what I thought was going to happen, I don't remember reading when this changed, at least I don't remember to have been mentioned on the list. -- Juancho
Re: [Mageia-dev] Can't switch to virtual consoles
On Wednesday 15 February 2012 20:18, andre999 wrote: As I understood it, it was explicitly decided that systemd was to be an option for mga2, with sysvinit remaining the default. And hopefully systemd was to be the default for mga3, with sysvinit removed. Also, cauldron switched temporarily to systemd as default in order to more fully test it. But to revert to sysvinit as the default for mga2 release. I thought this was the case, too. -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] New Dracut: Please test
'Twas brillig, and Colin Guthrie at 15/02/12 09:36 did gyre and gimble: 'Twas brillig, and David W. Hodgins at 15/02/12 01:38 did gyre and gimble: On Tue, 14 Feb 2012 10:55:17 -0500, Colin Guthrie mag...@colin.guthr.ie wrote: Can everyone please test the new dracut please? Especially those of you With dracut-015-2, / on a partition, /usr on a lvm logical volume, the initramfs no longer has the lvm2 command, or the dm_mod kernel module making it impossible to mount /usr. The file 50mount-usr.sh is present in hooks/pre-pivot, but the file 30parse-lvm.sh is no longer in hooks/cmdline. Damn, it looked like the code was OK for that. I'll have to reintroduce some patches I guess. Cheers for the report, I'll try and create a similar VM tonight. OK, that was a very strange quirk it all boiled down to a string comparison function :s Can you try with dracut-015-3.mga2 when it arrives? If you cannot boot, you can just pass rd.lvm.lv=foo/bar on the kernel command line (where foo is the vgname and bar is the lvname)... tho' this might or might not work too well as lvm might not be on the initrd itself Even if it's not included, it however possible to run things... with our current split of /usr (I was able to run the necessary binaries from /sysroot with appropriate LD_LIBRARY_PATH tweaks!) Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] Consolidation of the spell checkers - current status before Beta 1 and general version freeze
On 14.02.2012 15:40, Kamil Rytarowski wrote: To-do before the version freeze (I think, I can finish it tonight): - review additional ~50 hunspell dicts and use better obsoletion of myspell - stop providing enchant-dictionary in 2/3 aspell dicts Done. All Hunspell dictionaries are ready, Aspell one are cleaned and Myspell is moved into obsoletes. Have fun and feel free to submit bugs.
Re: [Mageia-dev] New Dracut: Please test
On Wed, 15 Feb 2012 19:10:09 -0500, Colin Guthrie mag...@colin.guthr.ie wrote: OK, that was a very strange quirk it all boiled down to a string comparison function :s Can you try with dracut-015-3.mga2 when it arrives? Still doesn't work. If you cannot boot, you can just pass rd.lvm.lv=foo/bar on the kernel command line (where foo is the vgname and bar is the lvname)... tho' this might or might not work too well as lvm might not be on the initrd The lvm command and the dm_mod kernel module are not in the initramfs. I'm using chroot from Mageia 1, to access the system. Regards, Dave Hodgins
Re: [Mageia-dev] In need of a mentor
On 15.02.2012 21:41, Steven Tucker wrote: Hi all, Hello Steven! I would like to make comment on the Mentoring system, and hopefully I will convey it, and be interpreted in the best possible spirit. I am glad Kyle has now had an offer to be mentored and by no means wish to stop this or interfere in anyway, however I felt quite deflated when I read the offer to mentor him, and I imagine others would too, so I feel obligated to comment. There is a list on the wiki of people looking for mentors https://wiki.mageia.org/en/Becoming_a_Mageia_Packager#Packaging_apprentice_candidates Kyle has indeed added his name to the list, however there are 5 people on the list before him, I have been on that list since mid January, and there is someone who has been waiting since late November. All things being equal, shouldn't preference be given to the top (longest waiting) of the list? Is there a reason why 5 people get overlooked, and someone who has been waiting 2 days is given a chance? There are lot kinds of packages in Mageia (C++, documentation, Java, Gnome, KDE, web, kernel, assembler, Perl, Haskell, XFCE4, Ruby, Ocaml, ...) and usually mentors take these apprentice candidates, where there is a common field of shared interests. If we are not as committed/capable/available/desirable can someone please let us know? Don't think like that please! As wiki says, the most important is enthusiasm! I have seen that even qualified computer scientists cannot finish the mentoring process due to lack of enthusiasm (they need to dedicate their free time to the project). I have already packaged a program I wrote and want added to Mageia, and I wait patiently for a Mentor, just to find the line has been cut. Do I need to constantly have IRC on to be chosen? Of course not! It's individual flavour of communication, some people prefer IRC, some e-mails, some other ways to communicate. is there some unwritten rules about how to gain a mentor? If so please let me know so I can do these things. There is probably one thing unwritten, just trying to ping developers helps in finding. Kyle was asking several times on IRC for mentor. I hope this is taken constructively, I don't wish for the mentoring offer to Kyle to be withdrawn, he sounds like he will be an asset to the packaging team, I do think though that you should consider the list first before making offers. If a person is not suitable, tell them so they can move on, perhaps package for another distro, whatever. Don't just leave them there to rot. The truth is simple, we are short of packagers and therefore mentors. Everybody with enthusiasm (even without great Unix skills) is welcome. I have mostly finished my project of the consolidation of spell-checkers in Mga, that costed hundreds of commits, and now I feel ready to start helping in the mentoring process. I have proposed to you and to Edward (edge226) to teach you packaging. To be clear, after reading your interests / skills / comments, I decided that I can be a better mentor for you, according to the field of interest. Tuxta Regards and welcome! Kamil
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release dracut-015-3.mga2
On Thu, 16 Feb 2012 01:05:15 +0100 (CET) colin buildsystem-dae...@mageia.org wrote: + tmb tmb - add info in README.urpmi that systemd users must use dracut What does this mean? Currently I am booting with systemd-sysvinit and using mkinitrd. Is it going to now magically/tragically stop working? Charles -- The scissors cut easiest past the buttonhole -- Murphy's Laws of Sewing n°19 -- Mageia release 2 (Cauldron) for x86_64$ On SuperSizehttp://www.eslrahc.com Registered Linux user #182463 3.2.6-server-0.rc1.1.mga2 x86_64 -- signature.asc Description: PGP signature
Re: [Mageia-dev] Incorrect submission check: Unity desktop
Le mercredi 15 février 2012 à 16:06 +, Pascal Terjan a écrit : On Wed, Feb 15, 2012 at 15:38, Olav Vitters o...@vitters.nl wrote: I got the following submission error: Submission errors, aborting: - yelp-3.3.3-2.mga2.x86_64: - invalid-desktopfile /usr/share/applications/yelp.desktop value GNOME;Unity; for key OnlyShowIn in group Desktop - yelp-3.3.3-2.mga2.i586: - invalid-desktopfile /usr/share/applications/yelp.desktop value GNOME;Unity; for key OnlyShowIn in group Desktop Unity is a valid and registered desktop. Desktop-file-utils validates it as of version 0.19. Above submission check is outdated and wrong. Please fix the check so I can submit it again. I think the test is run on the server, meaning Mageia 1, which has 0.18 Yep. I guess that's time to test the new shiny sysadmin repo \o/ -- Michael Scherer
Re: [Mageia-dev] Incorrect submission check: Unity desktop
Le jeudi 16 février 2012 à 07:34 +0100, Michael Scherer a écrit : Le mercredi 15 février 2012 à 16:06 +, Pascal Terjan a écrit : On Wed, Feb 15, 2012 at 15:38, Olav Vitters o...@vitters.nl wrote: I got the following submission error: Submission errors, aborting: - yelp-3.3.3-2.mga2.x86_64: - invalid-desktopfile /usr/share/applications/yelp.desktop value GNOME;Unity; for key OnlyShowIn in group Desktop - yelp-3.3.3-2.mga2.i586: - invalid-desktopfile /usr/share/applications/yelp.desktop value GNOME;Unity; for key OnlyShowIn in group Desktop Unity is a valid and registered desktop. Desktop-file-utils validates it as of version 0.19. Above submission check is outdated and wrong. Please fix the check so I can submit it again. I think the test is run on the server, meaning Mageia 1, which has 0.18 Yep. I guess that's time to test the new shiny sysadmin repo \o/ And to report that it doesn't work ( seems it cannot find glib-devel, so I assume 'wrong source configuration' ). -- Michael Scherer
Re: [Mageia-dev] New Dracut: Please test
On Wed, 15 Feb 2012 19:10:09 -0500, Colin Guthrie mag...@colin.guthr.ie wrote: Can you try with dracut-015-3.mga2 when it arrives? See https://bugs.mageia.org/show_bug.cgi?id=4537 Regards, Dave Hodgins
