Re: [Mageia-dev] i686 must be Pentium II ?
On Wednesday 22 September 2010 00:38:01 Tomasz Paweł Gajc wrote: Dnia 2010-09-21, o godz. 23:34:07 Anssi Hannula anssi.hann...@iki.fi napisał(a): On Monday 20 September 2010 23:31:21 Tomasz Paweł Gajc wrote: Dnia 2010-09-20, o godz. 11:36:01 André Machado afmach...@dcemail.com napisał(a): Guys, Mandriva - and many other distros, such like Arch Linux - are optimized to i686 architeture, what means Pentium II. Despite the need to keep compatibility with older machines, what would be the problem if packages was compiled aganist Pentium III or 4? Would the system gain more speed? x86 is a dead end. It would be nice to see sse/sse2 enabled by default for x86_64 It always has been enabled there. iirc it wasn't because of some geode compatibility crap, but i can be wrong here Geode is not x86_64, so it is not relevant at all. -- Anssi Hannula ___ Mageia-dev mailing list Mageia-dev@mageia.org https://www.mageia.org/mailman/listinfo/mageia-dev
[Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
break effective DRM (DVD CSS, AACS..) - p2p packages are not allowed, except torrent clients - gaming emulators that use rom files are not allowed === contrib Contains: - those packages not in main Restrictions: - same as main, except that packages can depend on other packages in contrib as well === non-free Contains: - those packages not in main or contrib o including most firmware files, for e.g. WLAN cards Restrictions: - same as contrib, except that only redistribution license is required, and packages can depend on other packages in non-free Ubuntu sectioning === == Main Contains: - packages that are fully supported Restrictions: - can't depend on outside packages (AFAIK) - applications and drivers need to be free software (non-free redistributable documentation, images, sounds, video clips and firmware are allowed on a case-by-case basis; in practice all firmware is shipped as long it is redistributable) - packages can't break effective DRM (DVD CSS, AACS..) - must not require royalty payments o apparently patents are an unwritten exception.. == Restricted Contains: - non-free packages that are officially supported - it contains the minimal amount of packages, currently only: bcmwl, fglrx, lpia, nvidia, sl-modem == Universe Contains: - packages without guaranteed security updates Restrictions: - same license policy as Main == Multiverse Contains: - packages without guaranteed security updates that do not qualify for Universe (including firmware with unknown license) == Partner repository Contains: - unspecified 3rd party packages - contains sun java, adobe flash, skype, realplayer, etc. Not mirrored in normal mirrors (redistribution outside Ubuntu is probably not allowed for some packages). Debian sectioning === == Main - packages that are open source == Contrib - open source packages that depend on non-free packages == Non-Free - packages that are non-free but redistributable Fedora/Opensuse sectioning === Single repository, see the beginning of message for restrictions. Opensuse seems to have a semi-official 'Contrib' repository nowadays, though it doesn't seem to be precisely specified what goes there: http://en.opensuse.org/openSUSE:Contrib It is apparently less official than e.g. Mandriva's 'contrib' or Ubuntu's 'universe', though. Arch sectioning === == Core - Core packages (basesystem only, no X.org, etc) == Extra - Other official packages == Community - Voted and reviewed packages from Unsupported (below). == Unsupported - User submitted packages - No binary packages. (users must build them themselves) [1] http://changelogs.ubuntu.com/changelogs/pool/multiverse/l/linux-firmware- nonfree/linux-firmware-nonfree_1.8/linux-firmware-nonfree.copyright -- Anssi Hannula
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
On Tuesday 12 October 2010 17:34:34 Thierry Vignaud wrote: On 12 October 2010 17:02, Anssi Hannula anssi.hann...@iki.fi wrote: Restrictions: - packages can only depend or builddepend on packages in main itself - packages need to have an open source license o unwritten exception: various non-free but distributable firmware (see kernel-firmware), for example radeon firmware and TG3 ethernet firmware are included despite their license; the selection is arbitrary It's not an exception. Those that as a reasonable licence go in main/release/kernel-firmware Those w/o a license go into non-free/release/kernel-firmware-extra It would seem like that, but if you take a look in the included firmware files you'll see that is not true (I also raised this on cooker@ once: [RFC] Non- free firmware: main or non-free, or?). Some randomexamples: kernel-firmware: - TG3 firmware: redistribution allowed, no modifications - Sun Cassini: Unknown - ti_usb_3410_5052: redistributable, no modifications. kernel-firmware-extra: - agere firmware: redistributable, modifications allowed - Atheros firmware: same - usbdux: GPL with source code Basically 'kernel-firmware' contains all firmware that has at some point been in the main kernel itself, while 'kernel-firmware-extra' contains all new firmware. License does not factor in here. -- Anssi Hannula
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
On Tuesday 12 October 2010 18:18:41 Jerome Quelin wrote: On 10/10/12 18:02 +0300, Anssi Hannula wrote: Do people have any thoughts on what kind of repository/media sectioning we should use on Mageia, and what should those sections contain? == Do we want a separated core repository? No separated core: Fedora, Debian, Opensuse Separated core: Mandriva (main), Ubuntu (main), Arch (Core) i'd rather have no separated core repository. it's really not funny to fail some builds in core because of deps in contrib: understanding why the build fails, requesting the move to main, waiting for someone with move powers to act, waiting for hdlist to be rebuilt and finally, finally resubmit the job... -ENOFUN! now, i guess this will also depend of the support policy we decide for mageia. but i'd really, really like *not* to split main contrib (or whatever their names are). I'd have to agree. However, if we'll only support a subset of the packages, it needs to be very clear for everyone what packages are supported and whatnot (meaning notable notifications in rpmdrake, etc). .. though AFAICS Mandriva didn't make this clear at all either, unless users went to the wiki page to read the media descriptions. We should do better. -- Anssi Hannula
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
On Tuesday 12 October 2010 13:31:21 Marc Paré wrote: There was actually nothing wrong with the Mandriva treatment of repos. It clearly satisfied everyone's expectation of their installation. It became a matter of user choice. By installing, by default, non-licensed software you are not giving the user the choice. You are then targeting a group of users who can install without legal consequence. Didn't you read the first post? :) Mandriva in fact includes lots of codec packages covered by patents. The point is that we need to decide what kind of packages do we want. Should we drop practically all codecs (like Fedora), or have them all in the repository (like Ubuntu)? I thought that PLF were on board with the Mageia project. Does anyone know? They are. -- Anssi Hannula
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
On Tuesday 12 October 2010 12:42:55 Marc Paré wrote: Le 2010-10-12 12:21, Lucien-Henry Horvath a écrit : Le 12/10/2010 18:19, Tux99 a écrit : I think Mageia should include as much multimedia codecs as possible, it the user's responsibility to know the laws of his/her country and if necessary uninstall anything unlicensed/illegal in his/her country. Not only multimedia but drivers too ... in my humble personal opinion / wishes. Unfortunately, if this is done, I will no longer be able to install legally any Mageia due to our laws. I think it is best if these are not installed but let users know where to get them, mostly through PLF. When I install Mandriva Free for people, I will let them know where the PLF repos are and the files needed and they install these themselves. If Mageia packages include unlicensed software and codecs, the Mageia brand may be held legally responsible for marketing software in countries where the laws do not permit this. I don't really think would be a wise decision. Like Ubuntu has been? :) I do see your point, though. -- Anssi Hannula
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
Michael Scherer kirjoitti: Le mercredi 13 octobre 2010 à 20:06 +0200, Olivier Méjean a écrit : Le mercredi 13 octobre 2010 19:31:44, Michael Scherer a écrit : Le mardi 12 octobre 2010 à 17:53 +0200, Olivier Méjean a écrit : == And DVDCSS, etc? What's in etc ? However, here in France we have a law Dadvsi on which the Conseil Constitutionnel (something like American Suprem Court) has statuted that the law could not prevent exception of decompilation and the exception of circumvention of DRM if this is for interoperability. In other words the use of libdvdcss is allowed for interoperability. So for me, Mageia can come with libdvdcss and other tools for interoperability And for the people hosting mirrors outside of France ? It's their own responsability, no one force them, and some in the world take the responsability to host mirrors with questionnable software. Let's give them the liberty to choose as we have the opportunity here in France to ship such software. No one forces several company, university, or other groups to mirror ArchLinux, PCLinuxOS, LinuxMint, PLF So I assume that you volunteer to find another Tier 1 mirror to replace ibiblio.org ? Well, ibiblio.org contains other distros that contain patented software (like arch and debian), and dvdcss (arch), and more than likely many others: ftp://ftp.ibiblio.org/pub/linux/distributions/ (note: I'm still not suggesting having or not having such software, just noting this fact) -- Anssi Hannula
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
Anssi Hannula kirjoitti torstai, 14. lokakuuta 2010 11:07:04: Michael Scherer kirjoitti: Le mercredi 13 octobre 2010 à 20:06 +0200, Olivier Méjean a écrit : Le mercredi 13 octobre 2010 19:31:44, Michael Scherer a écrit : Le mardi 12 octobre 2010 à 17:53 +0200, Olivier Méjean a écrit : == And DVDCSS, etc? What's in etc ? However, here in France we have a law Dadvsi on which the Conseil Constitutionnel (something like American Suprem Court) has statuted that the law could not prevent exception of decompilation and the exception of circumvention of DRM if this is for interoperability. In other words the use of libdvdcss is allowed for interoperability. So for me, Mageia can come with libdvdcss and other tools for interoperability And for the people hosting mirrors outside of France ? It's their own responsability, no one force them, and some in the world take the responsability to host mirrors with questionnable software. Let's give them the liberty to choose as we have the opportunity here in France to ship such software. No one forces several company, university, or other groups to mirror ArchLinux, PCLinuxOS, LinuxMint, PLF So I assume that you volunteer to find another Tier 1 mirror to replace ibiblio.org ? Well, ibiblio.org contains other distros that contain patented software (like arch and debian), and dvdcss (arch), and more than likely many others: ftp://ftp.ibiblio.org/pub/linux/distributions/ Oops, didn't notice the above posts were about DRM only, not patents... anyway, ibiblio contains such distros as well. -- Anssi Hannula
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
On Wednesday 13 October 2010 20:54:45 Dimitrios Glentadakis wrote: About codecs Codeina will be available in Mageia ? I find it very comfortable for new and advanced users. Yes. It is available on Mandriva and I don't see any reason to drop it from Mageia. -- Anssi Hannula
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
Michael scherer kirjoitti perjantai, 15. lokakuuta 2010 02:18:37: On Thu, Oct 14, 2010 at 09:57:03PM +0200, Olivier Méjean wrote: then French law is the law we have to consider for Mageia. Debian runs under SPI organization located in the state of New York, USA, thus is ruled by US Laws. Since the only people who will have issue with this are the president ( aka Anne ) and the people who distribute this ( ie mirrors admins ), I think we should ask them and follow their opinions, and only theirs. Because we can speak of we have no problem, we will have nothing what ever we do, because we are likely not liable. Anne and mirrors owners are. So their words is what does count. Seems sensible to ask the mirror owners. It is possible some of them have not been aware of the problem at all, so I think we should make sure they understand that Ubuntu, Debian, Arch, etc. also contain patented technologies (to avoid the situation where they are willing to mirror Ubuntu/Debian/Arch but not allow patented software in Mageia, just because the other distributions didn't notify them of the issue; if they don't want to mirror Mageia if it contained patent-encumbered software, they really shouldn't be mirroring those other distributions either). -- Anssi Hannula
Re: [Mageia-dev] Various proposals around backports and other media management
On Wednesday 06 October 2010 09:44:37 Samuel Verschelde wrote: Le mercredi 6 octobre 2010 00:06:41, Buchan Milne a écrit : As long as it doesn't take the focus off the development release. In Mandriva, I think there were some uploads to backports before the upload to cooker, which can cause problems for users if not corrected. Indeed. I think that the current policy already tries to enforce that. Those uploads to backports before upload to cooker were mistakes. What about when cooker is in freeze? I guess we should allow backports to cooker backports then? -- Anssi Hannula
Re: [Mageia-dev] Mirror layout, round two
On 30.11.2010 12:37, Thomas Backlund wrote: [...] Can we reach an agreement that this is the way to start the distro? Yes. and for refernece: The suggested layout for is: * core * nonfree * tainted * debug_core * debug_nonfree * debug_tainted Every media contains the same layout: * backports * backports_testing * release * updates * updates_testing I wonder which 32bit ones we should add on 64bit, and which ones of those should be enabled and which ones disabled. On MDV, main+main_updates were added and enabled. But for example wine backports are commonly wanted by 64bit users, and those are in main/backports (core/backports for us). Or is there an alternative approach that I can't think of? -- Anssi Hannula
Re: [Mageia-dev] Mirror layout, round two
On 01.12.2010 22:29, Anssi Hannula wrote: On 30.11.2010 12:37, Thomas Backlund wrote: [...] Can we reach an agreement that this is the way to start the distro? Yes. and for refernece: The suggested layout for is: * core * nonfree * tainted For the record, I'm not a big fan of tainted name (too negative), but I can't think of anything better either, so... :) * debug_core * debug_nonfree * debug_tainted Every media contains the same layout: * backports * backports_testing * release * updates * updates_testing I wonder which 32bit ones we should add on 64bit, and which ones of those should be enabled and which ones disabled. On MDV, main+main_updates were added and enabled. But for example wine backports are commonly wanted by 64bit users, and those are in main/backports (core/backports for us). Or is there an alternative approach that I can't think of? -- Anssi Hannula
Re: [Mageia-dev] Mirror layout, round two
On 03.12.2010 11:45, Ahmad Samir wrote: On 2 December 2010 18:43, Michael Scherer m...@zarb.org wrote: Le jeudi 02 décembre 2010 à 16:26 +0100, Wolfgang Bornath a écrit : 2010/12/2 Anssi Hannula anssi.hann...@iki.fi: For the record, I'm not a big fan of tainted name (too negative), but I can't think of anything better either, so... :) I agree, as restricted may be misleading former Mandriva users, why not special or extra? I know there is the name extra for some other branch but it may be easier to find another name for that one. That would be misleading to the content of the directory. What about limited ? restrained ? ( restrain, to deprive of liberty , seems like the perfect match ) -- Michael Scherer limited and restrained don't sound right as they don't fully convey the purpose/filtering-rule for packages in that repo Indeed. Wolfgang's foggy sounds nice, but I think I prefer tainted anyway. -- Anssi Hannula
Re: [Mageia-dev] Mirror layout, round two
On 05.12.2010 19:36, Daniel Kreuter wrote: On Sat, Dec 4, 2010 at 9:32 PM, andre999 and...@laposte.net mailto:and...@laposte.net wrote: Dale Huckeby a écrit : On Sat, 4 Dec 2010, andre999 wrote: John a écrit : On Fri, 3 Dec 2010 11:28:26 +0100 Maarten Vanraes wrote: Op vrijdag 03 december 2010 10:45:05 schreef Ahmad Samir: [...] The kernel uses the word tainted when it detects the nvidia proprietary module for example, (which admittedly gave me a bit of shock the first time I saw it :)). Heh, i had the same reaction. From all the proposed names, I think tainted is the best one, as the packages in there are in a grey zone, i.e. not totally illegal everywhere, but illegal only in some places in the world. And in reality the existence of a patent doesn't necessarily mean it's enforceable in a court of law (the only way we'd know for sure is if someone actually does try to sue)... my 0.02€ worth :) Generally only potentially illegal in some countries. Tainted means contaminated, polluted. A lot stronger than potentially illegal. (Really only actionable in a civil sense, not criminally illegal, as well.) A package could end up there due to an apparently credible rumour, later discredited. (Anyone remember SCO ?) I agree. Problematic comes closer to potentially illegal, so I looked up some synonyms: ambiguous, debatable, dubious, iffy, suspect, speculative, precarious, suspicious, uncertain, unsettled, in addition to problematic itself. Personally I like iffy, which is both short and to the point, but I think several of these would do. WDYT? Dale Huckeby A much better set of choices. (Thanks for looking these up. Good idea.) Let's remember that the question for these packages is not the quality of their functioning - but rather the advisability to use them, for other reasons, in some countries. So I think that it is better to avoid words that could question the QUALITY of the packages. Words in the list like ambiguous, debatable, problematic, and speculative avoid questioning the quality ... but could be too long or too formal. Or just not catchy enough ;) (Iffy might be ok - certainly catchy enough.) Additional words I found in Roget's thesaurus, along the same lines : Associated more with debatable : arguable, contestable, controvertible, disputable, questionable, Associated more with controversial : confutable, deniable, mistakable, moot Of these additional words, I think that contestable, disputable, and controversial are probably closest to the SENSE of the repositories. But maybe too formal ? Many of these words could be good choices. And maybe someone will come up with some more ? my 2 cents :) - André What about: main, free, non-free? In main is everything what belongs to the core, free contains only packages which are under a free license and in non-free are those which aren't clear if free or not (what you mentioned earlier in this discussion). All three names are as clear as possible what's meant. The license of the packages is not in question (they are free), the patent (etc) situation is. -- Anssi Hannula
Re: [Mageia-dev] Mirror layout, round two
On 05.12.2010 21:47, Daniel Kreuter wrote: On Sun, Dec 5, 2010 at 8:39 PM, Anssi Hannula anssi.hann...@iki.fi mailto:anssi.hann...@iki.fi wrote: On 05.12.2010 19:36, Daniel Kreuter wrote: On Sat, Dec 4, 2010 at 9:32 PM, andre999 and...@laposte.net mailto:and...@laposte.net mailto:and...@laposte.net mailto:and...@laposte.net wrote: Dale Huckeby a écrit : On Sat, 4 Dec 2010, andre999 wrote: John a écrit : On Fri, 3 Dec 2010 11:28:26 +0100 Maarten Vanraes wrote: Op vrijdag 03 december 2010 10:45:05 schreef Ahmad Samir: [...] The kernel uses the word tainted when it detects the nvidia proprietary module for example, (which admittedly gave me a bit of shock the first time I saw it :)). Heh, i had the same reaction. From all the proposed names, I think tainted is the best one, as the packages in there are in a grey zone, i.e. not totally illegal everywhere, but illegal only in some places in the world. And in reality the existence of a patent doesn't necessarily mean it's enforceable in a court of law (the only way we'd know for sure is if someone actually does try to sue)... my 0.02€ worth :) Generally only potentially illegal in some countries. Tainted means contaminated, polluted. A lot stronger than potentially illegal. (Really only actionable in a civil sense, not criminally illegal, as well.) A package could end up there due to an apparently credible rumour, later discredited. (Anyone remember SCO ?) I agree. Problematic comes closer to potentially illegal, so I looked up some synonyms: ambiguous, debatable, dubious, iffy, suspect, speculative, precarious, suspicious, uncertain, unsettled, in addition to problematic itself. Personally I like iffy, which is both short and to the point, but I think several of these would do. WDYT? Dale Huckeby A much better set of choices. (Thanks for looking these up. Good idea.) Let's remember that the question for these packages is not the quality of their functioning - but rather the advisability to use them, for other reasons, in some countries. So I think that it is better to avoid words that could question the QUALITY of the packages. Words in the list like ambiguous, debatable, problematic, and speculative avoid questioning the quality ... but could be too long or too formal. Or just not catchy enough ;) (Iffy might be ok - certainly catchy enough.) Additional words I found in Roget's thesaurus, along the same lines : Associated more with debatable : arguable, contestable, controvertible, disputable, questionable, Associated more with controversial : confutable, deniable, mistakable, moot Of these additional words, I think that contestable, disputable, and controversial are probably closest to the SENSE of the repositories. But maybe too formal ? Many of these words could be good choices. And maybe someone will come up with some more ? my 2 cents :) - André What about: main, free, non-free? In main is everything what belongs to the core, free contains only packages which are under a free license and in non-free are those which aren't clear if free or not (what you mentioned earlier in this discussion). All three names are as clear as possible what's meant. The license of the packages is not in question (they are free), the patent (etc) situation is. -- Anssi Hannula That's what i ment. I don't understand. So, where would you put e.g. patent-encumbered packages of free software, then? If to free, that runs counter to the desire to having them
Re: [Mageia-dev] Mirror layout, round two
On 06.12.2010 14:10, Daniel Kreuter wrote: On Mon, Dec 6, 2010 at 1:04 PM, Ahmad Samir ahmadsamir3...@gmail.com mailto:ahmadsamir3...@gmail.com wrote: Because Ubuntu already has a repo called universal? that's a similar reason to why it wasn't called restricted, because restricted is used by distros that offer a commercial repo as in pay to use some more stuff. -- Ahmad Samir Do they have a patent on the name? No, but it will cause confusion among users if we use the same name for a different thing than they do. -- Anssi Hannula
Re: [Mageia-dev] Mirror layout : Why validate software patents ?
Wolfgang Bornath kirjoitti: 2010/12/8 andre999 and...@laposte.net: Ok, I think, how many other distros have such repositories. Â According to comments on the list : none. Oh, really? Some (like Mandriva) do not have such a repository because they do not distribute such software at all, In theory only. In practice, Mandriva ships many kind of patented MPEG-4 encoders/decoders, MP3 decoders, VC-1 decoders, etc. Some discussion about this should probably be raised there as well.. If I simply had the time :/ PLF does that for Mandriva. What about Ubuntu? They ship such stuff (like ffmpeg with all decoders/encoders) in their main repository, like Debian does. Also, their universe repository (similar to Mandriva's contrib) does not contain such limitations either, containing stuff like x264 and mp3lame. What about Fedora? Fedora does not have such software. -- Anssi Hannula
Re: [Mageia-dev] Mirror layout : Why validate software patents ?
Wolfgang Bornath kirjoitti: 2010/12/8 Daniel Kreuter daniel.kreute...@googlemail.com: On Wed, Dec 8, 2010 at 9:51 AM, Wolfgang Bornath molc...@googlemail.com wrote: Oh, really? Some (like Mandriva) do not have such a repository because they do not distribute such software at all, PLF does that for Mandriva. What about Ubuntu? What about Fedora? In Ubuntu you have some patented software in the repos. Yes, I know. The question was: do they have those patented software within the same repo as all the other software or do they have an extra repo for that. In reply to andre999 I wanted to point out that there are other distributions who make a difference between patented software and everything else. Some do not distribute them at all (Mandriva, Fedora), some have them in an extra repository (Ubuntu). Ubuntu doesn't have an extra repository for them. They are in universe, which contains all the non-core packages (like mdv contrib). (Some patent-covered stuff, like ffmpeg, are in ubuntu main) -- Anssi Hannula
Re: [Mageia-dev] Mirror layout : Why validate software patents ?
Ahmad Samir kirjoitti: Debian has a non-US repo... etc There hasn't been a non-US repo in Debian releases in years. It existed due to cryptographic regulations in the US, IIRC. -- Anssi Hannula
Re: [Mageia-dev] Mirror layout
Just some smallish notes regarding other distros.. On 10.12.2010 12:22, andre999 wrote: Debian uses the same names main, contrib, non-free, with explicit policy close to Mandriva practices. In the same policy page, they say that patent-contrained software goes into non-free, then further down they say that it can be excluded. http://www.debian.org/doc/debian-policy/ch-archive.html Interesting.. this doesn't seem to correspond to reality (they have e.g. ffmpeg with patent-constrained codecs enabled). [...] Fedora package acceptance policy is explicitly dictated by RedHat. Includes only free packages (thus excluding redistributable drivers), plus excludes legally constrained packages. Fedora is the only distro reviewed here which does not accept non-free packages. They allow non-free firmware: http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#Binary_Firmware However, given that RedHat sells their versions of Linux (with support), one could question the motivation of the Fedora policy. -- Anssi Hannula
Re: [Mageia-dev] packages importing: what replaces rpm-mandriva-setup-build
On 08.01.2011 17:08, Jerome Quelin wrote: hi, perl does: BuildRequires: rpm-mandriva-setup-build = 1.8 what should it be translated to? rpm-mageia-setup-build? or nothing at all, since we'll have the latest greatest version? :-) I'd say it could be made simply rpm-setup-build (i.e. merging both rpm-mandriva-setup and rpm-manbo-setup to rpm-setup), but I guess that really depends on how the rpm*setup maintainer/importer handles it :) -- Anssi Hannula
Re: [Mageia-dev] Adding Java-Policy
On 10.01.2011 10:11, Daniel Kreuter wrote: On Sun, Jan 9, 2011 at 11:13 PM, Anssi Hannula anssi.hann...@iki.fi mailto:anssi.hann...@iki.fi wrote: On 08.01.2011 11:39, Farfouille wrote: My suggestion would be to look at how Mandriva packages are done, as we will probably initially follow their java policy. (note that the mandriva java packages do not have the gcj AOT binaries, and they are compiled with openjdk on archs were openjdk is available) I'm not saying that a completely new java packaging policy is not needed (it is), though, so if the java developers have the resources to convert all imported java packages to a completely new policy, I'm all for it :) There are around 400 java packages in Mandriva, though I hope we don't need to import all of them (i.e. hopefully many are unused/old). -- Anssi Hannula That could be a very hard task, because you have to look if there aren't any dependencies on some of these packages. I would suggest to drop the whole gcj packages, but even it's unmaintained now by upstream, GCJ is not unmaintained, it is part of GCC. See http://gcc.gnu.org/viewcvs/trunk/gcc/java/ChangeLog?view=markup Dropping it would be more work than not dropping it, so I don't see the point. there are a few programs depending on it (like a few packages of ant i think) Ant doesn't depend on it. There are several packages that depend on it, though, yes. But writing a policy about the openjdk would be the right thing now because we will integrate it, it's also in mandriva but without a policy or Remy didn't find one for that. Yes. -- Anssi Hannula
Re: [Mageia-dev] Adding Java-Policy
On 10.01.2011 16:28, Farfouille wrote: 2) Effective Mandriva Java packaging policy is almost the same as Fedora. Btw Fedora java package policy is up to date and very complete. It is written under Attribution-Share Alike 3.0 Unported licence (http://creativecommons.org/licenses/by-sa/3.0/). I was wondering if I can adapt the Fedora policy to Mageia. This is allowed by its licence, but I don't know if it is possible or desirable to attribute some Mageia policy stuff to Fedora. Help on this point is welcome. Mandriva java packages currently follow Fedora policy closely, so adopting the Fedora policy (with small changes like java=%java, ant=%ant etc) seems like the best course of action, at least for the time being. I don't see any problem with the Fedora policy license. -- Anssi Hannula
Re: [Mageia-dev] Java-Policy first draft published
On 10.01.2011 22:02, Farfouille wrote: Hi I have published a first draft of Java application package policy. http://mageia.org/wiki/doku.php?id=java_applications_policy Corrections and comments are welcome. BuildRequires: java-devel [= specific_version] BuildRequires: jpackage-utils These are satisfied by *any* java compiler, however we want packages to be always built by a specific compiler. On Mandriva we solved this by replacing BuildRequires: java-devel with BuildRequires: java-rpmbuild which is used to pull the main java compiler (openjdk on all archs where it is supported, gcj/ecj on others). BuildRequires: ant ... %build ... ant Replace ant with %ant. This ensures ant is called with the specific java compiler as mentioned above. Also, the policy should mention %jar, %java, %javac, %javadoc, %java_home that should be used when those tools/paths are needed. Questions/Points : Section Specfile Template for ant and maven, I am not sure that the definition of Release is correct. Shouldn't it be useful to have a general policy about package name and versioning (like Fedora : http://fedoraproject.org/wiki/Packaging/NamingGuidelines) ? Yes. MDV wiki has something on those, but not much indeed: http://wiki.mandriva.com/en/Development/Howto/RPM_Advanced#Naming_a_package http://wiki.mandriva.com/en/Development/Howto/RPM_Advanced#Releasing_pre-versions As I have never used maven, a deep reread is required Licence discrepency : dokuwiki template says licence is 'CC Attribution-Share Alike 3.0 Unported' but web application policy (http://mageia.org/wiki/doku.php?id=web_applications_policy) claims 'Creative Commons Attribution-ShareAlike 2.5 License' (end of the page) Cheers -- Farfouille -- Anssi Hannula
Re: [Mageia-dev] bs down
On 14.01.2011 15:53, Olivier Blin wrote: Olivier Blin mag...@blino.org writes: Thomas Spuhler tho...@btspuhler.com writes: Is the bs down. Looks like rpmbuild is missing? Yes, it was. [...] Actually, I already fixed this error in iurt SVN yesterday, but I've now uploaded a package with the fix on the BS nodes. Another common error these days is that file dependencies are not added automatically in hdlist. According to genhdlist doc, this should be done automatically for packages from the same media. Anssi, maybe you know if this is supposed to work? I *think* it used to work, however mdv mirrors seem to currently include a complete file-deps file. Haven't really looked into this, though. I am currently workarounding this by resurrecting a small file-deps file in media_info. BS should be working again now that I added /bin/rm (for procps) -- Anssi Hannula
Re: [Mageia-dev] bs down
On 14.01.2011 17:00, Olivier Thauvin wrote: * Anssi Hannula (anssi.hann...@iki.fi) wrote: On 14.01.2011 15:53, Olivier Blin wrote: Another common error these days is that file dependencies are not added automatically in hdlist. According to genhdlist doc, this should be done automatically for packages from the same media. Anssi, maybe you know if this is supposed to work? I *think* it used to work, however mdv mirrors seem to currently include a complete file-deps file. Are you sure it is not a file generated long time ago and never updated ? No, I think that is exactly what it is. No one would have notice since 1) everything to replace dep on file by direct package dependencies (with some side effect I guess) 2) they do not change so often. -- Anssi Hannula
Re: [Mageia-dev] bs down
On 14.01.2011 18:44, Olivier Blin wrote: Michael Scherer m...@zarb.org writes: Le vendredi 14 janvier 2011 à 11:39 +0100, Olivier Blin a écrit : Thomas Spuhler tho...@btspuhler.com writes: Is the bs down. Looks like rpmbuild is missing? [...] Actually, I already fixed this error in iurt SVN yesterday, but I've now uploaded a package with the fix on the BS nodes. But aren't the chroot tarball recreated at regular interval anymore ? No, we would have to put some cron if we want this. But is it really useful? If a basesystem change, the chroot gets rebuilt automatically already. If no basesystem change, the rebuilt chroot will be the same, and does not have to be rebuilt (just in case is usually the wrong way to do things). AFAIK it was only useful because on Mandriva BS iurt never regenerated the chroot if it was already there, even if it was not up-to-date. Would it have helped to remove it ? It would have helped if triggered every hour, which does not seem reasonable (I guess it was every 7 days at Mandriva). AFAIK daily. Anyway, my iurt fix helps not to encounter this issue anymore, with no other trick. -- Anssi Hannula
[Mageia-dev] large proprietary applications (was: Re: questions)
On 10.01.2011 22:50, Maarten Vanraes wrote: Op maandag 10 januari 2011 21:05:54 schreef Thomas Backlund: Maarten Vanraes skrev 10.1.2011 21:47: i noticed (in commits) that there is a sizelimit on the binrepos upload. what if i have a binary file that is larger than that limit? It hasn't triggered for me yet, and I've imported kernels with big tarballs... I am maintaining a non-free game that has a 400MB binary .. I wonder if we should have some size limit for such non-free stuff... I don't have a strong opinion on this one, though, what do other people think? -- Anssi Hannula
[Mageia-dev] Clarification on firmware licenses
Hi all! Sorry for bringing this stuff up again, but it seems there is still some confusion regarding firmware licenses and to which repository put the various firmware packages. Clear cases: - open-source firmware with source code goes to core - firmware which doesn't allow modifications or has other similar restrictions goes to non-free However, what to do with firmware that is licensed under a free license (e.g. BSD/GPL) that doesn't have source code? There are quite a few of those (see e.g. [1]). A quick look at other distros shows the following: Debian: - All firmware without source code goes to non-free. - No GPL firmware without source code at all, even in non-free (presumably because if Debian would distribute those files, Debian would have to provide the source code to comply with GPL, which it can't do because the source code isn't available at all). - No unknown-license firmware at all. Fedora: - All redistributable firmware is allowed in main repo (there is no non-free repo), even if non-free. - Unknown-license firmware is allowed only if it was previously distributed as part of kernel. Ubuntu: - All redistributable firmware is apparently allowed in main, even if non-free license with restrictions on modification. (this is in contrary to Ubuntu licensing page [2] which says that modification must be allowed for all packages in main). - Unknown-license firmware that was previously in kernel is also in main. - All other firmware files with no license at all is also allowed, in multiverse repository. Mandriva: - No sane policy, half of them is in non-free and the other half in main. - Unknown-license firmware is allowed only if it was previously distributed as part of kernel. [1] http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=blob;f=WHENCE;h=d807e25c5515d05ffe5fe949b480ae661eb079fb;hb=HEAD [2] http://www.ubuntu.com/project/about-ubuntu/licensing -- Anssi Hannula
[Mageia-dev] Compatibility: %mdkversion macro?
Hi all! Should we have a %mdkversion (and %mdkver/%mdvver) that is hardcoded to 201100 for the time being, or should we not have one at all? Not having it will cause any src.rpms that have any %if %mdkversion x to fail to build. I'm strongly in favor of having it for compatibility reasons, so that most MDV src.rpms keep building on Mageia for the time being, including those provided by any 3rd party packagers. Not having the macro will cause us to lose that compatibility for very little benefit, IMO. It could maybe be removed after several releases, but not before. However, it seems blino disagreed with this, and he thinks we should not have these macros at all. What do other people think? -- Anssi Hannula
Re: [Mageia-dev] Not present at tonight meeting ( again )
On 19.01.2011 02:12, Michael scherer wrote: Hi, I will not be present at the packagers's meeting tonight, as I will likely be finishing the app installer meeting in Nuremberg ( transalte : discuss in a pub ). The wifi is expensive, and so I had to use ninja powers to get ssh access ( translate : use mad h4x0r skill ). So sorry, especially for ennael that I let do the work. Unfortunately I'll miss the meeting as well. -- Anssi Hannula
Re: [Mageia-dev] On importing /soft
On 19.01.2011 22:32, Pascal Terjan wrote: http://svn.mageia.org/soft-cleaning/status.html#monitor-edid says - README: Some reference to the Mandriva mailing list and bugzilla will need to be changed to Mageia ones Do we really want to? What is the point? I think we can package this tool as-is, as a tool provided by Mandriva like if we were packaging a non distro specific tool developed by RedHat or Debian or anyone and let people report their bugs upstream if the README says so. If someday it becomes unmaintained or for any other reason, we can fork it, but currently I think of it as an external tool and see no reason in importing it into our svn I did not read the full list but I guess there are other standalone tools that we don't need to fork into our svn. Opinions? +1 for no-fork for now. -- Anssi Hannula
Re: [Mageia-dev] undefined reference to `pow' even with -lm
On 21.01.2011 15:32, philippe makowski wrote: Hi all, if any one have a clue to solve my build problem In the command line, -lm has to be *after* the file that needs it, like the other -lfoo entries are on the below log. the build is ok on my mdv with bm, but not on the mageia bs :( see : http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20110121084807.philippem.valstar.23877/log/botcmd.1295599743.jonund.log thanks -- Anssi Hannula
Re: [Mageia-dev] packages branches and revision numbers when submiting packages with mgarepo
Sorry for the delay. On 29.01.2011 16:30, nicolas vigier wrote: On Sat, 29 Jan 2011, Anssi Hannula wrote: AFAICS the above branch scheme doesn't work well with changelog generation. As changelog is generated from [packagename]/releases, one of two things seems bound to happen: a) There is no [packagename]/releases under the branch, and the changelog gets messed up (all commits since initial package import in a single release entry), or b) One tries to keep [packagename]/releases to preserve sane changelog when branching, but this will fail as this SVN command is invalid, as one can't copy a directory into itself: svn cp /packages/cauldron/[packagename] /packages/cauldron/[packagename]/branches/[branchname] Good question. I have looked at how it is working now : - it first looks at all svn logs from [packagename]/releases, and extract infos from %repsys markrelease logs, which contains infos about packages version, release, and relrevision. - it use commit logs from [packagename]/current and groups them by package releases using the infos from markrelease. So I think we can do this : - We don't copy releases directory in branches, only SPECS and SOURCES directories, we share the releases directory for current and branches. - In %repsys markrelease commits, we include the branch name - When generating logs for a branch package we only use markrelease infos from that branch, and from current from before the first markrelease for the branch - When generating logs for current package, we ignore markrelease from other branches Does it look ok ? What if branches are moved / branched to other branches? Also, that won't preserve the changelogs of branches when they are merged back (not 100% sure if that is wanted, though). -- Anssi Hannula
Re: [Mageia-dev] freedesktop spec and categories
On 24.02.2011 11:06, Samuel Verschelde wrote: Le jeudi 24 février 2011 08:27:36, Oliver Burger a écrit : Am Donnerstag 24 Februar 2011, 08:20:41 schrieb Tux99: I have always hated that apps 'disappear' in the Other folders, can we not completely get rid of the Other folders, they don't make any sense (at least intuitively for a user). IIRC this is triggered by the Categories entry in the desktop file of the application. I think we would have to patch ALL upstream desktop files to get rid of it which would be quite a pain. Oliver I don't think so. Several Mandriva releases ago, there was no such More entry, but real sub-categories in the menu. Then it changed for what we have now, but that wasn't a change in the .desktop files, rather a menu configuration. I guess that was a decision meant to bring simplicity, but I always hated that choice, because nobody can know in advance whether an application will show in the first level or be hidden in the more section. I prefer a 2-level menu tree. If people find that it makes too much clicks, then they shouldn't be using the menu but add a shortcut to the applications they use regularly in their taskbar or desktop (or just use ALT+F2). I can speak only for myself, but I also preferred the two-level tree. It has been long in my TODO to implement an alternative menu style file that would make the menu like that, but unfortunately my TODO is too crowded by other stuff... -- Anssi Hannula
Re: [Mageia-dev] freedesktop spec and categories
On 24.02.2011 18:57, Tux99 wrote: Quote: Michael Scherer wrote on Thu, 24 February 2011 13:27 Le jeudi 24 février 2011 à 10:06 +0100, Samuel Verschelde a écrit : I don't think so. Several Mandriva releases ago, there was no such More entry, but real sub-categories in the menu. Then it changed for what we have now, but that wasn't a change in the .desktop files, rather a menu configuration. I guess that was a decision meant to bring simplicity, Yes, and that's a choice that can be backed by several studies on the subject, the working memory have been estimated to be 7 chunks of information ( between 5 and 9 is a wildly accepted range ). I remember having seen a studie saying that it was less than this, but I cannot find it ( and it was on slashdot, so this may have been wrong ). So presenting only ~7 chunks of information ( ie ~7 items in menu ) is better according to the current cognitive model used, such as this one : http://en.wikipedia.org/wiki/Human_information_processor_model Eh, isn't that a reason to switch *back* to the two-level system, not to keep the current system? I have about 15-30 entries in everyone of Internet, Office, Audio/Video, Tools, Tools-System submenus. With a two-level system it would be considerably less and closer to the ~7 you mention. The study that estimates the number of chunks of information a normal human can keep in working memory might be correct, but it's applied in a completely unfitting situation here. Scanning a list of program names has nothing to do keeping chunks of info in the brain. I'm pretty sure that if we make a survey among Mandriva users the majority will be saying they don't like apps hidden behind More as it currently happens, they would want them in the higher level with all the other apps of the same type. Every Mandriva user I know (regarless if a complete noob or an IT literate person) finds the More.. folder confusing and counterintuitive and without any benefit. I would actually think this is one of those things where a poll among users would make sense, since it doesn't really have technical implications either way. Another solution would be to make it a configurable user preference, but of course that would require someone to write the necessary code, so that's not such an immediate solution as changing the config. The code is mostly written (drakmenustyle) as it is already possible to switch between mdv and kde/gnome menu styles, but it would be some work to create the menu style itself. BTW: can anyone tell me where exactly this More folder behaviour is configured? MDV menu style is in /etc/xdg/menus/kde-applications.menu for KDE and /etc/xdg/menus/applications.menu for others. Upstream kde4 menu is in /etc/xdg/kde4/menus/applications.menu. Upstream gnome menu is in /etc/xdg/gnome/menus/applications.menu. I don't remember which script/config file is used to change the menu style used, but this can be configured via drakmenustyle. -- Anssi Hannula
Re: [Mageia-dev] freedesktop spec and categories
On 25.02.2011 02:12, Michael Scherer wrote: Le vendredi 25 février 2011 à 00:09 +0200, Anssi Hannula a écrit : On 24.02.2011 21:15, Michael Scherer wrote: Le jeudi 24 février 2011 à 20:30 +0200, Anssi Hannula a écrit : With a two-level system it would be considerably less and closer to the ~7 you mention. Depend, what is the process that you are wanting to improve ? ( and closer is not good enough, even if 15 is nearer to 7 than 20, that's still too much and a different process is used ( according to studies )) No idea. IMO finding the wanted application is faster when it goes Internet = 5-7 submenus = each with 2-5 app entries instead of the current Internet = 20 app entries, plus 10 more in More Yes. But I think that what some people want is Internet = 30 apps. ( ie, suppress More ) Citing tux99 : I'm pretty sure that if we make a survey among Mandriva users the majority will be saying they don't like apps hidden behind More as it currently happens, they would want them in the higher level with all the other apps of the same type. So maybe I misunderstood. What need to be taken in account too is also the case Internet = 5-7 apps. Having : Internet = 5-7 submenus = 1 app entry is IMHO clearly suboptimal. ( ie, 1 step more to get application , on a total of 3, that's a lot ). The menu style file [1] allows for inline_limit attribute which specifies a minimum entry count before the submenu is added, otherwise the app entries are added to the parent menu instead. So e.g. submenus with less than 2-3 apps could be merged to parent submenu. [1] http://standards.freedesktop.org/menu-spec/menu-spec-latest.html -- Anssi Hannula
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
On 26.02.2011 07:35, andre999 wrote: Maarten Vanraes a écrit : Op donderdag 24 februari 2011 16:08:51 schreef Anne nicolas: 2011/2/24 Thierry Vignaudthierry.vign...@gmail.com: On 24 February 2011 07:13, andre999and...@laposte.net wrote: And if you discussed the issue and your POV wasn't adapted, what's the point re-emerging it now given that changing the new isn't easy now that the infra- is already in place. In 4+ months, a lot will be changed/corrected. In my mind, this inappropriate name will tarnish Mageia. We can surely find a much more appropriate name. Since the repositories in question are empty, and will never be very big, the cost of changing is minimal. Then what do you suggest? (Remember we already have that discussion) half free :-) maybe free free maybe patent-free in your country/release not sure (special idiocraty for blinopterjan) (me slapping enael for having let those guys view that film) As a side note, let me protest against this. I was a victim and had to watch it 3 or 4 times i'm really curious about the movie now... me too :) actually, any of those suggestions would be an improvement ;) I did suggest contrained. Ubuntu uses restricted and/or multiverse (which include mostly non-free packages), and there were a lot of other suggestions. There was only ONE that seemed inappropriate. Ubuntu's multiverse and restricted contain non-free packages only. Packages in tainted are all free packages. -- Anssi Hannula
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
On 26.02.2011 22:20, andre999 wrote: Anssi Hannula a écrit : On 26.02.2011 07:35, andre999 wrote: ... actually, any of those suggestions would be an improvement ;) I did suggest contrained. Ubuntu uses restricted and/or multiverse (which include mostly non-free packages), and there were a lot of other suggestions. There was only ONE that seemed inappropriate. Ubuntu's multiverse and restricted contain non-free packages only. Packages in tainted are all free packages. ok just the Ubuntu web site repository descriptions indicate that patent-threatened or legally restricted packages would go into these repositories, along with the usual non-free. I have no idea what they do in practice. They have fully enabled ffmpeg in main, and mplayer,x264,lame in universe. So patent-constrained pkgs do not appear to be put in multiverse. do you mean that you consider that non-free packages should go into non-free, even if threatened by legal or patent constraints ? Well, those don't really belong to either, so I'm unsure what would be done with those. However, I'm not aware of any such packages so it is a moot point :) -- Anssi Hannula
Re: [Mageia-dev] Importing Licensing Policy
On 09.01.2011 01:15, Remy CLOUARD wrote: Hello, I just started to import the Licensing policy from the Mandriva wiki. Here are notable changes: [...] - adding a complete list of license names (produced by rpmlint) This list directly contradicts the Fedora naming convention which we use, i.e. most of the names in the list are different from the ones we actually use. Also, a link to the Fedora list is missing. Thanks in advance for reviewing this policy -- Anssi Hannula
Re: [Mageia-dev] Contributors using real name/working email? or not? or maybe?
On 03.03.2011 16:00, Romain d'Alverny wrote: [...] The points to decide here are: a) should a contributor provide a public email address, to be used in changelogs, commits and everywhere her contribution to the project needs an id or contact id? (for instance changelog, commit, document authoring) I'm not sure what you mean by providing here. Contributors should have @mageia.org addresses, and this address must be shown in RPM Changelogs and RPM Packager fields (as is done in Mandriva). b) should a contributor provide a real name for the same goals? or is a fake name/alias ok, as long as there are people that do know/meet the person? I'd prefer everyone provide a real or fake name instead of an alias, but I don't feel so strongly about this. I won't comment on pros and cons below (not exclusive of others), but those were raised in the discussion before: The pros (as in yes one should): - that is the common way used in MDV and other major distributions - (email or name) it identifies the author of a change to the project/code - (email) it helps identifying contacting directly someone in the project (peer review or any ad hoc matter) - (email name) it helps building confidence among contributors and from the outside - (name) it encourages people to adopt a consistent behaviour - (email name) it builds one's contributions list for future/outside reference The cons (as in no, one should be free not to) - public email addresses get spammed I don't consider this a big issue, the email addresses are readable from mailing lists etc. in any case. - personal preferences to not reveal one's name - there are situations where anonymity is a requirement or nice to have (from a personal or corporate point of view) - it will encourage people to contact directly contributors instead of using other expected channels Note that one may use a fake name/identity anyway to stay anonymous (but unless one already has a network of trust within a group, she would not have a past public record to help building her new reputation). What is at stake is the accountability for each contributor, hence for the whole project. What will matter is what one does and how. And again, let's have this point discussed in a cool, informative, constructive and efficient way, please. Cheers, Romain -- Anssi Hannula
Re: [Mageia-dev] Contributors using real name/working email? or not? or maybe?
On 04.03.2011 00:51, Maarten Vanraes wrote: Op donderdag 03 maart 2011 22:58:16 schreef nicolas vigier: On Thu, 03 Mar 2011, Maarten Vanraes wrote: Op donderdag 03 maart 2011 22:31:10 schreef Romain d'Alverny: On Thu, Mar 3, 2011 at 21:54, Frank Griffin f...@roadrunner.com wrote: Maarten Vanraes wrote: C. how about we make packagename@packages.mageia.org, which could use the maintainers database to forward the email to maintainers (in case of more) (this could also be a packagegroup. eg: fire...@packages.mageia.org could refer to maintainers of firefox, xulrunner, etc...) (this option might just be too complex) That is an elegant and excellent idea. Elegant, but as in a changelog, that means the email does not match/identify/link to the _person_ taking the step of actually committing/releasing the change, but the team in charge of managing the package. Is that wanted? Romain it depends, the nickname could still be kept; and we were talking about having multiple maintainers in the future? Except that changelog is not for listing maintainers, but the persons who did some changes. but changelog is for committing, not submitting? isn't this a totally different thing? I don't understand what you mean. Changelog is a log of changes made to the package. -- Anssi Hannula
Re: [Mageia-dev] Importing Licensing Policy
On 05.03.2011 11:38, Remy CLOUARD wrote: On Sat, Mar 05, 2011 at 01:23:25AM +0200, Anssi Hannula wrote: On 28.02.2011 03:51, Anssi Hannula wrote: On 09.01.2011 01:15, Remy CLOUARD wrote: Hello, I just started to import the Licensing policy from the Mandriva wiki. Here are notable changes: [...] - adding a complete list of license names (produced by rpmlint) This list directly contradicts the Fedora naming convention which we use, i.e. most of the names in the list are different from the ones we actually use. Removed. -- Anssi Hannula All right, but where do one find the list of available license names ? http://fedoraproject.org/wiki/Licensing#SoftwareLicenses I think I mentioned in my earlier reply that the link was missing from the wiki page (it existed in mdv wiki), though I forgot to fix it at the same time it seems. I used rpmlint to produce this list, so if these licenses are wrong, we need some list of valid licenses names, so that we can fix rpmlint too. As a side note, we will also have a lot of work to fix all the wrong license names in the existing packages Regards, -- Anssi Hannula
Re: [Mageia-dev] [RPM] cauldron core/release speedtouch-firmware-extractor-0.1-7.mga1
On 06.03.2011 22:58, Thierry Vignaud wrote: On 6 March 2011 21:27, Mageia Team buildsystem-dae...@mageia.org wrote: ennael ennael 0.1-7.mga1: + Revision: 65624 - imported package speedtouch-firmware-extractor Honestly, are there still raie manta users somewhere in the world? Offtopic, but how can one subscribe to changelog@ ? I wasn't aware we had one, and I don't see it mentioned anywhere in the website... Do we happen to have one from commits as well? It is something I've been waiting for for quite some time now... -- Anssi Hannula
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
On 14.03.2011 01:01, Tux99 wrote: Personally I also think 'tainted' would be the better choice than 'non-free' since potential patent issues are a more serious concern than a non-FOSS license, but tbh I think both choices are far from ideal, I believe the only really clean solution would be to create a 'tainted+non-free' repo just like PLF has. One option would be to add it to tainted, but have it require a dummy metapackage from non-free repository, so that it can be only installed if non-free media is enabled. It might cause too much confusion, though, as the error message wouldn't be very clear. The PLF 'non-free' repo contains quite a few packages [1], I would think we will want to add most of them to Mageia too, so this will continue to be a problem. Most (if not all) of those either a) do not have patent issues and are thus eligible for mga/mdv non-free repositories (mdv didn't have a non-free section until 5 years ago, explaining why they are in plf), or b) are completely unredistributable, and thus uneligible for any mga/mdv repository. [1] http://distrib-coffee.ipsl.jussieu.fr/pub/linux/plf/mandriva/cooker/non-fre e/binary/i586/ -- Anssi Hannula
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
On 15.03.2011 12:28, Michael Scherer wrote: Le mardi 15 mars 2011 à 05:06 +0100, Tux99 a écrit : To add some examples of 'tainted+non-free' packages (that also include source code) I just came across in plf free (plf doesn't seem to be too strict about their free/non-free subdivision): I was in Vienna in May 2004 when we first discussed the split with the 3 others terrorists present ( but the change was effective 9 months later : http://comments.gmane.org/gmane.linux.mandrake.plf.general/993 ), so I think I can call myself knowledgeable on the way things should be for PLF, despites having leaved the project some time ago. So if you provides examples, that's nice, but that's likely bugs. amrnb-7.0.0.2-2plf2011.0.src.rpm amrwb-7.0.0.3-2plf2011.0.src.rpm This one is interesting, because the whole code is free in the tarball, as this download the code from the internet at compile time. The resulting code is IMHO non-free. I would suggest to drop it and to use http://sourceforge.net/projects/opencore-amr/ , which is more cleanly licensed ( Apache license ). That's how rpmfusion does. That's IMHO a bug that should be reported to PLF, unless Anssi disagree :) What you say above is completely true. faac-1.28-3plf2011.0.src.rpm The software license is LGPL 2 or later, according to Sophie http://sophie.zarb.org/rpms/7f88a24475773b9426d03122bcaa521f It is tagged incorrectly. It contains ISO reference source code that forbids use in products that do not claim conformance to MPEG-2 NBC/MPEG-4 standards. Actually faac is what this thread is about. Where will we put these in Mangeia? 'tainted' or 'non-free' or a new 'tainted+non-free' repo? amrnb - dropped, replaced by opencore-amr faac - tainted -- Anssi Hannula
Re: [Mageia-dev] [RPM] cauldron core/release playonlinux-3.8.8-2.mga1
On 12.03.2011 12:12, Samuel Verschelde wrote: Le samedi 12 mars 2011 09:27:54, Thierry Vignaud a écrit : On 11 March 2011 12:19, Mageia Team buildsystem-dae...@mageia.org wrote: stormi stormi 3.8.8-2.mga1: + Revision: 68228 - clean spec - imported package playonlinux This is bogus as in Mandriva. It enforces installing wine, thus loosing 64b support on x86_64 by removing wine64 in favor of wine. What would be the solution ? I must admit I didn't know this problem in Mandriva because I have only i586 systems. If you want playonlinux to always depend on 32-bit wine, while allowing 64-bit installations to have both 32-bit and 64-bit wine, you can use requires on wine32. If, on the other hand, you want playonlinux to depend on any wine regardless of bitness, you can use requires on wine-bin (note that 64-bit wine can't execute win32 applications without wine32 package aka 32-bit wine). Using simply requires on wine prevents installation of 64-bit wine completely, so it is therefore wrong. Playonlinux requires wine and wine-full (both provided by wine, and wine-full being an explicit Requires you added some months ago, from the changelog). Does wine64 provide those ? Is the requires on wine the problem ? Best regards Samuel Verschelde -- Anssi Hannula
Re: [Mageia-dev] Packaging errors to fix
On 15.03.2011 15:38, Michael Scherer wrote: 3rd : dbus. There is a vicious loop between dbus and its own library, So? Both of the requires are correct from what I know, and dependency loops are not forbidden. I can imagine there are also some more clear cases of such loops, like library A depending on B, B on C, and C again on A, which I personally don't believe are in the need of solving. -- Anssi Hannula
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
On 13.03.2011 22:01, Thomas Backlund wrote: sön 2011-03-13 klockan 21:55 +0200 skrev Tux99: During the review with my mentor Anssi of one of the packages I'm working on, the question came up what the appropriate repository for a package is that's both non-free (open source but not a FOSS license) and tainted (contains sw. that is covered by patents in some parts of the world). Should a non-free+tainted package go in tainted, i.e. is the tainted repo for all tainted packages, both free and non-free tainted, as thats a bigger issue than nonfree I agree. -- Anssi Hannula
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
On 14.03.2011 15:30, Tux99 wrote: Quote: Anssi Hannula wrote on Mon, 14 March 2011 00:35 On 14.03.2011 01:01, Tux99 wrote: Personally I also think 'tainted' would be the better choice than 'non-free' since potential patent issues are a more serious concern than a non-FOSS license, but tbh I think both choices are far from ideal, I believe the only really clean solution would be to create a 'tainted+non-free' repo just like PLF has. One option would be to add it to tainted, but have it require a dummy metapackage from non-free repository, so that it can be only installed if non-free media is enabled. It might cause too much confusion, though, as the error message wouldn't be very clear. I agree that the metapackage solution is impractical since it would cause too much confusion for users. We could make it Requires: nonfree-repository-required or similar so that the error message would give a better hint of what is wrong. -- Anssi Hannula
Re: [Mageia-dev] Non-free firmwares in installer
On 24.03.2011 12:53, Michael Scherer wrote: Le jeudi 24 mars 2011 à 11:15 +0100, Thorsten van Lil a écrit : Am 24.03.2011 09:57, schrieb Wolfgang Bornath: 2011/3/24 Ahmad Samirahmadsamir3...@gmail.com: On 24 March 2011 02:58, Dexter Morgandmorga...@gmail.com wrote: On Thu, Mar 24, 2011 at 1:38 AM, Ahmad Samirahmadsamir3...@gmail.com wrote: Has the Free DVD in Mandriva ever contained non-free firmware? No, but the question is more , will we provide a non free dvd iso, and this question is i think interesting. A possible solution for people with such a setup could be a non-free driver cd ISO which they could include in the installation process. What about a DVD including non-free packages but has the option to not install them? I think the majority of the users don't care that much about proprietary issues, they just need them for using there wireless card or graphic card. Those how do care can just uncheck the non-free part of the DVD. :) Well, personally, then I would just continue to use Fedora or others distribution on my computers, and keep Mageia just for the servers of the project. Fedora includes non-free firmware both in repo and medias, so why prefer that? -- Anssi Hannula
Re: [Mageia-dev] Non-free firmwares in installer
On 24.03.2011 12:39, Wolfgang Bornath wrote: But I don't think it would be a good idea to include non-free contents in the distribution ISOs at all. That this assumed majority does not care about the issue does not mean we should not care either. We should rather stress the point. Note that the current Alpha2 ISO contains many non-free [1] firmware files, and without those e.g. many popular wired NICs do not work, and the 3D acceleration of ATI *free* driver depends on those. [1] Depending on the definition - some are BSD/similar but still without source code, so considered non-free by OSI/FSF/Debian. -- Anssi Hannula
Re: [Mageia-dev] Non-free firmwares in installer
On 24.03.2011 14:41, Wolfgang Bornath wrote: 2011/3/24 Anssi Hannula anssi.hann...@iki.fi: On 24.03.2011 12:39, Wolfgang Bornath wrote: But I don't think it would be a good idea to include non-free contents in the distribution ISOs at all. That this assumed majority does not care about the issue does not mean we should not care either. We should rather stress the point. Note that the current Alpha2 ISO contains many non-free [1] firmware files, and without those e.g. many popular wired NICs do not work, and the 3D acceleration of ATI *free* driver depends on those. [1] Depending on the definition - some are BSD/similar but still without source code, so considered non-free by OSI/FSF/Debian. Good point. In this discussion we were too vague about this. As I see this the discussion so far was about non-free software, where non-free meant the software in the non-free repos, not the strict definition of free by FSF. Prominent example (and trigger of this discussion): WiFi driver/firmware. Well, currently the firmware are assigned between non-free and core at random (yes, we have non-free firmware in core, and yes, there are GPL firmware in non-free, etc), so... -- Anssi Hannula
Re: [Mageia-dev] Non-free firmwares in installer
On 25.03.2011 14:04, Frank Griffin wrote: Presumably, FLOSS supporters are satisfied with the state of the current ISOs, I'd not presume that, as as previously stated they contain firmware files without source code even now. -- Anssi Hannula
Re: [Mageia-dev] Non-free firmwares in installer
On 24.03.2011 22:27, Romain d'Alverny wrote: On Thu, Mar 24, 2011 at 20:08, Anssi Hannula anssi.hann...@iki.fi wrote: On 24.03.2011 19:35, Romain d'Alverny wrote: Summary (from http://mageia.org/wiki/doku.php?id=licensing_policy): * core: stuff that is not Free/Open Source according to OSI/FSF does not belong here. Not even closed-source stuff that we can redistribute. So if there is at this time, that's something to fix. Most of files in kernel-firmware (which is in core) are not OSI/FSF free (approximate list from 2010 [1]). There was a short thread about that [2] where I asked the question if they should be moved to non-free due to them not being OSI/FSF free, and tmb agreed, while pterjan disagreed (saying BSD without source code (where a portion of the firmware files in question fall) is eligible for core). [1] http://lists.mandriva.com/cooker/2010-01/msg00525.php [2] https://mageia.org/pipermail/mageia-dev/20110115/002172.html Ah right, sorry for overlooking this. So what do we do? amend core inclusion definition for that? or move these to nonfree? (and at what cost?) I don't really have a strong preference here, as long as 1) it is consistent, and 2) users are happy (e.g. no situation where even the free radeon driver doesn't work with any ISO) topic for next Council meeting to decide? Probably. would you like to write a summary for this in http://mageia.org/wiki/doku.php?id=meeting:council_notes_2011_03_28#open_questions ? OK, seems I was late, sorry. The summary looks good. -- Anssi Hannula
Re: [Mageia-dev] libdrm-2.4.25 and libva-1.0.12
On 14.04.2011 18:30, Thomas Backlund wrote: Hi, According to: http://intellinuxgraphics.org/2011Q1.html We need libdrm-2.4.25 and libva-1.0.12 + few kernel patches to get Intel Sandy Bridge support in good shape for Mageia 1 Any objections ? Nope. If not, I will push them this weekend... (unless someone beats me to it for libdrm libva part) -- Thomas -- Anssi Hannula
[Mageia-dev] Changes for dkms, dracut, drakx, drivers, initscripts, kms, mkinitrd, module-init-tools, udev
Hi all! I've now completed the implementation of the points from my earlier KMS + plymouth + DKMS + harddrake + speedboot + XFdrake + initrd stuff RFC at http://lists.mandriva.com/cooker/2011-01/msg00107.php. The only notable difference is that instead of regenerating initrds a new nokmsboot boot option flag is used instead. I'll do some final cleanups and testing before I start committing this work; this message is mostly a heads-up in case someone spots something that's not ok. The changes per package follow, feel free to comment: DKMS: - use display_driver_helper for loading display modules - no functional change, just needed due to the other changes Dracut: - fix find commandline to find gzip compressed KMS kernel modules Drakx-kbd-mouse-x11: - Added display_driver_helper script. - Add/Remove nokmsboot boot option depending on selected driver. display_driver_helper is used to detect if that is the case. - Ask for reboot instead of X restart in the usual case, as this is commonly required nowadays. Some checks could be added to allow only to restart X when that is enough, but those are for later. Drakxtools (harddrake-service): - Adapt splash handling for plymouth (i.e. hide splash when querying user). - Call drakx-kbd-mouse-x11 to add/remove nokmsboot boot option if needed. Detection is done using display_driver_helper and by checking for /dev/.late_kms which is created by display_driver_helper when it is called from udev and the kms driver wasn't yet loaded by initrd. - If a reboot is needed due to a driver switch (i.e. boot was done without nokmsboot but it is needed for the current driver), ask for it (user is given 30 sec to abort). display_driver_helper is used to detect this. - On driver switch, load the new driver by calling udevadm. - If X.org is already running when a driver change is initiated, defer change to next boot and disable speedboot for the next boot (note: irrelevant with systemd). - Generalize the harddrake_confirm code a bit. Drakxtools (installer): - When configuring bootloader after X is already configured (like One), use display_driver_helper to determine if nokmsboot should be used. Initscripts (rc.sysinit / speedboot, not relevant with systemd): - In very early boot, call display_driver_helper to check if there is a pending dkms build (that may cause a wrong older binary dkms driver to be loaded by X server) or a conflicting driver loaded by initrd (which may cause graphical corruption / freeze when starting server) and disable speedboot in those cases. - Load display drivers before X when in speedboot. - In speedboot mode, reopen file descriptors after X should've started. This ensures that harddrake_service (and other sysinit output) is shown to the user if the X startup failed. (plymouth grabs the output, and when it shuts down the output is lost until descriptors are reopened). Mkinitrd: - Allow putting nouveau/radeon in initrd (currently only i915 is allowed) - Do not load display drivers if booted with nokmsboot. Module-init-tools: - Remove now unneeded patch affecting blacklist behaviour. - Remove now unwanted blacklist entries for DKMS and KMS drivers. Proprietary drivers: - Remove modprobe.preload.d, udev now loads the drivers selectively using display_driver_helper. This also fixes a wrong version of a driver being loaded when during early boot there is an old binary dkms driver present and a newer source dkms driver is not yet built. Proprietary NVIDIA drivers: - Replace alias entry with install entry, to allow removal of a patch in module-init-tools. Udev: - Use display_driver_helper to load display drivers. It checks the drivers it knows so that the X.org configuration is appropriate for the driver before loading it. I.e. if vesa is enabled, no display drivers are loaded, and if fglrx is enabled radeon is not loaded, and vice versa, etc. Also, no wrong version dkms binary driver is loaded if the correct dkms source driver is going to be built later during this boot. - When in initrd, instead of using display_driver_helper, instead check for the nokmsboot boot parameter, and load drivers if that is not set (note: initrds do not contain proprietary drivers). -- Anssi Hannula
Re: [Mageia-dev] Wine upgrade problems
On 17.04.2011 16:33, Frank Griffin wrote: [root@ftglap network-scripts]# urpmi --auto-select A requested package cannot be installed: wine-1.3.18-1.mga1.i586 (due to conflicts with wine64-1.3.18-1.mga1.x86_64) Continue installation anyway? (Y/n) The following package has to be removed for others to be upgraded: wine-1.3.17-1.mga1.i586 (due to unsatisfied wine32 == 1:1.3.17-1.mga1) (y/N) Try --debug to see why is it trying to install both wine and wine64. -- Anssi Hannula
Re: [Mageia-dev] Changes for dkms, dracut, drakx, drivers, initscripts, kms, mkinitrd, module-init-tools, udev
On 22.04.2011 23:05, Anssi Hannula wrote: On 16.04.2011 21:19, Anssi Hannula wrote: Hi all! I've now completed the implementation of the points from my earlier KMS + plymouth + DKMS + harddrake + speedboot + XFdrake + initrd stuff RFC at http://lists.mandriva.com/cooker/2011-01/msg00107.php. The only notable difference is that instead of regenerating initrds a new nokmsboot boot option flag is used instead. I'll do some final cleanups and testing before I start committing this work; this message is mostly a heads-up in case someone spots something that's not ok. The changes per package follow, feel free to comment: [...] These have been submitted and some bugfixes have been made afterwards. Thomas will be testing radeon KMS and enabling it by default if it is ok. Seems he had already done it just before I sent this message :) -- Anssi Hannula
[Mageia-dev] Freeze push request: fglrx
Please push fglrx, it is an update to final 8.84 / 11.4, we currently have a prerelease from Ubuntu. -- Anssi Hannula
Re: [Mageia-dev] Please ensure that packages have higher version than in mandriva 2010.2
On 30.04.2011 23:05, Maarten Vanraes wrote: Op zaterdag 30 april 2011 21:42:54 schreef Pascal Terjan: Here is a list of packages to fix (not including backports yet) [...] netbook-kde4-config 0:1-0.28.mga1 = 0:2010.1-22mdv2010.1 [...] this sounds like a difficult one... how are you doing to do this? I'd rename it to the more logical kde4-config-netbook and add an obsoletes entry (this also avoids bumping epoch). -- Anssi Hannula
Re: [Mageia-dev] freeze push: manaplus
On 01.05.2011 01:46, Maarten Vanraes wrote: This one is partly new features and partly bugfix. The bugfix does include fixing a possible crash. Generally such updates that feature new features are not pushed at this point to avoid regressions. However, since manaplus is not that important and you are the maintainer and in contact with upstream, I won't oppose pushing it anyway, if the freeze pushers agree. (I'm the mentor of Maarten) Changelog: fix: some controls draw issue in SDL software mode. fix: map objects drawing. (incompotable with tmw maps). fix: default values for new configurations. fix: crash with incorrect maps. add: away log. add: attack filter. new tab in social window. new chat commands /addattack, /removeattack, /addignoreattack, /addpriorityattack add: reset yellow bar context menu item. -- Anssi Hannula
[Mageia-dev] Freeze push request: drakx-kbd-mouse-x11 0.96
Please push drakx-kbd-mouse-x11 0.96: - 0.96 o display_driver_helper: do not load radeon driver if the proprietary driver is temporarily disabled on a PowerXpress system o prefer boot display devices when probing cards (fixes at least an issue with an SLI laptop as reported by Maarten Vanraes) o add support for Asturian keyboard o do not try to probe monitor information via X server on laptops (it doesn't work with recent X servers) o fallback to X server run-time autodetection on laptops instead of 1024x768 when the monitor could not be probed (Mageia #1059) -- Anssi Hannula
Re: [Mageia-dev] why not disable bytecode interpreter in freetype2 ?
On 12.05.2011 03:33, Zé wrote: Until bytecode interpreter wasnt enabled, there wasnt complains about how fonts look. So can you explain why werent there complain untill bytecode was enabled? Seams you only know to say that i dont know how fonts looks best in other users eyes, well seams obvious, no? Else wouldnt be there any complain. They didn't complain because they simply used PLF freetype. -- Anssi Hannula
[Mageia-dev] Freeze push request: fglrx 8.850
I think the new version 8.85 should be pushed, changes include - fixes intel/fglrx switching on PowerXpress - fixes some cases of suspend not working Especially the first change is something that would be nice, since the ATI version we have now claims to support it as well but fails to work (it tries to mv libraries around manually; not sure how cleanly it fails with our alternatives), confusing users. -- Anssi Hannula
[Mageia-dev] Freeze push request: flash-player-plugin
This is an upgrade to flash player 10.3, which we always need the latest version of (security etc). -- Anssi Hannula
[Mageia-dev] Freeze push req: fglrx 8.850-2
Single trivial bugfix: - run ldconfig after alternatives call in PowerXpress switcher script -- Anssi Hannula
Re: [Mageia-dev] nvidia-settings
On 21.05.2011 15:00, Patrice BRUNELLE wrote: I've upgraded a mandriva 2010.2 with the 64 bit dvd of the mageia-RC. But the /usr/bin/nvidia-settings is not present. urpmf told me that it was in x11-driver package but it is already installed. I've not yet tried to remove and reinstall this package. I guess the most likely reason is that the driver isn't enabled/configured. Use XFdrake to reconfigure the graphics driver. -- Anssi Hannula
Re: [Mageia-dev] regarding tainted progress
On 30.05.2011 02:53, Philippe DIDIER wrote: 2) win32-codecs is missing too (perhaps might it be in non-free repo instead of tainted ) and maybe some problems may happen trying to read some videos It is unredistributable. Fortunately, I don't think many actual files need this anymore, since ffmpeg format support has steadily grown over the last years. why not to provide faac libs ? The problem with them is that they are nonfree *and* tainted. Fortunately there is libvo-aacenc which programs can be ported to. Nevertheless I congratulate everyone for such a huge work you did ... and for the transparency of every discussion ! -- Anssi Hannula
Re: [Mageia-dev] dkms
On 31.05.2011 06:13, Tux99 wrote: Is there any specific reason (regressions, incompatibilites?) why Mageia (and Mandriva) still ships dkms 2.0.19 even though 2.1.1.2 is the latest upstream release, or is it simply because nobody has updated the package? It has lots of customizations (=patches), and nobody has had the time to update and/or clean+push the changes upstream. -- Anssi Hannula
Re: [Mageia-dev] Finalizing update process
On 09.06.2011 02:25, Michael Scherer wrote: I guess we can start with a list of exception : - stuff that should be updated to latest version, because the security support for older releases ( firefox, chrome ) is too hard - we update to latest version if there is no regression and a strong reason to upgrade ( severe bugfixes, security issue, breakages ). Exception of this category should be very expectional - stuff where there is strict bugfixes only release ( postgresql ), or update to a stable version ( which should be a bugfix only release when compared to beta/rc :) ) - we upgrade to stable ( for rc/beta ) - we do version update if it is bug fixes and if the packager is ok with it ( and if the rules of the bugfix branches are clearly documented ) - everything else - only minimal patches The question of game is still open, ie, should it go in 1st category, or should we have different rules to see what should be there or not ? I guess this would only be for networked game ? Yes. Note that this applies to some other software that communicates with outside systems as well, e.g. subdownloader. Maybe also Vuze if the content delivery system requires a version update. Maybe the correct phrasing would be something like: - Packages where some functions no longer work due to remote server changes, requiring a newer version of the package. -- Anssi Hannula
Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?
On 10.06.2011 17:28, Thorsten van Lil wrote: Am 10.06.2011 16:09, schrieb James Kerr: On 10/06/11 13:54, Michael Scherer wrote: Le vendredi 10 juin 2011 à 14:21 +0200, Oliver Burger a écrit : Thomas Backlundt...@mageia.org schrieb am 10.06.2011 So the path would then be */updates_testing - */updates _if_ we decide that's the way to go... As I see it, it's the only user friendly way. Using backports is fine for experienced users who do know what to install from backports or who are capable of facing the consequences. If a total newbie asks fort a package in the forums and is pointed to backports he is in great danger of wrecking his system by installing some new kernel, graphics driver, desktop or whatever, precisely because there is no real qa on backports. He can also wait for the release. Or he can enable backport just for the time needed to install and then disable it. I think rpmdrake have some stuff for that. Even though backports are disabled rpmdrake can display a list of available backports. (The sources are automatically updated by mgaonline.) A selected backport can then be installed, without enabling the backports source. (I've just tested this on mdv 2010.0, the only mdv system that I have available.) Jim I've tested it on Mageia right now. I've activated Core-testing and see that there is one package inside it: iputils_20101006_3.mga1. After that I've disabled the testing repo and searched for iputils. Rpmdrake lists me the version 2.mga1. Therefore, rpmdrake only lists packages of the activated repos. Core-testing is not backports. The behavior depends on media name. -- Anssi Hannula
Re: [Mageia-dev] get-skype package for submission
On 10.06.2011 02:56, Barry Jackson wrote: I have been working on a package to install Skype current stable release and now feel that it is ready for submission for approval. It has already been improved/corrected/adapted many times following discussions on #mageia-mentoring where I have been given lots of help. The idea evolved here https://bugs.mageia.org/show_bug.cgi?id=154 where the current version is available as an attachment. https://bugs.mageia.org/attachment.cgi?id=551 It has been a challenge and I have learned a lot in working on this. :) I didn't test it, but the problems I see now: 1. The MD5SUM isn't checked, IMO it should be. 2. On error you exit with || exit 1 but leave the files in /tmp, polluting it. 3. You cp files to %_datadir using a wildcard (*), but these files may not be removed on uninstallation as you only have filename lists for avatars/sounds/langs. While it may work now (I didn't test, I hope you did), this will cause unnoticed problems when the skype tarball contents change. 4. Provide the script/commandline used to create the filelist files. 5. Versionize the filelist files to make sure they are renegerated when the package is updated to a new version (avatars-%version.txt) 6. Your usage of /tmp seems unsafe security-wise. What if some user has created something under /tmp/skype-%version already? Instead use mktemp to create a temporary directory. 7. You never remove the tarball, and the tarball is not %ghost. Also BTW, here is a package of mine for gootleearth from 2006 that uses a similar system: http://www.zarb.org/cgi-bin/viewvc.cgi/plf/SPECS/non-free/googleearth/ No need to make it like that, just pointing it out in case there are some ideas you'd like to use. -- Anssi Hannula
Re: [Mageia-dev] get-skype package for submission
On 11.06.2011 03:05, Barry Jackson wrote:
On 10/06/11 18:06, Anssi Hannula wrote:
3. You cp files to %_datadir using a wildcard (*), but these
files may not be removed on uninstallation as you only have filename
lists for avatars/sounds/langs. While it may work now (I didn't
test, I hope you did), this will cause unnoticed problems when the
skype tarball contents change.
The wildcard is used to move the remaining files which are all
individually handled by touch and the dir is removed by a %ghost.
I was just saving spec lines.
Yes it does work fine and all files/dirs are removed on uninstall.
The tarball contents can't change or the md5sum would fail :\
I meant that when updating the package to a new version it is easy to
not notice some added files in the tarball, leaving the wildcard in
place but not add respective %ghosted files.
4. Provide the script/commandline used to create the filelist files.
Do you mean the avatars.txt etc.
It was all done semi-manually, but I will write a script if necessary.
It did cross my mind, but it was quicker to just copy/paste into txt files.
I was assuming I could maintain it manually.
Maintaining manually is fine, just add a comment beside the SourceXX
lines to tell what to do.
5. Versionize the filelist files to make sure they are renegerated
when the package is updated to a new version (avatars-%version.txt)
OK - again I was expecting to maintain it manually.
Yes, but this makes sure they are not forgotten (i.e. the pkg build
fails completely if you forget to update them, instead of creating a
broken package).
6. Your usage of /tmp seems unsafe security-wise. What if some user
has created something under /tmp/skype-%version already?
Hmm.. point taken
Instead use mktemp to create a temporary directory.
OK ... but:
I can't figure out how to get a temp filename into a %define
If I use
%define mytmp $(mktemp -d -q)
then every reference to the %define generates a new tmp file.
How can I assign the output of a command expansion to a %define so it's
evaluated only once on assignment?
%global mytmp %(mktemp -d -q)
However, that doesn't do what you want. That creates a temporary
directory in the system where package build is not done, while you want
to create a temporary directory in the user system. See below.
I can use a variable in %pre but that is invisible in %post as it's in
another shell so I'm sorta stuck on that for now :(
Probably the easiest way is to use a fixed location under
%{_localstatedir}/lib/%{name} for the tarball instead. Then you can use
mktemp locally in %post.
Also, is there a need to use -q for mktemp?
--
Anssi Hannula
Re: [Mageia-dev] get-skype package for submission
On 11.06.2011 19:13, Barry Jackson wrote:
On 11/06/11 09:14, Anssi Hannula wrote:
-snip-
Probably the easiest way is to use a fixed location under
%{_localstatedir}/lib/%{name} for the tarball instead. Then you can use
mktemp locally in %post.
Also, is there a need to use -q for mktemp?
Thanks - that works fine and is certainly the least complicated way to
do this. I could have created a script for use in %post while in %pre,
but it would have made the spec harder to read.
I have dealt with all the points you raised in the attached spec which
is working OK.
Please dissect it and comment again if you see any blunders ;)
I will update the tar.gz in the bug report with this latest version.
OK, here goes :)
- I see you didn't get what I meant with the versionized filelist files.
The idea was that if someone updates the package to a new skype
version, the rpmbuild process would fail if one didn't touch the
filelist files. With your changes such a failure doesn't happen.
You need to use lang-%{version}.txt instead, so that when someone
updates %version, it will automatically start failing until the lang
list file is updated/moved.
- Best to add a comment in the %post script to remind that any new files
need to have a %ghost entry created.
(btw: an alternative idea is to create a post-script and the filelist
at the same time in a single for loop in %build/%install, so that
the lists can never get out of sync as they are created from a single
list; however, your current solution is adequate as well)
- Why define %tmpextdir instead of using $newtmp directly? Quite
confusing as %variables are defined at build-time while $variables
at run-time.
- You don't check for failures. If the mktemp call fails, you extract
the tarball into /root etc.etc.. You need to check for failures on
the mktemp/mkdir/cd commands (mktemp failure can be detected by
checking if $newtmp string is empty), or alternatively run set -e
to make the shell exit on failures (this leaves the tmpdir polluted,
but it doesn't matter as much as it is an uncommon failure case and
/tmp is cleaned periodically anyway).
- Dot in Summary.
- Noarch seems wrong to me.
--
Anssi Hannula
Re: [Mageia-dev] get-skype package for submission
On 12.06.2011 02:37, Barry Jackson wrote:
On 11/06/11 18:03, Anssi Hannula wrote:
- Best to add a comment in the %post script to remind that any new files
need to have a %ghost entry created.
(btw: an alternative idea is to create a post-script and the filelist
at the same time in a single for loop in %build/%install, so that
the lists can never get out of sync as they are created from a single
list; however, your current solution is adequate as well)
Note added - keep it simple.
You added the note in the %files section, not in %post. The issue only
happens if someone updates %post but not %files, so it doesn't make
sense to put the reminder in %files :)
- You don't check for failures. If the mktemp call fails, you extract
the tarball into /root etc.etc.. You need to check for failures on
the mktemp/mkdir/cd commands (mktemp failure can be detected by
checking if $newtmp string is empty), or alternatively run set -e
to make the shell exit on failures (this leaves the tmpdir polluted,
but it doesn't matter as much as it is an uncommon failure case and
/tmp is cleaned periodically anyway).
Added some checks - with clean-up of previously created dirs etc on fail.
mkdir %{mytmp}
[[ -d %{mytmp} ]] || exit 1
cd %{mytmp}
cd is not guaranteed to work even if %mytmp exists. Add || exit 1.
cd ${tmpextdir}
tar jxf %{mytmp}/skype-%{version}.tar.bz2
Same here...
Well, actually these two aren't that serious, since they can't be
exploited by non-root anyway. I'm somewhat ok with them, as long as your
mentor is as well and no one else objects.
Note that your if ! [[ -d %{tmpdir} ]]; then check is not 100%
necessary, as %tmpdir not existing is unlikely and causes no side effects.
Other nits:
- Use better variable names- %mytmp, $tmpextdir, %tmpdir are confusing.
- The description starts with an empty line. Remove it.
--
Anssi Hannula
Re: [Mageia-dev] weird bs behaviour
On 12.06.2011 19:13, Jerome Quelin wrote: hi, when rebuilding perl-DBD-SQLite and perl -DBD-SQLite2, i get some strange cpio errors: === PASTE === [...] extracting debug info from /home/iurt/rpm/BUILDROOT/perl-DBD-SQLite-1.330.0-1.mga2.i386/usr/lib/perl5/vendor_perl/5.14.0/i386-linux-thread-multi/auto/DBD/SQLite/SQLite.so *** WARNING: No build ID note found in /home/iurt/rpm/BUILDROOT/perl-DBD-SQLite-1.330.0-1.mga2.i386/usr/lib/perl5/vendor_perl/5.14.0/i386-linux-thread-multi/auto/DBD/SQLite/SQLite.so cpio: gcc-4.5.2/gcc/libgcc2.c: Cannot stat: No such file or directory cpio: gcc-4.5.2/gcc/libgcc2.h: Cannot stat: No such file or directory cpio: gcc-4.5.2/obj-i586-mageia-linux-gnu/gcc/include/stddef.h: Cannot stat: No such file or directory cpio: gcc-4.5.2/obj-i586-mageia-linux-gnu/i586-mageia-linux-gnu/libgcc: Cannot stat: No such file or directory cpio: glibc-2.12.1/bits/types.h: Cannot stat: No such file or directory cpio: glibc-2.12.1/debug: Cannot stat: No such file or directory cpio: glibc-2.12.1/debug/stack_chk_fail_local.c: Cannot stat: No such file or directory cpio: glibc-2.12.1/io: Cannot stat: No such file or directory cpio: glibc-2.12.1/io/fstat64.c: Cannot stat: No such file or directory cpio: glibc-2.12.1/io/stat64.c: Cannot stat: No such file or directory cpio: glibc-2.12.1/sysdeps/unix/sysv/linux/bits/stat.h: Cannot stat: No such file or directory cpio: glibc-2.12.1/time/time.h: Cannot stat: No such file or directory 9611 blocks === /PASTE === of course, tests fail afterwards. however, building perl-DBD-SQLite module in iurt on my machine yields no problem. (note that my machine is a x86_64, whereas the build fails on i586 bs node - but i don't know if it's related). == can someone more fluent with the bs / rpm can help please? cpio errors are normal during debug info extraction. They are most likely unrelated to your issue. -- Anssi Hannula
Re: [Mageia-dev] get-skype package for submission
On 13.06.2011 17:31, Barry Jackson wrote:
On 13/06/11 13:24, Anssi Hannula wrote:
Note that your if ! [[ -d %{tmpdir} ]]; then check is not 100%
necessary, as %tmpdir not existing is unlikely and causes no side
effects.
I added that as the dir is created by tar, so if the tarball had the
wrong content the dir may not be created with the correct name.
Unlikely as you say.
Yep, but in that case nothing bad happens anyway. A couple of errors
from failing cp and mv commands are printed, but nothing else.
I have started writing a script to generate the .txt files but can't
decide whether it should go as far as downloading the source from Skype
or simply be run on an extracted skype-version folder.
It could do both :)
Doesn't really matter, this is all extra anyway.
Note that if you make it download it, you could also implement:
a) make it print md5sum automatically
b) make it print the dependencies automatically
(see e.g. the earlier google earth script which does those IIRC)
But as said, all of this is extra. Maybe the priority should be getting
you a mentor.
A first draft of this is attached.
I assume this would ultimately be added as a SOURCE file with notes in
the package.
Yep.
--
Anssi Hannula
Re: [Mageia-dev] perl 5.14.1 on its way
On 19.06.2011 19:18, Michael Scherer wrote: Le dimanche 19 juin 2011 à 15:46 +0200, Jerome Quelin a écrit : hi, i just submitted perl 5.14.1, which should be a smooth upgrade. no need to recompile binary modules this time. Some packages seems to have some errors : http://check.mageia.org/dependencies.html perl found with incorrect range == 2:5.14.1-1.mga2 (needed == 2:5.14.0) Is this a youri error or a real issue ? Applications dynamically linked to perl need to be rebuilt for new perl versions as the perl library is in a versioned directory. -- Anssi Hannula
Re: [Mageia-dev] perl 5.14.1 on its way
On 19.06.2011 21:02, Jerome Quelin wrote: On 11/06/19 18:18 +0200, Michael Scherer wrote: perl found with incorrect range == 2:5.14.1-1.mga2 (needed == 2:5.14.0) Is this a youri error or a real issue ? how can we find those? afaik, urpmf --requires :perl cannot be used with a specific version. any help to find those packages is welcome. e.g. to find packages depending on 2:5.14.0: $ urpmf --requires :perl\[== 2:5.14.0 or to find all packages having a version-specific require on another version than 5.14.1: $ urpmf --requires ':perl\[== (?!2:5.14.1[-\]])' -- Anssi Hannula
Re: [Mageia-dev] Backports policy proposal
On 24.06.2011 03:10, Michael Scherer wrote: Another rule that we could add is that cauldron should always be newer than backports, in order to ensure upgradability. The same goes for n-2 and n-1 release. While this seems innocent, do not forget this will have a impact when we do the version freeze. So this will prevent backporting anything to mga1 if it is not in mga2 release/updates ? Also, I don't see the advantage in preventing backports during freeze. The backports are re-allowed soon anyway, and the upgradeability goes away anyway. -- Anssi Hannula
Re: [Mageia-dev] Backports policy proposal
On 26.06.2011 01:34, Michael Scherer wrote: Le vendredi 24 juin 2011 à 17:33 +0300, Anssi Hannula a écrit : On 24.06.2011 03:10, Michael Scherer wrote: Another rule that we could add is that cauldron should always be newer than backports, in order to ensure upgradability. The same goes for n-2 and n-1 release. While this seems innocent, do not forget this will have a impact when we do the version freeze. So this will prevent backporting anything to mga1 if it is not in mga2 release/updates ? That's a good question but yes, I would consider such policy. Ie, do backport only for the latest supported release. This will essentially prevent backporting anything to mga1 after mga2 release. :/ -- Anssi Hannula
Re: [Mageia-dev] How to add package into backports_testing
On 02.07.2011 13:00, Sander Lepik wrote: Hey, i'm having some trouble with adding get-skype into backports_testing. blino told me to cp get-skype into updates/1 as i can't submit it from cauldron. So i did. updates/1 is meant for updates, not backports. -- Anssi Hannula
Re: [Mageia-dev] [RPM] cauldron core/release handbrake-0.9.5-1.mga2
On 09.06.2011 17:07, Mageia Team wrote: Name: handbrakeRelocations: (not relocatable) [...] obgr_seneca obgr_seneca 0.9.5-1.mga2: + Revision: 102461 - added patches for libnotify and dbus-glib-1 - imported package handbrake Doesn't this contain faac, which is both nonfree and tainted (yet the pkg is in core)? Also, the package downloads source tarballs during %build. Shouldn't this be disallowed? -- Anssi Hannula
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
On 06.07.2011 16:04, Ahmad Samir wrote: On 6 July 2011 14:27, Romain d'Alverny rdalve...@gmail.com wrote: On Wed, Jul 6, 2011 at 14:04, Ahmad Samir ahmadsamir3...@gmail.com wrote: On 6 July 2011 13:58, Romain d'Alverny rdalve...@gmail.com wrote: On Wed, Jul 6, 2011 at 12:10, Wolfgang Bornath molc...@googlemail.com wrote: If we go back to the beginning of the discussion where to put such packages which were in PLF we made a clear difference: 1. All non-free goes into non-free 2. Software which may be illegal in some countries (mostly because of licensing) will go into tainted. That's all. Clear and simple. The question about GPL or other free licenses is not touched by tainted. So, everything which does not have to go to tainted will go to free (core) or non-free, depending on it's status. Indeed. http://mageia.org/wiki/doku.php?id=licensing_policy#acceptable_licenses says: The tainted section accepts software under a license that is might be free or open source and which cannot be redistributed publicly in certain areas in the world, or due to patents issues. Reformulating it in an other, more explicit way maybe: - core hosts 100% free software that can be redistributed anywhere (or almost, the world is a bit more complicated than that) - nonfree hosts non-free software that can be redistributed anywhere (same) - tainted hosts all the rest, be it free software or not. Third point is wrong, a license that is might be free or open source, which, I think, means only software with an open source software License. I understand this as: software that might be free or open source = can be not free or open source. might expressed the possibility, not the requirement. IOW, tainted does not discriminate free and non free software. It does differentiate; given that Anssi is the one who worked on the tainted policy the most, and he doesn't think faac should be in tainted, is enough to say that the wording in the wiki needs to express our stance on the issue in a clearer way... I don't remember saying that. Any consistent solution is acceptable to me (including put-in-nonfree, put-in-tainted, put-in-nowhere). There was opposition (from e.g. misc) to having nonfree stuff in tainted, though. -- Anssi Hannula
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
On 08.07.2011 07:37, Ahmad Samir wrote:
Hello.
I've had a rather vague idea about standardising the virtual provides
in the distro, there should be:
Provides: %{name}-devel
Provides: lib%{name}-devel
either both of them in _all_ packages, or one of them in _all_
packages, so that we don't have to check urpmq --provides all the
time. Personally, I am more inclined on having them both, so as not to
break already working specs.
For example:
$ urpmq --provides lib64gudev1.0-devel-166-5.mga1.x86_64
libgudev-devel[== 166-5.mga1]
pkgconfig(gudev-1.0)[== 166]
devel(libgudev-1.0(64bit))
lib64gudev1.0-devel[== 166-5.mga1]
lib64gudev1.0-devel(x86-64)[== 166-5.mga1]
only libgudev-devel, so if I put BR gudev-devel in a spec it won't
work, whereas I'd expect it to work since some other packages have
such similar provides:
$ urpmq --provides lib64dbus-1-devel
libdbus-1-devel[== 1.4.1-3.mga1]
libdbus-devel[== 1.4.1-3.mga1]
dbus-devel[== 1.4.1-3.mga1]
[...]
WDYT?
(If we agree to go one way or the other, will just fix them gradually
over time).
I remember having this discussion in Mandriva when we dropped %major
from devel name. As a result the library policy (which we have on Mageia
as well) was altered so that all packages should have
- name-devel
- tarballname-devel
as provides, i.e. without lib%name-devel (except for existing pkgs).
This is what I've been using for any new packages I've packaged.
However, as usual, I'm fine with any consistent scheme (one or the other
or both).
--
Anssi Hannula
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
On 12.07.2011 04:42, andre999 wrote: Romain d'Alverny a écrit : Speaking of the software patent stuff, the Debian Project just released a Community Distribution Patent Policy FAQ here: http://www.debian.org/reports/patent-faq (announce: http://www.debian.org/News/2011/20110709 ). Romain Interesting reading. Warning against paranoia regarding software patents. So maybe we should have a policy of putting packages in tainted for patent reasons only after being notified by the patent holder ? We are unlikely to be notified (Ubuntu/Debian hasn't been to my knowledge), so that would effectively make tainted empty. Or some other significant factor regarding actual willingness to attempt to enforce ? Or actual validity ? (In the few jurisdictions accepting software patents, of course.) That is what is done. If there is a licensing program or past enforcement, it is considered as tainted. -- Anssi Hannula
Re: [Mageia-dev] Adobe Flash player 11 Beta 1 in Cauldron
On 16.07.2011 15:17, Ahmad Samir wrote: On 16 July 2011 14:02, Ahmad Samir ahmadsamir3...@gmail.com wrote: On 16 July 2011 11:11, Anssi Hannula anssi.hann...@iki.fi wrote: On 15.07.2011 11:10, Ahmad Samir wrote: 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? I'd provide it as 'flash-player-plugin11' or 'flash-player-plugin-beta' for both cauldron and mga1. I had started working on flash-player-plugin11 yesterday (based on the current spec and the old PLF flash-player10.2). I've imported it in Cauldron. @Anssi (since you worked on the flash spec the most), please review, feel free to fix anything I missed. I removed an unwanted old obsoletes and made conflicts unversioned (as it indeed conflicts with all versions). Otherwise looks ok if it works. -- Anssi Hannula
Re: [Mageia-dev] [RPM] cauldron nonfree/release flash-player-plugin11-11.0.1.60-0.b1.071311.1.mga2.nonfree
On 18.07.2011 00:04, JA Magallón wrote: On Sun, 17 Jul 2011 14:06:12 +0200 (CEST), Mageia Team buildsystem-dae...@mageia.org wrote: Name: flash-player-plugin11Relocations: (not relocatable) Version : 11.0.1.60 Vendor: Mageia.Org Release : 0.b1.071311.1.mga2.nonfreeBuild Date: Sun Jul 17 14:05:18 2011 Install Date: (not installed) Build Host: jonund Group : Networking/WWWSource RPM: (none) Size: 11376License: Proprietary Signature : (none) Packager: Mageia Team http://www.mageia.org URL : http://www.adobe.com/products/flashplayer/ Summary : Flash Player plugin for browsers - 11 Beta 1 release Description : Adobe Flash Player plugin for browsers. 11 Beta 1 release. NOTE: This package does not contain the Flash Player itself. The software will be automatically downloaded from Adobe during package installation. Alternatively you can use the command download-flash-player-plugin manually. Installing this package indicates acceptance of the following documents: - Flash Player 11 License, http://labs.adobe.com/technologies/eula/flashplayer11.html - Adobe.com Terms of Use, http://www.adobe.com/go/labs_term_of_use - Adobe Online Privacy Policy, http://www.adobe.com/go/labs_privacy_policy anssi anssi 11.0.1.60-0.b1.071311.1.mga2: + Revision: 125340 - better obsoletes and conflicts + ahmad ahmad - imported package flash-player-plugin11 Why does it try to pull phonon and half KDE ? Fixed and resubmitted, thanks. -- Anssi Hannula
Re: [Mageia-dev] [RPM] cauldron nonfree/release flash-player-plugin11-11.0.1.60-0.b1.071311.1.mga2.nonfree
On 18.07.2011 08:20, Ahmad Samir wrote: On 18 July 2011 00:48, Anssi Hannula anssi.hann...@iki.fi wrote: On 18.07.2011 00:04, JA Magallón wrote: On Sun, 17 Jul 2011 14:06:12 +0200 (CEST), Mageia Team buildsystem-dae...@mageia.org wrote: Name: flash-player-plugin11Relocations: (not relocatable) Version : 11.0.1.60 Vendor: Mageia.Org Release : 0.b1.071311.1.mga2.nonfreeBuild Date: Sun Jul 17 14:05:18 2011 Install Date: (not installed) Build Host: jonund Group : Networking/WWWSource RPM: (none) Size: 11376License: Proprietary Signature : (none) Packager: Mageia Team http://www.mageia.org URL : http://www.adobe.com/products/flashplayer/ Summary : Flash Player plugin for browsers - 11 Beta 1 release Description : Adobe Flash Player plugin for browsers. 11 Beta 1 release. NOTE: This package does not contain the Flash Player itself. The software will be automatically downloaded from Adobe during package installation. Alternatively you can use the command download-flash-player-plugin manually. Installing this package indicates acceptance of the following documents: - Flash Player 11 License, http://labs.adobe.com/technologies/eula/flashplayer11.html - Adobe.com Terms of Use, http://www.adobe.com/go/labs_term_of_use - Adobe Online Privacy Policy, http://www.adobe.com/go/labs_privacy_policy anssi anssi 11.0.1.60-0.b1.071311.1.mga2: + Revision: 125340 - better obsoletes and conflicts + ahmad ahmad - imported package flash-player-plugin11 Why does it try to pull phonon and half KDE ? Fixed and resubmitted, thanks. -- Anssi Hannula lib*kutils4 should be a suggests at least otherwise opening Global Settings from the right click menu on any e.g. youtube video will complain about the missing lib. Trrh, we don't want flash player suggesting kde. Does it complain about this if one removes the kcm module? -- Anssi Hannula
Re: [Mageia-dev] [RPM] cauldron core/release mplayer-1.0-1.rc4.0.r32713.7.mga2
On 18.07.2011 12:26, Ahmad Samir wrote: On 18 July 2011 10:51, Samuel Verschelde samuel.versche...@pmsipilot.com wrote: Le lundi 18 juillet 2011 10:11:32, Mageia Team a écrit : Name: mplayer Relocations: (not relocatable) Version : 1.0 Vendor: Mageia.Org Release : 1.rc4.0.r32713.7.mga2 Build Date: Mon Jul 18 09:51:27 2011 Install Date: (not installed) Build Host: ecosse Group : Video Source RPM: (none) Size: 8890529 License: GPLv2 Signature : (none) Packager: Mageia Team http://www.mageia.org URL : http://www.mplayerhq.hu Summary : Movie player for linux Description : MPlayer is a movie player for LINUX (runs on many other Unices, and non-x86 CPUs, see the documentation). It plays most MPEG, VOB, AVI, VIVO, ASF/WMV, QT/MOV, FLI, NuppelVideo, yuv4mpeg, FILM, RoQ, and some RealMedia files, supported by many native, XAnim, and Win32 DLL codecs. You can watch VideoCD, SVCD, DVD, 3ivx, FLI, and even DivX movies too (and you don't need the avifile library at all!). The another big feature of mplayer is the wide range of supported output drivers. It works with X11, Xv, DGA, OpenGL, SVGAlib, fbdev, AAlib, but you can use SDL (and this way all drivers of SDL), VESA (on every VESA compatible card, even without X!), and some lowlevel card-specific drivers (for Matrox, 3Dfx and Radeon) too! Most of them supports software or hardware scaling, so you can enjoy movies in fullscreen. MPlayer supports displaying through some hardware MPEG decoder boards, such as the DVB and DXR3/Hollywood+! And what about the nice big antialiased shaded subtitles (9 supported types!!!) with european/ISO 8859-1,2 (hungarian, english, czech, etc), cyrillic, korean fonts, and OSD? Note: If you want to play Real content, you need to have the content of RealPlayer's Codecs directory in /usr/lib64/codecs/ Is it ok to have such a path (/usr/lib64/codecs/) in a summary ? Yes, because it's /usr/lib64/ in the x86_64 package and /usr/lib/ in the i586 one. (I think the email to the changelog ML resolves %_libdir/ depending on the machine that generated the email, not sure though). It depends on whether the src.rpm is from i586 or x86_64 build. -- Anssi Hannula
Re: [Mageia-dev] [RPM] cauldron nonfree/release flash-player-plugin11-11.0.1.60-0.b1.071311.1.mga2.nonfree
On 18.07.2011 17:14, Ahmad Samir wrote: On 18 July 2011 14:13, Balcaen John mik...@mageia.org wrote: On Monday 18 July 2011 12:33:34 Colin Guthrie wrote: 'Twas brillig, and Ahmad Samir at 18/07/11 12:01 did gyre and gimble: Does it complain about this if one removes the kcm module? I tested a while ago, we'd have to remove both the kcm module .so and .desktop files; I am OK with that, the GTK+ tool provides the same exact functionalities and is desktop-agnostic (i.e. it won't pull any extra deps AFAICS). I presume this is all just going into a flash-player-kde package rather than nuked completely? Is it possible to create this package on the fly? because last time we talked about that on the bug report ( https://bugs.mageia.org/show_bug.cgi?id=1275 ) it was not. -- Balcaen John You're right, I forgot about that limitation. @Colin: so, no we can't :) Actually, it is possible, with some added complexity (extraction of the KDE files from the file downloaded by the main pkg in the -kde subpkg %post script. I'll look into it. -- Anssi Hannula
Re: [Mageia-dev] [RPM] cauldron core/release mplayer-1.0-1.rc4.0.r32713.7.mga2
On 18.07.2011 13:57, Ahmad Samir wrote: On 18 July 2011 12:45, Samuel Verschelde sto...@laposte.net wrote: Le lundi 18 juillet 2011 11:26:34, Ahmad Samir a écrit : On 18 July 2011 10:51, Samuel Verschelde samuel.versche...@pmsipilot.com wrote: Le lundi 18 juillet 2011 10:11:32, Mageia Team a écrit : Name: mplayer Relocations: (not relocatable) Version : 1.0 Vendor: Mageia.Org Release : 1.rc4.0.r32713.7.mga2 Build Date: Mon Jul 18 09:51:27 2011 Install Date: (not installed) Build Host: ecosse Group : Video Source RPM: (none) Size: 8890529 License: GPLv2 Signature : (none) Packager: Mageia Team http://www.mageia.org URL : http://www.mplayerhq.hu Summary : Movie player for linux Description : MPlayer is a movie player for LINUX (runs on many other Unices, and non-x86 CPUs, see the documentation). It plays most MPEG, VOB, AVI, VIVO, ASF/WMV, QT/MOV, FLI, NuppelVideo, yuv4mpeg, FILM, RoQ, and some RealMedia files, supported by many native, XAnim, and Win32 DLL codecs. You can watch VideoCD, SVCD, DVD, 3ivx, FLI, and even DivX movies too (and you don't need the avifile library at all!). The another big feature of mplayer is the wide range of supported output drivers. It works with X11, Xv, DGA, OpenGL, SVGAlib, fbdev, AAlib, but you can use SDL (and this way all drivers of SDL), VESA (on every VESA compatible card, even without X!), and some lowlevel card-specific drivers (for Matrox, 3Dfx and Radeon) too! Most of them supports software or hardware scaling, so you can enjoy movies in fullscreen. MPlayer supports displaying through some hardware MPEG decoder boards, such as the DVB and DXR3/Hollywood+! And what about the nice big antialiased shaded subtitles (9 supported types!!!) with european/ISO 8859-1,2 (hungarian, english, czech, etc), cyrillic, korean fonts, and OSD? Note: If you want to play Real content, you need to have the content of RealPlayer's Codecs directory in /usr/lib64/codecs/ Is it ok to have such a path (/usr/lib64/codecs/) in a summary ? Yes, because it's /usr/lib64/ in the x86_64 package and /usr/lib/ in the i586 one. (I think the email to the changelog ML resolves %_libdir/ depending on the machine that generated the email, not sure though). I'm not fond of descriptions changing according to the arch, it makes my life harder in madb where I need one description per package name (tainted packages are already problematic in this regard) :) Samuel Whether this causes problems for other tools or not, that bit of the description is giving users useful info. Maybe it can be moved to a README.urpmi, Anssi? IMO it can be removed, Real content plays fine without real-codecs (which is non-redistributable). -- Anssi Hannula
Re: [Mageia-dev] maven packages not replacing older ones - conflict results
On 19.07.2011 19:13, Frank Griffin wrote: On 07/19/2011 12:08 PM, Frank Griffin wrote: auto-select: adding maven2-2.2.1-72.mga2.noarch replacing maven2-2.2.1-70.mga1.noarch Actually, it looks like it *is* supposed to replace, so why the conflicts ? dmorgan forgot to add conflicts entries when he moved files between packages. -- Anssi Hannula
Re: [Mageia-dev] [RPM] cauldron nonfree/release t-lasku-1.10.0-1.mga2.nonfree
On 21.07.2011 21:13, Thierry Vignaud wrote: On 21 July 2011 19:16, Mageia Team buildsystem-dae...@mageia.org wrote: Description : T-lasku is a Finnish invoicing software for Linux. It should be explained why it's in tainted... It is not in tainted, though, and generally we do not have explanations for nonfree packages. This is an interesting case of BSD licensed software without source code, so I guess it would be good to either a) mention the reason it being in nonfree in the Description, or b) change our license tag policy to mark such software as e.g. Freeware or BSD without source. I slightly prefer a) to avoid complicating the policy for the rare cases, but either solution is fine to me. -- Anssi Hannula
Re: [Mageia-dev] Updates and 0 release
On 26.07.2011 18:48, Samuel Verschelde wrote: Le mardi 26 juillet 2011 12:40:02, Michael Scherer a écrit : Hi, while trying to work on the queue of update needing a push, I noticed that almost all of them use a Release: 0. Since this has a specific meaning ( ie, used for pre release, or svn snapshot ), using this for updates is quite confusing, and I do not see the reason for that. If the goal is to be sure that the software is still upgradable, the whole %mkrel stuff should take care of that. And if not, we can rebuild in cauldron to increase the release. The goal is indeed to make sure the software is still upgradable. Until now, in Mandriva and we followed the same way in Mageia, the rule has been : * if version is the same, just increase subrel * if the update is a new version, put release 0 and subrel 1, then increase subrel in subsequent updates concerning the same version If %mkrel could take care of that, that would be good, but for now this is not the case, unless I'm mistaken : [sam@localhost mga]$ rpmdev-vercmp 1.6.17-1.1.mga1.i586 1.6.17-1.mga2.i586 1.6.17-1.1.mga1.i586 1.6.17-1.mga2.i586 I think misc meant using simply 1.6.17-1.mga1.i586. whereas : [sam@localhost mga]$ rpmdev-vercmp 1.6.17-0.1.mga1.i586 1.6.17-1.mga2.i586 1.6.17-0.1.mga1.i586 1.6.17-1.mga2.i586 So, yes, it would be good if %mkrel would take care of that, but AFAIK it requires development. Would 1.6.17-mga1.1.1.i586 instead of 1.6.17-1.1.mga1.i586 be a solution so that the distrelease tag has higher precedence than the numbers ? If I'm forgetting something important that invalidates what I'm saying, just let me know, it will just improve my understanding of RPM versioning :) Best regards Samuel Verschelde -- Anssi Hannula
Re: [Mageia-dev] Updates and 0 release
On 26.07.2011 19:20, Colin Guthrie wrote: 'Twas brillig, and Michael Scherer at 26/07/11 11:40 did gyre and gimble: If the goal is to be sure that the software is still upgradable, the whole %mkrel stuff should take care of that. No it doesn't. That only works for one release assuming we do not use subrel with that release. Even with mkrel, we will instantly need to bump the cauldron package as soon as it's used for the first time. If one does another update (i.e. adds subrel), it should mean that the fixes/whatever have been done to the cauldron tree first and thus cauldron has 1.0-2.mga1, while mga1 gets 1.0-1.1.mga1. We used to do 0 releases in Mandriva quite often, and I don't think this is necessarily problematic. If a package is a prerelease, the release itself will likely contain the word git or svn etc. Col -- Anssi Hannula
Re: [Mageia-dev] Some more new rpmlint warning on upload
On 27.07.2011 15:15, Christiaan Welvaart wrote: On Wed, 27 Jul 2011, Michael Scherer wrote: * useless-provides that's when foo provide foo. There is no case where it would needed. AFAIK there are many packages in the i586 repository that are called libfoo-devel and have a provides libfoo-devel. For x86-64 the packages are called lib64foo-devel so the rpmlint warning doesn't show up there. Indeed. Somewhat related: http://rpm.org/ticket/80 -- Anssi Hannula
Re: [Mageia-dev] Some more new rpmlint warning on upload
On 27.07.2011 14:37, Michael Scherer wrote: I also found some stuff that would cause real problem : hunspell-ca.noarch: W: world-writable /usr/share/doc/hunspell-ca/LICENSES-en.txt 0666 Yet, there is maybe some good case to have a file to be world writable ? Maybe, but I'd guess not in /usr. -- Anssi Hannula
