Re: [Mageia-dev] How broken are RPM dependencies allowed to be?
On Wednesday, 14 December 2011 04:04:39 Liam R E Quin wrote: > On Tue, 2011-12-13 at 16:31 -0800, Dan Fandrich wrote: > > I raised a bug ticket on drakxtools (#3731) because the RPM in Cauldron > > installs without complaints in Mageia 1 but won't work there because > > it requires a newer version of perl. This is unsupported. Maybe you should instead contribute documentation that makes this more explicitly obvious, but it is a well-known rule in Mandriva and Mageia (and usually applies to other distros as well). If this weren't the case, there wouldn't be a need for backports ... > > The perl dependency in the > > RPM is listed as "perl-base" when it should really be something like > > "perl-base >= 5.14.2" (Mageia 1 ships with version 5.12.3). The response > > I got was that such an upgrade (from release to Cauldron) wasn't > > supported and this bug was likely a wontfix. Installing packages individually from one release on another release is not supported. Either upgrade the entire distro first, or stick to packages from the version you are on. However 'upgrade from release to Cauldron', when done correctly, should usually work as expected. > It's really hard to test for dependencies like this, as the person > building the package will have working versions of everything. > > Worse, in two years' time, perl-base of 5.14.3 will be hopelessly > outdated (we all expect, at least). So it becomes one more thing to > maintain. > > But it's also a problem worth solving for some of the system-critical > components such as perl, urpmi and drak*. I don't think "wontfix" is a > good answer here. But, in supported use cases, urpmi *does* ensure that all the pieces to keep urpmi are upgraded in one transaction. Supporting the use case of installing any random package from a different release will take more effort than just adding and maintaining a version on one perl-base dependency. Regards, Buchan
Re: [Mageia-dev] HIME (new input method forked from gcin) for Mageia
2011/12/14 Franklin Weng : > Hi list, > > > Yesterday some developers launched a new input method project HIME > (http://hime.luna.com.tw) which is forked from gcin. > I downloaded the source code and made a rpm package. It successfully > installed with rpm. > > I can use hime as my input method. However, in the localdrake I > couldn't choose hime as my input method. > > If I set the QT_IM_MODULE, GTK_IM_MODULE, XMODIFIER, ... variables I > could use it. Could anyone please tell me how to make it appear in > the input method list of localedrake? > > BTW, this is the first time I try to package a new software. After I > completed all the post-install scripts, can you accept that in the > cauldron (and even mageia 2) repository? > > > Thanks, > Franklin lol I just packed it about the same time you sent this message. XD The spec file is attached with this message, I also upload the srpm here: http://www.megaupload.com/?d=8F114XOU I'm still looking for a mentor. Hopefully some one could push it, and I can maintain it after I'm mentored and qualified for packaging. Thanks, You-Cheng Hsieh hime.spec Description: Binary data
[Mageia-dev] HIME (new input method forked from gcin) for Mageia
Hi list, Yesterday some developers launched a new input method project HIME (http://hime.luna.com.tw) which is forked from gcin. I downloaded the source code and made a rpm package. It successfully installed with rpm. I can use hime as my input method. However, in the localdrake I couldn't choose hime as my input method. If I set the QT_IM_MODULE, GTK_IM_MODULE, XMODIFIER, ... variables I could use it. Could anyone please tell me how to make it appear in the input method list of localedrake? BTW, this is the first time I try to package a new software. After I completed all the post-install scripts, can you accept that in the cauldron (and even mageia 2) repository? Thanks, Franklin
[Mageia-dev] No sound after reboot.
After rebooting tonight for the first time in approx a week I find that sound no longer works. Sound card is c-media and is properly detected in both harddrake and alsaconf and uses the snd_cmipci driver and is set to use pulseaudio. Driver and modules are loaded [root@SuperSize ~]# lspcidrake -v |grep AUDIO snd_cmipci : C-Media Electronics Inc|CM8738 [MULTIMEDIA_AUDIO] (vendor:13f6 device:0111 subv:584d subd:3731) (rev: 10) [root@SuperSize ~]# lsmod |grep snd snd_cmipci 40460 0 gameport 14963 1 snd_cmipci snd_pcm84041 1 snd_cmipci snd_page_alloc 18101 1 snd_pcm snd_opl3_lib 18620 1 snd_cmipci snd_timer 28855 2 snd_pcm,snd_opl3_lib snd_hwdep 13515 1 snd_opl3_lib snd_mpu401_uart13992 1 snd_cmipci snd_rawmidi29657 1 snd_mpu401_uart snd_seq_device 14136 2 snd_opl3_lib,snd_rawmidi snd70007 8 snd_cmipci,snd_pcm,snd_opl3_lib,snd_timer,snd_hwdep,snd_mpu401_uart,snd_rawmidi,snd_seq_device soundcore 14491 1 snd But the card is not detected by pulseaudio Running PulseAudio Volumne Control: Shows only for Dummy Output Configuration: Shows: No cards available for configuration Charles -- Yow! Now I get to think about all the BAD THINGS I did to a BOWLING BALL when I was in JUNIOR HIGH SCHOOL! -- Mageia release 2 (Cauldron) for x86_64$ On SuperSizehttp://www.eslrahc.com Registered Linux user #182463 3.1.5-tmb-server-1.mga2 x86_64 -- signature.asc Description: PGP signature
Re: [Mageia-dev] mentors + apprentices
Le 12/12/2011 23:49, andre999 a écrit : Hi everyone, We have several new packagers -- barjac and malo (thanks to mentor shlomif), and eatdirt (thanks to mentor obgr_seneca). All of whom are already active maintainers (with at least one package). (malo has over 50.) We have 5 apprentice candidates, all eagerly awaiting their mentor. neocrust (Alexander Scherbakov), who has been waiting over a month, and has experience maintaining packages for openSuse and Lunar Linux, as well as translating to Russion, and doing documentation with the Gentoo Russion team. regularlambda (Mahmut Bulut), who has been waiting almost a month (sorry for missing you), and has experience packaging for other distros. am2605 (Andrew Myers), who has been waiting over a week, a longtime Fedora, a web developer, interested in packaging related to Gnome, Java, Ecliple among others, teaching himself Mageia packaging basics. ajunior (Adjamiltion Júnior), who is interested in maintaining packages related to pinpoint, gzip, or any others needing a maintainer hurdman ((Yyves-Gaël Chény), who develops system software and maintains a Gnu/Linux server at work. You can find more details at: https://wiki.mageia.org/en/Becoming_a_Mageia_Packager#Packager_apprentice_candidates (Note that this address has changed with the new wiki.) Mentors, let me know who you take on, and I'll update the tables for you. Thanks :-) We now have 53 active packagers (maintaining at least one package), with several who have yet to take a package. We currently have about 40 apprentices. Almost 80% of packages have a maintainer. Anyone else looking for a mentor, let me know so I can add your name as an apprentice candidate -- or you can do it yourself. https://wiki.mageia.org/en/Becoming_a_Mageia_Packager#Packager_apprentice_candidates See also the previous sections, on becoming a Mageia packager : https://wiki.mageia.org/mw-en/index.php?title=Becoming_a_Mageia_Packager&action=submit#What_is_needed_to_become_a_Mageia_packager To find a mentor, you can also post to this list (mageia-dev), or on IRC at freenode #mageia-mentoring. Regards :-) I am still waiting on my mentor to give me a report of what he thinks about my AVR32 and ARM packages. I would be interested in becoming the maintainer of mate if no one is doing it yet. I hate gnome 3 with a passion and I find kde too bloated. Michel Catudal -- For OS/2 and Linux Software visit http://home.comcast.net/~mcatudal
Re: [Mageia-dev] How broken are RPM dependencies allowed to be?
On Tue, 2011-12-13 at 16:31 -0800, Dan Fandrich wrote: > I raised a bug ticket on drakxtools (#3731) because the RPM in Cauldron > installs without complaints in Mageia 1 but won't work there because > it requires a newer version of perl. The perl dependency in the > RPM is listed as "perl-base" when it should really be something like > "perl-base >= 5.14.2" (Mageia 1 ships with version 5.12.3). The response > I got was that such an upgrade (from release to Cauldron) wasn't supported > and this bug was likely a wontfix. It's really hard to test for dependencies like this, as the person building the package will have working versions of everything. Worse, in two years' time, perl-base of 5.14.3 will be hopelessly outdated (we all expect, at least). So it becomes one more thing to maintain. But it's also a problem worth solving for some of the system-critical components such as perl, urpmi and drak*. I don't think "wontfix" is a good answer here. My Mandriva Cooker system was unbootable for a while recently because upgrading udev didn't pull in other required packages; the desktop wasn't working for similar reasons. You can say, don't stop mid-upgrade, but a network outage or a power failure can make such things happen. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/
Re: [Mageia-dev] mentors + apprentices
2011/12/14 Samuel Verschelde : > Le mardi 13 décembre 2011 05:49:45, andre999 a écrit : >> Hi everyone, >> >> We have several new packagers -- barjac and malo (thanks to mentor >> shlomif), and eatdirt (thanks to mentor obgr_seneca). All of whom are >> already active maintainers (with at least one package). (malo has over >> 50.) >> >> We have 5 apprentice candidates, all eagerly awaiting their mentor. >> > > According to another thread, I guess that dmorgan is now hurdman's mentor. > > 4 left :) > > Samuel > Hello, I'm not sure if I should post a new message or reply this thread, but I'm looking for a mentor. I'm currently living in Taiwan, where the timezone is UTC+8. English is preferred during mentoring. With very basic packaging experience, I have packed gcin, libchewing, scim-chewing, pcmanx-gtk2 for personal use on Mandriva and Mageia. In the future I wish to maintain these packages since they're not maintained in Mageia. My personal info has been added in the wiki: https://wiki.mageia.org/en/Becoming_a_Mageia_Packager#Packager_apprentice_candidates Best Regards, You-Cheng Hsieh
Re: [Mageia-dev] [RFC] nouveau, swrastg, libdri-drivers-experimental
On 05.12.2011 08:09, Anssi Hannula wrote: > Hi! > > 1. nouveau > > I propose to move nouveau DRI drivers from libdri-drivers-experimental > to libdri-drivers. > > Fedora moved them out of -experimental in last January, Ubuntu in last > June, OpenSUSE in July (though OpenSUSE doesn't have the legacy > nouveau_vieux DRI driver at all), and Debian a week ago. > > I've been running with it for the last week or so with no problems on my > card. > > WDYT? No one was against, so I'm moving nouveau drivers to main dri-drivers package. > 2. swrastg > > It seems we have both swrast_dri.so and swrastg_dri.so in libdri-drivers > package. > > swrast_dri.so is the traditional SW rasterizer used when there is no HW > support. > > swrastg_dri.so is the Gallium3d-based rasterizer which is considerably > faster. > > However, actually only swrast_dri.so is used, so should we: > 1) switch to swrastg, drop swrast (Fedora in Nov 2010) > 2) keep it as is, unused (~4 MB) > 3) move swrastg to libdri-drivers-experimental (Ubuntu in Jun 2010, >Debian a week ago) which nouveau is probably moving out of > 4) drop swrastg completely for now (seemingly OpenSUSE) > > Unfortunately I have no idea on the status of swrastg beyond the above > distro information, and the fact that it does indeed work as tested > while writing this, and XBMC runs smoother with it than with swrast. > > I'd be somewhat inclined to follow Fedora here, but I'm not at all sure. > > WDYT (see also below)? Seems 1 was more preferred in general, so I'll do that and drop legacy swrast. > Implementation note: With a quick look I didn't find any easy way to > switch a system to use swrastg_dri.so when both are installed; if we > want to provide switching between them, we need to either > a) use alternatives for swrast_dri.so, or > b) have swrastg_dri.so in a different dir and have that path first in >the dri search path so that when -experimental is installed, it >will get preferred (while mesa has the needed code already, xserver >would need a trivial patch as it currently has a single search path) > > WDYT? > -- Anssi Hannula
[Mageia-dev] How broken are RPM dependencies allowed to be?
I raised a bug ticket on drakxtools (#3731) because the RPM in Cauldron installs without complaints in Mageia 1 but won't work there because it requires a newer version of perl. The perl dependency in the RPM is listed as "perl-base" when it should really be something like "perl-base >= 5.14.2" (Mageia 1 ships with version 5.12.3). The response I got was that such an upgrade (from release to Cauldron) wasn't supported and this bug was likely a wontfix. I looked for a policy that covers this kind of situation and found nothing clear. The closest I found was this: Packages should only contain Requires if those are absolutely necessary for the program to work correctly...Packages must not contain explicit Requires on libraries except when absolutely necessary. When explicit library Requires are necessary, there should be a spec file comment justifying it...Packagers should revisit an explicit dependency as appropriate to avoid it becoming inaccurate and superfluous. What isn't in the policy is what "absolutely necessary" is. It is clearly "absolutely necessary" from a technical perspective that the newer drakxtools have the newer perl installed for it to work. But, is it necessary to list that version dependency in the RPM? IMHO, it is, given that the perl version in the currently-shipping Mageia distribution is too old to support it. That seems to me to be the kind of use case for which versioned requires were invented. The other argument would be that you shouldn't put any versioned requires on packages that are shipping along with the dependent package. In essence, as long as all the packages in your system come from the same Mageia release, you'll be fine. I think this is much too lax, and won't even really work on Cauldron because there can be so many possible combinations of package versions. It could also break upgrading a system in place to a new distro version, as urpmi could choose to upgrade the dependent package first and leave the newer versioned dependency until much later, leaving the system in a broken state in the meantime. It also ignores one of the most powerful features of RPM and can end up causing "DLL hell". What makes the most sense to me is to use versioned requires whenever technically necessary, but put a limit on how old a version can be before it's dropped. So, if one package absolutely needs a minimum version of another, that version should be listed as long as an older version shipped at some point in the past 3 years or 6 releases (or something along those lines). After then, the version can be dropped in the spec file. Checking for older versions that could be dropped could even be automated. That, to me, strikes a reasonable balance between maintaining flexibility in being able to switch between package versions and maintainability of the spec files and RPMs themselves. >>> Dan
Re: [Mageia-dev] RFC: Drop mkinitrd completely in favour of dracut.
On 03.12.2011 16:39, Anssi Hannula wrote: > On 03.12.2011 08:05, Thomas Backlund wrote: >> Anssi Hannula skrev 3.12.2011 01:06: >>> On 03.12.2011 00:18, Thomas Backlund wrote: Anssi Hannula skrev 2.12.2011 23:17: > > Patch attached. I guess this would remain as a Mageia specific patch as > the wanted behavior is dependant on how the distribution handles driver > switching etc... Speaking of driver switching... Is it possible to detect missing radeon firmware in initrd in early boot, and then switch to loading radeon with modeset=0 ? >>> >>> Seems doable (if a bit hacky), but unfortunately new radeon cards (at >>> least cayman/northern islands) do not work without KMS at all (while >>> slightly older cards like Evergreen mostly work but without any kind of >>> 2d/3d acceleration). >>> >> >> Yeah, I started thinking about those too after my post... >> >>> This also means that X server will fail to start since it doesn't >>> fallback to autodetection (and therefore vesa) when the card is >>> explicitely listed in xorg.conf. >>> >>> Not quite sure what is the best way forward. >>> >> >> Hm, so we would need a split in detection for nonkms capable cards >> and the rest... >> >> or take the easy way out and boot everyone on vesa until radeon firmware >> is available... > > Does loading of radeon modesetting kernel driver without firmware break > the boot completely, or does it just make X.org server fail to start? Does anyone know? >>> BTW, shouldn't we regenerate initrds when installing radeon-firmware for >>> the first time? >>> >> >> Yeah, I've been thinking the same, but haven't gotten around to doing it >> yet. One possibility is to make dracut record the missing firmware files somewhere, and then in %post or in filetrigger (for /lib/firmware) check if missing firmware got installed, and in that case run bootloader-config --action rebuild-initrds. >> and what about nvidia* and fglrx, should they do the same ? > > Well, currently we always include the KMS drivers in initrd, and when > nvidia* or fglrx is enabled we simply add nokmsboot (mga/mdv specific) > kernel parameter to avoid initrd rebuild. > >> and for a dkms related issue, I've also been thinking we whould >> trigger dkms rebuild on kernel install to save time on next bootup. > > That would seem reasonable, it would just be a matter of > [ -x /usr/sbin/dkms_autoinstaller ] && \ > /usr/sbin/dkms_autoinstaller start %kernelver || : > in kernel %post AFAICS... > -- Anssi Hannula
[Mageia-dev] pixmap
Hello,
In a spec file, to install icons, if you copy the image in xpm format in
/usr/share/pixmap how do you update the image?
I search a command like %{_bindir}/gtk-update-icon-cache -q
%{_datadir}/icons/hicolor; but for a pixmap image.
Thank you for advance.
Re: [Mageia-dev] Welcome to tthe packager team: eatdirt
On 13/12/11 17:35, Oliver Burger wrote:
It seems I forgot something.
I'd like to welcome Christophe Ringeval ("eatdirt") to the Mageia packager
team.
Welcome and continue the good work, you already did.
Oliver
Hi there
Thank you Venerable Master, I owe you everything and will do my best to
not turn to the dark side, of course, and honour your teaching with
dignity!! :)
There is a fantastic atmosphere around, I should thank everyone who
helped me, as Colin for his patience and others for their answers to
boring questions (now I can think of a few that were indeed jokes).
Anyway, even if I am now able to not piss on myself doing a mgarepo
"hello word", I'll still ping you, people, for some help I guess :)
Cheers,
chris.
Re: [Mageia-dev] mentors + apprentices
On Tue, Dec 13, 2011 at 5:57 PM, Samuel Verschelde wrote: > Le mardi 13 décembre 2011 05:49:45, andre999 a écrit : >> Hi everyone, >> >> We have several new packagers -- barjac and malo (thanks to mentor >> shlomif), and eatdirt (thanks to mentor obgr_seneca). All of whom are >> already active maintainers (with at least one package). (malo has over >> 50.) >> >> We have 5 apprentice candidates, all eagerly awaiting their mentor. >> > > According to another thread, I guess that dmorgan is now hurdman's mentor. > > 4 left :) > > Samuel > yes done, and account created. I started to find work to do for him
Re: [Mageia-dev] mentors + apprentices
Le mardi 13 décembre 2011 05:49:45, andre999 a écrit : > Hi everyone, > > We have several new packagers -- barjac and malo (thanks to mentor > shlomif), and eatdirt (thanks to mentor obgr_seneca). All of whom are > already active maintainers (with at least one package). (malo has over > 50.) > > We have 5 apprentice candidates, all eagerly awaiting their mentor. > According to another thread, I guess that dmorgan is now hurdman's mentor. 4 left :) Samuel
Re: [Mageia-dev] Welcome New Packagers: barjac and Malo
Am Montag, 12. Dezember 2011, 22:14:36 schrieb Shlomi Fish:
> Hi all,
>
> I'm proud to announce that Barry Jackson ("barjac") and Pierre-Malo Denielou
> ("Malo") have both graduated from their packager mentorship process and got
> submit rights.
>
> Welcome to the Mageia Packaging Team!
>
Welcome here. Your work is appreciated!
Oliver
[Mageia-dev] Welcome to tthe packager team: eatdirt
It seems I forgot something.
I'd like to welcome Christophe Ringeval ("eatdirt") to the Mageia packager
team.
Welcome and continue the good work, you already did.
Oliver
Re: [Mageia-dev] Welcome New Packagers: barjac and Malo
Le lundi 12 décembre 2011 21:14:36, Shlomi Fish a écrit :
> Hi all,
>
> I'm proud to announce that Barry Jackson ("barjac") and Pierre-Malo
> Denielou ("Malo") have both graduated from their packager mentorship
> process and got submit rights.
>
> Welcome to the Mageia Packaging Team!
>
> Regards,
>
> Shlomi Fish
Excellent!
Don't forget to update your maintainership status in the maintdb, if not done
already!
Samuel
