Re: [Mageia-dev] Network issue with pm-suspend
Hi, To move between my home and work I swith off my computer using pm-suspend. But when I wake up my laptop, the network is not reset so previous IP and route remain (on both ethernet and wifi card). Pluging and unpluging the ethernet cable has no action and even an ifconfig down / ifconfig up does not make the ethernet sending a dhcp request. Am I the only one to have sucj issue ? Any idea about this issue ? on my worklaptop (mga2) i use suspend-to-disk, and after i have my screensaver, it seems to hang and take quite a while before the screensaver actually moves... (1min)? by that time, the network is down and after a little while after i log in, the wifi comes up with the new wifi connection... or did you use suspend-to-memory? (i used that too, for smaller times, but haven't switched locations in between suspends)
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release kernel-3.5.0-1.mga3
On 28 July 2012 05:11, tmb buildsystem-dae...@mageia.org wrote: tmb tmb 3.5.0-1.mga3: + Revision: 275103 - fix perf build with glibc-2.16 - fix unionfs build with 3.5 series kernels - rediff mrproper patch - update defconfigs - drop merged patches - rediff unionfs patch - add include/memory/ to -devel and -source filelists - update to 3.5 Could you enable fontswap zcache please? Thx also, not directly related, btrfs.fsck doesn't have a -a option, which means it's not executed at boot time, if needed...
Re: [Mageia-dev] Packagers meeting
On 27 June 2012 08:11, AL13N al...@rmail.be wrote: Our meeting will happen tomorrow evening at 19hUTC. Here are the proposed topics: - pending security updates - Mageia 3 features - Backports policy For the 2 last topics please read following links *before* meeting: https://www.mageia.org/pipermail/mageia-dev/2012-June/016819.html https://www.mageia.org/pipermail/mageia-dev/2012-June/016855.html Cheers can we have another talk of bug 2317? to find people willing to make a new patch that's quite more complex? ideally bug 2317 should be fixed before backports opens No, it's not related since you can't garanty that every user will get the update prior to use backports. So there's no need to rush... QA team told me that it would increase their workload dramatically, so i think there is need rush.
Re: [Mageia-dev] bug 2317 revisited: --update option should behave like --search-media
21.06.2012 13:35, AL13N kirjutas: B. fetch dependencies only from enabled repositories Problems: - if backports are enabled, dependencies could come from backports instead of release. Solutions for this: - this can be prevented in various ways: even as simple as the backport packager to bump an update with stricter requires so that the backport wouldn't be fetched (_IF_ it indeed would be incompatible) AND the update could have stricter requires for that new dependency. I still can't see how are you going to solve this case: I have backports enabled. There are packages that are newer than the one in release. I haven't installed them. Now new update requires such package that is both in release and in backports. Update will pull package from enabled backports as they are newer - i didn't want that. And you can't just submit new backport that blocks it. Older backports are still there. So you can install those if new backport doesn't work for you (the same we have for updates at the moment). IF the update cannot work with the backported new dependency, it should be strict required in the update. in that case, the one from release will be used. if the update does work with the backport, then i don't see why you wouldn't want that, since you enabled backports. == this sounds like cherry-picking backports. in other words, you're advanced enough to find out what you want, because i don't think we can support all forms of cherry-picking backports.
[Mageia-dev] Freeze push: task-lamp
task-lamp requires mysql I've changed it to mariadb instead (and added the mariadb-extra on task-lamp- extra as well (there was no mysql-extra))
Re: [Mageia-dev] Mageia 2 LiveCD contents...
Op zaterdag 05 mei 2012 07:37:12 schreef Mika Laitio: On 05/02/2012 12:28 AM, David Walser wrote: Pascal Terjan wrote: On Mon, Apr 30, 2012 at 19:42, John j...@neodoc.biz wrote: On Mon, 30 Apr 2012 17:59:13 +0200 zezinho wrote: Em 30-04-2012 16:28, Thomas Backlund escreveu: tvtime can be removed, as analog tv is going away almost everywhere. Everywhere is exactly where? Luxembourg, the Netherlands, Finland, Andorra, Sweden, Switzerland, Belgium, Germany, the United States, Norway, Denmark, Spain, Latvia, Estonia, Slovenia, Israel, Austria, Monaco, UK, Cyprus, Japan, Malta, France, Czech Republic, Arab World, Serbia, Canada, Brazil. Australia is doing it region by region. http://en.wikipedia.org/wiki/Analog_television#Transition_to_digital_bro adcasts tvtime is used for more than analog broadcast TV, so this is irrelevant. It probably doesn't need to be on the LiveCDs anyway, however. I agree, no need for being in livecd. But I for example need tvtime for being able to connect Wii to same display with my computer. My display does not have Wii compatible input connection, so I have connected my Wii to Technotrends dvb-t ff card on my computer and then I use tvtime for showing up the wii screen in my desktop. Mika ok, but is this something you will do with a livecd? i think you will install it, if it comes to this...
[Mageia-dev] advisories for rpmdrake
this bug report has been lying around for too long: https://bugs.mageia.org/show_bug.cgi?id=2223 ( rpmdrake doesn't show advisories) apparently it's pretty easy and the descriptions file just needs to be modified by the people who push the update. (is this sysadmin?) i think we just need to put this in the policy and have the people who push it put the advisory in this descriptions file on the mirrors. the only question i have is how does this get onto the mirrors? is there an svn file we can just modify so that the advisories become available? in any case, i'm planning on putting this in the policy once and for all, so that this minor bug is finally resolved. any objections?
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release btrfs-progs-0.19-1.20120328.1.mga2
Op zaterdag 28 april 2012 20:16:53 schreef Thomas Backlund: 27.04.2012 13:41, Thierry Vignaud skrev: On 22 April 2012 15:29, tmb buildsystem-dae...@mageia.org wrote: tmb tmb 0.19-1.20120328.1.mga2: + Revision: 232555 - update to 2012-03-28 snapshot * switch back to master branch as dangerdonteveruse branch is now merged You should add btrfsck to: perl-install/install/share/list.xml added. rescue/list.xml already there Also we still miss something to set UUID on btrfs partitions (see fs/format.pm) I dont know yet how... i noticed today that it tried to do fsck -a on the btrfs partition but btrfsck: -a option does not exist... i donno if it actually checks the partition or not though...
Re: [Mageia-dev] Release blocker bugs
Op donderdag 26 april 2012 17:14:27 schreef Thierry Vignaud: On 26 April 2012 16:35, Guillaume Rousse guillomovi...@gmail.com wrote: Please quote only what's needed next time. I humbly apologize for pasting at least 5 perfectly useless lines. Ops, I did it again ! Stop trolling. You quoted 52 lines for a 2 lines answer (which was only answering to the two last lines about spec-helper) i saw an attached file, not quoted lines...
Re: [Mageia-dev] microcode needed by default
Op zondag 22 april 2012 07:01:04 schreef simple w8: Hi, when booting i alwas saw that systemd was complaning about not being able to start service microcode.service (Description: LSB: Update the Intel / AMD CPU microcode). I made a research with urpmq and found the package microcode, i installed it and now theres no complains in systemd regarding microcode. perhaps it would be better to have the service in the packages itself... and get this to split off
Re: [Mageia-dev] RPM groups change: Productivity ?
Op zaterdag 21 april 2012 07:33:23 schreef Remco Rijnders: Hi all, I've just submitted taskwarrior, a command line tool to organise, prioritise, and track tasks etc. From the Fedora spec which I adopted, they have it in the group Applications/Productivity. We have no such group available on https://wiki.mageia.org/en/RPM_groups_policy . In the end I resorted to picking Text tools, but it just didn't feel right to me. As I have similar tools I'm thinking of packaging, as well as we have other tools in the distro such as taskcoach in Office, I think a Productivity category might be of use. What do you think? Remmy Since our license policy is fedora based, i see no problem with this group policy change
Re: [Mageia-dev] freeze push: linux ha cluster stack
Op vrijdag 20 april 2012 20:38:55 schreef Anne Nicolas: Le 20/04/2012 20:13, nicolas vigier a écrit : [...] - cluster (including cman, rmanager) : obsoleted upstream, pacemaker should be used instead : https://fedorahosted.org/cluster/wiki/HomePage cluster seems not to be deleted... see http://check.mageia.org/cauldron/dependencies.html [...] - openais : project seems dead (no website online anymore), and nothing require this (except cman from cluster package which we are dropping) ocfs2-tools seems to require openais-devel, and as such is now broken: see http://check.mageia.org/cauldron/dependencies.html
[Mageia-dev] broken dependencies are growing again...
plz look at: http://check.mageia.org/cauldron/dependencies.html == wrong strict versioned requires? (or not enough rebuilt packages) brasero == needs dropping: cluster == rebuild without the dropped openais? ocfs2-tools == missing perl modules: perl-Catalyst-Authentication-Credential-OpenID perl-JavaScript == likely need rebuild due to newer dependant libs: telepathy-qt4
Re: [Mageia-dev] broken dependencies are growing again...
Op zaterdag 21 april 2012 21:42:23 schreef Pascal Terjan: On Sat, Apr 21, 2012 at 20:15, Maarten Vanraes al...@rmail.be wrote: [...] == missing perl modules: perl-Catalyst-Authentication-Credential-OpenID perl-JavaScript Yes and we can't do more about them, we should probably just remove them from mirrors [...] iinm identity uses perl-Catalyst-Authentication-Credential-OpenID (or planned to at some point) besides, it points to perl-Catalyst-Engine-HTTP not being there. which seems to me (a novice) a more important package (unless renames or stuff)
[Mageia-dev] mysql CVE's in mga1 = have it update to mariadb
regarding bug https://bugs.mageia.org/show_bug.cgi?id=5260 after talking with mariadb people and some others, i'm proposing to update mysql 5.5.10 to mariadb-5.5.23 in mga1. however, QA should extra-double-test the php-mysql dependency, as mariadb noted that php-mysql seems to have a very strict versioning scheme sometimes and having a new mysql provider without rebuilding php-mysql often fails... in case of no objections, i'll go ahead with this.
Re: [Mageia-dev] mysql CVE's in mga1 = have it update to mariadb
Op vrijdag 13 april 2012 13:12:08 schreef AL13N: [] i guess most packagers want option 2 here. i don't think this is a good idea in general and i was of the opinion that the diff between migrating mysql 5.5.22 and mariadb 5.5.23 were quite the same... nonetheless, the package naming difference could have effects on it on a stable version, so i concede to this solution. however, i'll note that mariadb likely contains extra bugfixes, which this mysql 5.5.22 will not have. i guess this is the step where this is more or less decided and some packager steps in and does the actual work. any volunteers? perhaps that person can also become maintainer of it?
Re: [Mageia-dev] mysql CVE's in mga1 = have it update to mariadb
Op vrijdag 13 april 2012 18:19:14 schreef Thomas Backlund: [...] I've started working on mysql-5.5.23 (as it contains another security fix), and will release it to updates_testing for Mageia 1 as soon as possible. bye any chance do you have the CVE for the new one? i remember there was one in mariadb a few days ago, so i want to make sure this is the same one.
Re: [Mageia-dev] mysql CVE's in mga1 = have it update to mariadb
Op vrijdag 13 april 2012 19:35:15 schreef Thomas Backlund: 13.04.2012 19:30, Maarten Vanraes skrev: [...] bye any chance do you have the CVE for the new one? i remember there was one in mariadb a few days ago, so i want to make sure this is the same one. Unfortunately no CVE yet... it only refers to a locked bug report: Security Fix: Bug #59533 was fixed. But as mariadb 5.5.23 is supposed to be based on mysql 5.5.23, it should be fixed. I hate this... oracle is really fucking things up here...
Re: [Mageia-dev] Freeze push mariadb 5.5 GA release
Op woensdag 11 april 2012 01:56:04 schreef Maarten Vanraes: Please push mariadb: This updates to the 5.5 GA release (it's not announced yet, but they are waiting for it to hit all the mirrors) ping
Re: [Mageia-dev] bumblebee in mageia (and mentoring)
Op dinsdag 10 april 2012 21:28:19 schreef simple w8: [...] better to follow the policy. I dont know about mageia policies, but i will read about them so i can start using them from now on. check https://wiki.mageia.org/en/Policies , you don't have to read all of them, but it's nice to look at what kind of policies exist, so that later you can look them up if required. [...] you can afterwards make a kmod-bbswitch and kmod-acpi_call packages that make prebuilt modules for all available kernels. Yeap, i have seen those kind of packages and that way theres no need to use a dkms. well, except to actually build the kmod package, since it requires the dkms package :-) [...] perhaps filetriggers or the post and preun service helpers do all this automagically... i don't know, i usually just look at other packages. i think a provided existing service file is picked up by filetriggers I do see one systemd filetrigger: systemd-daemon-reload.script but i would like to know hows processed, so far for what i have seen i dont see how that is possible, to put systemd running services without put them in the scripts. And to remember that bumblebee is provided with service files for systemd and sysvinit, i did had that caution, thats why i put in scripts both usage. Still i think it would be better to simply keep the ones for systemd, since its the one used by default. well, if i was you, comment out the code and see if it actually does enable it by default. i'm definately not an expert, but for mariadb i didn't have to enable it, it worked like that... since i have not seen any other packages where it effectively does that, i don't think it's required. [...] iinm you can also add extra option to %cmake. if it's possible it'd be nice to have %cmake in it. if there would be systemwide changes at a later time, possibly due to changed newer cmake behavior, or whatever, it can be picked up without much effort. also it looks better to me, having all cmake packages using %cmake :-) Did you read what i wrote? ? of course i did, why else would i take the effort to reply? i did tried to use %cmake but build fails, so its really need to use it explicitely like its currently, and the same goes for when i did not used %makeinstall_std in libbsd. well as you already know, %cmake evaluates to cmake with some extra stuff, so if one of these things give you difficulty, either it points to a point that can be improved, or you can just override them for the ones you need. that way, you can still make it work with %cmake. [...]
Re: [Mageia-dev] bumblebee in mageia (and mentoring)
Op dinsdag 10 april 2012 21:53:57 schreef Guillaume Rousse: Le 10/04/2012 21:12, Maarten Vanraes a écrit : if [ $1 -eq 1 ]; then # Initial set # Enable (but don't start) the unit by default /bin/systemctl enable bumblebeed.service fi I don't think this stuff is needed on Mageia, that is done by default. Really? I didnt knew about it, is there any page documenting that? Im quite curious about how is done :) just read the the add-service helper code, or alternatively the rpm-helper README file. perhaps filetriggers or the post and preun service helpers do all this automagically... i don't know, i usually just look at other packages. i think a provided existing service file is picked up by filetriggers No, that's handled by add-service helper here. thanks for correcting me
[Mageia-dev] Freeze push mariadb 5.5 GA release
Please push mariadb: This updates to the 5.5 GA release (it's not announced yet, but they are waiting for it to hit all the mirrors)
[Mageia-dev] alternatives policy
Hi, from a question someone asked, i was reminded why an alternative file ( /var/lib/rpm/alternative/gl_conf ) was not owned. I found out that alternative files are usually %ghost 'ed, but it seems not in this case. I looked at the alternatives policy, but it was empty as it needs yet to be written. so, is it true that alternative files should be %ghost 'ed? or not?
Re: [Mageia-dev] [RFC] How to proceed with seamonkey/iceape for security updates and freeze push
Op zaterdag 07 april 2012 20:50:03 schreef Florian Hubold: Am 05.04.2012 14:19, schrieb Romain d'Alverny: On Thu, Apr 5, 2012 at 08:11, Maarten Vanraes al...@rmail.be wrote: Op woensdag 04 april 2012 22:59:30 schreef Florian Hubold: As there was no real objection, and no other comments or votes for iceape, i've dropped it from cauldron. FWIW i'm quite unhappy with this. Related, i've also not got any reply yet to my aforementioned inquiry about mozilla branding permissions. About the mozilla branding... Perhaps this should be a meeting point for packaging/council meeting... ie: someone assigned to this point so it's not forgotten. Would have been good to raise this point in Council way sooner. No other than the maintainers may answer both questions (about changes, and about contact/permissions from Mozilla). For Firefox it's dmorgan and for Thunderbird it's anssi. For thunderbird it's actually me, Anssi grabbed it on my behalf when i was still apprentice ;) no offense, but if you're the thunderbird maintainer, why don't you ask mozilla about it? tell them if we're not getting this official permission we won't ship it and do the iceape thing instead...
[Mageia-dev] [systemd] keyboard shortcut to show jobs during boot
in order to investigate hangs or slow boots or whatever, it would be useful to have some kind of key combination that lists the current systemd jobs and where it's hanging/waiting or whatever either that or detect a hang an spawn some kind of emergency login somewhere actually, if i'm really pulling out my want-to-have book, howabout a tty that (until it can actually get a tty), shows an top like watch of current jobs in systemd, where you can force some kind of process, ie: killing it, or letting all the dependant ones go through. perhaps that could be on the tty that would eventually always become a tty (as i remember we talked about) let's say that tty12 gets the kernel logging, then tty11 could show first dracut/udev stuff, then proceed with systemd jobs, and when it can get a tty, to be reserved for tty. (all the others could be reserved for graphicals then) that way, no matter what happens, you get some nice info/tty availability. ok, give all this nice-to-have... is there a way we can find out why a boot hangs? is there some logging we can check in a rescue or ...?
Re: [Mageia-dev] [RFC] How to proceed with seamonkey/iceape for security updates and freeze push
Op zaterdag 07 april 2012 21:14:00 schreef Florian Hubold: Am 07.04.2012 20:59, schrieb Maarten Vanraes: Op zaterdag 07 april 2012 20:50:03 schreef Florian Hubold: Am 05.04.2012 14:19, schrieb Romain d'Alverny: On Thu, Apr 5, 2012 at 08:11, Maarten Vanraes al...@rmail.be wrote: Op woensdag 04 april 2012 22:59:30 schreef Florian Hubold: As there was no real objection, and no other comments or votes for iceape, i've dropped it from cauldron. FWIW i'm quite unhappy with this. Related, i've also not got any reply yet to my aforementioned inquiry about mozilla branding permissions. About the mozilla branding... Perhaps this should be a meeting point for packaging/council meeting... ie: someone assigned to this point so it's not forgotten. Would have been good to raise this point in Council way sooner. No other than the maintainers may answer both questions (about changes, and about contact/permissions from Mozilla). For Firefox it's dmorgan and for Thunderbird it's anssi. For thunderbird it's actually me, Anssi grabbed it on my behalf when i was still apprentice ;) no offense, but if you're the thunderbird maintainer, why don't you ask mozilla about it? tell them if we're not getting this official permission we won't ship it and do the iceape thing instead... Did you read my previous mails? I've asked Kev Needham, mozilla distribution channel manager, about the approval process, sadly no answer yet. ah, mea culpa, i must've missed a few and too bad though... you can ask a few more people and CC some of the important people (or ones having good connections) like annael, stewb or such... otoh, silence is acceptance is one of my favourite sayings...
Re: [Mageia-dev] [RFC] How to proceed with seamonkey/iceape for security updates and freeze push
Op zaterdag 07 april 2012 23:48:59 schreef Florian Hubold: Am 07.04.2012 21:25, schrieb Maarten Vanraes: [...] otoh, silence is acceptance is one of my favourite sayings... Well, when i pointed out those branding issues before, noone was interested either, here on this list ... guilty as charged...
Re: [Mageia-dev] Release_blocker bugs
Op vrijdag 06 april 2012 13:17:46 schreef Anne nicolas: [...] Does not seem to be release_blocker === 4301 bugsq...@mageia.org Migration of module-init-tools to kmod lib in Mageia 2 - specifications = 4802 [...] i may understand this wrong, but iinm, module-init-tools doesn't work with current kernel anymore, and kmod is now required = doublecheck with tmb
Re: [Mageia-dev] [RFC] How to proceed with seamonkey/iceape for security updates and freeze push
Op woensdag 04 april 2012 22:59:30 schreef Florian Hubold: Am 26.03.2012 19:46, schrieb Florian Hubold: Hi all, i've taken a look at iceape and locally updated it to 2.7.2¹ after talking with maintainer about it, with the intent to at least push this to Mageia 1, because since initial import it has not received any security updates (and there are countless security problem) I've also completed the rebrand to iceape as far as i saw fit (change URL to release notes, applied some more debian rebranding patches, removed updater files and updater menu item, and some more smaller fixes, current svn diff is attached) and did some cleaning of old and unused stuff. ¹: I've only updated it to 2.7.2 as 2.8 does require newer NSPR, and that's a no-go for Mageia 1, which is my primary target. The biggest problem is: current maintainer does not have enough time to maintain it properly, and i'm not planning on doing it either, as i don't use it or know it well. There are at least 3 good options on how to proceed, apart from mga1 update: 1. push latest version to cauldron, and hope somebody will maintain it afterwards (this is the worst IMHO, as we'll probably face the same situation with a de-facto umaintained package throughout Mageia 2 lifetime, which i want to avoid) 2. drop iceape, package as seamonkey again and sync with Fedora (this one would at least make maintenance easier, only need to follow Fedora) 3. drop iceape completely (actually this has the advantage that users can have official upstream binaries, and take advantage of automatic updates. Current maintainer agrees with this, as it's simply too fragile for him to maintain it easily. If somebody is against this, please step up as maintainer or help the current maintainer) I'm currently in contact with some seamonkey developers, to maybe clear up why/if the rebrand is needed, if it's needed like it's currently done, and why Fedora can simply ship seamonkey without the need for a rebrand, but the dialog may take some time, this would be only relevant for option 2. If nobody responds, i'll push my current work as security update for Mageia 1, and drop iceape from cauldron so that we won't have an outdated package and a potential security risk for Mageia 2. Kind regards As there was no real objection, and no other comments or votes for iceape, i've dropped it from cauldron. FWIW i'm quite unhappy with this. Related, i've also not got any reply yet to my aforementioned inquiry about mozilla branding permissions. About the mozilla branding... Perhaps this should be a meeting point for packaging/council meeting... ie: someone assigned to this point so it's not forgotten.
Re: [Mageia-dev] Please push fwbuilder
Op maandag 02 april 2012 03:07:35 schreef Luis Daniel Lucio Quiroz: Please kindly push fwbuilder, it fixes many iptables compillations issues and it reports itself that there is a new update. Complete changelog is here http://www.fwbuilder.org/4.0/docs/firewall_builder_release_notes.html#5.0 Enviado desde mi teléfono Verizon Wireless fwbuilder is irritating in the fact that if someone has edited with a newer version, the .fwb file is upgraded and you need that version or more to open it again...
Re: [Mageia-dev] noarch packages containing binaries should be rejected
Op maandag 02 april 2012 12:35:49 schreef Guillaume Rousse: Le 02/04/2012 10:37, Thierry Vignaud a écrit : Please make arch-independent-package-contains-binary-or-object a reason to reject packages at upload time: The rule need some subtle exceptions. For instance, some pentest tools such as metasploit are arch-independant, but contains native code to be executed on remote systems. hmm, that's an interesting use case that i didn't think of...
Re: [Mageia-dev] Freeze push: pidgin-sipe
Op maandag 02 april 2012 11:36:37 schreef Damien Lallement: Le 01/04/2012 20:06, Damien Lallement a écrit : Le 30/03/2012 10:31, Damien Lallement a écrit : Le 29/03/2012 11:46, Damien Lallement a écrit : Le 28/03/2012 13:22, Damien Lallement a écrit : Hi, Can you please push pidgin-sipe. The new version (1.13.0) is a bug fix version: - add TLS-DSK authentification scheme (mandatory for Office365) - add non-public Lync support - fix build vith latest glib2 - refactored crypto code - remove kopete backend (telepathy now) http://sourceforge.net/projects/sipe/files/sipe/pidgin-sipe-1.13.0/ Thanks, ping ? ping ? ping? ping? ping?
Re: [Mageia-dev] Problems with flash 11.2
Op zaterdag 31 maart 2012 10:46:43 schreef JA Magallón: On 03/31/2012 08:43 AM, Dimitrios Glentadakis wrote: Στις 31/03/2012 08:38:19 γράψατε: Στις 31/03/2012 02:38:24 JA Magallón γράψατε: And, btw, to get hw video decoding I had to write a file in /etc/adobe/mms.cfg with EnableLinuxHWVideoDecode=1 Thanks, this solved the problem for me i had to reverse to disable hw acceleration because the embedded youtube videos in konqueror are invisible (in youtube it is ok) Yep, and flash also behaves mch more unstable, I'm having hangs I has never seen before. Crappy flash... BTW, how can I check if html5 has hardware support ? depending on the browser, but i think most browsers use native stuff, therefor if you have hw support, it's likely to be working in html5 as well
Re: [Mageia-dev] No time for maintainership
Op vrijdag 30 maart 2012 04:13:50 schreef Remco Rijnders: [...] fetchmail eandry [...] Feel free to pick any that have your fancy. I imagine that we'll want to set to 'nobody' any packages that have not been adopted in say a week or two from now? actually, i cannot grab one because they are still assigned. please someone set them to nobody.
Re: [Mageia-dev] dropping mysql-workbench
Op vrijdag 30 maart 2012 10:11:34 schreef nicolas vigier: On Thu, 29 Mar 2012, Maarten Vanraes wrote: unfortunately, atm it doesn't work, so it needs to be rebuilt, but it doesn't rebuild at all... and since we're in version freeze, you can't just update to a new version. even more is that soon is release freeze... No, fixing a package that doesn't work can be a good reason for version freeze exception. So if a new version can help fix the problem, it should be considered. ic, well in that case, i guess it can be done like this, but if there's no maintainer for it... personally, i have no problem with this being dropped. which is not to say i'm trying to hurt people who use it... but if we can't maintain a package, maybe it's better if the people who want to use it, can get it from upstream themselves. and since this is from oracle, i guess the maintainer should also doublecheck licensing to be on the safe side, since oracle has relicensed quite some code. who knows, maybe we can't even redistribute it anymore...
Re: [Mageia-dev] Removal of sun java
Op vrijdag 30 maart 2012 16:00:22 schreef nicolas vigier: [...] I think an empty package is not a good idea, it would be better to obsolete it in task-obsolete : - it's more clear that the package is obsoleted and is not a regular update. Users installing an empty package as update would only see that it is removed but not updated when it's already removed. - package is really removed and no longer listed as installed in rpm database - it's easy to add task-obsolete in urpmi skip.list for people who don't want unmaintained packages to be automatically removed wrt to task-obsolete, do the users get notified? maybe a README.urpmi listing all the packages and reasons would be an option to get notified?
Re: [Mageia-dev] Removal of sun java
Op vrijdag 30 maart 2012 16:03:14 schreef Guillaume Rousse: [...] Issuing a specific sun jdk security update package, containing only a README.urpmi file and a shell script inciting the user to read this file eventually, would be a fair compromise for me. And can be considered as a standard practice for semi-automatically removing very-dangerous-packages-we-cannot-afford-to-let-installed-anywhere-otherwis e-the-apocalypse-will-happen. if at all possible, i'd like a similar solution, but with task-obsolete somehow, since it ties in nicely with all the related stuff (iiuc above) but i think it is nice to have such a notification with such kind of packages... ie: if we're proposing to delete something, i'd rather know why...
Re: [Mageia-dev] Removal of sun java
Op donderdag 29 maart 2012 21:08:22 schreef David Walser: Guillaume Rousse guillomovitch@... writes: If I want to keep a proprietary JRE on my computers, because I trust it more to run crap proprietary applications (also called corporate-compliants), than marvelous free-licensed environment they have never been tested with, that is my choice, not yours. If they really want to keep Sun Java, shouldn't they just download the installer from Sun and install it themselves, rather than using some obsolete Mageia 1 package of it? well, iinm the version that the people have, will still have the correct license and we are able to distribute it fine. i would argue that if security bugs we could remove it, but i'm not too sure on this point... i mean, can we really remove it from them? otoh, people wanting to have the proprietary ones, likely know what they are doing... perhaps we can obsolete it with one of those nonfree getters? (if security bug) or, maybe a package that gives an README.urpmi ... IMHO: i think obsoleting it is fine, but with a README.urpmi that says notifies that it's been obsoleted. (unless someone wants to have and maintain a nonfree getter application that fetches the upstream releases) we really shouldn't keep stuff we can't maintain...
Re: [Mageia-dev] RFT: xen support
Op maandag 11 april 2011 10:33:30 schreef Thomas Backlund: Hi, xen-4.1.0-1.mga1 is now avaliable in the repos. And as of kernel-2.6.38.2-4.mga1 there has been some cleanups and addons for xen: There is now a kernel-xen-pvops that also should work as dom0. Now this is mostly upstream kenel.org code so its not as fully featured as the old kernel-xen. You can see the features listed here: http://wiki.xensource.com/xenwiki/XenParavirtOps. There is one exception: our 2.6.38 kernel has xen-netback backend driver added. So those of you that have been using xen, please test atleast the following: - check that kernel-server still works as a xen guest - try to use kernel-xen-pvops as dom0 and see how it works (you can also try to use kernel-xen-pvops as a normal xen guest) Have fun... -- Thomas i don't know how much people have been testing, but... dom0 xen didn't work with .xz kernels, i put in a patch for that, and now it works. in a kvm guest, i've got a working xen dom0 host, but the libvirtd implementation seems unable to find the cpu architecture, and if i force to be the same as the host, i am unable to boot the dom0 anymore. (i think this is likely due to the nature of a KVM guest not really being suitable for a XEN dom0). i've tried a physical server, but when i finally got to the point of libvirtd, it seemed to not bootup anymore (it was an old disk, which i thought got broken, seeing the IO errors) I put in a new disk, only to note that the X2 suddenly only had 1 core, which i found very odd, and i noticed the IO errors before (and also now) were really sata bus errors... (and if i remember correctly this machine had been used with a semi-exploding PowerSupply)... so i think this mobo/cpu is fried... now i need to find new hardware to restart testing again :-( . note that allthough i can have everything running, i never tested with actual guests, let alone online migrations... however, i did find out that this xenpvops has 2 different toolchains: xm and xl. xl seems to do pretty much the same, but apparently doesn't require xend to be running (it reacts directly to the kernel/hypervisor?) also the xencommons init script seems to start xenconsoled and xenstored on it's own. i'm thinking of removing both those init scripts and having xend not start as default. (allthough i don't know about xendomains). i'll keep you guys posted.
[Mageia-dev] dropping mysql-workbench
someone asked me to see about https://bugs.mageia.org/show_bug.cgi?id=5146 it looks like it needed a rebuild, but the rebuild failed with automake errors of some kind... tbh: i don't really care about this package, and have no idea if anyone (except reporter) actually uses this, is it even useful? so, since it has no maintainer, and it doesn't work anymore, and it can't be rebuilt... perhaps we should drop it. if someone wants to have it, he can likely get it from upstream directly? WDYT?
Re: [Mageia-dev] dropping mysql-workbench
Op donderdag 29 maart 2012 23:03:46 schreef Juan Luis Baptiste: On Thu, Mar 29, 2012 at 3:57 PM, Maarten Vanraes al...@rmail.be wrote: someone asked me to see about https://bugs.mageia.org/show_bug.cgi?id=5146 it looks like it needed a rebuild, but the rebuild failed with automake errors of some kind... tbh: i don't really care about this package, and have no idea if anyone (except reporter) actually uses this, is it even useful? This program is REALLY useful for web developers and database admins, I use it, so I'll get maintainership of it and try to fix the errors as soon as I can (swamped with work lately). See what it's useful for: http://www.mysql.com/downloads/workbench/ no offense meant, but i am in $dayjob both a webdev and sysadmin, and i don't use these kind of things, i don't even use phpmyadmin... unfortunately, atm it doesn't work, so it needs to be rebuilt, but it doesn't rebuild at all... and since we're in version freeze, you can't just update to a new version. even more is that soon is release freeze... i guess this means you have 1 week to get this fixed... otherwise i think we'll have no choice but to remove it... good luck, (if you need any pointer or help, i can still try to help/answer you though)
[Mageia-dev] Freeze push: mariadb (rc)
Please push mariadb: mariadb (and mysql) seem to have an odd method of increasing version number for each of there alpha/beta/rc/final versions. This updates to the 5.5 RC release (it's not announced yet, but they are waiting for it to hit all the mirrors) Normally, the final is expected to be released april 9th.
Re: [Mageia-dev] freez push clamav-0.97.4
Op zondag 25 maart 2012 00:21:36 schreef Colin Guthrie: 'Twas brillig, and Thomas Spuhler at 24/03/12 22:49 did gyre and gimble: On Saturday, March 24, 2012 12:36:06 PM Sander Lepik wrote: On Mar 24, 2012 9:13 PM, Thomas Spuhler tho...@btspuhler.com wrote: please push clamav-0.97.4 -- Best regards Thomas Spuhler Why? -- Sander it's an upgrade from 0.97.4 We need to provide the newest version of the antivirus package This, by itself, is not a very good explanation. If this is purely a definitions update then that's fine. If this is a bugfix update that's probably fine too (depending on the bug) If it's a new feature update then that likely won't make it. People are all very busy. It only takes the person requesting the push a minute or two to describe things properly. Please give your busy colleagues the respect they deserve and provide good explanations to save them having to spend time discussing and asking further questions. We still don't really have enough information to decide on this one! So please state whether it's just definitions or bugfix (and if so what bugs) etc. Col IIUC older clamav engines aren't supported, and stop working. but the reason given was indeed not enough. keep in mind that new features for this often means a security fix :-D i think this'll likely go through, but the original poster should check to see how things are, and report them accurately.
Re: [Mageia-dev] installing minimal is not really that minimal
Op vrijdag 23 maart 2012 02:08:26 schreef Maarten Vanraes: Op donderdag 22 maart 2012 00:30:53 schreef Maarten Vanraes: [...] in a chroot, i did a test with requiring plymouth or suggesting it (from dracut) the difference is: with plymouth: 301 packages/335MB without plymouth: 294 packages/294MB i'm gonna try a minimal install and see how much this'll differ ok, i was a bit wrong: i have a local dracut version overridden with urpmi-proxy so as not to required but suggest plymouth testing with which packages would become requested with rpmsrate... in a chroot, this becomes: 246 packages/299MB but, with suggests, this becomes 337 packages/385MB however, in an install i have 371 packages but the / contains 731MB so, where do all these extra packages come from? these are the different packages between installing with suggests, or chrooted rpmsrate expansion with suggests... acpi acpid bc coreutils-doc cpufreq dhcp-client dhcp-common dmraid dmraid-events gpg-pubkey hdparm hexedit ipset iptables kpartx lib64dmraid1 lib64ip4tc0 lib64ip6tc0 lib64iptables7 lib64mnl0 lib64nfnetlink0 locales-en lsof mageia-gfxboot-theme mandi mandi-ifw microcode microcode_ctl procmail shorewall strace sudo tree for one, mageia-gfxboot-theme is here again... it didn't get selected in chrooted install from manually checked rpmsrate settings... where does this come from? is there a part in the installer that hardcodes certain packages? clearly according to the ddebug.log file, this mageia-gfxboot-theme gets selected during the choosePackages step and not later on... what am i missing here? does anyone have an idea? i'd like to get to the bottom of this, so a pointer in a direction would help me alot...
Re: [Mageia-dev] rescue has mount.nfs, but no statd
Op vrijdag 23 maart 2012 10:34:55 schreef Thierry Vignaud: On 22 March 2012 20:33, Maarten Vanraes al...@rmail.be wrote: nfs was available, so we wanted to mount but the mount failed, because nfs module wasn't modprobed, and drvinst didn't fix that (maybe it should modprobe nfs as well) or maybe mount.nfs should try to modprobe nfs if needed. however, statd wasn't there and it complained that it needed that for locking atm we're doing -o nolock and that works... but... statd would be quite usefull here... perhaps i should rephrase... can i fix this by adding statd on the rescue? or would this take too much space? it's simpler to use mount -o nolock instead... it's what i did at the time, but would it be alot of work/space to include statd? when doing backup of files to somewhere else, you kind of want to know it's not gonna get mushed if someone just goes around opening some files or something... would it just be running statd? or would it also require portmapper etc... etc... ? if it's too much work, or too complex, it's not needed, but if it's not too much space and just having statd, then it's good
Re: [Mageia-dev] installing minimal is not really that minimal
Op vrijdag 23 maart 2012 10:42:40 schreef Thierry Vignaud: On 23 March 2012 08:32, Maarten Vanraes al...@rmail.be wrote: Op vrijdag 23 maart 2012 02:08:26 schreef Maarten Vanraes: Op donderdag 22 maart 2012 00:30:53 schreef Maarten Vanraes: [...] in a chroot, i did a test with requiring plymouth or suggesting it (from dracut) the difference is: with plymouth: 301 packages/335MB without plymouth: 294 packages/294MB i'm gonna try a minimal install and see how much this'll differ ok, i was a bit wrong: i have a local dracut version overridden with urpmi-proxy so as not to required but suggest plymouth testing with which packages would become requested with rpmsrate... in a chroot, this becomes: 246 packages/299MB but, with suggests, this becomes 337 packages/385MB however, in an install i have 371 packages but the / contains 731MB so, where do all these extra packages come from? these are the different packages between installing with suggests, or chrooted rpmsrate expansion with suggests... acpi acpid bc coreutils-doc cpufreq dhcp-client dhcp-common dmraid dmraid-events gpg-pubkey hdparm hexedit ipset iptables kpartx lib64dmraid1 lib64ip4tc0 lib64ip6tc0 lib64iptables7 lib64mnl0 lib64nfnetlink0 locales-en lsof mageia-gfxboot-theme mandi mandi-ifw microcode microcode_ctl procmail shorewall strace sudo tree for one, mageia-gfxboot-theme is here again... it didn't get selected in chrooted install from manually checked rpmsrate settings... where does this come from? is there a part in the installer that hardcodes certain packages? clearly according to the ddebug.log file, this mageia-gfxboot-theme gets selected during the choosePackages step and not later on... what am i missing here? does anyone have an idea? i'd like to get to the bottom of this, so a pointer in a direction would help me alot... acpi* mageia-gfxboot-them are pulled by the installer mandi* shorewall ( thus iptables*) too. I've asked previously if we want a firewall installed before summary, anne blino said it was OK microcode* is pulled b/c your CPU supports patching idem for cpufreq dhcp was selected b/c there was a network interface configured as DHCP dmraid ( thus kpartx) was selected b/c you've some fake raid (...) you always got gpg-pubkey, those are fake packages containing the keys used to verify packages thanks for the explanations, i really appreciate this, it seems logical, somehow, except maybe what i'm coming back to: mageia-gfxboot-theme is pulled by installer? how does that work? is this really required? or is this something that's somehow done in the graphic installer? i mean, i didn't select graphic grub, i chose text-grub specifically. and somehow during the choosePackages step, the mageia-gfxboot-theme is automatically selected... this is the packages that's adding via extra dep and suggests, most of the stuff... where can i find the code that is responsible for this, so i can try and fix it? about firewall, perhaps it's possible to just include iptables, but set policy on DROP incoming? shorewall seems a bit over the top... but, if summary isn't completed, you can't boot into it, wrt bootloader? so firewall seems useless for that...? what is the rationale behind this?
Re: [Mageia-dev] installing minimal is not really that minimal
Op vrijdag 23 maart 2012 17:38:05 schreef Thierry Vignaud: [...] we preselect it here so that it got installed early: http://svnweb.mageia.org/soft/drakx/trunk/perl-install/install/any.pm?revis ion=3532view=markup because else it'll be automatically pulled later, adding a one package (or more) wait later: http://svnweb.mageia.org/soft/drakx/trunk/perl-install/bootloader.pm?revisi on=3581view=markup just look mageia-gfxboot-theme Of course, that's OK for 99% of our users but for those manually selecting text lilo. text grub would still need this? hmm... i'll look into this more deeply... That's a trade off: enforcing waiting for packages installation after all the other package installation so that a couple users can not have the bootsplash installed and select lilo or having a couple users unhappy yeah, i get that, and i agree with this, but there's no reason some advanced setting can be done to turn more stuff off, be it visible or even via kickstart or cmdline... BWe could not preselect what is 'BWe' ? well, i was thinking to disable the preselect and/or later part when CAT_X is disabled. that should be fairly easy to do... about firewall, perhaps it's possible to just include iptables, but set policy on DROP incoming? shorewall seems a bit over the top... we configure shorewall, not iptables. but, if summary isn't completed, you can't boot into it, wrt bootloader? so firewall seems useless for that...? what is the rationale behind this? In the old days we let poeple choose the security level early then we automatically install set up the firewall accordingly. Later the security choice was moved to the summary and security level number was reduced from to 3 (see msec or security::level) But since the default security level is 1 (standard), we automatically install the firewall anyway. For years. sure, but i don't see the need to preselect it, again, it could be in rpmsrate and handled that way now that the security level is unused otoh, i could just use defcfg (if i ever get it working) and set security to 0 if i wanted to.
[Mageia-dev] MariaDB: problem: final estimated release date
( see https://mariadb.atlassian.net/secure/Dashboard.jspa , look at road map ) MariaDB RC 5.5.22 29/Mar/12 MariaDB GA 5.5.23 09/Apr/12 that means that the GA (final release) is 2 days after release freeze :-( (not counting any possible extra delays) however, i would like to have the final release and not the release candidate. any thoughts on this?
Re: [Mageia-dev] freeze push: drakxtools and drakx-installer-stage2
Op vrijdag 23 maart 2012 21:56:36 schreef Thierry Vignaud: Hi Please let in drakxtools drakx-installer-stage2. A lot of messages were bogus after the cleaning (replacing Mdv by %s without providing any Mageia to actually sprintf in...). There might be similar issues in other tools cleaned. People can use perl_checker to find those (not enough parameters). Also, other bugs found by perl_checker and the support for splash/quiet in drakboot. Here's the detailed changelog: 1) drakxtools - drakauth: o fix actually displaying Domain Windows for authentication - drakboot: o use splash on the kernel command line vs. splash=silent as per upstream code (e.g. plymouth, systemd and others) o support the quiet kernel command line argument to hide kernel text - drakbug, draksec, drakxhelp, logdrake: o fix displaying Mageia - harddrake: o fix detecting bluetooth devices 2) drakx-installer-stage2 - better bootloader message (mga#484) - fix displaying Mageia in some messages See you does i18n need to be notified?
Re: [Mageia-dev] Please push
Op donderdag 22 maart 2012 05:36:47 schreef Thomas Spuhler: Please push php-apacheaccessor I upgraded it in svn to 0.1.1 in Dec. 2011, but it either didn't build or I forgot to submit it. i'm pretty sure the requirements for freeze pushes are also at least that you must know it builds and works perfectly, on top of that it usually needs to be only bugfixes, or due to client/server changes that it is required... plz add more info to this request
Re: [Mageia-dev] installing minimal is not really that minimal
Op donderdag 22 maart 2012 08:40:14 schreef Thierry Vignaud: [...] ic your point, i too am interested in non-bloated install. however, this mail is specifically on installing WITHOUT suggests, or X. and in this particular case, i'd like to get it really really small. atm i'm looking at 670MB... which is way to bloated. at time of mga1, i had a similar install of around 450MB IIRC. thing is, without a full kickstart (which i don't want to, i'd like to keep doing partitioning manually, but kickstart seems not to do the interactive requests), i can't really make a minimal system to begin with... you can still do a semi automatic install. kickstart=file didn't seem to honor the interactive steps, and gave error because no / was found. defcfg=file seemed to have a little bit of default settings, but still i had to go through every step... i haven't found a way to have the middle ground. (or it needs some love)
Re: [Mageia-dev] installing minimal is not really that minimal
Op donderdag 22 maart 2012 17:57:29 schreef Thomas Backlund: [...] Installer already have a option to select do not install suggests and it does... that's exactly what i stated in my original email... PEOPLE ARE HIJACKING MY THREAD!!!
Re: [Mageia-dev] rescue has mount.nfs, but no statd
Op donderdag 22 maart 2012 10:14:27 schreef Maarten Vanraes: at $dayjob, we're testing out the rescue. so at first we're doing an rsync, but we need to do it on a network disk. cifs was not available, but that's not a big issue. nfs was available, so we wanted to mount but the mount failed, because nfs module wasn't modprobed, and drvinst didn't fix that (maybe it should modprobe nfs as well) or maybe mount.nfs should try to modprobe nfs if needed. however, statd wasn't there and it complained that it needed that for locking atm we're doing -o nolock and that works... but... statd would be quite usefull here... perhaps i should rephrase... can i fix this by adding statd on the rescue? or would this take too much space? plz advise...
Re: [Mageia-dev] installing minimal is not really that minimal
Op donderdag 22 maart 2012 00:30:53 schreef Maarten Vanraes: i did a network install and choose 'custom', then deselected everything, pressed next i got to the next menu of installation and left these to default: - no X - no suggestions - basic doc still on - truly minimal was off but, i ended up with x libraries, fonts, etc... so i dug a bit deeper as to why and looked at the ddebug.log file: i looked once more, after the choose packages step: these are the categories selected: CAT_MINIMAL_DOCS CAT_SYSTEM CHARSETC LOCALESen LOCALES_ LOCALESen_US META_CLASSdownload TRUE USB UTF8 this should be: man info man-pages eject ldetect harddrake sharutils locales iputils urpmi tmpwatch dmidecode ntfs-3g pm-utils numlock lftp mageia-release-Default these should result in a selection of 235 packages (i tried to track these manually through the rpmsrate file however, somehow other packages seem to be getting extra installed anyway (during the choosePackages step)! first package being selected is: - lib64drm_radeon1 ... even in rpmsrate radeon-firmware (the closest thing i can imagine), needs CAT_X next: - lib64pam0 - bootsplash am i missing something, i have the feeling there's another file that has effect to these stuff?
Re: [Mageia-dev] installing minimal is not really that minimal
Op vrijdag 23 maart 2012 00:44:09 schreef Pascal Terjan: [...] next: - lib64pam0 - bootsplash am i missing something, i have the feeling there's another file that has effect to these stuff? Well all the packages have plenty of dependencies... bootsplash is a good thing to look for: see the relevant part of ddebug.log: http://paste.pocoo.org/show/569781/ look for bootsplash, it gets selected, but never chosen nor required, but it's somehow there... and it should need CAT_X... to get selected... also see that the lib64drm_radeon1 is the very first in the ddebug.log...? why first? somehow it's been preselected, but it's not even in rpmsrate...
Re: [Mageia-dev] installing minimal is not really that minimal
Op donderdag 22 maart 2012 00:30:53 schreef Maarten Vanraes: [...] in a chroot, i did a test with requiring plymouth or suggesting it (from dracut) the difference is: with plymouth: 301 packages/335MB without plymouth: 294 packages/294MB i'm gonna try a minimal install and see how much this'll differ
Re: [Mageia-dev] installing minimal is not really that minimal
Op donderdag 22 maart 2012 19:04:07 schreef Maarten Vanraes: Op donderdag 22 maart 2012 17:57:29 schreef Thomas Backlund: [...] Installer already have a option to select do not install suggests and it does... that's exactly what i stated in my original email... PEOPLE ARE HIJACKING MY THREAD!!! of course, this was a joke at the time... but i should've known better... it appears the no suggests option is broken, since i did minimal install, with and without this, and i have exactly the same system... both times i have messages in ddebug.log saying: ... as suggested by ... :-( can someone fix this one?
Re: [Mageia-dev] Mageia ARM on Raspberry Pi (David Sj?lin)
Op woensdag 21 maart 2012 15:11:47 schreef brett: Sorry for the double post - n00b to the dev-list here! I am among those to receive one of the first batch or two of raspberry pi devices. I would be happy to help with testing as I would LOVE to be able to use Mageia on the device (as well as on a smartphone!) It seems that the ARM port has been rather inactive over the past year, though? iinm we're actually still starting it up... contact rtp for more info regarding this.
[Mageia-dev] Freeze push request: urpmi-proxy-0.3.2
plz push urpmi-proxy It's a bugfix release with only one fix
[Mageia-dev] installing minimal is not really that minimal
i did a network install and choose 'custom', then deselected everything, pressed next i got to the next menu of installation and left these to default: - no X - no suggestions - basic doc still on - truly minimal was off but, i ended up with x libraries, fonts, etc... so i dug a bit deeper as to why and looked at the ddebug.log file: afaict dracut seems to require plymouth, and mageia-gfxboot-theme seems to be there no matter what option i choose from the summary, it seems it was already installed before the summary. thing is, without a full kickstart (which i don't want to, i'd like to keep doing partitioning manually, but kickstart seems not to do the interactive requests), i can't really make a minimal system to begin with... for this release, if at all possible, i'd still like to get a bit smaller for minimal setups, and like to present a nongraphic grub by default when X is unselected, and also have no need for gfxboot or plymouth when i don't have a graphic grub (even though this isn't the same) furthermore, if i'm installing without X the default runlevel target seems to still be the graphic one, and not the multi-user one... perhaps it's possible to have this as alternatives or something? which could be set by the CAT_X thingie? one installing one package and the other installing the other package?
Re: [Mageia-dev] [Freeze] please let in xonotic
Op vrijdag 16 maart 2012 08:57:45 schreef Samuel Verschelde: [...] It's already the case. If you re-read Ennael's mail about version freeze, it says exactly that about exceptions. Samuel i'm looking at this mail, but don't see the exact same exceptions? https://www.mageia.org/pipermail/mageia-dev/2012-March/012533.html which email are you looking at?
Re: [Mageia-dev] [Freeze] please let in xonotic
Op vrijdag 16 maart 2012 16:15:22 schreef Pascal Terjan: On Fri, Mar 16, 2012 at 15:11, Maarten Vanraes al...@rmail.be wrote: Op vrijdag 16 maart 2012 08:57:45 schreef Samuel Verschelde: [...] It's already the case. If you re-read Ennael's mail about version freeze, it says exactly that about exceptions. Samuel i'm looking at this mail, but don't see the exact same exceptions? https://www.mageia.org/pipermail/mageia-dev/2012-March/012533.html which email are you looking at? Criteria for accepting updates -- Since we aim for stability, the criteria would be near the ones of updates. ah, like this... i read this as near (ie: not exact) and then the next parts were clarifications on the criteria (and the client/server protocol ones weren't in there). my bad, although in my defence, it could have been worded better, or a wiki policy with a link to it in this email. imho, if this were clearer, then i would guess misc would on his original email likely ask questions regarding client/server protocol changes as well... so i can only conclude that it might not have been 100% clear for everyone. (and i wasn't the only one)
Re: [Mageia-dev] [Freeze] please let in xonotic
Op donderdag 15 maart 2012 18:35:04 schreef Juan Luis Baptiste: On Thu, Mar 15, 2012 at 12:24 PM, Bertaux Xavier berta...@yahoo.fr wrote: If this is the case, then I say that xonotic should be allowed to be updated. I'm not about to be okay with that, a version Freeze only accepts updates on bug fixes and security warnings, so RC to Release is OK but not to revision's change, otherwise that would mean that if fate xonotic in version 0.7 just before the Release we should built. To me this should be pushed Backport, to limit the update after Release Backports are for new versions, not bug fixes. In this case even as this is a new version, the use of an older version of the game client with a new game server version could bring issues to users, so that makes this release more of a bug fix release, because we are trying to avoid any possible problem to our users, not because we want to have the latest version of the game. If we leave the current version and then a user reports a problem while playing the game, the 0.6 or 0.7 or whatever version is available at the time would be pushed as an update, not as a backport. well, the version policy is for updates. my point here is that we should maybe equalize simplify our policys by having the same kind of exceptions in both policies. of course, there may be a good reason to now similar exceptions to both policies, it's just that atm, i don't see any.
[Mageia-dev] Freeze push: mariadb (beta)
Please push mariadb: mariadb (and mysql) seem to have an odd method of increasing version number for each of there alpha/beta/rc/final versions. This updates to the 5.5 Beta release (it's not announced yet, but they are waiting for it to hit all the mirrors) Normally, the final is expected to released in about 2 weeks.
Re: [Mageia-dev] [Freeze] please let in xonotic
Op woensdag 14 maart 2012 01:16:23 schreef Juan Luis Baptiste: On Sun, Mar 11, 2012 at 7:21 AM, Michael Scherer m...@zarb.org wrote: Le samedi 10 mars 2012 à 10:26 +0100, Thierry Vignaud a écrit : Hi please let in xonotic-0.6.0 It's just a game that impacts nothing else. Niet. That's bugfix or security fixes. Well I vote to be updated, why ? global game servers are currently running 0.6.0, and by personal experience over several years (omg how much time wasted on this) these FPS games need to have the same client/server version, in some cases different versions won't work at all (ie. Urban Terror 3.7 - 4.0 - 4.1, Warsow 0.5 - 0.8 etc). I just did the test of running a 0.5.0 client on a 0.6.0 server and it works, but a big and annoying yellow announce floats across the screen remaining you that a new version is available. I also talked with one dev over IRC and he told me that there could be issues when running different client/server versions. So just to be on the safe side this new version should be pushed. If not then probably we will need to do it later as an update if any problems arise. I commit my self to test the new version, I know very well how this game works. IINM we have some kind of exception regarding games for their client/server relation regarding updates vs backports? if so, then perhaps we could have the same policy wrt updates to version freeze?
Re: [Mageia-dev] Freeze push: firefox, xulrunner
Op woensdag 14 maart 2012 03:02:57 schreef Funda Wang: Hello, Could somebody push firefox 10.0.3esr and xulrunner 10.0.3esr into cauldron? Thanks. i thought the maintainer wanted to push _only_ the esr version? or has something changed?
Re: [Mageia-dev] Freeze push: firefox, xulrunner
Op woensdag 14 maart 2012 09:28:07 schreef D.Morgan: On Wed, Mar 14, 2012 at 8:27 AM, Maarten Vanraes al...@rmail.be wrote: Op woensdag 14 maart 2012 03:02:57 schreef Funda Wang: Hello, Could somebody push firefox 10.0.3esr and xulrunner 10.0.3esr into cauldron? Thanks. i thought the maintainer wanted to push _only_ the esr version? or has something changed? funda told 10.0.3esr and xulrunner 10.0.3esr so what is wrong for you ? well, i thought you said you were only gonna do esr... as such to me, it seemed unnecessary to add esr ... it seems to imply the other versions gonna get pushed later... but then, maybe they will be backported or something... if you're ok with it, it's fine, i just noticed it and found it odd...
Re: [Mageia-dev] freeze push: pidgin
Op woensdag 14 maart 2012 17:33:24 schreef Damien Lallement: Hi, pidgin 2.10.2 just landed! It builds on my laptop and I use it since a few hours now. All is working. Can we push it to cauldron? A lot of big improvements like: - GNOME3 better support - NM better support - fix crash - update MSN protocol to MSNP18 http://developer.pidgin.im/wiki/ChangeLog Thanks, the MSN protocol will likely be necessary for it to work? can the crash fix and MSN patches be backported? or is it not doable?
Re: [Mageia-dev] Odd Window framing in curses part of install
Op dinsdag 13 maart 2012 20:47:48 schreef Frank Griffin: On 03/13/2012 02:40 PM, Frank Griffin wrote: Just a small thing, but the curses windows which appear at the start of isolinux prompting for the type of install, server address and so forth have suddenly had their borders filled with characters - U at the left corner, A along the top, and an upside-down question mark at the right corner. I assume that curses is using ASCII extended graphics characters to draw the perimeter of the windows, but that the install itself is using UTF-8 or some other character set which doesn't have them. My bad. This is bug 4894. I just didn't guess it from the title. my bad, if you find a better title, please do
Re: [Mageia-dev] [Freeze] please let in xonotic
Op maandag 12 maart 2012 07:53:38 schreef David W. Hodgins: [...] My understanding was that Magea 1 supported updating from Mandriva 2010.2 + Contrib + PLF-Free. There were several updates submitted to qa a few days ago, that are only available in backports in Mdv 2010.2. [...] IMHO backports could be supported under Mageia backports, not in regular media. Keeping in mind our limited resources, nonetheless, several of these bugs which seemed to require workaround upon workaround, should get fixed sooner rather than later, because it seems to be getting more complicated or more discussed (and in generally too much resources being spent on it) i'm thinking of: - backports - noarch linking - bug 2317 - livemedia - or in general what we promise ( or rather to be careful what and how we promise): if we say: there are no livemedia yet, but we're working on it to get it in the next few weeks ... some people become angry, but you can also say: There's a major bug preventing us from making livemedia, but we're working on them and possibly even updating it when it becomes clear it'll be for the next release into This beta release doesn't have any livemedia, we're hoping to have the next beta release containing livemedia Similar with backports: it's been promised this time without timelimit, but people seem to be convinced it'll never make it. 3rd party repositories popping up etc... It does not make us look good. and I'm getting to the point where the resources spent on discussing backports seem to be larger than the eventual losses in resources that would have been due to backports being open. But now of all times, backports shouldn't open, rather in the first week after release of mga2 would be a nice timing. to get back on topic: perhaps it's not unreasonable to allow a timelimit exception, like for instance 3 or 4 days where i forgot it was freeze or didn't make it in time AND it's not likely to mess everything up kind of reason... But i think the point is now becoming moot if temporary freeze of Beta2 is in effect... (not sure if it is, but i think i saw something regarding it) (about communication: maybe it's more prudent to have a messagebox above http://pkgsubmit.mageia.org/ telling us about various freezes and upcoming soon freezes, even though as a packager it's my task to read meeting logs and keeping myself up2date)
Re: [Mageia-dev] [Freeze] please let in xonotic
Op maandag 12 maart 2012 10:56:57 schreef Michael Scherer: Le lundi 12 mars 2012 à 08:29 +0100, Maarten Vanraes a écrit : to get back on topic: perhaps it's not unreasonable to allow a timelimit exception, like for instance 3 or 4 days where i forgot it was freeze or didn't make it in time AND it's not likely to mess everything up kind of reason... That was already discussed when we discussed the release cycle. And basically, that would just let's reduce the freeze by 3/4 days in a more inefficient way. You just move the bickering at the 3/4 days limit ( but it could have bene if I had submitted yesterday ) instead of the beggining of the freeze, and you take time to the people who are submitting, since they get message, have to warn packager about it doesn't work ( as it happened several time last freeze period ). [...] So next time, maybe we should have a pure good faith based system, [...] - everybody can do as he see fit I'll take this suggestion as a cynic suggestions and ignore it for now [...] Patch welcome, but frankly, I think there is a point where the duty of being informed must be on the packagers. It is rather depressing to realize that people do not read the announce you send ( and what is more depressing is the number of those that don't once you start to dig out ). If some people missed the announce, maybe we should ask them where do you read information about the project and where don't you read, so we can identify the communication channel that should be used and those that shouldn't, as i am not sure that hammering more is the solution. I do understand both your pov, and i do remember that discussion. IMHO: good strict policies are good, and exceptions are exceptions. but we should also try to prevent irritation if it's possible... we're short on contributors and I don't like to decrease motivation... I guess that makes me more lax than others.
Re: [Mageia-dev] [Freeze] please let in xonotic
Op maandag 12 maart 2012 22:02:56 schreef Guillaume Rousse: Le 12/03/2012 21:27, Maarten Vanraes a écrit : but we should also try to prevent irritation if it's possible... we're short on contributors and I don't like to decrease motivation... I guess that makes me more lax than others. OK, I want a new version of cowsay. Right now. Otherwise I'm leaving. Far away and forever. ok, fine, your point is noted...
Re: [Mageia-dev] Deprecating startx
Op zaterdag 10 maart 2012 22:06:09 schreef Florian Hubold: Am 10.03.2012 14:15, schrieb eatdirt: On 10/03/12 10:12, Maarten Vanraes wrote: I have a pentium 66MHz (not MMX) With the turbo button 33 - 66 ? Man, that's a proper collector :) Normally turbo button was only effective for 468DX/586DX type of machines, not for pentium IIRC. you likely mean 486/586 and alas 586 machines are called pentium there's a difference between pentium and pentium MMX though, even though i recall there are even pentium MMX's who had a turbo button... if it was really effective of not, that's another matter entirely...
Re: [Mageia-dev] deprecate text installer
Op vrijdag 09 maart 2012 14:29:42 schreef Thierry Vignaud: On 9 March 2012 07:42, Maarten Vanraes al...@rmail.be wrote: If we deprecate and remove the abillity to use a text installer, we are effectlively blocking blind users from beeing able to install the system. I know how you guys feel, but the fact is that we're at beta1 and it's not working and it doesn't seem to be a simple problem... we're trying to fix it, but it doesn't seem good atm: https://bugs.mageia.org/show_bug.cgi?id=4724 and if it's not working, we shouldn't advertise it You lie. It's working perfectly. ah, you fixed it? thanks alot, i'll go test immediately
Re: [Mageia-dev] deprecate text installer
Op vrijdag 09 maart 2012 17:42:33 schreef Thierry Vignaud: On 9 March 2012 17:29, Maarten Vanraes al...@rmail.be wrote: ah, you fixed it? thanks alot, i'll go test immediately No, I mean you're all lyers :-) you mean liars? More seriously, on x86_64 you 'll need the 48132096 bytes install/stage2/mdkinst.sqfs file from Mar 9 2012 13:22 (different size on i586 of course) yeah i already confirmed it slightly working, there's still a curses bug i presume see the bug report
Re: [Mageia-dev] deprecate text installer
Op zaterdag 10 maart 2012 00:25:46 schreef Thierry Vignaud: On 9 March 2012 19:44, Maarten Vanraes al...@rmail.be wrote: yeah i already confirmed it slightly working, there's still a curses bug i presume see the bug report You shouldn't have mixed this with that bug report. (btw this looks like a virtuabl bios issue imho) oh, sorry, i'll try it out on a real machine tomorrow. allthough, the pictures i have from the text installer from mga1 didn't have this, and the vbox host and version is still the same...
Re: [Mageia-dev] deprecate text installer
Op vrijdag 09 maart 2012 04:29:39 schreef Liam R E Quin: On Fri, 2012-03-09 at 04:11 +0100, Johnny A. Solbu wrote: If we deprecate and remove the abillity to use a text installer, we are effectlively blocking blind users from beeing able to install the system. [..] I know how you guys feel, but the fact is that we're at beta1 and it's not working and it doesn't seem to be a simple problem... we're trying to fix it, but it doesn't seem good atm: https://bugs.mageia.org/show_bug.cgi?id=4724 and if it's not working, we shouldn't advertise it
[Mageia-dev] deprecate text installer
considering https://bugs.mageia.org/show_bug.cgi?id=4724 and that it's likely not working in cauldron for months, and also considering it's beyond our perl guru jq and our drakx-guru tv, and considering it looks like google didn't help... and considering there's 4 or 5 text-installer bugs i wanted to test out... perhaps we should consider in fact that text installer does not work... after all, if we get this fixed, there's still the other text-installer bugs... maybe it's premature for me, but considering this is version freeze... we're getting closer to the end... WDYT?
Re: [Mageia-dev] Deprecating startx
Op woensdag 07 maart 2012 22:34:50 schreef Samuel Verschelde: [...] I apparently missed a few meetings or e-mails where this was discussed, but wasn't the initial plan to keep sysvinit by default in mga2 and switch to systemd by default in mga3? Wasn't the switch to systemd by default in cauldron a temporary switch in order to get more testing? Samuel that is what i originally thought too, but i guess i was mistaken
Re: [Mageia-dev] Missing noarch package from i586 repository
Op dinsdag 06 maart 2012 15:39:53 schreef Pascal Terjan: On Tue, Mar 6, 2012 at 14:39, Pascal Terjan pter...@gmail.com wrote: On Tue, Mar 6, 2012 at 14:29, Oliver Burger oliver@googlemail.com wrote: According to check.mageia.org, dmenu has a broken dependency, since terminus-font is missing from i586 repositories. According to svnweb, it was last commited 7 months ago as a noarch package by wally. And it was not shown as broken dependency this weekend so it must have been deleted from the mirrors in the last few days out of some reason unknown to me. Is this a general problem on noarch packages or just some isolated thing with this package? Hmm I restored it but I have no idea what happened and it is not in old/ (the place where we move things to be deleted so that they stay around for a few weeks) [schedbot@valstar ~]$ diff (find /distrib/bootstrap/distrib/cauldron/i586/ -name '*noarch.rpm' | xargs -n1 basename |sort) (find /distrib/bootstrap/distrib/cauldron/x86_64/ -name '*noarch.rpm' | xargs -n1 basename | sort) | grep '^[]' audiokonverter-5.9.1-1.mga2.tainted.noarch.rpm bluez-firmware-1.2-6.mga1.noarch.rpm jgoodies-animation-javadoc-1.3.0-1.mga2.noarch.rpm xml-commons-apis-manual-1.4.01-6.mga2.noarch.rpm maybe unrelated, i've rebuilt some packages these last few days because they were missing one of the subpackages
Re: [Mageia-dev] Minimum install of cauldron don't start console
Op dinsdag 06 maart 2012 14:28:38 schreef Colin Guthrie: [...] Now I'm not sure on the logic inside the Xserver that is used to search for a free getty. it maybe starts from the current one and counts up. If so, this logic should (IMO) be changed to start searching from 1 that way it would relatively consistently start on vt1 even when restarted from tty2. Col have you been successfull with 2 user sessions?
Re: [Mageia-dev] Minimum install of cauldron don't start console
Op dinsdag 06 maart 2012 20:50:11 schreef Colin Guthrie: [...] Yeah. I would agree there has to be a limit. I'd say RC2 should be that limit. If I've not found a better way of doing things by then, I'll do whatever is needed to make a getty appear... There is no RC2 planned... Planned timetable is: beta2: March 15th rc: April 10th final: May 3rd OK, then I guess by the rc then :) Col release freeze is April 7th...
Re: [Mageia-dev] Minimum install of cauldron don't start console
Op dinsdag 06 maart 2012 20:52:02 schreef Colin Guthrie: 'Twas brillig, and Maarten Vanraes at 06/03/12 19:41 did gyre and gimble: Op dinsdag 06 maart 2012 14:28:38 schreef Colin Guthrie: [...] Now I'm not sure on the logic inside the Xserver that is used to search for a free getty. it maybe starts from the current one and counts up. If so, this logic should (IMO) be changed to start searching from 1 that way it would relatively consistently start on vt1 even when restarted from tty2. Col have you been successfull with 2 user sessions? As in logging out and back in again or with fast user switching? The former has worked quite happily for me. Not tested the latter but I expect there to be some quirks. Col err, no, i mean 2 X sessions. often i have one KDE session running on vt8 and one for my wife on vt9 and sometimes on for my daughter at vt10... the question is, with the prefdm only conflicting with the first getty, will several X sessions be possible?
Re: [Mageia-dev] Minimum install of cauldron don't start console
Op dinsdag 06 maart 2012 21:19:49 schreef Colin Guthrie: 'Twas brillig, and Maarten Vanraes at 06/03/12 20:09 did gyre and gimble: Op dinsdag 06 maart 2012 20:52:02 schreef Colin Guthrie: 'Twas brillig, and Maarten Vanraes at 06/03/12 19:41 did gyre and gimble: Op dinsdag 06 maart 2012 14:28:38 schreef Colin Guthrie: [...] Now I'm not sure on the logic inside the Xserver that is used to search for a free getty. it maybe starts from the current one and counts up. If so, this logic should (IMO) be changed to start searching from 1 that way it would relatively consistently start on vt1 even when restarted from tty2. Col have you been successfull with 2 user sessions? As in logging out and back in again or with fast user switching? The former has worked quite happily for me. Not tested the latter but I expect there to be some quirks. Col err, no, i mean 2 X sessions. often i have one KDE session running on vt8 and one for my wife on vt9 and sometimes on for my daughter at vt10... OK, so fast user switching then. the question is, with the prefdm only conflicting with the first getty, will several X sessions be possible? Yeah. They should, in theory at least, start on vt2 and vt3, tho' this may depend on the desktop itself. With GDM+Gnome the second session starts on tty2, the third on tty3 etc. There is a caveat however. If you have switched to tty2 before picking the Login as another user option, then autovt will have kicked in and started a getty there. It then hogs tty2 and prevents X from using it. Of course if I manage to get my idea working, switching to tty2 when in graphical.target will actually give you a graphical login prompt anyway, so pretty much the same thing as picking the Login as another user option from within the first graphical session. Col ic... i do hope we get some kind of vt that will always be tty? i do sometimes require that, when getting too much load and OOM'ing... also, it'd be nice to have as possibility (in the dm) to start a tty session instead of a graphical session (as an alternative) but i guess the important parts are all the other things...
Re: [Mageia-dev] Network lost with last update
Op maandag 05 maart 2012 18:56:36 schreef Colin Guthrie: [...] Of course those without internet access might have trouble reading the mailing list :p Col /me facepalms
Re: [Mageia-dev] Versions freeze
Op zondag 04 maart 2012 11:38:08 schreef Michael Scherer: [...] Why assume that we are late ? If there is no post we are late, then we are not. Such a post would usually come late :-)
Re: [Mageia-dev] Versions freeze
Op zaterdag 03 maart 2012 10:36:55 schreef Thomas Backlund: 03.03.2012 11:24, Michael Scherer skrev: Le vendredi 02 mars 2012 à 20:53 +0100, Maarten Vanraes a écrit : Op vrijdag 02 maart 2012 20:16:11 schreef Thomas Backlund: 02.03.2012 21:08, Dimitri Jakov skrev: Besides... GNOME 3.4 is going to be released on March 28 - does that Yes we know... mean that we won't be able to ship it with Mageia 2? Nope, we have that as an exception to the freeze... (that's why we already run 3.3.x) we will have Gnome 3.4.x and KDE 4.8.x in Mageia 2 also, I hope mariadb-5.5.x final (right now we have 5.5.20 which is the alpha version; beta will come quite soon, then the rc and finals follow pretty fast and these only contain bugfixes) Next time, maybe waiting for the beta would be better, cauldron is not mean to be a playground for testing upstream softwares when we do not have a strong assurance that the stable will end i the stable release. Actually in this case it is ok, since we've been tracking upstream 5.5.x branch with the target for 5.5.x final, so alpha in this case only means fully synced with mysql 5.5 and afaik all intended mariadb patches merged... yes, and so far that haven't been any complaints yet, waiting for mikala, since he's the most likely person to have issues about it. They are only a bit late :/ yes :-( allthough according to upstream, there seems to be a good chance it will be released as final quite quickly If everybody start to do that, we spend more time on upgrading to version that should have been stable than fixing others bugs. And if upstream could also try to be a little bit less original and follow some easy to grasp convetion about version number. yes, it seems they will upgrade the version to +1 for beta and so forth. but they consider the major versions 5.5 the real version. but still, took me a while to figure it out...
Re: [Mageia-dev] Versions freeze
Op zaterdag 03 maart 2012 22:34:41 schreef Sander Lepik: Well, actually I'm sure it could. But why? All meeting logs are publicly available at https://meetbot.mageia.org/ Why? Because now i know this link for some time and then i forget it again :) Sorry but Mageia isn't the only project where i'm contributing. I just can't remember everything. But thanks for the link. -- Sander maybe we could have the meetbot send it to another mailing list and the people who don't frequently are able to follow the meetings can subscribe to that. i don't think it's a bad idea to read what has happened in the meetings as a packager team member...
Re: [Mageia-dev] Versions freeze
Op vrijdag 02 maart 2012 20:16:11 schreef Thomas Backlund: 02.03.2012 21:08, Dimitri Jakov skrev: Besides... GNOME 3.4 is going to be released on March 28 - does that Yes we know... mean that we won't be able to ship it with Mageia 2? Nope, we have that as an exception to the freeze... (that's why we already run 3.3.x) we will have Gnome 3.4.x and KDE 4.8.x in Mageia 2 also, I hope mariadb-5.5.x final (right now we have 5.5.20 which is the alpha version; beta will come quite soon, then the rc and finals follow pretty fast and these only contain bugfixes)
Re: [Mageia-dev] executable libraries
Op vrijdag 02 maart 2012 21:29:05 schreef Anssi Hannula: 02.03.2012 21:57, Maarten Vanraes kirjoitti: Op vrijdag 02 maart 2012 15:22:23 schreef Anssi Hannula: 02.03.2012 00:17, Maarten Vanraes kirjoitti: Op donderdag 01 maart 2012 23:05:35 schreef Anssi Hannula: [...] does this mean debug info fails for these? I'm not immediately sure (I never remember how the debug/stripping stuff works exactly), but I think either a) debug symbols extraction and thus -debug packaging, b) stripping, or c) both will fail with non-executable shared libs. in that case i guess we would need a policy or bs check to make sure we don't fail some libraries debug and strip Possibly. Interestingly, Debian policy disallows executable permission on shared libs: http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs- ru ntime Shared libraries should not be installed executable, since the dynamic linker does not require this and trying to execute a shared library usually results in a core dump. which is sort of strange, since libc is actually executable by design. i see where they are coming from but i guess the first part of this is, why is there a find with executable restrictions for the code relating to stripped binaries and debug? is it because it's also used for real executables? I guess it is there just to speed up the process, otherwise it would have to run 'file' for every file in the package (and many packages have lots of files). still, it seems kind of weird, there are rpmlint checks for unstripped libraries, but i do have 34 libraries not marked as executable, while the stripping+ debug seems to target only executables? i wonder if we should make another check library unset as executable or even check what happened with these libraries not marked as executable?
[Mageia-dev] executable libraries
I noticed that on my system, some libraries are marked executable and others aren't. I know that certain libraries are executable, like libc, but i figure that this is rather the exception rather than the rule. I wonder if we should have some kind of policy about this? I can be wrong, but i didn't think it's necessary to make libraries as executable? I don't want any bikeshedding, but what do you think? is such a policy useful? or not?
Re: [Mageia-dev] executable libraries
Op donderdag 01 maart 2012 22:22:37 schreef Maarten Vanraes: [...] forgot to add my counts from my system: [ ]$ find -L /lib /lib64 /usr/lib /usr/lib64 -iname *.so -executable | sort | uniq | wc -l 4113 [ ]$ find -L /lib /lib64 /usr/lib /usr/lib64 -iname *.so | sort | uniq | wc - l 4147 [ ]$ find -L /lib /lib64 /usr/lib /usr/lib64 -iname *.so -not -executable | sort | uniq | wc -l 34 hmm, only 34 not marked as executable?
Re: [Mageia-dev] executable libraries
Op donderdag 01 maart 2012 22:36:08 schreef Pascal Terjan: [...] I would say it doesn't matter and would not spend any time on it ok, thanks for your pov
Re: [Mageia-dev] executable libraries
Op donderdag 01 maart 2012 22:54:59 schreef Anssi Hannula:
01.03.2012 23:36, Pascal Terjan kirjoitti:
I would say it doesn't matter and would not spend any time on it
/usr/lib/rpm/mageia/find-debuginfo.sh:
# Strip ELF binaries
find $RPM_BUILD_ROOT ! -path ${debugdir}/*.debug -type f \
\( -perm -0100 -or -perm -0010 -or -perm -0001 \) \
^
-print |
file -N -f - | sed -n -e 's/^\(.*\):[ ]*.*ELF.*, not stripped/\1/p' |
xargs --no-run-if-empty stat -c '%h %D_%i %n' |
while read nlinks inum f; do
Looks like debug packages and/or stripping won't work for non-executable
shared libraries.
hmm, there's a '!' there, so isn't it reverse then?
but if this only works with executable libraries, (kind of weird imho), there
are at least 34 libraries on my system not marked as executable...
does this mean debug info fails for these?
Re: [Mageia-dev] executable libraries
Op donderdag 01 maart 2012 23:05:35 schreef Anssi Hannula: [...] does this mean debug info fails for these? I'm not immediately sure (I never remember how the debug/stripping stuff works exactly), but I think either a) debug symbols extraction and thus -debug packaging, b) stripping, or c) both will fail with non-executable shared libs. in that case i guess we would need a policy or bs check to make sure we don't fail some libraries debug and strip
Re: [Mageia-dev] executable libraries
Op donderdag 01 maart 2012 23:37:02 schreef Per Øyvind Karlsen: [...] rpmlint already has a check for unstripped files at least.. :) does it also check only executable files?
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release evolution-3.3.90-2.mga2
Op woensdag 29 februari 2012 00:10:47 schreef Olav Vitters: On Tue, Feb 28, 2012 at 09:19:46PM +0100, mitya wrote: mitya mitya 3.3.90-2.mga2: + Revision: 215887 - bump release - Fix GNOME bug #669294 (will be merged upstream in 3.3.91+) If you forget to increase the release, you can do something like: SILENT: bump release anything with SILENT on the line is hidden. and no need to mention you're bumping the release; if you didn't, the buildsystem wouldn't allow you to submit and you can also modify the svn commit log so that future changelog entries will look good
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release dovecot-1.2.17-3.mga2
Op maandag 27 februari 2012 09:20:17 schreef Guillaume Rousse: Le 27/02/2012 08:00, Maarten Vanraes a écrit : Is it necessary to have these --with[out]* compile flags in the package description? maybe not necessary, but definitively useful. maybe it'd be better to just list whatever support it has been built with. It has been a standard practice for all our packages allowing conditional build options for quite a long time. Of course, this could be mentioned elsewhere as package description. i have no problem it being in the spec file, but surely a better place rather than the description... it's not like users really need to know which compile flags there is or what you can do with rpmbuild... i'm just saying this info should be moved out to comments in spec file, and change the description to state what exactly is compiled in...
Re: [Mageia-dev] Looking for a packaging mentor
Op zondag 26 februari 2012 17:55:42 schreef Jeff Robins: [...] Awesome, thanks. What's a good IRC client? I've honestly never used it before. there are several: - irssi - bitchX - XChat - pidgin has a IRC plugin - ...
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release dovecot-1.2.17-3.mga2
Is it necessary to have these --with[out]* compile flags in the package description? maybe it'd be better to just list whatever support it has been built with. Op zondag 26 februari 2012 19:46:34 schreef colin: Name: dovecot Relocations: (not relocatable) [...] Description : Dovecot is an IMAP and POP3 server for Linux/UNIX-like systems, written with security primarily in mind. Although it's written with C, it uses several coding techniques to avoid most of the common pitfalls. Dovecot can work with standard mbox and maildir formats and it's fully compatible with UW-IMAP and Courier IMAP servers as well as mail clients accessing the mailboxes directly. You can build dovecot with some conditional build swithes; (ie. use with rpm --rebuild): --with[out] gssapiGSSAPI support (enabled) --with[out] ldap LDAP support (enabled) --with[out] luceneLucene support (enabled) --with[out] mysql MySQL support (enabled) --with[out] pgsql PostgreSQL support (enabled) --with[out] sqliteSQLite support (enabled) --with[out] sieve CMU Sieve support (enabled) --with[out] managesieve MmanageSieve support (enabled) [...]
