Re: [Mageia-dev] Q: how long should we able to upgrade from?
On Mon, Oct 18, 2010 at 07:30, Thierry Vignaud thierry.vign...@gmail.com wrote: On 18 October 2010 00:31, Michael Scherer m...@zarb.org wrote: While I cannot answer, i think we should indeed try to have a policy for this. And in fact, I would also try to remove older Conflicts and Obsoletes from specs files, as this only add useless computation on urpmi side. I'm not against that. We could probably drop some old tags. The issue is how do we detect old tags??? By commenting when adding an Obsoletes ?
Re: [Mageia-dev] Q: how long should we able to upgrade from?
On Mon, Oct 18, 2010 at 08:41, Pascal Terjan pter...@gmail.com wrote: The issue is how do we detect old tags??? By commenting when adding an Obsoletes ? Another a way to do it could be svn annotate *.spec + grep Obsoletes + look for revision older than a given one
Re: [Mageia-dev] sync with mandriva
On Thu, Nov 18, 2010 at 18:11, Maarten Vanraes maarten.vanr...@gmail.com wrote: if people keep in mind that sometimes tarballs aren't always fetchable from the internetz; then i'm ok with this. also, possibly if the tar is the same as the previous version/revision, it could even be fetched from the older packages/releases Removing it from svn does not mean no longer hosting it, but svn is not appropriate to keep history of all versions of tarball that have once existed in cooker One solution can be for example - Storing the tarballs matching svn head on a ftp if the src.rpm is not yet available - Having the tool that checkouts from svn to also download src.rpm and extract tarball from there, looking on the ftp if there is not yet a src.rpm for that version
Re: [Mageia-dev] Choosing packagers representatives
On Thu, Dec 23, 2010 at 11:00, Maarten Vanraes maarten.vanr...@gmail.com wrote: Op donderdag 23 december 2010 11:51:31 schreef Pascal Terjan: On Wed, Dec 22, 2010 at 20:22, Maarten Vanraes maarten.vanr...@gmail.com wrote: Op maandag 20 december 2010 23:19:11 schreef Anne nicolas: Hi there - experience in packaging - willing to *manage* team - start with these 2 guys until first release is done (as done in i18n team) I'm applying for packagers reprentative rather on general management side (organization,meetings, planning...)for the 5 coming months. I would like to help in order to have a good start then when people know each other new representatives are elected. I've been working in engineering team in Mandriva for the 6 last years doing some packaging, working on isos release and managing relations with Mandriva community. My full profile here: http://www.linkedin.com/profile/view?id=4195950 Cheers I nominate Anne, if she's backed by an expert(god-level) packager Do you have a link to packages from god, to get an idea of his level? mageia-app-db isn't online yet :-P that being said, is that a candidacy from yourself? No, I don't want any responsability right now (at least until I have internet at home)
Re: [Mageia-dev] Choosing packagers representatives
On Thu, Jan 6, 2011 at 23:55, Maarten Vanraes maarten.vanr...@gmail.com wrote: Op vrijdag 07 januari 2011 00:02:56 schreef Anne nicolas: Here are finally the results and detail of this vote https://epoll.mageia.org/vote/ISJTLYRT Thanks for participating! the voting is clear, but however: something odd is going on with epoll, and should be looked it, imho: there's invalid votes, but there's also a valid vote with a non-participant on it. (anssi) ? and sandro is there twice? perhaps there is still bugs in it? (not that it would change the results) Maybe invalid ballots are when people chose someone from the list of voters and not the list of candidates
Re: [Mageia-dev] packages importing: what replaces rpm-mandriva-setup-build
On Sat, Jan 8, 2011 at 15:08, Jerome Quelin jque...@gmail.com 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 would say nothing since older version will never exist on mageia and that package will always be installed during build
[Mageia-dev] On importing /soft
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?
Re: [Mageia-dev] On importing /soft
On Wed, Jan 19, 2011 at 21:13, Angelo Naselli anase...@linux.it wrote: 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 Do you mean to avoid importing the source code to modify it? If so, i agree, we can just import it as source package like other tarball... Yes I mean not importing into /soft and handling it as external tarball
Re: [Mageia-dev] On importing /soft
On Wed, Jan 19, 2011 at 21:33, Maarten Vanraes maarten.vanr...@gmail.com wrote: Op woensdag 19 januari 2011 21:32:13 schreef Pascal Terjan: 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? i agree, about spec-helper ... similar thing? or not? Not sure, I think it's independent from the distro (as the scripts don't handle the policy themselves, it's done by rpm config) but some rpm guru would know more :)
Re: [Mageia-dev] Packaging for Mageia
On Fri, Jan 21, 2011 at 15:03, Michael scherer m...@zarb.org wrote: On Fri, Jan 21, 2011 at 10:59:52AM +0100, Jerome Quelin wrote: On 11/01/20 21:33 +0100, Erwan Velu wrote: PS: just pray not to fall into the jquelin massive submits :D sorry, i throttled a bit more between my packages. in fact, my throttling is ok except when people submit big packages! :-) i guess this'll be mitigated when: a) more build nodes will be added to bs Well, we do have a limited rack space at lost oasis so we cannot add much server for the moment, and for now, I think we are planning others stuff with potential server ( and as people will ask it, no, we still do not plan to let people run a buildnode if the sysadmin team is not the only group of people to access to it as admin for security reason ). b) bs will be updated to allow priorities, queue per submitter, etc. (and i want a pony too) We do not have it ( except the pony ), but how should we be distribute build in a fair fashion ? I fear that having this would lead to some frustration ( while first in, first out is IMHO easy to understand and quite fair most of the time ). No frustration if the submitter can request low priority himself. For massive rebuild, you can then submit everything but other people (or your own other packages) don't have to wait.
Re: [Mageia-dev] [Announce] Rejection of submission with missing dependencies
On Sun, Jan 23, 2011 at 20:14, Olivier Blin mag...@blino.org wrote: Pascal Terjan pter...@gmail.com writes: Hi everyone, I have added a new check in youri, to verify that all BuildRequires are available. If some are missing, they get listed and the submit is rejected. You might encounter some issues, because some buildrequires might depend on the arch. iurt does a src.rpm rebuild before trying to install its dependencies, so that all the conditional buildrequires are recomputed correctly. Currently I accept the submit if the dependency is available on any arch
Re: [Mageia-dev] [Announce] Rejection of submission with missing dependencies
On Sun, Jan 23, 2011 at 20:55, Pascal Terjan pter...@gmail.com wrote: On Sun, Jan 23, 2011 at 20:14, Olivier Blin mag...@blino.org wrote: Pascal Terjan pter...@gmail.com writes: Hi everyone, I have added a new check in youri, to verify that all BuildRequires are available. If some are missing, they get listed and the submit is rejected. You might encounter some issues, because some buildrequires might depend on the arch. iurt does a src.rpm rebuild before trying to install its dependencies, so that all the conditional buildrequires are recomputed correctly. Currently I accept the submit if the dependency is available on any arch Hmm I thought so but looking at the current version of the code I only check on i586 :) Anyway the test seems to accept anything currently...
Re: [Mageia-dev] [Announce] Rejection of submission with missing dependencies
On Tue, Jan 25, 2011 at 11:37, Olivier Thauvin nanar...@nanardon.zarb.org wrote: * Jerome Quelin (jque...@gmail.com) wrote: On 11/01/22 15:31 +, Pascal Terjan wrote: I have added a new check in youri, to verify that all BuildRequires are available. If some are missing, they get listed and the submit is rejected. This way you don't have to wait for the build to be scheduled and iurt to try to install them in a chroot. And you also get the full list of missing ones, instead of only the first one. Please report any bug you may encounter $ mgarepo submit perl [...] Submission errors, aborting: - perl-5.12.2-8.mga1.src: - Unresolved dep on devel(libgdbm_compat(64bit)) On Mandriva we had a rules claiming that BuildRequires must be arch independant. This rules still apply on Mageia, isn't it ? I guess it was never enforced, else iurt would not need to first rebuild the src.rpm on the target arch And it would anyway prevent from rebuilding things on arch when some optional stuff are not available But yes this dep on lib should not be depending on the arch
[Mageia-dev] Accident
Sorry everyone, while removing my tests run on valstar, as that's not the best place for tests, I removed bootsrap repository :( I have stopped the build system and Nanar is sending back his copy of the repository.
Re: [Mageia-dev] BS down
2011/1/30 Michael Scherer m...@zarb.org: On Sat, 29 Jan 2011 22:58:07 +0100, Michael Scherer wrote: On Sat, 29 Jan 2011 21:00:31 +0100, Michael Scherer wrote: Hi following a manipulation error, part of the bootstrap mirror have been erased. We have restored part of it from the backup made on d-c, but we are not sure that everything was restored, Olivier is currently checking. We are working on fixing it ASAP. It seems we have all srpms ( 4084, only one is missing, and that's a php-pear-foo rpm so something easy to rebuild from svn and not too critical for now ). On the binary side, we didn't finish to evaluate what is missing, as we are currently syncing from various backups ( d-c, rabbit, tmb server ), but a network problem out of our reach make thing quite slow. So for now, consider the BS to be down, we will warn you once things are finished to sync ( likely tomorow ), and see what we need to do once the exact damage can be evaluated. We have the list of submitted rpms since 3 days, so we should be able to rebuild what is missing in the proper order, with too much trouble. So the sync finished ths mornig, and there is 258 packages to rebuild, around 170 being python/php/perl/ruby modules so fast to rebuild, see the attached list. We will submit them, after disabling youri check that prevent reuploading packages. We will also do the switch on the layout of the mirror for having debug media in a subdirectory ( since the BS is down ). All packages have been rebuild, BS should be back in its original state
Re: [Mageia-dev] BS down
On Mon, Jan 31, 2011 at 08:21, Thomas Backlund t...@iki.fi wrote: Pascal Terjan skrev 31.1.2011 00:54: All packages have been rebuild, BS should be back in its original state Have you also re-enabled youri reuploading check ? Yes that's what I mean by BS should be back in its original state
Re: [Mageia-dev] Packager meetings for tonight
On Mon, Feb 7, 2011 at 12:08, Thierry Vignaud thierry.vign...@gmail.com wrote: On 3 February 2011 17:06, Michael Scherer m...@zarb.org wrote: So as discussed tonight ( but if you couldn't be present at the meeting, do not hesitate to express yourself now ), we proposed to have some order in the import of rpm ( ie avoid the resulting anarchy due to lack of process for bootstrap ). In order to start by something tangible and easy to manage, let's take a concrete case. The sysadmin team discussed to use mageia on the servers ( once the stable release is out ie, not now ) for obvious reasons of dogfooding. But for this, we will have to import the needed rpms. I extracted from puppet logs the lists of rpm, and I have a list of the major component needed. The rule would be to take 1 and only 1 rpm ( or family ) at the time, to make sure it work fine ( ie, compile for the moment, and also install ), to make sure the package is cleaned ( ie, patchs sent upstream, commented, etc ), and to make sure that everybody can find something to do. And that of course requires to do the same for missing BuildRequires, and Requires ( but since lots of rpm have been imported without being fully cleaned, and since there is now a fast web interface for svn, people have no excuse to not check ). I will place the list on the wiki tomorrow, and people wishing to work on importing a rpm should add their name/login/whatever after the rpm, and then to work on it. If there is already someone working on a rpm, just take another one, or try to work with this person. So it seems that my list of 20 rpms is now much lower than needed, as most servers applications needed have been imported. The only thing left are : What would really help us is the list of actually successfully build package rather than the list of submitted packages that we previously have on pkgsubmit.mga.org It has been replaced by the list of missing BR for currently submited packages (http://pkgsubmit.mageia.org/data/missing-deps.i586.txt) but having the list of succesfully rebuild packages would help too. OK, I removed the list of built one when removing the (empty) list of missing one to get rid of the ugly temporary code I can add it back until having something better... Or maybe add the generation of those lists to the script run every 15 minutes that lists missing deps.
Re: [Mageia-dev] build system tools
On Fri, Feb 11, 2011 at 16:02, Michael Scherer m...@zarb.org wrote: Le vendredi 11 février 2011 à 16:49 +0100, philippe makowski a écrit : Hi, about the build system, with Mandriva we had ssh access to build boxes under Fedora I can use fedpkg to either make a local build into a clean chroot or to ask for a scratch-build on the build system from a local srpm (scratch-build from a local srpm is really nice when testing a new package) will we have something similar soon ? We do have mgarepo and iurt, and I think e should aim to improves theses tools. But there is no plan to have chroot for developpers in the short term, as we lack servers ( and time ) for that. Building from a local src.rpm can probably be done (like in a lower priority queue) but we need to see how long to keep the packages, how much disk and bandwidth would be needed, etc. In the meantime doing a local build using the same system (iurt) is easier given that you have a fast enough mirror (and no download quota...).
Re: [Mageia-dev] Virtual machine image distribution
On Mon, Feb 14, 2011 at 12:28, Michael Scherer m...@zarb.org wrote: Hi, while debugging the last issues for iso for alpha 1, Anne reminded us that some people asked in the past for appliance ( ie, virtual machine ) to be distributed along the isos on mirrors. While we will likely not do for the next release ( due tomorrow ), I would like to have some feedback about it ( as i seldom use such features, I prefer to install my vm myself ). There is some question to answer : - what technology would people like to see ? ( remember, this has to be something that can be created using free softwares in the distribution ) Ideally, an image than can be usable in kvm / virtualbox / vmware
Re: [Mageia-dev] Multiple builds on mirrors
On Wed, Feb 16, 2011 at 10:09, James Kerr j...@jkerr82508.free-online.co.uk wrote: A couple of issues that I've not seen mentioned elsewhere: 1. There are multiple builds of some packages on the mirrors. For example: drakconf-12.21-1 drakconf-12.21-2 drakconf-12.21-3 2. In /core/release/media_info there is an ever-increasing number of symlinks to the meta-data files (hdlist.cz etc.) (These apply to distrib-coffee and mandrivauser.de, but ibiblio seems not to be fully sync'd. I haven't checked the others.) Are these known issues or should I open bug reports? It was my fault, fixed yesterday in svn but forgot to deploy it
Re: [Mageia-dev] perl 5.12.3 on its way
On Wed, Feb 16, 2011 at 22:38, Thomas Backlund t...@iki.fi wrote: Do you have ideas for this pb to not happen anymore ? a BIG FAT warning at top of spec. Or a specific check at upload (in rpmlint ?)
Re: [Mageia-dev] Is there any reason keeping ask.com as firefox's default search engine?
On Fri, Feb 18, 2011 at 08:23, Funda Wang fundaw...@gmail.com wrote: Hello, I couldn't have time installing alpha now, but I've found that we still promote ask.com as default search engine of firefox, and other additional search engines such as jamendo. I think mageia has nothing todo with above search engine. Yes there is no reason What should be decided is if Mageia switches back to default search engine or selects another one for whatever reason
Re: [Mageia-dev] please keep note of missing dependancies
On Sun, Feb 20, 2011 at 23:52, Balcaen John balcaen.j...@gmail.com wrote: Le dimanche 20 février 2011 20:23:30, Maarten Vanraes a écrit : Hi, Now and then, i'm refreshing http://pkgsubmit.mageia.org/ and sometimes i notice the missing dependancies increasing... [...] Maybe we should in fact check dependencies directly from the spec fix requires before uploading the « main » package ? The reason to not reject packages with missing dependencies is for bootstrapping Sometime one of the subpackages will not be installable immediately, but the other subpackage needed to build the package which will satisfy this dependency will be.
[Mageia-dev] noarch subpackages
Hi packagers, I have just tested and our build system supports having a noarch subpackage together with arch specific ones. So please, have noarch data/doc packages (expecially for games or other stuff with huge data), this will allow them to not be duplicated on mirrors
Re: [Mageia-dev] freedesktop spec and categories
On Fri, Feb 25, 2011 at 10:33, Michael Scherer m...@zarb.org wrote: Le vendredi 25 février 2011 à 09:19 +0100, Samuel Verschelde a écrit : Le vendredi 25 février 2011 01:12:07, Michael Scherer a écrit : 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 ). Does it happen ? In a default Mandriva KDE installation I already have more than 10 internet applications. I do not use kde, but that doesn't sound good. What are the entries ? Are all of them really needed ? I prefer 3 quick steps rather than 2 long steps. This would requires some testing and measures to see which is faster, which is more confusing. Fcrozat did some tests, but I think the report were not published :/ I hate submenus, I always fail to navigate them properly (move the mouse out and switch to other higher level menu and have to go back and go down again in the submenu) Having submenus will usually make it 5 or 6 quick upsetting steps instead of 1 long one.
Re: [Mageia-dev] base system size for next beta1
On Fri, Mar 18, 2011 at 08:05, andre999 and...@laposte.net wrote: In principle, I think it should be something required by virtually any working Mageia system. I notice that there is a basesystem-minimal and a basesystem, which adds requires kernel and bootloader ?! (Both of which seem kind of essential ;) ) Not if you want to create a chroot, you can then have a Mageia system without a kernel or bootloader We should probably drop the distinction. (They are in the same source task package anyway.) If we keep the distinction, we could make basesystem optional, and include not-absolutely-necessary-but-almost type packages. This would make it easier to reduce basesystem-minimal in size. (We could then maybe change the names to basesystem and basesystem-plus ? ) At first glance, most of the requires seem pretty basic to any realistic minimal Linux system. The only thing I notice that is optional and somewhat big is vim (some 20M), but some sort of editor is needed. And it is pretty standard in *nix type environments. (Not my favorite, but even I know how to use vim.) We could always find an alternative, but it has to function without X. The point is not to check what is required directly by the package but what is required by that dependencies i.e. urpmq -d basesystem-minimal to check if something strange gets pulled in We could save a lot of space without the bootloader and the kernel, but that would make it _really_ hard to get up and running :) In sum, it's not apparent how we could save much space. my (meandering) 2 cents :) -- André
Re: [Mageia-dev] cairo and poppler conflicts
On Sat, Apr 2, 2011 at 08:57, Remy CLOUARD shikam...@mandriva.org wrote: On Wed, Mar 30, 2011 at 05:45:34PM +0200, Olivier Blin wrote: Frank Griffin f...@roadrunner.com writes: On 03/29/2011 03:01 PM, Ahmad Samir wrote: [...] “attach”... Anyway, from the log: auto-select: adding lib64cairo-xcb2-1.10.2-4.mga1.x86_64 replacing lib64cairo-xcb2-1.10.2-3.mga1.x86_64 which means you have lib64cairo-xcb2 installed (rpm -qa lib64cairo* should confirm/deny); this is not the default, urpmi is set to prefer lib(64)cairo2 over lib(64)cairo-xcb2, so I think, 'urpmi lib64cairo2' should fix this issue. You're correct, but I'm damned if I know why. I have two cauldron systems which get updated via --auto-update exclusively. On one, I have [...] Thanks for the assist, and sorry for the noise. There might have been a bug for a short time where pkgconfig(cairo) got resolved to cairo-xcb-devel, so it is possible the wrong package got pulled at some point. It should not be the case anymore (with a fix in urpmi prefer.vendor.list), but it won't be fixed automatically for cauldron users that got the wrong package before. Yep, sorry for that, I was unaware of that pkgconfig(cairo) provides. But f-spot’s case has been bugging me for quite some time. I don’t use it so I could not see the issue, but I don’t understand why it does have an explicit require on lib64cairo2… all its dependencies don’t. Here are the requires of f-spot : sqlite-tools sqlite3-tools lib64exif12 lib64gphoto2 shared-mime-info[*] scrollkeeper[*] shared-mime-info[*] scrollkeeper[*] /bin/sh[*] bash libX11.so.6()(64bit) libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libcairo.so.2()(64bit) libgdk-x11-2.0.so.0()(64bit) libgdk_pixbuf-2.0.so.0()(64bit) libglib-2.0.so.0()(64bit) liblcms.so.1()(64bit) libm.so.6()(64bit) libm.so.6(GLIBC_2.2.5)(64bit) libpthread.so.0()(64bit) rtld(GNU_HASH) pkgconfig lib64atk1.0_0 lib64cairo2 lib64gdk_pixbuf2.0_0 lib64gio2.0_0 lib64glib2.0_0 lib64gnomeui2_0 lib64gtk+-x11-2.0_0 lib64lcms1 lib64pango1.0_0 lib64unique0 lib64x11_6 lib64xcomposite1 mono(FlickrNet)[== 2.1.5.0] mono(Gnome.Keyring)[== 1.0.0.0] mono(ICSharpCode.SharpZipLib)[== 2.84.0.0] mono(Mono.Addins)[== 0.6.0.0] mono(Mono.Addins.Gui)[== 0.6.0.0] mono(Mono.Addins.Setup)[== 0.6.0.0] mono(Mono.Cairo)[== 2.0.0.0] mono(Mono.Posix)[== 2.0.0.0] mono(Mono.Simd)[== 2.0.0.0] mono(NDesk.DBus)[== 1.0.0.0] mono(System)[== 2.0.0.0] mono(System.Core)[== 3.5.0.0] mono(System.Web)[== 2.0.0.0] mono(System.Xml)[== 2.0.0.0] mono(atk-sharp)[== 2.12.0.0] mono(gconf-sharp)[== 2.24.0.0] mono(gdk-sharp)[== 2.12.0.0] mono(glib-sharp)[== 2.12.0.0] mono(gnome-sharp)[== 2.24.0.0] mono(gtk-sharp)[== 2.12.0.0] mono(mscorlib)[== 2.0.0.0] mono(pango-sharp)[== 2.12.0.0] As you can see, lib64cairo2 is completely unnecessary because the package already requires libcairo.so.2()(64bit). Looking at the spec: http://svnweb.mageia.org/packages/cauldron/f-spot/current/SPECS/f-spot.spec?revision=63695view=markup I don’t understand line 43 to 45 though I’m not sure these are the one that pulls cairo, nor do I understand which problem Götz tried to work around. I think this is unrelated All the lib64* requires are added automatically by something
Re: [Mageia-dev] Youri check installlation
On Tue, Apr 5, 2011 at 01:51, Michael Scherer m...@zarb.org wrote: The second check if a binary rpm is missing a source rpm. ( there is some false positive due to clever trick, like rpmlint-mageia-policy ) So that's likely one for admins for now. But do not blindly import missing rpms, something, the requires is wrong : So for example, if you see : task-lamp task-lamp-python apache-mod_python not found Check that apache-mod_python is still needed ( in this case, the software was dropped upstream since a few years ( and that's a shame IMHO )). On the other hand, errors like the one of backuppc may be a error in the check. No it's not, it's a noarch package which contains binary, and was built on x86_64 so is not installable eon i586 # rpm -qp --requires /distrib/bootstrap/distrib/cauldron/i586/media/core/release/backuppc-3.2.0-2.mga1.noarch.rpm | grep libc.so.6 libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) So it is not installable on i586 # rpmdiff /home/schedbot/old/backuppc-3.2.0-1.mga1.noarch.rpm /distrib/bootstrap/distrib/cauldron/i586/media/core/release/backuppc-3.2.0-2.mga1.noarch.rpm | grep added added REQUIRES libc.so.6()(64bit) added REQUIRES libc.so.6(GLIBC_2.2.5)(64bit) added REQUIRES rtld(GNU_HASH) added /var/www/backuppc/BackupPC_Admin
Re: [Mageia-dev] No meeting for 06/04, reported to next week
On Wed, Apr 6, 2011 at 01:16, Michael scherer m...@zarb.org wrote: Hi, due to various reasons, neither Anne or me will be availiable on Wenesday. So the meeting is reported to next week ( 13/04 ). In the mean time, if you need some work to do, I will remind that http://check.mageia.org/dependencies.html is not empty, There is now http://check.mageia.org/dependencies.html :) that there is some bug to fix ( be it bugs on installer as reported by marteen ), or some critical bugs ( like urpme unable to remove 2 rpms ), or the issue that i gave when upgrading servers :) Also, do not forget that version freeze is near ( in 3 weeks, the 20th april ), so in 2 weeks, no version update will be accepted without a good reason ( I expect that this period will be slightly chaotic , as we are doing it for the first time on the project ). -- Michael Scherer
Re: [Mageia-dev] [RPM] cauldron core/release kipi-plugins-1.9.0-2.mga1
On Sun, Apr 10, 2011 at 22:59, Mageia Team buildsystem-dae...@mageia.org wrote: Name : kipi-plugins Relocations: (not relocatable) Version : 1.9.0 Vendor: Mageia.Org Release : 2.mga1 Build Date: Sun Apr 10 23:36:58 2011 Install Date: (not installed) Build Host: ecosse Group : System/Libraries Source RPM: (none) Size : 5806608 License: GPLv2+ Signature : (none) Packager : Mageia Team http://www.mageia.org URL : http://www.kipi-plugins.org Summary : KDE image Interface Plugins Description : The library of the KDE Image Plugin Interface. Libkipi allows image applications to use a plugin architecture for additional functionality such as: RawConverter, SlideShow, ImagesGallery, HTMLExport, PrintAssistant... dmorgan dmorgan 1:1.9.0-2.mga1: + Revision: 83035 - Fix Groups (#765) + mikala mikala - Drop Obsoletes - Clean spec I did not look at the changes, but there are plenty of packages from previous build which are no longer created and are not obsoleted, see http://check.mageia.org/missing.html
Re: [Mageia-dev] [RPM] cauldron core/release kipi-plugins-1.9.0-2.mga1
On Tue, Apr 12, 2011 at 11:30, Angelo Naselli anase...@linux.it wrote: lunedì 11 aprile 2011 alle 10:38, Pascal Terjan ha scritto: I did not look at the changes, but there are plenty of packages from previous build which are no longer created and are not obsoleted, see http://check.mageia.org/missing.html IIRC mikala (and I not so much really) removed some obsoletes because they were very old and related to kde3 packages here. However obsoleting packageng older than mandriva 2010.1 (mabye 2010.0 if really wished) should be useless i believe. Yes sorry, it was a build system bug, the package is correct :)
Re: [Mageia-dev] [RPM] cauldron core/release zeromq-2.1.4-1.mga1
On Thu, Apr 14, 2011 at 00:59, Mageia Team buildsystem-dae...@mageia.org wrote: Name : zeromq Relocations: (not relocatable) Version : 2.1.4 Vendor: Mageia.Org Release : 1.mga1 Build Date: Thu Apr 14 01:58:16 2011 Install Date: (not installed) Build Host: ecosse Group : Development/Other Source RPM: (none) Size : 1864901 License: LGPLv3+ Signature : (none) Packager : Mageia Team http://www.mageia.org URL : http://www.zeromq.org Summary : Software library for fast, message-based applications Description : The 0MQ lightweight messaging kernel is a library which extends the standard socket interfaces with features traditionally provided by specialized messaging middle-ware products. 0MQ sockets provide an abstraction of asynchronous message queues, multiple messaging patterns, message filtering (subscriptions), seamless access to multiple transport protocols and more. dams dams 2.1.4-1.mga1: + Revision: 84840 - update to 2.1.4 It seems zeromq-utils no longer exists, should it be obsoleted? zeromq zeromq-utilsi5862.0.10-1.mga1 Obsolete binaries (source 2.1.4-2.mga1 found) zeromq-utilsx86_64 2.0.10-1.mga1 Obsolete binaries (source 2.1.4-2.mga1 found)
Re: [Mageia-dev] php and php-pear
On Sun, Apr 17, 2011 at 23:34, Thomas Spuhler tho...@btspuhler.com wrote: On Saturday, April 16, 2011 01:22:53 pm Thomas Spuhler wrote: Just a notification, I am working on updating the php and php-pear packages. I guess, I was too late. It seems we are not very efficient, I was working on this quite some time, just to find out someone else did the same thing. OK, I will not work on the other php packages before I'll be asked. Sorry I had missed this email and updated php after seeing that it was older than the one in 2010.2 updates (and fixed several CVE)
Re: [Mageia-dev] Maintainers policy
On Thu, Apr 14, 2011 at 10:17, Funda Wang fundaw...@gmail.com wrote: 2011/4/14 Anne nicolas enn...@mageia.org: Hi there Following tonight's meeting, we will start one week discussion about maintainers policy. Some questions to be discussed: - shall we have ACL's on svn, submits? - what about having co-maintenership or teams? How shall we manage this? - what about sensitive packages ? ... Pleas make any comments and proposals we could discus to build it. Final decisions will be taken during next packagers meeting (20th of april) If we are about to stick to subversion, then only maintainer could submit certain package. Of course, if package don't have maintainer, then anybody could submit it. As a maintainer, I would like to be at least notified when someone updates one of my packages If we will turn to git, then everybody could have his own clone, but the merge request should be reviewed by maintainer. After merging, anybody could submit it. The problem is that, we couldn't assure every package have a valid maintainer. Even if git would make it easier, I think it would in any case be nice for people to be able to upload somewhere changes for review, and for maintainer to easily apply them if correct
Re: [Mageia-dev] dev86 builds fine locally but failed on BS?
On Tue, Apr 19, 2011 at 16:10, Thierry Vignaud thierry.vign...@gmail.com wrote: Hi I'm seeing strange error: dev86 builds fine locally but then when I uploaded it, it failed on BS. Any idea? Different CPU Added a patch
Re: [Mageia-dev] Opnions about Mageia mirror in Brazil
On Sun, Apr 24, 2011 at 16:52, Filipe Saraiva filip.sara...@gmail.com wrote: Hello Mages, I need opnions about Mageia mirror in Brazil. My question: is it better update the brazilian mirror via distro.ibiblio.org (EUA based, 1GB bandwidth) or distrib-coffee.ipsl.jussieu.fr (France based, 100MB bandwidth)? I would suggest that you test the speed of a few mirrors from your mirror It is true that ibiblio synchronizes only once a day? Yes, I just checked and it is still true. Someone should contact them.
[Mageia-dev] Please ensure that packages have higher version than in mandriva 2010.2
Here is a list of packages to fix (not including backports yet) afio 0:2.5-1.mga1 = 0:2.5-6mdv2010.0 automake1.7 0:1.7.9-10.mga1 = 0:1.7.9-10.1mdv2010.1 avalon-framework 0:4.1.4-10.mga1 = 0:4.2.0-1.4.2mdv2010.1 avalon-framework-javadoc 0:4.1.4-10.mga1 = 0:4.2.0-1.4.2mdv2010.1 avalon-framework-manual 0:4.1.4-10.mga1 = 0:4.2.0-1.4.2mdv2010.1 buffer 0:1.19-1.mga1 = 0:1.19-8mdv2010.0 docker 0:1.5-1.mga1 = 0:1.5-4mdv2010.0 emesene 0:1.6.3-1.mga1 = 0:1.6.3-3mdv2010.2 fping 0:2.4b2-1.mga1 = 0:2.4b2-14mdv2010.1 hfsplusutils 0:1.0.4-1.mga1 = 0:1.0.4-6mdv2010.1 jakarta-taglibs-standard 0:1.1.1-14.mga1 = 0:1.1.2-6mdv2008.0 jakarta-taglibs-standard-javadoc 0:1.1.1-14.mga1 = 0:1.1.2-6mdv2008.0 jfsutils 0:1.1.13-3.mga1 = 0:1.1.13-3mnb2 jsr-305 0:0-0.5.20090319svn.1.mga1 = 0:0.1-1.0.2mdv2010.0 jsr-305-javadoc 0:0-0.5.20090319svn.1.mga1 = 0:0.1-1.0.2mdv2010.0 libmikmod-devel 0:3.2.0-0.beta2.1.mga1 = 0:3.2.0-0.beta2.7.1mdv2010.1 libmikmod-devel 0:3.2.0-0.beta2.1.mga1 = 0:3.2.0-0.beta2.7mdv2010.1 libmikmod3 0:3.2.0-0.beta2.1.mga1 = 0:3.2.0-0.beta2.7.1mdv2010.1 libmikmod3 0:3.2.0-0.beta2.1.mga1 = 0:3.2.0-0.beta2.7mdv2010.1 libportmidi-devel 0:217-2.mga1 = 0:20070107-3mdv2009.0 libportmidi0 0:217-2.mga1 = 0:20070107-3mdv2009.0 librpmconstant-devel 0:0.1.3-6.mga1 = 0:0.1.3-8mdv2010.1 librpmconstant0 0:0.1.3-6.mga1 = 0:0.1.3-8mdv2010.1 libvde-devel 0:2.2.2-1.mga1 = 0:2.2.2-4mdv2010.1 libvde2 0:2.2.2-1.mga1 = 0:2.2.2-4mdv2010.1 mirror 0:2.9-1.mga1 = 0:2.9-12mdv2010.0 mondo 0:2.2.9.5-1.mga1 = 0:2.29.3-1mdv2010.1 netbook-kde4-config 0:1-0.28.mga1 = 0:2010.1-22mdv2010.1 ngrep 0:1.45-1.mga1 = 0:1.45-6mdv2010.0 ocaml-camlidl 0:1.05-1.mga1 = 0:1.05-5mdv2010.1 ocaml-camlidl-devel 0:1.05-1.mga1 = 0:1.05-5mdv2010.1 ocaml-csv 0:1.1.7-1.mga1 = 0:1.1.7-3mdv2010.1 ocaml-csv-devel 0:1.1.7-1.mga1 = 0:1.1.7-3mdv2010.1 ocaml-extlib 0:1.5.1-1.mga1 = 0:1.5.1-3mdv2010.1 ocaml-extlib-devel 0:1.5.1-1.mga1 = 0:1.5.1-3mdv2010.1 ocaml-extlib-doc 0:1.5.1-1.mga1 = 0:1.5.1-3mdv2010.1 ocaml-json-wheel 0:1.0.6-4.mga1 = 0:1.0.6-4.1mdv2010.1 ocaml-json-wheel-devel 0:1.0.6-4.mga1 = 0:1.0.6-4.1mdv2010.1 ocaml-libvirt 0:0.6.1.0-1.mga1 = 0:0.6.1.0-2mdv2010.1 ocaml-libvirt-devel 0:0.6.1.0-1.mga1 = 0:0.6.1.0-2mdv2010.1 ocaml-ocamlnet 0:2.2.9-8.mga1 = 0:2.2.9-8.1mdv2010.1 ocaml-ocamlnet-devel 0:2.2.9-8.mga1 = 0:2.2.9-8.1mdv2010.1 ocaml-ocamlnet-nethttpd 0:2.2.9-8.mga1 = 0:2.2.9-8.1mdv2010.1 ocaml-ocamlnet-nethttpd-devel 0:2.2.9-8.mga1 = 0:2.2.9-8.1mdv2010.1 ocaml-ounit 0:1.0.3-1.mga1 = 0:1.0.3-4mdv2010.1 ocaml-ounit-devel 0:1.0.3-1.mga1 = 0:1.0.3-4mdv2010.1 ocaml-xml-light 0:2.2-1.mga1 = 0:2.2-17mdv2010.1 ocaml-xml-light-devel 0:2.2-1.mga1 = 0:2.2-17mdv2010.1 openntpd 0:3.9p1-1.mga1 = 0:3.9p1-6mdv2010.1 php-sasl 1:0.1.0-1.mga1 = 1:0.1.0-33.4mdv2010.2 php-sasl 1:0.1.0-1.mga1 = 1:0.1.0-33mdv2010.1 plasma-wallpaper-timeoftheday 0:0.1-2.mga1 = 0:0.1-5mdv2010.1 pmtools 0:1.100.0-1.mga1 = 0:20071116-6mdv2010.1 portmidi 0:217-2.mga1 = 0:20070107-3mdv2009.0 python-gpgme 0:0.1-1.mga1 = 0:0.1-3mdv2010.1 rdate 0:1.4-1.mga1 = 0:1.4-10mdv2010.1 reiserfsprogs 1:3.6.21-1.mga1 = 1:3.6.21-1mnb2 rpmconstant 0:0.1.3-6.mga1 = 0:0.1.3-8mdv2010.1 rsh 0:0.17-26.mga1 = 0:0.17-26.1mdv2010.1 rsh-server 0:0.17-26.mga1 = 0:0.17-26.1mdv2010.1 tellico 0:2.3.3-1.mga1 = 3:2.2-2mdv2010.1 tuxpaint 1:0.9.21-1.mga1 = 1:0.9.21-2mdv2010.2 tuxpaint-config 0:0.0.12-1.mga1 = 0:0.0.12-2mdv2010.1 tuxpaint-config 0:0.0.12-1.mga1 = 0:0.0.12-4mdv2010.2 tuxpaint-devel 1:0.9.21-1.mga1 = 1:0.9.21-2mdv2010.2 unrtf 0:0.21.1-1.mga1 = 0:0.21.1-4.2mdv2010.2 unrtf 0:0.21.1-1.mga1 = 0:0.21.1-4mdv2010.1 uucp 0:1.07-1.mga1 = 0:1.07-9mdv2010.1 vde2 0:2.2.2-1.mga1 = 0:2.2.2-4mdv2010.1 w3m 0:0.5.2-1.mga1 = 0:0.5.2-9mdv2010.1 wol 0:0.7.1-1.mga1 = 0:0.7.1-6mdv2010.0 ws-commons-util 0:1.0.1-2.mga1 = 0:1.0.1-6.1.2mdv2009.0 ws-commons-util-javadoc 0:1.0.1-2.mga1 = 0:1.0.1-6.1.2mdv2009.0 wsdl4j 0:1.6.2-1.mga1 = 0:1.6.2-2.0.6mdv2010.1 wsdl4j-javadoc 0:1.6.2-1.mga1 = 0:1.6.2-2.0.6mdv2010.1
Re: [Mageia-dev] Please ensure that packages have higher version than in mandriva 2010.2
On Sat, Apr 30, 2011 at 22:05, Maarten Vanraes maarten.vanr...@gmail.com 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? It needs epoch to be increased to 1
Re: [Mageia-dev] Please ensure that packages have higher version than in mandriva 2010.2
On Sat, Apr 30, 2011 at 22:21, Maarten Vanraes maarten.vanr...@gmail.com wrote: Op zaterdag 30 april 2011 21:42:54 schreef Pascal Terjan: Here is a list of packages to fix (not including backports yet) afio 0:2.5-1.mga1 = 0:2.5-6mdv2010.0 automake1.7 0:1.7.9-10.mga1 = 0:1.7.9-10.1mdv2010.1 [...] isn't this one actually higher? afaik the matchings come from ascii, and digits are always less than letters? (ie: 1 m )? No this is not ascii rpm first compares the numeric part (numbers and dots), then if they are equal compares the rest
Re: [Mageia-dev] Please ensure that packages have higher version than in mandriva 2010.2
Updated list (includes backports) avalon-framework 0:4.1.4-10.mga1 = 0:4.2.0-1.4.2mdv2010.1 avalon-framework-javadoc 0:4.1.4-10.mga1 = 0:4.2.0-1.4.2mdv2010.1 avalon-framework-manual 0:4.1.4-10.mga1 = 0:4.2.0-1.4.2mdv2010.1 blender 0:2.49b-7.mga1 = 0:2.57-2mdv2010.2 # This one should be reverted in Mandriva according to discussion on ML cget 0:1.0.19-2.mga1 = 0:1.2.2-1mdv2010.2 cherokee 0:1.0.19-2.mga1 = 0:1.2.2-1mdv2010.2 cherokee-devel 0:1.0.19-2.mga1 = 0:1.2.2-1mdv2010.2 horde 0:3.3.8-3.mga1 = 0:3.3.9-3mdv2010.2 horde-kronolith 0:2.3.4-1.mga1 = 0:2.3.5-2mdv2010.2 horde-nag 0:2.3.5-1.mga1 = 0:2.3.6-1mdv2010.2 horde-turba 0:2.3.4-2.mga1 = 0:2.3.5-1mdv2010.2 jsr-305 0:0-0.5.20090319svn.1.mga1 = 0:0.1-1.0.2mdv2010.0 jsr-305-javadoc 0:0-0.5.20090319svn.1.mga1 = 0:0.1-1.0.2mdv2010.0 krb5 0:1.8.3-4.mga1 = 0:1.9-4mdv2010.2 krb5-pkinit-openssl 0:1.8.3-4.mga1 = 0:1.9-4mdv2010.2 krb5-server 0:1.8.3-4.mga1 = 0:1.9-4mdv2010.2 krb5-server-ldap 0:1.8.3-4.mga1 = 0:1.9-4mdv2010.2 krb5-workstation 0:1.8.3-4.mga1 = 0:1.9-4mdv2010.2 libcherokee-base0 0:1.0.19-2.mga1 = 0:1.2.2-1mdv2010.2 libcherokee-client0 0:1.0.19-2.mga1 = 0:1.2.2-1mdv2010.2 libcherokee-server0 0:1.0.19-2.mga1 = 0:1.2.2-1mdv2010.2 libkrb53 0:1.8.3-4.mga1 = 0:1.9-4mdv2010.2 libkrb53-devel 0:1.8.3-4.mga1 = 0:1.9-4mdv2010.2 libmikmod-devel 0:3.2.0-0.beta2.7.mga1 = 0:3.2.0-0.beta2.7.1mdv2010.1 libmikmod3 0:3.2.0-0.beta2.7.mga1 = 0:3.2.0-0.beta2.7.1mdv2010.1 mondo 0:2.2.9.5-1.mga1 = 0:2.29.3-1mdv2010.1 nagios-check_mk 0:1.1.8-1.mga1 = 0:1.1.10-1mdv2010.2 nagios-check_mk-agent 0:1.1.8-1.mga1 = 0:1.1.10-1mdv2010.2 nagios-check_netapp 0:20060619-4.mga1 = 1:1.4.14-8mdv2010.1 nagios-check_netapp 0:20060619-4.mga1 = 1:1.4.15-6mdv2010.2 netbook-kde4-config 0:1-0.28.mga1 = 0:2010.1-22.1mdv2010.1 netbook-kde4-config 0:1-0.28.mga1 = 0:2010.1-22mdv2010.1 pmtools 0:1.100.0-1.mga1 = 0:20071116-6mdv2010.1 # This one is a different package with the same name... qtractor 0:0.4.7-1.mga1 = 0:0.4.8-1mdv2010.2 remmina-plugins 0:0.9.2-1.mga1 = 0:0.9.2-2mdv2010.2 squid 0:3.1.11-1.mga1 = 0:3.1.12.1-2mdv2010.2 squid-cachemgr 0:3.1.11-1.mga1 = 0:3.1.12.1-2mdv2010.2 t-lasku 0:1.9.1-1.mga1 = 0:1.9.2-1mdv2010.2 texmaker 1:2.2.1-1.mga1 = 1:3.0.1-1mdv2010.2
Re: [Mageia-dev] Please ensure that packages have higher version than in mandriva 2010.2
On Sun, May 1, 2011 at 00:28, Maarten Vanraes maarten.vanr...@gmail.com wrote: Op zaterdag 30 april 2011 22:53:49 schreef Pascal Terjan: On Sat, Apr 30, 2011 at 22:21, Maarten Vanraes maarten.vanr...@gmail.com wrote: Op zaterdag 30 april 2011 21:42:54 schreef Pascal Terjan: Here is a list of packages to fix (not including backports yet) afio 0:2.5-1.mga1 = 0:2.5-6mdv2010.0 automake1.7 0:1.7.9-10.mga1 = 0:1.7.9-10.1mdv2010.1 [...] isn't this one actually higher? afaik the matchings come from ascii, and digits are always less than letters? (ie: 1 m )? No this is not ascii rpm first compares the numeric part (numbers and dots), then if they are equal compares the rest you mean, disttag is compared separately? whatever non numeric 1.beta1.0mga 1.1mga
Re: [Mageia-dev] Please ensure that packages have higher version than in mandriva 2010.2
On Sun, May 1, 2011 at 00:06, Michael scherer m...@zarb.org wrote: On Sun, May 01, 2011 at 12:28:58AM +0200, Pascal Terjan wrote: Updated list (includes backports) do not forget that version freeze is in effect. So unless there is a reason to upgrade ( and upgrade from backports is like upgrade from cooker, nice to have but not required ) Without including backports, we still have: libcelt0_0 0:0.5.1.3-1.mga1 = 0:0.7.1-1mdv2010.1 avalon-framework-manual 0:4.1.4-10.mga1 = 0:4.2.0-1.4.2mdv2010.1 avalon-framework 0:4.1.4-10.mga1 = 0:4.2.0-1.4.2mdv2010.1 avalon-framework-javadoc 0:4.1.4-10.mga1 = 0:4.2.0-1.4.2mdv2010.1 netbook-kde4-config 0:1-0.32.mga1 = 0:2010.1-22mdv2010.1 tcl-sqlite3 0:3.7.6.1-1.mga1 = 0:3.7.6.2-0.1mdv2010.2 jsr-305 0:0-0.5.20090319svn.1.mga1 = 0:0.1-1.0.2mdv2010.0 kernel-vserver-devel-latest 0:2.6.38.5-1.mga1 = 1:2.6.22.19-1mdv2009.0 jsr-305-javadoc 0:0-0.5.20090319svn.1.mga1 = 0:0.1-1.0.2mdv2010.0 kernel-vserver-latest 0:2.6.38.5-1.mga1 = 1:2.6.22.19-1mdv2009.0 kernel-vserver-source-latest 0:2.6.38.5-1.mga1 = 1:2.6.22.19-1mdv2009.0 opengl-games-utils 0:0.1-1.mga1 = 0:0.1-3mdv2010.1 pmtools 0:1.100.0-1.mga1 = 0:20071116-6mdv2010.1 nagios-check_netapp 0:20060619-4.mga1 = 1:1.4.14-8mdv2010.1 mondo 0:2.2.9.5-1.mga1 = 0:2.29.3-1mdv2010.1 ssmtp 0:2.64-1.mga1 = 0:2.64-4mdv2010.1
Re: [Mageia-dev] [Mageia-sysadm] Package removal request
On Mon, May 9, 2011 at 10:36, nicolas vigier bo...@mars-attacks.org wrote: On Mon, 09 May 2011, Colin Guthrie wrote: 'Twas brillig, and Ahmad Samir at 07/05/11 22:30 did gyre and gimble: On 3 March 2011 03:31, Ahmad Samir ahmadsamir3...@gmail.com wrote: Please remove esound binary and src packages: esound-utils lib*esound-devel lib*esound0 As has been discussed on the -dev ML, esound should be phased out from the distro. I've rebuilt all the packages that had BR esound-devel, and now nothing requires it in Mageia. (I am wondering if it should be added to the import-to-svn blacklist, to prevent it being resubmitted). I think it should be left in SVN for a while though. -- Ahmad Samir This request was lost in the ML; and now two packages were built against esound-devel. If the esound phasing sounds logical at this stage, I can try building those two packages without esound, but then you gotta promise to add esound to the blacklist... I'm certainly all in favour of this! Death to esound!!! I removed esound from the repository. You can now rebuild packages that were built against esound-devel. http://check.mageia.org/dependencies.html 10 packages buildrequire esound-devel SDL12 SDL_mixer blender bumprace csmash gkrellm-plugins libmikmod rocksndiamonds soundwrapper tritonus Including 2 which are linked against the lib : gkrellm-plugins tritonus
Re: [Mageia-dev] Does Mageia (Mandriva) fully follow XDG menu specifications?
On Wed, May 11, 2011 at 06:10, Franklin Weng frank...@goodhorse.idv.tw wrote: Hi list, Right now I'm customizing my own menu (without menu editor). I'm implementing our own menu structure, so I followed XDG menu specs to create our own menu. However, I found that the menu layout attributes, like show_empty, inline, ... etc., seemed to be ignored. AFAIK, the XDG menu spec implementation should be done by distribution vendors. If yes, would anyone please tell me if Mageia (or even Mandriva) fully follows the XDG menu spec? Or, what should I do to make the show_empty, inline work? On which environment did you test? GNOME? KDE? The specification is followed by the desktop environment as far as I know, but the distro defines some rules (using the menu spec) inline works and is used in /etc/xdg/menus/applications.menu: NameApplications/Name Layout Menuname inline=falseInternet/Menuname Menuname inline=falseOffice/Menuname Menuname inline=falseGraphics/Menuname Menuname inline=falseSoundVideo/Menuname Menuname inline=falseTools/Menuname Menuname inline=falseDevelopment/Menuname Menuname inline=falseGames/Menuname Menuname inline=falseEducation/Menuname Menuname inline=falseSciences/Menuname Menuname inline=falseDocumentation/Menuname Merge type=menus/ Merge type=files/ Separator/ Filenamerpmdrake.desktop/Filename /Layout DefaultLayout inline=true inline_limit=1 Merge type=files/ MenunameMore/Menuname Merge type=menus/ /DefaultLayout
Re: [Mageia-dev] Freeze push request: festvox
On Mon, May 16, 2011 at 09:18, Michael Scherer m...@zarb.org wrote: Le lundi 16 mai 2011 à 02:11 +0300, Ahmad Samir a écrit : Please submit festvox, it's just been imported, it provides the English speakers for festival https://bugs.mageia.org/show_bug.cgi?id=1296 Pushed festvox noarch festvox-kallpc-common festlex-CMU not found error noarch festvox-kedlpc-common festlex-CMU not found error
Re: [Mageia-dev] Security Update Process
On Mon, May 16, 2011 at 15:45, Stew Benedict stewbi...@gmail.com wrote: OK, Mageia 1 is approaching quickly and we need to get our process in place for security updates. We talked a bit about it a few weeks ago, and I started a wiki page, but it needs more detail. Anne and I chatted on IRC and it looks like we'll want to cutoff the on the iso updates at the end of this week, so we need a process in place to release post-iso updates. ref: http://mageia.org/wiki/doku.php?id=security As I see it, initially we need, in no particular order: 1) a means to build updates for the release (iurt setup for mga1?) A iurt setup for mga1 will exist anyway, what is missing is a way to later upload to non public place. Initially, we can just setup youri to restrict submitting a build to updates_testing or updates to the secteam and it should be enough. 2) a means to publish updates (mail list, web page) 3) a means to manage/track the updates (bugzilla?) 4) work out/publish the process so we all know how it works And then of course we need people to be aware of vulnerabilities as they are exposed. For now, we'll have be be slightly trailing until we can show a history of releasing updates and hopefully gain access to the closed list to get access to embargoed issues. Once that happens we will possibly need additional infrastructure changes to keep the work non-public before the embargo date. osvdb has a nice email aggregator that sends all the distro update announcements, and the oss-security list has many of the CVE requests. Unfortunately, my personal time hasn't allowed much more than a quick read as they go by :/ I know many of you have been doing security related bug reports and updates, which is great, thank-you. If anyone wants to take a larger role in managing the process I'm more than happy to let that happen. While I have experience, the time I'm able to commit is less than helpful. Comments, volunteers?
Re: [Mageia-dev] [1475] Drop line which should never have been commited
On Mon, May 23, 2011 at 07:09, Thierry Vignaud thierry.vign...@gmail.com wrote: On 23 May 2011 01:00, r...@mageia.org wrote: Revision 1475 Author pterjan Date 2011-05-23 01:00:33 +0200 (Mon, 23 May 2011) Log Message Drop line which should never have been commited OK but you also committed totally unrelated stuff: Yes I know and noticed when svn said Sendingiurt/trunk/ulri, and I decided to go to sleep.
Re: [Mageia-dev] protobuf package problem
On Fri, May 20, 2011 at 16:05, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and Dexter Morgan at 20/05/11 14:21 did gyre and gimble: On Fri, May 20, 2011 at 1:07 PM, Dexter Morgan dmorga...@gmail.com wrote: On Fri, May 20, 2011 at 12:27 PM, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and Colin Guthrie at 20/05/11 11:22 did gyre and gimble: To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium CoreRelease-64) protobuf 2.3.0 10.mga1 x86_64 protobuf-compiler 2.3.0 10.mga1 x86_64 1.6MB of additional disk space will be used. 473KB of packages will be retrieved. Proceed with the installation of the 2 packages? (Y/n) can you test new packages please ? Got it. Seems to work great. Thanks :D Is it intended that most subpackages no longer exist and were not obsoleted (all the -10) ? /distrib/bootstrap/distrib/cauldron/x86_64/media/core/release/protobuf-vim-2.3.0-11.mga1.x86_64.rpm /distrib/bootstrap/distrib/cauldron/x86_64/media/core/release/protobuf-java-2.3.0-11.mga1.x86_64.rpm /distrib/bootstrap/distrib/cauldron/x86_64/media/core/release/protobuf-devel-2.3.0-10.mga1.x86_64.rpm /distrib/bootstrap/distrib/cauldron/x86_64/media/core/release/protobuf-lite-2.3.0-10.mga1.x86_64.rpm /distrib/bootstrap/distrib/cauldron/x86_64/media/core/release/protobuf-2.3.0-10.mga1.x86_64.rpm /distrib/bootstrap/distrib/cauldron/x86_64/media/core/release/protobuf-lite-devel-2.3.0-10.mga1.x86_64.rpm /distrib/bootstrap/distrib/cauldron/x86_64/media/core/release/protobuf-lite-static-2.3.0-10.mga1.x86_64.rpm /distrib/bootstrap/distrib/cauldron/x86_64/media/core/release/protobuf-static-2.3.0-10.mga1.x86_64.rpm /distrib/bootstrap/distrib/cauldron/x86_64/media/core/release/protobuf-compiler-2.3.0-11.mga1.x86_64.rpm /distrib/bootstrap/distrib/cauldron/x86_64/media/core/release/protobuf-javadoc-2.3.0-11.mga1.x86_64.rpm /distrib/bootstrap/distrib/cauldron/x86_64/media/debug/core/release/protobuf-debug-2.3.0-11.mga1.x86_64.rpm /distrib/bootstrap/distrib/cauldron/SRPMS/core/release/protobuf-2.3.0-11.mga1.src.rpm /distrib/bootstrap/distrib/cauldron/i586/media/core/release/protobuf-vim-2.3.0-11.mga1.i586.rpm /distrib/bootstrap/distrib/cauldron/i586/media/core/release/protobuf-lite-devel-2.3.0-10.mga1.i586.rpm /distrib/bootstrap/distrib/cauldron/i586/media/core/release/protobuf-2.3.0-10.mga1.i586.rpm /distrib/bootstrap/distrib/cauldron/i586/media/core/release/protobuf-static-2.3.0-10.mga1.i586.rpm /distrib/bootstrap/distrib/cauldron/i586/media/core/release/protobuf-lite-static-2.3.0-10.mga1.i586.rpm /distrib/bootstrap/distrib/cauldron/i586/media/core/release/protobuf-lite-2.3.0-10.mga1.i586.rpm /distrib/bootstrap/distrib/cauldron/i586/media/core/release/protobuf-devel-2.3.0-10.mga1.i586.rpm /distrib/bootstrap/distrib/cauldron/i586/media/core/release/protobuf-compiler-2.3.0-11.mga1.i586.rpm /distrib/bootstrap/distrib/cauldron/i586/media/core/release/protobuf-java-2.3.0-11.mga1.i586.rpm /distrib/bootstrap/distrib/cauldron/i586/media/core/release/protobuf-javadoc-2.3.0-11.mga1.i586.rpm /distrib/bootstrap/distrib/cauldron/i586/media/debug/core/release/protobuf-debug-2.3.0-11.mga1.i586.rpm
Re: [Mageia-dev] protobuf package problem
On Wed, May 25, 2011 at 23:30, Dexter Morgan dmorga...@gmail.com wrote: On Thu, May 26, 2011 at 12:24 AM, Pascal Terjan pter...@gmail.com wrote: On Fri, May 20, 2011 at 16:05, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and Dexter Morgan at 20/05/11 14:21 did gyre and gimble: On Fri, May 20, 2011 at 1:07 PM, Dexter Morgan dmorga...@gmail.com wrote: On Fri, May 20, 2011 at 12:27 PM, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and Colin Guthrie at 20/05/11 11:22 did gyre and gimble: To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium CoreRelease-64) protobuf 2.3.0 10.mga1 x86_64 protobuf-compiler 2.3.0 10.mga1 x86_64 1.6MB of additional disk space will be used. 473KB of packages will be retrieved. Proceed with the installation of the 2 packages? (Y/n) can you test new packages please ? Got it. Seems to work great. Thanks :D Is it intended that most subpackages no longer exist and were not obsoleted (all the -10) ? /distrib/bootstrap/distrib/cauldron/x86_64/media/core/release/protobuf-vim-2.3.0-11.mga1.x86_64.rpm /distrib/bootstrap/distrib/cauldron/x86_64/media/core/release/protobuf-java-2.3.0-11.mga1.x86_64.rpm /distrib/bootstrap/distrib/cauldron/x86_64/media/core/release/protobuf-devel-2.3.0-10.mga1.x86_64.rpm /distrib/bootstrap/distrib/cauldron/x86_64/media/core/release/protobuf-lite-2.3.0-10.mga1.x86_64.rpm /distrib/bootstrap/distrib/cauldron/x86_64/media/core/release/protobuf-2.3.0-10.mga1.x86_64.rpm /distrib/bootstrap/distrib/cauldron/x86_64/media/core/release/protobuf-lite-devel-2.3.0-10.mga1.x86_64.rpm /distrib/bootstrap/distrib/cauldron/x86_64/media/core/release/protobuf-lite-static-2.3.0-10.mga1.x86_64.rpm /distrib/bootstrap/distrib/cauldron/x86_64/media/core/release/protobuf-static-2.3.0-10.mga1.x86_64.rpm /distrib/bootstrap/distrib/cauldron/x86_64/media/core/release/protobuf-compiler-2.3.0-11.mga1.x86_64.rpm /distrib/bootstrap/distrib/cauldron/x86_64/media/core/release/protobuf-javadoc-2.3.0-11.mga1.x86_64.rpm /distrib/bootstrap/distrib/cauldron/x86_64/media/debug/core/release/protobuf-debug-2.3.0-11.mga1.x86_64.rpm /distrib/bootstrap/distrib/cauldron/SRPMS/core/release/protobuf-2.3.0-11.mga1.src.rpm /distrib/bootstrap/distrib/cauldron/i586/media/core/release/protobuf-vim-2.3.0-11.mga1.i586.rpm /distrib/bootstrap/distrib/cauldron/i586/media/core/release/protobuf-lite-devel-2.3.0-10.mga1.i586.rpm /distrib/bootstrap/distrib/cauldron/i586/media/core/release/protobuf-2.3.0-10.mga1.i586.rpm /distrib/bootstrap/distrib/cauldron/i586/media/core/release/protobuf-static-2.3.0-10.mga1.i586.rpm /distrib/bootstrap/distrib/cauldron/i586/media/core/release/protobuf-lite-static-2.3.0-10.mga1.i586.rpm /distrib/bootstrap/distrib/cauldron/i586/media/core/release/protobuf-lite-2.3.0-10.mga1.i586.rpm /distrib/bootstrap/distrib/cauldron/i586/media/core/release/protobuf-devel-2.3.0-10.mga1.i586.rpm /distrib/bootstrap/distrib/cauldron/i586/media/core/release/protobuf-compiler-2.3.0-11.mga1.i586.rpm /distrib/bootstrap/distrib/cauldron/i586/media/core/release/protobuf-java-2.3.0-11.mga1.i586.rpm /distrib/bootstrap/distrib/cauldron/i586/media/core/release/protobuf-javadoc-2.3.0-11.mga1.i586.rpm /distrib/bootstrap/distrib/cauldron/i586/media/debug/core/release/protobuf-debug-2.3.0-11.mga1.i586.rpm As this was a cauldron only issue i though this wasn't needed, do you prefer them to be obsoleted ? i can do it right now if needed. No but I won't remove them from mirrors if this is not normal, that's why I asked if it was intended
Re: [Mageia-dev] [1601] Do not append .%distro_section if section is core
On Mon, May 30, 2011 at 13:08, Thomas Backlund t...@mageia.org wrote:
root-odjjhxpcy38dnm+yrof...@public.gmane.org skrev 30.5.2011 14:44:
Revision
1601
Author
pterjan
Date
2011-05-30 13:44:17 +0200 (Mon, 30 May 2011)
Log Message
Do not append .%distro_section if section is core
[...]
Modified: rpm/rpm-setup/trunk/build.macros.in
===
--- rpm/rpm-setup/trunk/build.macros.in 2011-05-30 10:02:43 UTC (rev 1600)
+++ rpm/rpm-setup/trunk/build.macros.in 2011-05-30 11:44:17 UTC (rev 1601)
@@ -152,7 +152,7 @@
%distsuffix @DISTSUFFIX@
-%mkrel(c:) %{-c:
0.%{-c*}.}%{1}%{?subrel:.%subrel}%{?distsuffix:%distsuffix}%{?!distsuffix:.mga}%{?distro_release:%distro_release}%{?distro_section:.%distro_section}
+%mkrel(c:) %{-c:
0.%{-c*}.}%{1}%{?subrel:.%subrel}%{?distsuffix:%distsuffix}%{?!distsuffix:.mga}%{?distro_release:%distro_release}%([%{distro_section}
!=core ] echo .%distro_section)
This is wrong...
It will trigger on nonfree
Isnt it better to only check for tainted ?
I had planned to have if on nonfree and tainted since the beginning,
as we way have some packages in core + nonfree, if they can be built
with some support for nonfree stuff
Re: [Mageia-dev] Iurt
On Fri, Jun 3, 2011 at 11:19, Balcaen John mik...@mageia.org wrote:
Le vendredi 3 juin 2011 05:57:14, Stefano Negro a écrit :
Hi.
I'd like to learn Iurt. Can someone teach me starting to configure the
testing environment and an example of src.rpm?
1) You need to have a local mirror of the distribution .
I don't think so
You need a fast one else creating chroots will be long, but can use an
url for the mirror given to iurt
2) install iurt via urpmi
3) give your build user the correct right to use /usr/sbin/iurt_root_command
Which is done in sudo config
4) configure the configuration file for example here to use a cauldron iurt
i've
got a ~/.iurt.cauldron.conf
{
local_home = /home/mikala/build,
home = /home/mikala/iurt,
upload = /home/mikala,
local_upload = /home/mikala,
repository = '/Public/pub/linux/Mageia/distrib',
admin = 'mik...@mageia.org',
sendmail = 0,
packager = 'Iurt the rebuild bot mik...@mageia.org',
}
You'll find here the result of the build builds logs in /home/mikala/iurt
/home/mikala/build is used for storing the chroot tarball
5) you can now start playing with iurt to build package
on a x86_64 arch you can also build i586 packages using linux32
aka
linux32 iurt -r cauldron i586 your.src.rpm
will build a i586 package
iurt -r cauldron x86_64 your.src.rpm
allow you to build the x86_64 package
--
Balcaen John
Re: [Mageia-dev] perl 5.14.0 now available
On Sat, Jun 11, 2011 at 17:00, Thomas Spuhler tho...@btspuhler.com wrote: On Saturday, June 11, 2011 03:33:18 am Olivier Blin wrote: Jerome Quelin jque...@gmail.com writes: hi, perl 5.14.0 should arrive soon. it compiles fine on both i586 x86_64, and it seem we fixed the only problem arisen in perl-URPM. since other packages need to be rebuilt in the same loop, and given that urpmi is written in perl, it needs a special treatment to bypass the regular bs upload. blino will likely do this magic dance upload them in the coming hours - you may want to wait till his final go before updating your cauldron box. Hi, I've uploaded perl 5.14 last night. (I just had to update perl-FCGI to a newer version, since it didn't build anymore) Help is welcome to rebuild perlapi-5.12-dependent packages. Thanks Jérôme! I'll help to build Thanks for helping but 1) Please use a better changelog message, like Rebuild for perl 5.14. Increase rel for rebuild is not interesting when looking at the history of a package. 2) How did you get the list of packages to rebuild? You seem to rebuild packages which don't need to be rebuilt. I noticed perl-Youri-Package which I wouldn't expect needing to be rebuilt. # rpm -qp --requires /distrib/bootstrap/distrib/1/i586/media/core/release/perl-Youri-Package-0.2.2-4.mga1.noarch.rpm perl-version rpmlib(PayloadFilesHavePrefix) = 4.0-1 rpmlib(CompressedFileNames) = 3.0.4-1 rpmlib(VersionedDependencies) = 3.0.3-1 perl-base = 2:5.12.3 rpmlib(PayloadIsLzma) = 4.4.6-1 It does not depend on perlapi-5.12
Re: [Mageia-dev] Cleaning orphans from the mirrors
On Tue, Jul 19, 2011 at 02:43, Michael Scherer m...@zarb.org wrote: Hi, as discussed on irc from time to time since years , and as proposed on https://www.mageia.org/pipermail/mageia-dev/2011-June/006153.html , I have implemented a script to clean orphan automatically. One more mail I had missed :/ As said in the mail, the delay is 2 weeks of presence, and 1 month after, total removal. I didn't deployed it yet, as I would like to have some feedback and review ( but if no one step for that, I will do it myself in a few days ). I used had a script to do that after manual review (except for kernels), for things which are not libs changing majors I try to ask people if they forgot Obsoletes or if this intended before doing the move
Re: [Mageia-dev] [RPM] cauldron core/release gnutls-3.0.0-1.mga2
On Wed, Aug 3, 2011 at 22:35, D.Morgan dmorga...@gmail.com wrote: On Wed, Aug 3, 2011 at 11:16 PM, Balcaen John mik...@mageia.org wrote: Le Mercredi 3 Août 2011 22:43:21 D.Morgan a écrit : [...] what ? the error here is about PA not to gnutls She's talking about the « WARNING: no socket to connect to » warning i guess. Regards, -- Balcaen John ah and this is gnutls errors ? Just for the infos after the last cauldron update aria seems to works fine. ( except the « WARNING: no socket to connect to » errors that i don't understand for the moment. but it works ;) It seems this message comes from the gnome-keyring pkcs11 module
Re: [Mageia-dev] noarch vs. arch
On Fri, Sep 2, 2011 at 03:57, Thomas Spuhler tho...@btspuhler.com wrote: When upgrading lilypond I noticed that someone else mad the doc package noarch to make the huge doc subpackage be noarch 1. What is the advantage of this? We have noarch packages in i586 and x86_64 anyway They are hardlinks 2. The result wasn't as intended, we now have the arch + noarch package in the repos Yes there is still a bug in the build system, packages switching between arch/noarch are not deleted
Re: [Mageia-dev] Review of security updates
On Mon, Sep 12, 2011 at 21:03, Manuel Hiebel man...@hiebel.eu wrote: * 1854 .config in / 2011-06-19 18:41 CEST by james Whitby Modified: 2011-06-20 01:42 CEST I don't think this is a security problem * 1971 PHP 2011-06-30 15:54 CEST by Stew Benedict Modified: 2011-08-30 11:59 CEST This one needs to be fixed (urgently) * 1979 oprofile 2011-06-30 23:43 CEST by Nicolas Vigier Modified: 2011-08-30 10:00 CEST This one needs to be fixed
Re: [Mageia-dev] [ANN] rpm-4.9.1
On Tue, Sep 13, 2011 at 22:33, D.Morgan dmorga...@gmail.com wrote:
On Tue, Sep 13, 2011 at 7:30 PM, Guillaume Rousse
guillomovi...@gmail.com wrote:
Le 13/09/2011 23:11, D.Morgan a écrit :
On Tue, Sep 13, 2011 at 5:52 PM, Thierry Vignaud
thierry.vign...@gmail.com wrote:
Hi
rpm-4.9.1 has been pushed into core/updates_testing
You're welcome to test it.
I've tested with success:
- live upgrade
- a special build of drakx-installer
(the installer available on mirrors still uses older rpm-4.8.1).
Please further test.
Thanks
See you
just to complete what thierry said, this is in update_testing
because we did big changes and we still need to apply/rediff some
patches.
Know issues:
- rpm -b{a,i,s} does not work you need rpmbuild -b{a,i,s}
rpm -b is supposed to be deprecated for ages...
Yes we plan to remove it too, but i fear that removing it now would be
too hard for packagers ( so i first though of it for rpm 4.10 ) . But
if ppl agree we can make it deprecated for us too.
Btw i looked and asked and iurt use rpmbuild so nothing will be broken.
Uploads to updates_testing fail because urpmi fails when restarting
with new rpm:
error: dbiOpen: dbapi 1 not available
Re: [Mageia-dev] [ANN] rpm-4.9.1
On Wed, Sep 14, 2011 at 15:09, Thierry Vignaud
thierry.vign...@gmail.com wrote:
On 14 September 2011 15:59, Pascal Terjan pter...@gmail.com wrote:
rpm-4.9.1 has been pushed into core/updates_testing
You're welcome to test it.
I've tested with success:
- live upgrade
- a special build of drakx-installer
(the installer available on mirrors still uses older rpm-4.8.1).
Please further test.
Thanks
See you
just to complete what thierry said, this is in update_testing
because we did big changes and we still need to apply/rediff some
patches.
Know issues:
- rpm -b{a,i,s} does not work you need rpmbuild -b{a,i,s}
rpm -b is supposed to be deprecated for ages...
Yes we plan to remove it too, but i fear that removing it now would be
too hard for packagers ( so i first though of it for rpm 4.10 ) . But
if ppl agree we can make it deprecated for us too.
Btw i looked and asked and iurt use rpmbuild so nothing will be broken.
Uploads to updates_testing fail because urpmi fails when restarting
with new rpm:
error: dbiOpen: dbapi 1 not available
it looks like in some case, priority upgrade fail to update perl-URPM along
rpm
though it did worked for me.
/me is looking why
I suppose the problem is that's it's not an auto-select but
installation of buildrequires which pulls new version of rpm
Re: [Mageia-dev] What's wrong with BS?
On Mon, Sep 19, 2011 at 13:29, Funda Wang fundaw...@gmail.com wrote: http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20110919121040.fwang.valstar.7596/log/botcmd.1316434263.ecosse.log It seems %distro_section is wrongly set? Did you use a non default command to submit ? It seems fine for me but BS is currently broken due to other reason
Re: [Mageia-dev] What's wrong with BS?
On Mon, Sep 19, 2011 at 14:03, Pascal Terjan pter...@gmail.com wrote: On Mon, Sep 19, 2011 at 13:29, Funda Wang fundaw...@gmail.com wrote: http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20110919121040.fwang.valstar.7596/log/botcmd.1316434263.ecosse.log It seems %distro_section is wrongly set? Did you use a non default command to submit ? It seems fine for me but BS is currently broken due to other reason Ah sorry I can reproduce now that the http is fixed, will look more
Re: [Mageia-dev] What's wrong with BS?
On Mon, Sep 19, 2011 at 14:18, Michael Scherer m...@zarb.org wrote: Le lundi 19 septembre 2011 à 15:16 +0200, Michael Scherer a écrit : Le lundi 19 septembre 2011 à 14:45 +0200, Michael Scherer a écrit : Le lundi 19 septembre 2011 à 20:29 +0800, Funda Wang a écrit : http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20110919121040.fwang.valstar.7596/log/botcmd.1316434263.ecosse.log It seems %distro_section is wrongly set? In a iurt chroot, that's ok. So, the problem should be fixed now. I spoke too soon, that's not fixed, we will keep you informed Fix on its way, it should work fine now (I committed the fix and applied it manually on the server)
Re: [Mageia-dev] [Mageia-sysadm] [changelog] cauldron core/release mplayer-1.0-1.rc4.0.r32713.8.mga2
On Tue, Sep 20, 2011 at 08:35, Thierry Vignaud thierry.vign...@gmail.com wrote: On 20 September 2011 08:43, Mageia Team buildsystem-dae...@mageia.org wrote: fwang fwang 1.0-1.rc4.0.r32713.8.mga2: + Revision: 145939 - fix typo - fix build with libpng 1.5 - rebuild for new libpng BTW what about autosubmiting packages to tainted when a tainted build for it already exists? https://bugs.mageia.org/show_bug.cgi?id=338#c33
Re: [Mageia-dev] [RFC] nspluginwrapper should exclude native x86_64 plugins from wrapping
On Wed, Oct 12, 2011 at 11:24, Florian Hubold doktor5...@arcor.de wrote: Hey there, currently nspluginwrapper tries to wrap x86_64 plugins (like native x86_64 flash player plugin), but there is only i386 npviewer which is needed to run the plugins. I'm quite sure we used to have the x86-64 version too You can see the problem from the following output, which are a more verbose form of the scripts run through nspluginwrapper filetrigger: $ nspluginwrapper -v -i /usr/lib64/mozilla/plugins/libflashplayer.so *** NSPlugin Viewer *** ERROR: /usr/lib64/mozilla/plugins/libflashplayer.so: wrong ELF class: ELFCLASS64 nspluginwrapper: no appropriate viewer found for /usr/lib64/mozilla/plugins/libflashplayer.so In my and Anssi's opinion, nspluginwrapper.script (from nspluginwrapper filetrigger, http://svnweb.mageia.org/packages/cauldron/nspluginwrapper/current/SOURCES/nspluginwrapper.script?view=markup ) should be modified by excluding /usr/lib64. BTW the scripts run during is nspluginwrapper installation/removal get it right by only using /usr/lib: http://svnweb.mageia.org/packages/cauldron/nspluginwrapper/current/SPECS/nspluginwrapper.spec?view=markup Anybody more knowledgeable on nspluginwrapper care to share his opinion, or are there other reasons for objections? It used to be a good way to separate plugin execution into another process which is good for security/stability but browsers include that feature now Also are there good reasons to still use nspluginwraper for flash player at all, as all current browser support out-of-thread execution of plugins and flash-player-plugin is available as native i586 and x86_64 plugins? Indeed it is now less useful
Re: [Mageia-dev] require help to understand stage1/stage2/rescue source files
On Thu, Oct 20, 2011 at 17:40, Maarten Vanraes al...@rmail.be wrote: Op donderdag 20 oktober 2011 00:26:54 schreef Pascal Terjan: On Wed, Oct 19, 2011 at 21:36, Maarten Vanraes al...@rmail.be wrote: Hi, is there someone who can help me understand the stage1/stage2/rescue system? or point to some docs? i've looked at it, but it seems to be sometimes one source file used for both... it's really confusing me. Sources in mdk-stage1/ are used to build several binaries (including init, stage1 and rescue-gui) images/make_boot_img is used to generate the boot images which will include stage1 and busybox do i need to install busybox rpm before executing this script? I would suggest that you look at the drakx-installer-images rpm dependencies I usually build the rpm rescue/ is used to make rescue.sqfs image which contains a /etc/rc.sysinit which will prepare things and then run rescue-gui At the end stage1, if in rescue mode, the rescue image get loaded (from local cd, ftp, http, ...), mounted and the code is run (else same happens to stage2) by any chance, do you know where i can make these rescue menuitems? Without looking, I would say in rescue-gui.c but I may be wrong
Re: [Mageia-dev] require help to understand stage1/stage2/rescue source files
On Thu, Oct 20, 2011 at 17:41, Maarten Vanraes al...@rmail.be wrote: oh and can i test this rescue.sqfs somehow (without fucking up work system) or need i build an iso? You can place it somewhere, for example accessible over ftp or http in a directory called something/install/stage2, and boot an install image in a vm
Re: [Mageia-dev] Updating a new install is too long...
On Thu, Oct 27, 2011 at 15:47, Florian Hubold doktor5...@arcor.de wrote: Am 27.10.2011 16:02, schrieb Pierre Jarillon: Mageia 1 is a nice distribution and I install it on more and more PC. But updating after an install is very long, too much long. Now, 600 packages must be updated after an install. This shows a good health of Mageia but it is too much for users. My ADSL link is not very fast and a lot of people use a slower link. A workaround is necessary. There are two path: 1- publish each month a new iso: mageia-1a, mageia-1b, and so on 2- create an iso with updates: mageia-1-upd01, ... In each case, the sources of packages must be updated. You will find the volunteers who will join QA team to do the necessary quality assurance for the additional ISOs? Each month is not really feasible, as I believe it takes one week of work to build and test an iso. Doing it every 3 or 6 months could be a good idea
Re: [Mageia-dev] Updating a new install is too long...
On Thu, Oct 27, 2011 at 16:16, Florian Hubold doktor5...@arcor.de wrote: Am 27.10.2011 17:02, schrieb Pascal Terjan: On Thu, Oct 27, 2011 at 15:47, Florian Hubolddoktor5...@arcor.de wrote: Am 27.10.2011 16:02, schrieb Pierre Jarillon: Mageia 1 is a nice distribution and I install it on more and more PC. But updating after an install is very long, too much long. Now, 600 packages must be updated after an install. This shows a good health of Mageia but it is too much for users. My ADSL link is not very fast and a lot of people use a slower link. A workaround is necessary. There are two path: 1- publish each month a new iso: mageia-1a, mageia-1b, and so on 2- create an iso with updates: mageia-1-upd01, ... In each case, the sources of packages must be updated. You will find the volunteers who will join QA team to do the necessary quality assurance for the additional ISOs? Each month is not really feasible, as I believe it takes one week of work to build and test an iso. Doing it every 3 or 6 months could be a good idea Well, the second proposal should not really take a whole week to do, no? Just create an iso from $repo_updates and merge all those into one if there's enough space on the CD. First you need to make it fit on the CD (which is unlikely to be easy given that dependencies got added in updates) Then you need to test that installation still works fine in different configurations as some libraries used by the tools got updated But then, i fail to see the difference between doing a default install, and installing 600 updates from repos, or downloading an ISO with those updates. The difference is between: - downloading one iso, burning it, installing it, downloading 600 packages then installing it on another computer, downloading 600 packages - downloading one iso, burning it, installing it then installing it on another computer
Re: [Mageia-dev] Updating ruby to 1.9.3?
On Mon, Oct 31, 2011 at 06:12, Funda Wang fundaw...@gmail.com wrote: Hello, After reading this: http://www.ruby-lang.org/en/news/2011/10/06/plans-for-1-8-7 We will support mageia 2 for 18 months (May 2012 to Nov 2013). But upstream will end ruby 1.8.7 at the time of June 2013. That means, we won't have any support from upstream even for security issues from June 2013 to Nov 2013. Of course, if mageia 2 be delayed Should we update ruby into 1.9 so that we still have support from upstream? Especially the answer from current maintainer pascal. I had started updated to 1.9.2 but only spent a few hours on it and did not finish I think it would be better to have it but I can not decide before studying the impact If someone wants to work on it, Patch0 can be dropped and replaced with this option to configure: - --with-sitedir=%_prefix/lib/ruby/site_ruby \ - --with-vendordir=%_prefix/lib/ruby/vendor_ruby \ + --with-rubylibprefix=%_prefix/lib/ruby \
Re: [Mageia-dev] Preparing Alpha 1 isos of Mageia2
On Wed, Nov 23, 2011 at 15:34, philippe makowski makowski.mag...@gmail.com wrote: 2011/11/23 Funda Wang fundaw...@gmail.com: The problem is, why we are shipping a dead package? Dead ? https://bitbucket.org/troorl/pino3/ not sure it is dead It is dead as in build errors reported 1 year ago have not been fixed yet even if the developer commits a few changes every few months and patches are available in the bug tracker. See https://bitbucket.org/troorl/pino3/issue/17/build-error#comment-472096 for example or https://bitbucket.org/troorl/pino3/issue/4/patch-for-some-more-ambiguous-reference The developper has been quite active when he started the project in september 2010, again at christmas last year, and spent a few hours on it every few months since... I would not expect a working release before a few years if it ever happens...
Re: [Mageia-dev] Teamviewer and X86_64 build . . .
On Tue, Nov 29, 2011 at 11:08, Robert Fox l...@foxconsult.net wrote: On Tue, 2011-11-29 at 11:05 +0100, nicolas vigier wrote: On Tue, 29 Nov 2011, Robert Fox wrote: If you watch what the other major distros are doing related to this topic - it may give a hint. I am NOT advocating that we have to be like them, I believe we need to offer the ability and the choice. Yes, it can give a hint : - fedora does not provide any teamviewer package - opensuse does not provide any teamviewer package - debian does not provide any teamviewer package - ubuntu does not provide any teamviewer package Agreed. I just meant, if the package provided by the proprietary supplier does not work - then we should help ensure it does or make our own that works for those of us that needs such programs. Maybe we should have a voting system for our user base - like a wish list, and if enough people ask for it - we could consider it? I don't like such system. If many people want something, it does not mean that this is a good idea and that there is not a better way to do it. People just vote for an idea that someone else wrote that would workaround their current problem instead of reporting what is really their problem so that we can fix it. A place to discuss request is IMHO more useful than a place to vote for them.
Re: [Mageia-dev] RFC: Improvements for ioquake3 package and related games
On Wed, Nov 30, 2011 at 08:58, zezinho lists.jjo...@free.fr wrote: 1.Will the download have a nice window? I mean download speed/time till end, stop button, etc. Because this are big downloads, not like flash-player-plugin. 2. As user, I would expect the download to happen at install time, rather than first run. It could be run in the post? But what happens if the download fails in %post? You will end up with the package installed and the game not usable At least in %pre it will prevent the package from installing, but this will fail all the transaction
Re: [Mageia-dev] rpm macro help! %apply_patches
On Thu, Dec 1, 2011 at 09:58, Colin Guthrie mag...@colin.guthr.ie wrote: Hi, There are times when the backup files from patches applied with %apply_patches get in the way. It would be nice to be able to disable backup file generation. e.g. with %apply_patches -n Can someone with the appropriate skills do this? I can't remember who wrote this macro (I wrote the very crappy initial version of it and someone else made it awesome!), but I have a feeling it was pterjan or Annsi (or maybe it was pixel before he left...?). Anyway, it's a super useful macro, but it would be really nice if it could avoid the backups. I think it was pixel Or another suggestion. who actually uses these backup files? Perhaps they can just be dropped completely? I use them when updating patches
Re: [Mageia-dev] rpm macro help! %apply_patches
On Thu, Dec 1, 2011 at 10:28, Colin Guthrie mag...@colin.guthr.ie wrote:
'Twas brillig, and Pascal Terjan at 01/12/11 10:19 did gyre and gimble:
On Thu, Dec 1, 2011 at 09:58, Colin Guthrie mag...@colin.guthr.ie wrote:
Hi,
There are times when the backup files from patches applied with
%apply_patches get in the way. It would be nice to be able to disable
backup file generation. e.g. with %apply_patches -n
Can someone with the appropriate skills do this? I can't remember who
wrote this macro (I wrote the very crappy initial version of it and
someone else made it awesome!), but I have a feeling it was pterjan or
Annsi (or maybe it was pixel before he left...?). Anyway, it's a super
useful macro, but it would be really nice if it could avoid the backups.
I think it was pixel
Yeah, I think I remember now. It was a parting gift before he left :)
Or another suggestion. who actually uses these backup files? Perhaps
they can just be dropped completely?
I use them when updating patches
OK, so a more graceful way is needed to deal with the situation when the
patches are problematic (i.e. a dump installer just installing all the
files it finds.
My work around is just a simple:
find -name *.[0-9][0-9][0-9][0-9] -delete
but it could be too greedy in some circumstances.
So I guess an rpmmacro guru is needed.
I think we can have an option quite easily but I don't want to learn lua :)
%apply_patches %{lua: keys = {}; for i, p in ipairs(patches) do
print(rpm.expand(%{_patch} -s -p1 -b --suffix ..
string.format(.%04d, patches_num[p]) ..
--fuzz=%{_default_patch_fuzz} -i .. p .. \\n)) end }
Re: [Mageia-dev] Buildsystem stalled?
On Fri, Dec 2, 2011 at 07:39, Funda Wang fundaw...@gmail.com wrote: Hello, Is the build system currently stalled? Several failure packages do not show error logs. Yes sorry, I broke it for noarch packages last night while fixing the race causing some kernel packages to be missing, fixed now
Re: [Mageia-dev] Buildsystem stalled?
On Fri, Dec 2, 2011 at 08:21, Pascal Terjan pter...@gmail.com wrote: On Fri, Dec 2, 2011 at 07:39, Funda Wang fundaw...@gmail.com wrote: Hello, Is the build system currently stalled? Several failure packages do not show error logs. Yes sorry, I broke it for noarch packages last night while fixing the race causing some kernel packages to be missing, fixed now Actually I fixed the noarch packages failing to be detected as built and blocking the queue, but not the log collection, will have a look soon
Re: [Mageia-dev] How broken are RPM dependencies allowed to be?
On Wed, Dec 14, 2011 at 09:14, Dan Fandrich d...@coneharvesters.com wrote: On Wed, Dec 14, 2011 at 09:49:15AM +0200, Buchan Milne wrote: This is unsupported. Maybe you should instead contribute documentation that makes this more explicitly obvious, but it is a well-known rule in Mandriva and Mageia (and usually applies to other distros as well). I can understand that my particular case is unsupported, but I described a different, supported, scenario that would also fail due to this problem. To reiterate, a distribution upgrade from 1 to 2 (once it's finalized) could involve urpmi first upgrading the perl-dependent package but avoid installing the new perl itself until the end of the upgrade, which could be hours or (if interrupted) days later. During an upgrade urpmi starts by updating what it uses (perl, rpm, few other things, itself) and then restarts. During the entirety of that time, that package would be unusable. If that package happened to be a key CGI script for a web site, the entire site would be down for that entire time. That would not be prevented. The result would be that you need to install thousands of packages in the same transaction as they are all required by each other, and nothing would prevent your CGI from being at the end of the transaction which will happen hours or days later. If this weren't the case, there wouldn't be a need for backports ... Backports are nice in that they are leaf packages that don't generally require a ton of newer libraries be installed as well. Installing a single package of any complexity from a newer distribution often results in a cascading series of new packages to resolve all the dependencies. But it's often expeditious to upgrade simpler packages in that way in cases when the system can't completely upgraded right away. It's possible to handle that kind of case reliably, but I understand that it would be more work to get the dependencies just right. Many library authors put plenty of effort into maintaining binary compatibility across releases just so this sort of thing is possible. But even if this isn't an officially-supported mode of operation, problems like the one I described above can still result in broken systems if the dependencies aren't correctly described. Installing packages individually from one release on another release is not supported. Either upgrade the entire distro first, or stick to packages from the version you are on. However 'upgrade from release to Cauldron', when done correctly, should usually work as expected. Yes, usually. Is Mageia the operating system that works reliably 95% of the time? But, in supported use cases, urpmi *does* ensure that all the pieces to keep urpmi are upgraded in one transaction. But only if the dependencies are set correctly. And my original bug report on that has just now been closed as WONTFIX. Supporting the use case of installing any random package from a different release will take more effort than just adding and maintaining a version on one perl-base dependency. Yes, it will, but it can be automated to a certain extent. There just has to be a will to make sure that even the corner cases work. Dan
Re: [Mageia-dev] How broken are RPM dependencies allowed to be?
On Wed, Dec 14, 2011 at 19:19, Dan Fandrich d...@coneharvesters.com wrote: On Wed, Dec 14, 2011 at 11:30:33AM +, Pascal Terjan wrote: On Wed, Dec 14, 2011 at 09:14, Dan Fandrich d...@coneharvesters.com wrote: I can understand that my particular case is unsupported, but I described a different, supported, scenario that would also fail due to this problem. To reiterate, a distribution upgrade from 1 to 2 (once it's finalized) could involve urpmi first upgrading the perl-dependent package but avoid installing the new perl itself until the end of the upgrade, which could be hours or (if interrupted) days later. During an upgrade urpmi starts by updating what it uses (perl, rpm, few other things, itself) and then restarts. That has nothing to do with the problem in general. This same issue could occur with any package that relies on a newer library (even just a newer point version) but without mentioning that newer library version as a versioned require. That's the more general issue of which my perl-using example was but one example. During the entirety of that time, that package would be unusable. If that package happened to be a key CGI script for a web site, the entire site would be down for that entire time. That would not be prevented. The result would be that you need to install thousands of packages in the same transaction as they are all required by each other, and nothing would prevent your CGI from being at the end of the transaction which will happen hours or days later. All packages are not required by each other. On my system, 13% of packages are leaves that nothing depends on. 15% depend on nothing other than glibc, libstdc++ or bash. Another 14% have a single other dependency, in most cases a tightly-coupled library built from the same source code. So trying to argue that a transaction must install thousands of packages is specious. And RPM's installation sequence is designed to minimize the window when software is unusable during an upgrade. 13% of packages may be leaves that nothing depends on, but they will depend on something and need to be updated at the same time that what they depend on, so this is not relevant. Then you list 29% not depending on much other things, meaning 71% have more dependencies.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release kadu-0.10.1-1.mga2
Hi funda, It seems you added subpackage module-mediaplayer_mpris with a requires on mpris = 1.0, there is not such dependency in the distribution and I don't know what it is supposed to be given that MPRIS is a generic api
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release kwooty-0.8.0-2.mga2
On Fri, Dec 30, 2011 at 07:34, Mageia Team buildsystem-dae...@mageia.org wrote: Name : kwooty Relocations: (not relocatable) Version : 0.8.0 Vendor: Mageia.Org Release : 2.mga2 Build Date: Fri Dec 30 08:27:13 2011 Install Date: (not installed) Build Host: ecosse Group : Networking/File transfer Source RPM: (none) Size : 247809 License: GPLv2 Signature : (none) Packager : Mageia Team http://www.mageia.org URL : http://kwooty.sourceforge.net/ Summary : A friendly nzb Usenet binary downloader This package requires unrar from nonfree. The possible solutions: - Replace the Requires with a Suggests if it can work without unrar - Move kwooty to nonfree if it is not usable without unrar - Require the free unrar from http://download.gna.org/unrar/ which I think is useless as it can not open recent rar files
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release kadu-0.10.1-1.mga2
On Fri, Dec 30, 2011 at 21:21, Kamil Rytarowski n...@gmx.com wrote: W dniu 30.12.2011 22:13, Pascal Terjan pisze: Hi funda, It seems you added subpackage module-mediaplayer_mpris with a requires on mpris= 1.0, there is not such dependency in the distribution and I don't know what it is supposed to be given that MPRIS is a generic api This is my package (or the package of kicer86) - we are waiting for a new feature in find-lang to implement (--with-qt) and then we will rework the Funda's changes. Until then it will not be reedited. Why? This seems to be an unrelated problem, what prevents fixing it now?
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release kadu-0.10.1-1.mga2
On Fri, Dec 30, 2011 at 21:24, Kamil Rytarowski n...@gmx.com wrote: W dniu 30.12.2011 22:21, Kamil Rytarowski pisze: W dniu 30.12.2011 22:13, Pascal Terjan pisze: Hi funda, It seems you added subpackage module-mediaplayer_mpris with a requires on mpris= 1.0, there is not such dependency in the distribution and I don't know what it is supposed to be given that MPRIS is a generic api This is my package (or the package of kicer86) - we are waiting for a new feature in find-lang to implement (--with-qt) and then we will rework the Funda's changes. Until then it will not be reedited. And this package had to be svn-locked... Why?
Re: [Mageia-dev] [packages-commits] [188982] fixed desktop file patch
On Sat, Dec 31, 2011 at 09:51, Matteo pasotti.mat...@gmail.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 30/12/2011 12:43, D.Morgan ha scritto:
On Fri, Dec 30, 2011 at 12:43 PM, r...@mageia.org wrote:
Revision 188982 Author matteo Date 2011-12-30 12:43:10 +0100 (Fri, 30 Dec
2011)
Log Message
fixed desktop file patch
Modified Paths
cauldron/rmanage/current/SPECS/rmanage.spec
Modified: cauldron/rmanage/current/SPECS/rmanage.spec
===
--- cauldron/rmanage/current/SPECS/rmanage.spec 2011-12-30 11:42:03
UTC (rev
188981)
+++ cauldron/rmanage/current/SPECS/rmanage.spec 2011-12-30 11:43:10
UTC (rev
188982)
@@ -7,7 +7,7 @@
Url: http://rmanage.googlecode.com/
Group: Networking/Other
Source:
http://rmanage.googlecode.com/files/%{name}-%{version}.tar.gz
-Patch: %{name}-desktopfile.patch.bz2
+Patch: %{name}-desktop.patch.bz2
Summary: A network discovery and management tool
BuildRequires: desktop-file-utils
BuildRequires: gtk2-devel
please unzip patches
Ok, I was following the warnings coming from rpmlint.
Regards,
There should not be any warnings for patches
Re: [Mageia-dev] rpmlint
On Sat, Dec 31, 2011 at 14:28, Olivier Blin mag...@blino.org wrote: Florian Hubold doktor5...@arcor.de writes: Am 31.12.2011 14:26, schrieb Johnny A. Solbu: On Saturday 31 December 2011 11:34, Matteo wrote: Install rpmlint-mageia-policy. Yeap, my fault (I rebuilt my vm and I missed this package). Is it an idea to have rpmlint-mageia-policy added as a suggested package in rpmlint? Then packagers who forget to install it when (re)installing rpmlint will get a small notice that they are missing this pakcage. IIRC misc is against that, especially in the form of suggests. Then we could add it as a require in rpmbuild, if misc wants to keep our rpmlint package untouched. It would make sense to me.
Re: [Mageia-dev] rpmlint
On Sun, Jan 1, 2012 at 15:58, Pascal Terjan pter...@gmail.com wrote: On Sat, Dec 31, 2011 at 14:28, Olivier Blin mag...@blino.org wrote: Florian Hubold doktor5...@arcor.de writes: Am 31.12.2011 14:26, schrieb Johnny A. Solbu: On Saturday 31 December 2011 11:34, Matteo wrote: Install rpmlint-mageia-policy. Yeap, my fault (I rebuilt my vm and I missed this package). Is it an idea to have rpmlint-mageia-policy added as a suggested package in rpmlint? Then packagers who forget to install it when (re)installing rpmlint will get a small notice that they are missing this pakcage. IIRC misc is against that, especially in the form of suggests. Then we could add it as a require in rpmbuild, if misc wants to keep our rpmlint package untouched. It would make sense to me. Actually, what about rpm-mageia-setup-build ?
[Mageia-dev] Emails
Sorry, sent it initially to the wrong mailing list. Following a little change last night: - Packager field of rpms is now login login (for example pterjan pterjan) - Mails on changelog email are from login buildsystem-dae...@mageia.org - You should receive an email when a package you submitted fails to build
Re: [Mageia-dev] Emails
On Mon, Jan 2, 2012 at 16:39, Balcaen John mik...@mageia.org wrote: Le lundi 2 janvier 2012 13:34:05, Pascal Terjan a écrit : Sorry, sent it initially to the wrong mailing list. Following a little change last night: - Packager field of rpms is now login login (for example pterjan pterjan) - Mails on changelog email are from login buildsystem-dae...@mageia.org - You should receive an email when a package you submitted fails to build Only when it failed to build or also when it was rejected by the BS ? Iurt only sends on build failure I think youri should send it on reject but I did not check if it works
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2
On Tue, Jan 3, 2012 at 21:05, Anssi Hannula an...@mageia.org wrote: On 02.01.2012 12:21, guillomovitch wrote: Name : dsniff Relocations: (not relocatable) Version : 2.4 Vendor: Mageia.Org Release : 0.b1.1.mga2 Build Date: Mon Jan 2 11:18:17 2012 Install Date: (not installed) Build Host: ecosse Group : Monitoring Source RPM: (none) Size : 210074 License: BSD Signature : (none) Packager : guillomovitch guillomovitch URL : http://www.monkey.org/~dugsong/dsniff/ Summary : Network audit tools Description : Tools to audit network and to demonstrate the insecurity of cleartext network protocols. Please do not abuse this software. guillomovitch guillomovitch 2.4-0.b1.1.mga2: + Revision: 189630 - drop epoch, we don't care about updating from mdv anymore We don't? Previous upgraders like me still have dsniff-2.4-0.b2.14mdv2010.1 on their MGA1 / cauldron systmes, which won't get upgraded to the MGA package without epoch. IMHO the epoch should be added. Also, not your fault but it seems genhdlist didn't handle the removal of epoch without altering rpm file name well, hdlists still show the epoch, causing urpmi to try upgrading to the now epoch-less version, causing the transaction to be rejected by rpm. Yes genhdlist2 only considers the filename to decide if a package was added/removed, and keeps the header if filename didn't change
Re: [Mageia-dev] BS down for now
On Wed, Jan 4, 2012 at 09:57, Michael Scherer m...@zarb.org wrote: Hi, as signaled by jq and mikala, the BS is down for the moment, a issue with chroot. It sems perl(URPM) is no longer provided ( and urpmi provide perl(urpm) instead ), and therefore, we cannot install basesystem. Sysadmins are looking at the problem, we will keep you updated. It seems the package had been removed from the mirrors (investigation in progress), it has been restored and build system should work fine.
[Mageia-dev] List of CVE referencing software versions present in Mageia 1
Here is the output of a little script I just wrote. Vulnerable version, please check that a patch was applied if needed * arora 0.11.0 - CVE-2011-3367 * bind 9.8.0 - CVE-2011-1907 - CVE-2011-1910 - CVE-2011-2464 - CVE-2011-2465 - CVE-2011-4313 * cherokee 1.0.19 - CVE-2011-2190 - CVE-2011-2191 * conky 1.8.1 - CVE-2011-3616 * cups 1.4.6 - CVE-2011-2896 - CVE-2011-3170 * dbus 1.4.1 - CVE-2011-2200 * dhcp 4.2.1 - CVE-2011-0997 - CVE-2011-2748 - CVE-2011-2749 - CVE-2011-4539 * drupal 7.0 - CVE-2011-2687 - CVE-2011-3730 * empathy 2.34.0 - CVE-2011-3635 - CVE-2011-4170 * etherape 0.9.10 - CVE-2011-3369 * fuse 2.8.5 - CVE-2011-0541 - CVE-2011-0542 - CVE-2011-0543 * ganglia 3.1.7 - CVE-2011-3741 * gdm 2.32.1 - CVE-2011-1709 * gimp 2.6.11 - CVE-2011-1178 - CVE-2011-1782 * glibc 2.12.1 - CVE-2011-1071 - CVE-2011-1089 - CVE-2011-1095 - CVE-2011-1658 - CVE-2011-1659 * glpi 0.78.2 - CVE-2011-2720 * icinga - CVE-2011-2179 * jasper 1.900.1 - CVE-2011-4516 - CVE-2011-4517 * keepalived 1.2.2 - CVE-2011-1784 * kernel 2.6.38.8 - CVE-2011-0726 - CVE-2011-1170 - CVE-2011-1171 - CVE-2011-1172 - CVE-2011-1173 - CVE-2011-1771 - CVE-2011-1776 - CVE-2011-2184 - CVE-2011-2213 - CVE-2011-2484 - CVE-2011-2492 - CVE-2011-2497 - CVE-2011-2534 - CVE-2011-2689 - CVE-2011-2695 - CVE-2011-2700 - CVE-2011-2723 - CVE-2011-2928 * libgnomesu 1.0.0 - CVE-2011-1946 * libsndfile 1.0.23 - CVE-2011-2696 * libsoup 2.32.2 - CVE-2011-2524 * libuser 0.56.18 - CVE-2011-0002 * libvirt 0.9.0 - CVE-2011-2178 - CVE-2011-2511 * libxml 1.8.17 - CVE-2011-1944 * linux - CVE-2011-2162 * logrotate 3.7.9 - CVE-2011-1098 - CVE-2011-1154 - CVE-2011-1155 * mailman 2.1.13 - CVE-2011-0707 * mapserver 5.6.6 - CVE-2011-2703 - CVE-2011-2704 - CVE-2011-2975 * nagios 3.2.3 - CVE-2011-1523 * ncpfs 2.2.6 - CVE-2011-1679 - CVE-2011-1680 * openafs 1.4.14 - CVE-2011-0430 - CVE-2011-0431 * openbsd - CVE-2011-2895 * openldap 2.4.25 - CVE-2011-4079 * openssl 1.0.0d - CVE-2011-1945 - CVE-2011-3207 - CVE-2011-3210 * openswan 2.6.28 - CVE-2011-4073 * openttd 1.1.0 - CVE-2011-3341 - CVE-2011-3342 - CVE-2011-3343 * oprofile 0.9.6 - CVE-2011-1760 - CVE-2011-2471 - CVE-2011-2472 - CVE-2011-2473 * perl 5.12.3 - CVE-2011-1487 * php 5.3.6 - CVE-2011-1148 - CVE-2011-1657 - CVE-2011-1938 - CVE-2011-2202 - CVE-2011-2483 - CVE-2011-3182 - CVE-2011-3267 - CVE-2011-3268 - CVE-2011-4885 * pidgin 2.7.11 - CVE-2011-2943 - CVE-2011-3184 - CVE-2011-3185 - CVE-2011-4601 - CVE-2011-4602 - CVE-2011-4603 * plib 1.8.5 - CVE-2011-4620 * prosody 0.7.0 - CVE-2011-2205 * puppet 2.6.8 - CVE-2011-3848 - CVE-2011-3869 - CVE-2011-3870 - CVE-2011-3871 * puppet_enterprise_users - CVE-2011-3872 * python 2.7.1 - CVE-2011-1521 * quagga 0.99.18 - CVE-2011-3323 - CVE-2011-3324 - CVE-2011-3325 - CVE-2011-3326 - CVE-2011-3327 * quassel 0.7.2 - CVE-2011-3354 * rekonq 0.7.0 - CVE-2011-3366 * rsyslog 5.6.2 - CVE-2011-3200 * ruby 1.8.7.p334 - CVE-2011-4815 * samba 3.5.8 - CVE-2011-1678 - CVE-2011-2522 - CVE-2011-2694 - CVE-2011-2724 * squid 3.1.15 - CVE-2011-4096 * systemtap 1.3 - CVE-2011-1769 * t1lib 5.1.2 - CVE-2011-0764 - CVE-2011-1552 - CVE-2011-1553 - CVE-2011-1554 * tmux 1.4 - CVE-2011-1496 * vino 2.32.1 - CVE-2011-0904 - CVE-2011-0905 * weechat 0.3.0 - CVE-2011-1428 * wireshark 1.4.6 - CVE-2011-1957 - CVE-2011-1958 - CVE-2011-1959 - CVE-2011-2174 - CVE-2011-2175 - CVE-2011-2597 - CVE-2011-2698 - CVE-2011-3360 - CVE-2011-4101 - CVE-2011-4102 * wordpress 3.1.1 - CVE-2011-3122 - CVE-2011-3125 - CVE-2011-3126 - CVE-2011-3127 - CVE-2011-3128 - CVE-2011-3129 - CVE-2011-3130 * xen 4.1.0 - CVE-2011-1583 - CVE-2011-1898 - CVE-2011-3262 Maybe vulnerable * phpmyadmin 3.3.10: - CVE-2011-3181: 3.3.10.3 3.3.10.0 3.3.10.1 3.3.10.2 - CVE-2011-2506: 3.3.10.0 3.3.10.1 - CVE-2011-2507: 3.3.10.0 3.3.10.1 - CVE-2011-2508: 3.3.10.0 3.3.10.1 - CVE-2011-4107: 3.3.10.3 3.3.10.4 3.3.10.0 3.3.10.1 3.3.10.2 - CVE-2011-2642: 3.3.10.1 3.3.10.2 3.3.10.0 - CVE-2011-2719: 3.3.10.1 3.3.10.2 3.3.10.0 - CVE-2011-2505: 3.3.10.0 3.3.10.1 * glibc 2.12.1: - CVE-2011-0536: 2.12.1.7.el6_0.3 * policykit 0.9: - CVE-2011-1485: 0.96
Re: [Mageia-dev] mirror problem ?
On Fri, Jan 6, 2012 at 15:58, philippe makowski makowski.mag...@gmail.com wrote: Hi, am I the only one that can't do updates since yesterday ? I get this message : erreur: /var/cache/urpmi/partial/autocorr-fr-3.4.4.2-0.3.mga1.noarch.rpm: not an rpm package erreur: /var/cache/urpmi/partial/libreoffice-opensymbol-fonts-3.4.4.2-0.3.mga1.noarch.rpm: not an rpm package erreur: /var/cache/urpmi/partial/libreoffice-xsltfilter-3.4.4.2-0.3.mga1.x86_64.rpm: not an rpm package erreur: /var/cache/urpmi/partial/libreoffice-pyuno-3.4.4.2-0.3.mga1.x86_64.rpm: not an rpm package http://mirrors.mageia.org/api/mageia.1.x86_64.list: media/../../i586/media/core/updates/libreoffice-opensymbol-fonts-3.4.4.2-0.3.mga1.noarch.rpm http://mirrors.mageia.org/api/mageia.1.x86_64.list: media/../../i586/media/core/updates/autocorr-fr-3.4.4.2-0.3.mga1.noarch.rpm erreur: /var/cache/urpmi/partial/libreoffice-opensymbol-fonts-3.4.4.2-0.3.mga1.noarch.rpm: not an rpm package erreur: /var/cache/urpmi/partial/autocorr-fr-3.4.4.2-0.3.mga1.noarch.rpm: not an rpm package L'installation a échoué à cause de paquets bogués : http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/1/x86_64/media/core/updates/libreoffice-xsltfilter-3.4.4.2-0.3.mga1.x86_64.rpm http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/1/i586/media/core/updates/libreoffice-opensymbol-fonts-3.4.4.2-0.3.mga1.noarch.rpm http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/1/x86_64/media/core/updates/libreoffice-pyuno-3.4.4.2-0.3.mga1.x86_64.rpm http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/1/i586/media/core/updates/autocorr-fr-3.4.4.2-0.3.mga1.noarch.rpm The first package is valid here: [pterjan@coin dr]$ wget http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/1/x86_64/media/core/updates/libreoffice-xsltfilter-3.4.4.2-0.3.mga1.x86_64.rpm --2012-01-06 17:10:06-- http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/1/x86_64/media/core/updates/libreoffice-xsltfilter-3.4.4.2-0.3.mga1.x86_64.rpm R�solution de distrib-coffee.ipsl.jussieu.fr (distrib-coffee.ipsl.jussieu.fr)... 134.157.176.20 Connexion vers distrib-coffee.ipsl.jussieu.fr (distrib-coffee.ipsl.jussieu.fr)|134.157.176.20|:80...connect�. requ�te HTTP transmise, en attente de la r�ponse...200 OK Longueur: 187713 (183K) [text/plain] Sauvegarde en : �libreoffice-xsltfilter-3.4.4.2-0.3.mga1.x86_64.rpm� 100%[===] 187 713 65,2K/s ds 2,8s 2012-01-06 17:10:09 (65,2 KB/s) - �libreoffice-xsltfilter-3.4.4.2-0.3.mga1.x86_64.rpm� sauvegard� [187713/187713] [pterjan@coin dr]$ rpm -qp libreoffice-xsltfilter-3.4.4.2-0.3.mga1.x86_64.rpm libreoffice-xsltfilter-3.4.4.2-0.3.mga1
Re: [Mageia-dev] Orphans - those poor orphans . . .
On Sat, Jan 7, 2012 at 16:48, Thomas Spuhler tho...@btspuhler.com wrote: On Friday, January 06, 2012 12:57:39 PM Sander Lepik wrote: 06.01.2012 21:06, Dale Huckeby kirjutas: Evidently once I've installed package A which requests X, sometimes packages F, L, and T might subsequently get installed which also need X *and presumably would have requested it had it not already been installed*. But when I uninstall A it orphans X because A is the only package that *requested* it. When F, L, and T are installed can't all the packages they *would have requested* be marked whether or not they're already installed? That way a package would be orphaned only when the last package that needs it is uninstalled? Or am I missing something? This is already so. See example: http://pastebin.com/AMj87QiV - after first urpme libplasmaweather4 should be marked as orphan but it's not as it's still required by other package. -- Sander It seems to me, auto-orphans gives more headaches than benefits. Why are we clinching to it? Because I and meany other people finding it useful never faced any problems on their machine with it. The only problems I can remember are: - people wanted to remove some things required by task-kde, which implied removing task-kde, and then all of kde was orphan. I think many things were move to suggests since - some kind of install was installing packages requested by nothing and they were not marked as requested so they were listed as orphans, but this was fixed long ago
Re: [Mageia-dev] Orphans - those poor orphans . . .
On Sat, Jan 7, 2012 at 14:24, Wolfgang Bornath molc...@googlemail.com wrote: 2012/1/7 Sander Lepik sander.le...@eesti.ee: 07.01.2012 13:39, Wolfgang Bornath kirjutas: Of course this is one way to find bugs in packages. But what about the documented (in German) case where - after fresh installation, reboot (ok) and updates right after installation I was presented with a list of more than 100 orphans. - I ran 'urpme --auto-orphans' and rebooted - several system services (which started successfully after installation) refused to start now because of missing files Of course urpmi was not the culprit because it only checks dependencies. But that did matter in that situation. The auto-orphans function obviously listed packages which may have no dependencies but are needed by the system. That's why I do not complain about urpmi but about the whole function. As long as this function is only based on package dependencies it is not safe to use it. Did you choose custom install and unchecked some options? Or did you use LiveCD maybe? Anyway.. function is not to blame. Next time copy those packages that are going to be uninstalled. And they can be rechecked. Which are needed and why they get orphaned. Used the full DVD (32-bit) Mageia 2 Alpha 2 - minimal install with X - after installation and reboot everything was ok - setup the package media (dedicated mirror) and did 'urpmi -auto-update' - I did NOT install or remove one single package manually - after that urpmi showed a list of more than 100 orphans - used 'urpme -auto-orphans - at reboot the start messages showed several errors concerning crond, network-up, postfix, display manager, etc. - system start stopped before x was started. Repeated the boot process with same result. A side question is why I got so many orphans in a minimal system with only around 700 packages in total and only around 2 or 3 dozens of updates (all this happened not long after Alpha 2 release.) Of course urpmi is not the culprit, it is the shortcomings of the function as it is. It should just not be there if its use could lead to such behavior, no matter where the cause comes from. Simply said: a gasoline brand should not be sold if it could do damage to the car's motor, no matter which of the components of the fluid causes the damage.. Anyhow, I will repeat the same operation when Alpha 2 is released in a couple of days and as soon as the system shows orphans I will document that list and (if the same problem arises) dmesg output if available. What else do you need for a reasonable documentation? Thanks, this is obviously an installation bug as those packages should be listed as requested.
Re: [Mageia-dev] Orphans - those poor orphans . . .
On Sun, Jan 8, 2012 at 16:04, ptyxs pt...@free.fr wrote: Le 08/01/2012 16:59, Pascal Terjan a écrit : On Sat, Jan 7, 2012 at 16:48, Thomas Spuhlertho...@btspuhler.com wrote: On Friday, January 06, 2012 12:57:39 PM Sander Lepik wrote: 06.01.2012 21:06, Dale Huckeby kirjutas: Evidently once I've installed package A which requests X, sometimes packages F, L, and T might subsequently get installed which also need X *and presumably would have requested it had it not already been installed*. But when I uninstall A it orphans X because A is the only package that *requested* it. When F, L, and T are installed can't all the packages they *would have requested* be marked whether or not they're already installed? That way a package would be orphaned only when the last package that needs it is uninstalled? Or am I missing something? This is already so. See example: http://pastebin.com/AMj87QiV - after first urpme libplasmaweather4 should be marked as orphan but it's not as it's still required by other package. -- Sander It seems to me, auto-orphans gives more headaches than benefits. Why are we clinching to it? Because I and meany other people finding it useful never faced any problems on their machine with it. The only problems I can remember are: - people wanted to remove some things required by task-kde, which implied removing task-kde, and then all of kde was orphan. I think many things were move to suggests since - some kind of install was installing packages requested by nothing and they were not marked as requested so they were listed as orphans, but this was fixed long ago I recently installed Okular then i removed xpdf and then used auto-orphans : I immedialtely lost any possibility to use wifi... What would be useful would be to know what package was removed, and how it had been installed
Re: [Mageia-dev] urpmi installing src.rpm defaults to --buildrequires
On Sun, Jan 8, 2012 at 22:12, Maarten Vanraes al...@rmail.be wrote: Hi, i donno if it's me, but i noticed the following: [alien@localhost manaplus]$ /usr/sbin/urpmi /tmp/manaplus-1.1.5.1-4.mga1.src.rpm please use --buildrequires or --install-src, defaulting to --buildrequires ... i noticed something was wrong when i clicked on the .src.rpm file on the file browser and chose install the src.rpm file... I do believe it should default to --install-src ? Maybe it should depend if you are root
Re: [Mageia-dev] urpmi installing src.rpm defaults to --buildrequires
On Sun, Jan 8, 2012 at 23:25, Maarten Vanraes al...@rmail.be wrote: Op zondag 08 januari 2012 23:26:38 schreef Pascal Terjan: On Sun, Jan 8, 2012 at 22:12, Maarten Vanraes al...@rmail.be wrote: Hi, i donno if it's me, but i noticed the following: [alien@localhost manaplus]$ /usr/sbin/urpmi /tmp/manaplus-1.1.5.1-4.mga1.src.rpm please use --buildrequires or --install-src, defaulting to --buildrequires ... i noticed something was wrong when i clicked on the .src.rpm file on the file browser and chose install the src.rpm file... I do believe it should default to --install-src ? Maybe it should depend if you are root the thing is that defaulting to --buildrequires is not intuitive, ok, it's what you mostly use, but not what you expect if you're using urpmi. imho if you wanted the buildrequires; you'd exactly do that. I think urpmi used to always install buildrequires and have no option. The old behaviour remained as default. i imagine this also changes that in GUI and you're installing .src.rpm, it should NOT ask for superuser credentials... because it's not needed and definately not what you want. is this behavior changed recently, or was it always like this? It has always been like that as far as I remember
Re: [Mageia-dev] [RFC] Moving various packages/codecs to tainted
On Tue, Jan 10, 2012 at 03:20, Anssi Hannula an...@mageia.org wrote: The problem is that that balance was achieved by sticking packages in PLF/main/contrib semi-randomly. For example, H.264 decoders and MPEG-4 video encoders are in main/core, while e.g. AAC audio decoders are in PLF/tainted. If one'd put them into an order, IMO H.264 and MPEG-4 would be much more prominent and tainted candidates instead of AAC decoding... Also, in e.g. MPEG-4 case we have encoders both in core and in tainted, e.g. we have ffmpeg in core, but xvid in tainted. I agree we need rules, but being covered with patents does not make sense, as the patent owner may agree with using it in free software. I think something like No actively enforced patent in core would be good. I suppose you can't blame a US company like RedHat for being overly paranoid, but as you said, Mandriva hasn't had any problems. Are there any there examples out of there of distros trying to achieve this balance? Obviously we don't want to follow Ubuntu or ROSA in pretending patents don't exist. Linux Mint provides a No codecs CD: http://www.linuxmint.com/download.php Ubuntu has a patent policy (which basically IIRC says rights owner or packager, please contact us if you think there is an infringement, we will investgate): https://wiki.ubuntu.com/PatentPolicy Note also that the Ubuntu Live CD and therefore the default Ubuntu installation do not contain any codecs. By default Totem is installed, however, and gstreamer is plugged into gnome-codec-install (which seems really nice, do we use it?), so that wen you try to play an unsupported video the first time, it will prompt to install the codecs (it will also show a warning dialog about patents etc, but AFAICS this comes from gnome-codec-install itself, not Ubuntu). This looks nice
Re: [Mageia-dev] [RFC] Moving various packages/codecs to tainted
On Wed, Jan 11, 2012 at 12:56, Anssi Hannula an...@mageia.org wrote: On 10.01.2012 15:07, Pascal Terjan wrote: On Tue, Jan 10, 2012 at 03:20, Anssi Hannula an...@mageia.org wrote: The problem is that that balance was achieved by sticking packages in PLF/main/contrib semi-randomly. For example, H.264 decoders and MPEG-4 video encoders are in main/core, while e.g. AAC audio decoders are in PLF/tainted. If one'd put them into an order, IMO H.264 and MPEG-4 would be much more prominent and tainted candidates instead of AAC decoding... Also, in e.g. MPEG-4 case we have encoders both in core and in tainted, e.g. we have ffmpeg in core, but xvid in tainted. I agree we need rules, but being covered with patents does not make sense, as the patent owner may agree with using it in free software. I think something like No actively enforced patent in core would be good. Possibly, but how do you define that, exactly? Does a licensing program count as enforcing or do you mean something else? Yes, that's what I meant
Re: [Mageia-dev] Mageia 2 Alpha 3 available for tests
On Fri, Jan 13, 2012 at 15:37, Manuel Hiebel man...@hiebel.eu wrote: Hello, any news about the nonfree iso ? It is still non free, which means it was not released. (Sorry)
Re: [Mageia-dev] Working bug-buddy/abrt-like software?
On Sat, Jan 14, 2012 at 10:05, Olav Vitters o...@vitters.nl wrote: In https://bugs.mageia.org/show_bug.cgi?id=4088, gnome-shell process crashes due to a bug in libcogl. I'm seeing the same on my machine. However, as this in gnome-shell, it is pretty difficult to catch this. I have ABRT installed, but it relies on yum. It seems to include patches we had made for Mandriva, adapted for Mageia, so I would expect it to work
Re: [Mageia-dev] HAL daemon required for Mageia 2 alpha 3
On Sat, Jan 21, 2012 at 00:28, Pierre Jarillon jaril...@abul.org wrote: I have burn a DVD and make a fresh install in french. At the end of installation, I have asked yes for the updates. The bunch of hdlists was installed, bu nothing was updated. After the reboot, any urpmi fails with Daemon HAL (hald) not ready or available (free translation) I have manualy downloaded hal and its dependances (crypsetup, usbutils, hal- info, lib64hal1, lib64crypsetup4) and start hald. Then update was possible for more than 300 rpm. Upgrade from a previous alpha release seems to have no problem because hal is already installed. I thought that hal was no longer needed... Am I wrong? It is still used by urpmi to search cd drive :(
