Re: [Mageia-dev] A question about BuildRequires and other RPM questions.
Am 28.02.2013 22:18, schrieb Dan Fandrich: On Thu, Feb 28, 2013 at 03:25:41PM +0100, Guillaume Rousse wrote: Build dependencies are usually specified in installation instructions. For humans, of course. You may also try to parse the outpout of ./configure (or equivalent) script. In both case, there is not garanty then every build dependency will get specified. The other way is to work backwards by looking at the install dependencies that rpmbuild discovered, or the NEEDED lines from objdump -x, and adding the -devel versions of those libraries. That won't catch any compile-time-only dependencies, though (like libtool, autoconf or flex) but it will give you something to start from. Note also that some programs will automatically discover what optional libraries are available at build time and configure themselves accordingly. So, if you miss some BuildRequires, you might end up with a binary that works but is missing features. Dan Or you could try to use iurt, which basically does what the buildsystem does, but it either needs a local Mageia mirror, or fast internet connection, or some patience ;) As the buildsystem can only be used by those with full packager accounts, iurt is the corresponding alternative for padawans and everybody else. https://wiki.mageia.org/en/Packagers_Mentoring_Howto#iurt
Re: [Mageia-dev] [RFC] keep or remove the popup asking confirmation for closing any drakxtools
Am 20.02.2013 05:19, schrieb You-Cheng Hsieh: 2013/2/20 Manuel Hiebel manuel.mag...@hiebel.eu: Hello, Since december, any drakxtools (also inside tools of another one) open popup asking user to confirm if he is agree to close the windows. I opened a bug at this time: https://bugs.mageia.org/show_bug.cgi?id=8476 As Thierry asked to speak about this on this mailing, I'm sending this mail. So any comment, opinion, suggestion, enhancement, patch ? The original bug was reported against a live system, so it serves its purpose. Can we have it only show up when running draklive-install? Exactly - (do not show it by default on installed systems) or AT LEAST please provide an option to disable the popup. FWIW, i don't really understand why this has to be discussed further. 10 users wanted this to be removed again for installed systems in that bugreport, and users is what counts here IMHO. In comparison, many developers will probably not see drakxtools that often during daily use, e.g. i can't really remember when i've fired MCC up last time (except for cases when i needed to make a screenshot or look up how something i called in english for support purposes) so they will probably not notice that much. Now imagine the average user, running drakxtools much more often ... Kind regards
[Mageia-dev] Freeze push: razor-qt (fixes mga2-mga3 update)
Hi there, please push razor-qt. It's a bugfix release only to 0.5.2, and i've worked on it so that upgrading from mga2 - 3 works now, as it was broken before. And i've added a missing BuildRequire for two of the basic panel plugins, which was unnoticed until now, it seems. I've also enabled tests, and replaced the URL with the current one, as the github one is not working anymore. The maintainer (Matteo aka pasmatt) told me he's currently quite busy and he's okay with me committing those fixes. barjac helped me with testing build on cauldron, as for me most mirrors are not working currently and iurt often bails :/ Thanks to Barry for that :) Kind regards Florian Hubold
Re: [Mageia-dev] Freeze push: razor-qt (fixes mga2-mga3 update)
Am 16.02.2013 23:09, schrieb Thomas Backlund: Matteo Pasotti skrev 16.2.2013 23:45: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16/02/2013 19:52, Florian Hubold wrote: Hi there, please push razor-qt. It's a bugfix release only to 0.5.2, and i've worked on it so that upgrading from mga2 - 3 works now, as it was broken before. And i've added a missing BuildRequire for two of the basic panel plugins, which was unnoticed until now, it seems. I've also enabled tests, and replaced the URL with the current one, as the github one is not working anymore. Yeap, no new features, just fixes (systemd fix was already applied through a patch - razorqt-0.5.0-systemd.patch). The maintainer (Matteo aka pasmatt) told me he's currently quite busy and he's okay with me committing those fixes. I can confirm :) Well, it would be easier if you would suggest correct package, as the srpm is called razorqt (and not razor-qt like upstream) Anyway... submitted... -- Thomas Sorry, forgot to mention or link to commit :/ But anyways, thanks for pushing :)
Re: [Mageia-dev] File Commander Linux repo configuration
Am 27.12.2012 09:48, schrieb Felix Miata: On 2012-12-27 09:02 (GMT+0100) Guillaume Rousse composed: Felix Miata composed: According to http://silk.apana.org.au/fc2development.html I ought to be able to configure a repo from the content of http://silk.apana.org.au/rpm-stable-dev/fcl.repo : You should reread it more carefully, they are assuming everyone uses yum metadata... Morevoer, a binary package build on fedora 1O isn't likely to install properly on mageia. Mandriva 2009 is explicitly listed. libstdc++5-3.3.6-4mdv2009.0.i586.rpm installs on Cauldron (and AFAICT compat with or substitute for it still isn't available from Mageia repos). So I would expect since that works, so would an FCL rpm expressly built for the same system, even if not conveniently via a configured repo. It's author has been around Linux a long time. I doubt he would claim what he claims about running on/built for old Fedora Mandriva releases if it wouldn't install on newer versions. His goal is for it to just work using a minimum of deps that all distros require or at least provide anyway. It installed for me easily using the supplied repo file at least on openSUSE 11.3, 11.4, 12.1, 12.2 release next. I find it hard to believe it wouldn't install as well on Mageia 1, 2 or next, and I would rather have it from a configured repo instead of having to fetch it manually for each new devel build. You'd better get the source package and rebuild it. I looked around that site but didn't notice source even being available. I guess to find out if it even is requires access via a repo mechanism. Not counting Gentoo, last I built anything from source was more than 5 years ago, and I don't expect it will happen again in my lifetime. I don't build. I test software others build. You should be able to install it via urpmi http://silk.apana.org.au/pub/fcl/filecommander-2.40-release1_fedora10.i386.rpm or urpmi http://silk.apana.org.au/pub/fcl/filecommander-2.40-release1_fedora10.x86_64.rpm for x86_64 system, but that doesn't mean that the package will necessarily work. You can't add a Fedora/RHEL style repo as an urpmi repo, and as it only contains one package, which receives no updates, this is even quite useless.
Re: [Mageia-dev] task-obsolete - questions about implementation details and how to disable it
Am 27.12.2012 09:49, schrieb AL13N: Op donderdag 27 december 2012 00:02:28 schreef Florian Hubold: Am 25.12.2012 22:41, schrieb Charles A Edwards: On Tue, 25 Dec 2012 22:24:56 +0100 Guillaume Rousse wrote: As root, run this command: echo task-obsolete /etc/urpmi/skip.list This will add task-obsolete into the skip list and you can use obsoleted software. even easier: rpm -e task-obsolete Needed, but if you do not add it to the skip.list it will be re-installed the next time you update. Charles OK, so there is currently only the option to have all packages obsoleted or to have the mechanism completely disabled? No proper way to only have selected obsoletes? @Thierry, do you have any other clever solution here? Or some workaround or something similar? i just don't think there's any reasonable use case for this. (if you're not a developer), meaning you can maintain it yourself. Well, i just gave one use case (k9copy) which does not need to be maintained, but has been obsoleted. Which does not mean in turn, there's a drop-in replacement for it and/or that it has become obsolete at all. With that in mind, quoting the author: Published on Sunday, 24 July 2011 Written by Jean-Michel Developments on K9Copy stopped. After seven years, I decided to move on and get involved in other projects. The DVD is obsolete, and I no longer believe in the future of desktop Linux. I started working on this project after the installation of Mandrake. I thought it was wonderful and it could replace Windows. One thing was missing: a software to backup my DVD. That was my first program for Linux. I did not know what language to use, or what programming environment. I chose C + + and KDevelop on KDE, because it worked well on Mandrake. Well, the DVD is not really obsolete, many people still use it and want to provide contents via DVDs as that is the only widespread medium that most people have players for. But i get what you mean, and this is quite a cornercase ... Still i'd be happy if there's some solution for this problem.
Re: [Mageia-dev] task-obsolete - questions about implementation details and how to disable it
Am 25.12.2012 22:41, schrieb Charles A Edwards: On Tue, 25 Dec 2012 22:24:56 +0100 Guillaume Rousse wrote: As root, run this command: echo task-obsolete /etc/urpmi/skip.list This will add task-obsolete into the skip list and you can use obsoleted software. even easier: rpm -e task-obsolete Needed, but if you do not add it to the skip.list it will be re-installed the next time you update. Charles OK, so there is currently only the option to have all packages obsoleted or to have the mechanism completely disabled? No proper way to only have selected obsoletes? @Thierry, do you have any other clever solution here? Or some workaround or something similar?
[Mageia-dev] task-obsolete - questions about implementation details and how to disable it
Hello, this should not be about complaints, only some technical questions. How is task-obsolete supposed to work as a package, i.e. what is the mechanism used to pull it in, and then remove it again? It is required by nothing else, so i guess this is either pulled by urpmi/perl-urpm/rpmdrake itself. Can sombody enlighten me about this? And the next step would be the question for the proper way how to disable this mechanism as an enduser. For a valid scenario, here's an example: Say a user wants to use k9copy, as that's his favorite frontend. Currently he can't, even if he removes task-obsolete, it will get reinstalled during next update, removing k9copy in thee process, at least he told me so. Unfortunately i've never seen it in action, so can't give more details here. But in above scenario, how can a user selectively disable task-obsolete mechanism for this one package without touching task-obsoletes package, removing the obsoletes tag and without disabling obsoletes mechanism altogether? And on a further question: Shouldn't this be only run during distro upgrades, but not within the lifecycle of an released distro? Kind regards (and a merry christmas :) ) Florian
Re: [Mageia-dev] Welcome Götz!
Am 24.10.2012 23:24, schrieb John Balcaen: 2012/10/24 Nicolas Lécureuil nicolas.lecure...@free.fr: Le mercredi 24 octobre 2012 22:50:13 Olav Vitters a écrit : On Mon, Oct 22, 2012 at 11:15:53PM +0200, Olivier Blin wrote: Please welcome him aboard! Yay! Benefited from his work for many many years. ah there is now 2 gnome packagers :) i hope you will talk to make us a even better gnome distro :) Hum there's already more than two. Welcome Götz, long time no see :)
Re: [Mageia-dev] AppStream-Core 0.1 released! (forwarded from distributi...@lists.freedesktop.org)
Am 07.10.2012 11:45, schrieb Samuel Verschelde: AppStream-Core 0.1 released! May i ask when this is planned to drop into cauldron, or not yet?
Re: [Mageia-dev] Suspending package maintainership
Am 04.10.2012 05:26, schrieb Cesar Vargas: Hello I'll take care of: aircrack-ng airsnort devede dvdauthor exaile grip gwibber wireshark Atte. César Vargas -- Linux Registered User: 423743 Linux Registered Machine: 331399 Key GPG: 61513A1E FingerPrinting: 263E 102B B8ED 8F2B 2ACE ED31 9FAD 9DFD 6151 3A1E Please don't forget to set yourself as maintainer via mgarepo for those: https://wiki.mageia.org/en/Packaging_guidelines#Maintaining_a_Package https://wiki.mageia.org/en/Mgarepo#I_want_to_be_set_as_maintainer_of_a_package
Re: [Mageia-dev] Suspending package maintainership
Am 09.08.2012 10:42, schrieb Colin Guthrie: 'Twas brillig, and Florian Hubold at 08/08/12 20:57 did gyre and gimble: Hi all, sadly i need to announce that i'll suspend maintainership because lack of time currently, and in the near future, say at least for the next half year or so. I've already waited a bit too long and some others already did some security updates on my behalf like for wireshark and avidemux. Quite sad about this, but in the end it's better than falsely pretending packages are maintained when they are effectively not. I'll try to take on the bugs which are currently assigned to me as i find the time to do so. In exchange i'd try to mentor one or two new padawans, to somehow make up for the gap. Sad to hear but such is the way of things sometimes. Thankfully you'll still be around generally which is very nice to hear :) All the best Col To finalize this, after resolving most of the bugs which were assigned to me, i've dropped maintainership of all packages which i grabbed to not see them dropped. After all that was maybe not the best idea, as that's nearly the same as having them unmaintained, at least partially. Here's the list: [doktor5000@Mageia2 ~]$ mgarepo maintdb get | grep doktor5000 | grep -vE 'thunderbird|hplip' | cut -d -f1 X11 forwarding request failed on channel 0 2mandvd aircrack-ng airsnort aria2 autoconf autoconf2.1 autogen cairo-dock cairo-dock-plugins cairo-dock-themes ccache chkrootkit conky desktop-file-utils devede dkms dvdauthor e e17_themes e_dbus e_modules ecore edb edje edje_viewer eet efreet eina embryo eterm evas exaile exalt fontforge gpsbabel gramps grip gwibber handbrake hwinfo icecream imlib2 inkscape libast lshw me-tv moovida moovida-plugins-bad moovida-plugins-good moovida-plugins-ugly navit ndiswrapper ntfs-3g qbittorrent task-e17 tesseract wireshark wpa_supplicant x264 xdg-utils Feel free to grab them and care for them ...
[Mageia-dev] Suspending package maintainership
Hi all, sadly i need to announce that i'll suspend maintainership because lack of time currently, and in the near future, say at least for the next half year or so. I've already waited a bit too long and some others already did some security updates on my behalf like for wireshark and avidemux. Quite sad about this, but in the end it's better than falsely pretending packages are maintained when they are effectively not. I'll try to take on the bugs which are currently assigned to me as i find the time to do so. In exchange i'd try to mentor one or two new padawans, to somehow make up for the gap. Best Regards Florian
Re: [Mageia-dev] Fwd: [VDPAU] [PATCH] Implement workarounds for Adobe Flash bugs
Am 26.07.2012 14:15, schrieb Glen Ogilvie: On Wed, Jul 25, 2012 at 5:00 AM, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and Glen Ogilvie at 24/07/12 11:06 did gyre and gimble: On Tue, May 22, 2012 at 8:56 AM, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and Colin Guthrie at 03/05/12 17:00 did gyre and gimble: 'Twas brillig, and Anssi Hannula at 03/05/12 15:37 did gyre and gimble: I think we should probably apply the below libvdpau workaround for Adobe Flash issues, for both mga2 and mga1, WDYT? Sounds like a good idea. I tend to trust Stephen's work generally, even if I don't know much about the VDPAU issues specifically. Don't think these were ever pushed. I just tested this patch on a machine that is half built here. It worked OK provided you also include the only commit from git master since 0.4.1 too. Seemed to work OK for me, but haven't managed to test too much yet. Col Hi Colin, Do you happen to have an SRPM or RPM for mageia2 I could test?I have a system that suffers from the problem this patch fixes. You can try the srpm from here: http://colin.guthr.ie/libvdpau-0.4.1-3.1.csg3.src.rpm There may very well be newer updates and releases now, I've not checked. All I did was add the only patch from git master: http://cgit.freedesktop.org/~aplattner/libvdpau/ and then apply the other patch on top. They are both in the srpm. I've tested the SRPM above it on my system and it resolves the blue tint issue. Thank you. Hope someone can get this into Mageia testing for others to test. Regards Glen Ogilvie Following up on this, this also solved the blue tint issue for me, and also that the flash overlay shows f.ex. in konsole windows and similar things. Shouldn't we put out an update for Mageia 2 at least for this issue?
Re: [Mageia-dev] Last signs of life from maintainers in Bugzilla
Am 08.06.2012 12:53, schrieb Marja van Waes: On 08-06-12 11:29, Marja van Waes wrote: On 07-06-12 09:41, Marja van Waes wrote: Hi everyone, AFAIK, there isn't an easy way to find the last sign of life of a maintainer in our Bugzilla, I use the bugzilla-daemon mails for that. The last sign of life of: supp (Tomáš Kindl) was on *2011-11-24* when he changed the status of bug 3429 to ASSIGNED shikamaru (Rémy Clouard) was on 2012-05-31, when he commented in bug 2822. That looks like he's still alive, however, his last sign of life in a ruby-* bug was on *2011-10-22*, in bug 3070 cjw alias spturtle (Christiaan Welvaart) was on *2011-12-30*, when he commented in bug 2157 Another one: dlucio (Daniel Lucio, AKA Luis Daniel Lucio Quiroz) *2012-04-28* when he closed bug 5605 as fixed He mentioned he had problems with email, but now: [11:28] xochiquetzal dlucio was last seen in #mageia-dev 67 days 7 hours ago saying whos fixing mysql-admin?. lol: another one erwan (Erwan Velu) *2011-10-05* @ Erwan I know you're not dead, can you please have a look at bugs 44, 2038 and 2652. or tell us if you're too busy or whatever and they should be reassigned? To be fair, supp recently dropped one of the packages which had him listed as maintainer (hplip). Apart from that, i've never saw him in action. spturtle recently just got active again, put out an update for iceape for Mageia 1 and just helped to get out an firefox beta build. shikamaru was already away for quite some time, and currently the whole ruby stack in Mageia 2 is unmaintained, AFAIK.
Re: [Mageia-dev] What to use instead of /dev/usb/lp*
Am 25.07.2012 20:05, schrieb Christiaan Welvaart: On Wed, 25 Jul 2012, Jeff Robins wrote: On Wed, Jul 25, 2012 at 2:11 AM, Claire Robinson m...@gmail.com wrote: usblp is blacklisted but you may find using modprobe usblp cures it for you. If it does then comment it in /etc/modprobe.d/blacklist-cups-common.conf or remove that file. I'll give that a try. Is there a better/newer way to access the device? I'd like to update and fix the program if possible. The blacklisting is not needed anymore with recent cups(?) according to https://bugs.launchpad.net/ubuntu/+source/cups/+bug/902970/comments/12 so removing the file from the cups package should be the solution. Christiaan Are you sure we have the exact same cups usb backend as in recent *buntu versions? AFAIK usblp caused some segfaults and crashes, so it was blacklisted by default. But if any program loads it explicitely, it will work.
Re: [Mageia-dev] What to use instead of /dev/usb/lp*
Am 28.07.2012 15:34, schrieb Christiaan Welvaart: On Sat, 28 Jul 2012, Florian Hubold wrote: Am 25.07.2012 20:05, schrieb Christiaan Welvaart: On Wed, 25 Jul 2012, Jeff Robins wrote: On Wed, Jul 25, 2012 at 2:11 AM, Claire Robinson m...@gmail.com wrote: usblp is blacklisted but you may find using modprobe usblp cures it for you. If it does then comment it in /etc/modprobe.d/blacklist-cups-common.conf or remove that file. I'll give that a try. Is there a better/newer way to access the device? I'd like to update and fix the program if possible. The blacklisting is not needed anymore with recent cups(?) according to https://bugs.launchpad.net/ubuntu/+source/cups/+bug/902970/comments/12 so removing the file from the cups package should be the solution. Christiaan Are you sure we have the exact same cups usb backend as in recent *buntu versions? AFAIK usblp caused some segfaults and crashes, so it was blacklisted by default. But if any program loads it explicitely, it will work. No, but I plan to update cups to 1.5.4 which has those fixes for usb AFAICT, see http://www.cups.org/str.php?L4128 . Maintenance of cups is greatly appreciated, thanks ;)
Re: [Mageia-dev] Welcome new packager: vaci0
Am 28.07.2012 10:55, schrieb Shlomi Fish: On Fri, 27 Jul 2012 23:40:34 -0500 Juan Luis Baptiste juan...@mageia.org wrote: Hi, I'm proud to announce that Cesar Vargas (vaci0), one of blogdrake's packagers just got submit rights and will be leaving the padawan ranks to become another jedi :D Please welcome to the Mageia packaging team !! Congratulations! And welcome aboard. Regards, Shlomi Fish Cheers, Congratulations, also to Juancho for his continuous work with blogdrake packagers, absolutely appreciated :)
Re: [Mageia-dev] Fwd: [VDPAU] [PATCH] Implement workarounds for Adobe Flash bugs
Am 28.07.2012 15:31, schrieb Dimitrios Glentadakis: 2012/7/28 Anssi Hannula an...@mageia.org mailto:an...@mageia.org Submitted to cooker,mga2,mga1, update request here: https://bugs.mageia.org/show_bug.cgi?id=6892 I also added support for konqueror and opera into the workaround. -- Anssi Hannula Thanks for including these two browsers, i use konqueror and my wife uses opera :) -- Dimitrios Glentadakis Anssi, you're awesome as always, thanks :)
[Mageia-dev] Current status of Mageia ARM port
Hi all, i'd like to know what the current status of the ARM port is and if there's any documentation available, and if so, where? I may be forgiven for asking, as i still have ~800 unread -dev mails, but i saw there was somebody asking for ARM on Raspberry Pi, but not any results so far. Only ocassions where i saw ARM port mentioned was in https://wiki.mageia.org/en/Mageia_2_Release_Notes#Stage_1 and http://packages.rtp-net.org/mageia/cauldron/armv5tl/docs/README.ARMv5TL which seems quite outdated from looking at the mtime. And what does that mean currently, one can fire up stage1 on an ARM system and just point it to rtp's ARM mirror, and it will install, say basesystem-minimal or so? Or still much porting work to be done? Regards
Re: [Mageia-dev] Updating usb_modeswitch in mga2
Am 03.06.2012 20:45, schrieb Colin Guthrie: Hi, In order to fix https://bugs.mageia.org/show_bug.cgi?id=4853 we would need a newer usb_modeswitch (and it's -data supplement). Do you think it's worth updating to the newest version? I don't know this package well but it would seem to be quite a safe one for updating (especially the -data package) Col CCing dams as he updated usb_modeswitch in cauldron the other day - I've updated the -data package today. I'm totally for it, as it was pretty much unmaintained before, and there are quite some issues about usb_modeswitch, so it's just better if there are less of these issues, and more hardware gets supported.
Re: [Mageia-dev] help with update/testing needed / freeze exception for me-tv
Am 11.05.2012 15:14, schrieb Wolfgang Bornath: 2012/5/11 Wolfgang Bornath molc...@googlemail.com: 2012/5/9 Florian Hubold doktor5...@arcor.de: Am 09.05.2012 12:44, schrieb Colin Guthrie: 'Twas brillig, and Wolfgang Bornath at 05/05/12 21:06 did gyre and gimble: 2012/5/5 Wolfgang Bornath molc...@googlemail.com: 2012/5/5 Florian Hubold doktor5...@arcor.de: Am 05.05.2012 21:04, schrieb Wolfgang Bornath: 2012/4/4 Florian Hubold doktor5...@arcor.de: But as me-tv development was suspended, and now restarted (2.0 branch was complete rewrite, with differing features, f.ex. server/client based) so that 1.4 branch is the followup to what we have in cauldron: https://launchpad.net/me-tv/+announcement/9377 FWIW, me-tv-1.3.6 in cauldron was built last time beginning of last july. I'd like to get some sort of freeze exception for me-tv, but primarily help with testing this in cauldron, i've just pushed a rebuild of it, could all who possess a DVB-receiver and a physical cauldron installation please test it, should be available soon, rebuild went through. And as the developer says that new 1.4 branch is still buggy, i'm updating me-tv to 1.3.7 and hope it'll fix the issue. *fingers crossed* Bug fixed here with new package 1.3.6-4mga2 But another is opened: After starting me-tv it starts in a small window and displays the first station in the list. Right after start the window and the icons in the window are not responding to any mouse action. Closing the window via close button results in a crash message from kwin. Funny thing: while the window and buttons are not responding, the display of the tv signal is still working including sound. Arf! Starting again and letting the window alone for a minute, then clicked on Maximum and it worked. Other buttons are working as well. A minute later it freezes again. It's very unstable. As already told in forum thread, i've locally prepared some packages for me-tv-1.4.0.9 which is the latest version upstream currently, and it at least starts. If somebody wants to try those out or wants to help with testing in between, just contact me or ping me on IRC. Otherwise suspending this until after the mga2 release.
Re: [Mageia-dev] Proposal to drop the package wicd
Am 14.05.2012 01:05, schrieb David W. Hodgins: On Sat, 12 May 2012 08:40:15 -0400, zezinho lists.jjo...@free.fr wrote: Em 12-05-2012 05:39, David W. Hodgins escreveu: I think the package should be made obsolete in both Cauldron, and Mageia 1. Opinions? I agree. If no-one objects, I'll post a request to the sysadmin team in a few hours. Regards, Dave Hodgins I'm also in favour of removing it.
[Mageia-dev] Freeze push request: task-e17
Please push task-e17, it only adds a Suggests on xterm to make the default terminal launcher work properly.
[Mageia-dev] Freeze push request: fontforge
Please push fontforge, i've removed an unneeded explicit Require on mfwin, which would pull texlive, which is not needed.
Re: [Mageia-dev] Freeze push: edje_viewer
Am 08.05.2012 23:16, schrieb Anne Nicolas: Le 08/05/2012 22:13, Florian Hubold a écrit : Please push edje_viewer, it updates our outdated snapshot to a recent one, and adds a patch to fix recent API breakage. Previously it segfaulted directly, now it works as intended. Failed. Please fix and mail again Fixed (damn .desktop file validation problems, not caught locally). Please repush.
Re: [Mageia-dev] help with update/testing needed / freeze exception for me-tv
Am 09.05.2012 12:44, schrieb Colin Guthrie: 'Twas brillig, and Wolfgang Bornath at 05/05/12 21:06 did gyre and gimble: 2012/5/5 Wolfgang Bornath molc...@googlemail.com: 2012/5/5 Florian Hubold doktor5...@arcor.de: Am 05.05.2012 21:04, schrieb Wolfgang Bornath: 2012/4/4 Florian Hubold doktor5...@arcor.de: Hi all, me-tv (a really nice and easy to-use DVB viewer with EPG guide) totally went under my radar and it has not been updated nor rebuild yet for cauldron since quite some time, seems i forgot to commit my local update to 2.x branch, and me-tv was not covered by check.mageia.org updates report, and i've to update it when i was still apprentice. But as me-tv development was suspended, and now restarted (2.0 branch was complete rewrite, with differing features, f.ex. server/client based) so that 1.4 branch is the followup to what we have in cauldron: https://launchpad.net/me-tv/+announcement/9377 FWIW, me-tv-1.3.6 in cauldron was built last time beginning of last july. I'd like to get some sort of freeze exception for me-tv, but primarily help with testing this in cauldron, i've just pushed a rebuild of it, could all who possess a DVB-receiver and a physical cauldron installation please test it, should be available soon, rebuild went through. What exactly do you need (sorry for picking this up so late)? Todays experience as posted in the forum: Cauldron 64-bit with all updates. KDE. Real installation on a Samsung R530. Adapter Happauge Nova-T, firmware: dvb-usb-dib0700-1.20.fw in /lib/firmware, plugging in the adapter gives success message in syslog: Hauppauge Nova-T in warm state Installed is me-tv (including dependencies): me-tv-1.3.6-3.mga2 dvb-apps-1.1.1-8.hg1465.1.mga2 lib64unique1.0_0-1.1.6-6.mga2 lib64dvbapps-1.1.1-8.hg1465.1.mga2 After installation and starting the application me-tv shows a message that the existing Me-Tv database is to old to be used by this version. This sounds like complete bogus to me, as the only version of me-tv for Mageia 1 and cauldron is 1.3.6, there should be no difference at all. But different builds. This cauldron install, was it upgraded from mga1, or where did the old .me-tv config come from? Fresh Beta3 installation. The database (NOT config!) file is me-tv.db and it is installed by the package. I also tried erasing the file after installation before starting the application - the message about the old db persists. See below But if this problem persists, mostly all me-tv users should face it after upgrading from Mageia 1 to Mageia 2, so we probably need some kind of fix for this ... Option Cancel ends the whole application, clicking on Erase old Me-Tv data the messagebox runs into a freeze which crashes the whole application. In the konsole this looks like: $ me-tv -v Me TV 1.3.6 05.05.2012 15:02:55: Application constructor 05.05.2012 15:02:55: sqlite3_threadsafe() = 1 05.05.2012 15:02:55: Database 'exists' 05.05.2012 15:02:55: Opening database file '/home/alfred/.local/share/me-tv/me-tv.db' 05.05.2012 15:02:55: Loading UI files 05.05.2012 15:02:55: Application constructed 05.05.2012 15:02:55: Initialising table 'version' 05.05.2012 15:02:55: Required Database version: 6 05.05.2012 15:02:55: Actual Database version: 0 --- here the message box pops up and I click on Erase old data 05.05.2012 15:03:26: Dropping Me TV schema 05.05.2012 15:03:26: Dropping table 'channel' 05.05.2012 15:03:26: Dropping table 'epg_event' 05.05.2012 15:03:26: Dropping table 'epg_event_text' 05.05.2012 15:03:26: Dropping table 'scheduled_recording' 05.05.2012 15:03:26: Dropping table 'version' 05.05.2012 15:03:26: Vacuuming database 05.05.2012 15:03:27: Initialising table 'channel' 05.05.2012 15:03:27: Initialising table 'epg_event' 05.05.2012 15:03:27: Initialising table 'epg_event_text' 05.05.2012 15:03:27: Initialising table 'scheduled_recording' 05.05.2012 15:03:27: Initialising table 'version' and that's it. In MGA1 Me-TV works nicely with the same adapter. In MGA1 the package is me-tv-1.3.6-1.1.mga1 - in MGA2 the packages is me-tv-1.3.6-3.mga2 Can you please try again after removing ~/.local/share/me-tv/ ? - removed ~/.local/share/me-tv/ (including the me-tv.db) Result: Starting me-tv runs into a timeout. Message in konsole: (me-tv:1956) : Unique-DBUS-WARNING **: Error while sending message: Did not receive a reply. Possible causes include [followed by the generic causes ( message bus security block, reply timeout expired, network connection broke, etc.)] After reboot I started me-tv again, the message about the old database appears - ~/.local/share/me-tv/ is there again, including the database. Now I installed me-tv (plus dependencies) on a Cauldron which has been updated since Alpha stage: exactly the same result. Another user posted his erg.txt
[Mageia-dev] Freeze push request: me-tv
Please push me-tv, it fixes the problem where if started for the first time, it complains about database being too old ad not starting at all. This fix has been backported from 1.3.7.
[Mageia-dev] Freeze push: edje_viewer
Please push edje_viewer, it updates our outdated snapshot to a recent one, and adds a patch to fix recent API breakage. Previously it segfaulted directly, now it works as intended.
Re: [Mageia-dev] Freeze push: kmess
Am 02.05.2012 09:56, schrieb Funda Wang: Hello, Could kmess 2.0.6.2 be pushed to fix bug#3336 (empty contact list after logging in)? Thanks. This has also been commited to mga1, will you submit there too? Problem was also reported via forums recently.
[Mageia-dev] Freeze push request: e / e_modules
Due to some upgrade issues because version issues with Conflicts: tags, please push e and e_modules. Kind Regards
[Mageia-dev] Freeze push request: e / e17-themes
Hi, please push e17-themes and e itself. The default theme has been changed to the one with the new Mageia 2 background, but for this it needed to be moved to main e package. Hopefully this will be the last push ;) Kind Regards
[Mageia-dev] Freeze push request: hplip / testing and volunteer needed
Hi, please push hplip. Usually we keep this updated to latest version to get the best printer support. Additionally, there have been some fixes for newer AIO devices. Excerpt from commit message: o Print/Fax queues can now be analyzed by running hp-diagnose-queues o fixes some issues and duplex scanning support with newer AIO devices o fixes Wireless configuration using hp-wificonfig command for HP Deskjet 3000 J310 series and HP Deskjet 3050 J610 series o fixes the blurry printing issue on HP LaserJet CP1025 and CP1025nw Full upstream changelog available at http://hplipopensource.com/hplip-web/release_notes.html Only problem is i can't really test it myself, as i don't have an HP printer. Also i'd need support from someone with an HP printer which needs a plugin, to troubleshoot and fix https://bugs.mageia.org/show_bug.cgi?id=5395 Any volunteers?
Re: [Mageia-dev] Freeze push request: e / e17-themes
Am 29.04.2012 14:38, schrieb Florian Hubold: Hi, please push e17-themes and e itself. The default theme has been changed to the one with the new Mageia 2 background, but for this it needed to be moved to main e package. Hopefully this will be the last push ;) Kind Regards Ping?
Re: [Mageia-dev] Freeze push request: hplip / testing and volunteer needed
Am 29.04.2012 14:43, schrieb Florian Hubold: Hi, please push hplip. Usually we keep this updated to latest version to get the best printer support. Additionally, there have been some fixes for newer AIO devices. Excerpt from commit message: o Print/Fax queues can now be analyzed by running hp-diagnose-queues o fixes some issues and duplex scanning support with newer AIO devices o fixes Wireless configuration using hp-wificonfig command for HP Deskjet 3000 J310 series and HP Deskjet 3050 J610 series o fixes the blurry printing issue on HP LaserJet CP1025 and CP1025nw Full upstream changelog available at http://hplipopensource.com/hplip-web/release_notes.html Only problem is i can't really test it myself, as i don't have an HP printer. Also i'd need support from someone with an HP printer which needs a plugin, to troubleshoot and fix https://bugs.mageia.org/show_bug.cgi?id=5395 Any volunteers? Ping? To test the plugin installation, maybe it's already enough to do a rebuild without applying Patch213: hp-mkuri-take-into-account-already-installed-plugin-also-for-exit-value.dpatch
[Mageia-dev] Freeze push request: thunderbird and thunderbird-l10n
Hi, please push thunderbird and thunderbird-l10n, was just updated to 10.0.4ESR and fixes the following issues: o fixes http://www.mozilla.org/security/announce/2012/mfsa2012-20.html (Miscellaneous memory safety hazards [CVE-2012-0468, CVE-2012-0467]) o fixes http://www.mozilla.org/security/announce/2012/mfsa2012-22.html (use-after-free in IDBKeyRange[CVE-2012-0469]) o fixes http://www.mozilla.org/security/announce/2012/mfsa2012-23.html (Invalid frees causes heap corruption in gfxImageSurface [CVE-2012-0470]) o fixes http://www.mozilla.org/security/announce/2012/mfsa2012-24.html (Potential XSS via multibyte content processing errors [CVE-2012-0471]) o fixes http://www.mozilla.org/security/announce/2012/mfsa2012-25.html (Potential memory corruption during font rendering using cairo-dwrite [CVE-2012-0472]) o fixes http://www.mozilla.org/security/announce/2012/mfsa2012-26.html (WebGL.drawElements may read illegal video memory due to FindMaxUshortElement error [CVE-2012-0473]) o fixes http://www.mozilla.org/security/announce/2012/mfsa2012-27.html (Page load short-circuit can lead to XSS [CVE-2012-0474]) o fixes http://www.mozilla.org/security/announce/2012/mfsa2012-28.html (Ambiguous IPv6 in Origin headers may bypass webserver access restrictions [CVE-2012-0475]) o fixes http://www.mozilla.org/security/announce/2012/mfsa2012-29.html (Potential XSS through ISO-2022-KR/ISO-2022-CN decoding issues [CVE-2012-0477]) o fixes http://www.mozilla.org/security/announce/2012/mfsa2012-30.html (Crash with WebGL content using textImage2D [CVE-2012-0478]) o fixes http://www.mozilla.org/security/announce/2012/mfsa2012-31.html (Off-by-one error in OpenType Sanitizer [CVE-2011-3062]) o fixes http://www.mozilla.org/security/announce/2012/mfsa2012-33.html (Potential site identity spoofing when loading RSS and Atom feeds [CVE-2012-0479]) - switch to Enigmail 1.4, officially supported version for ESR releases o fixes a problem with inline PGP decrpytion Kind Regards
Re: [Mageia-dev] Freeze push request: thunderbird and thunderbird-l10n
Am 26.04.2012 20:13, schrieb nicolas vigier:
On Thu, 26 Apr 2012, Florian Hubold wrote:
Hi,
please push thunderbird and thunderbird-l10n,
was just updated to 10.0.4ESR and fixes the following issues:
thunderbird submitted, but there was an error for thunderbird-l10n :
error: Bad file:
/var/lib/schedbot/repsys/tmp/tmpJkNlGS/SOURCES/%{language_ast}.xpi: No
such file or directory
Should be OK now, please repush.
[Mageia-dev] Freeze push request: e17-themes
Hi, please push again e17-themes. It has been renamed and split into two subpackages, e17-themes-mageia and e17-themes-extra, and three new exclusive Mageia themes, kindly provided by Agust, have been added. Kind Regards
Re: [Mageia-dev] [Mageia-discuss] many systemd temporary directories
Am 24.04.2012 20:51, schrieb Juergen Harms: I just saw that systemd creates (and does not purge) lots of directories like /tmp/systemd-namespace-uniqueid/ - I now have nearly 50 of them (one partial explanation might be that I did quite some re-booting these last days). Nothing serious, they are small - but nevertheless ... Is this normal, shouldnt there be some automatic purging mechanism? Juergen Maybe we should default to /tmp being on tmpfs so that this gets purged on every reboot? This would also be more in accordance with FHS imho. CC'ing -dev for this one.
Re: [Mageia-dev] DVD isos content
Am 24.04.2012 22:46, schrieb Anne Nicolas: Hi there As you may have seen, we have some room left on DVD isos. Please answer this mail if you have some proposals for apps to be added (about 500Mo left) and why we should add it in iso. Cheers Maybe i've just not seen it, but is there some pastebin or wiki document of the current list, or is it still the same as of beta3 state, e.g. http://ftp.mandrivauser.de/mirrors/Mageia/iso/cauldron/Mageia-2-beta3-i586-DVD/Mageia-2-beta3-i586-DVD.idx ? For one, maybe we could put new version of e17-themes-mageia on it when we renamed it, as Agust was so nice to provide even more exclusive Mageia themes for us. So we plan on installing e17-themes-mageia by default with task-e17 and e17-themes-extra wouldn't even need to be on the DVD. (package rename still needs to be done, so i have no numbers yet, was busy with thunderbird 10.0.4esr)
Re: [Mageia-dev] [Mageia-discuss] many systemd temporary directories
Am 24.04.2012 22:51, schrieb Colin Guthrie: 'Twas brillig, and Florian Hubold at 24/04/12 21:27 did gyre and gimble: Am 24.04.2012 20:51, schrieb Juergen Harms: I just saw that systemd creates (and does not purge) lots of directories like /tmp/systemd-namespace-uniqueid/ - I now have nearly 50 of them (one partial explanation might be that I did quite some re-booting these last days). Nothing serious, they are small - but nevertheless ... Is this normal, shouldnt there be some automatic purging mechanism? Juergen Maybe we should default to /tmp being on tmpfs so that this gets purged on every reboot? This would also be more in accordance with FHS imho. This is one of my goals for mga3 (I have it in my notes for the technical specs discussion that will come), but certainly not for mga2 as this is quite a big change and some apps may have to be patched to use /var/tmp instead etc. if they store large things in there. Col Well, this is what FHS says (in an ideal world it would reflect reality) Programs must not assume that any files or directories in /tmp are preserved between invocations of the program. IEEE standard P1003.2 (POSIX, part 2) makes requirements that are similar to the above section. Although data stored in /tmp may be deleted in a site-specific manner, it is recommended that files and directories located in /tmp be deleted whenever the system is booted. Just mentioned it as one possible solution to the problem at hands.
Re: [Mageia-dev] sun java issue for mga 1 handling
Am 22.04.2012 20:01, schrieb Guillaume Rousse: Despite not realling blocking for mageia 2 release, the issue is still to address, the sooner the better. Here are the previous discussion references: https://bugs.mageia.org/show_bug.cgi?id=3101 https://www.mageia.org/pipermail/mageia-dev/2012-March/013649.html Various proposal sofar: 1) provide an upgrade package with current content and some README.urpmi file telling to fetch it from oracle 2) provide an upgrade package with just the README.urpmi file 3) provide an upgrade package with some kind of automated downloading script We need both a consensus and someone to implement it, preferentially the maintainer of course. I personally think 3 is way too much work for the added value, and 2 seem both the easiest and safer option. I'm all for 2.
Re: [Mageia-dev] Freeze push request: wireshark
Am 16.04.2012 20:07, schrieb Florian Hubold: Please push wireshark-1.6.7, it's a bugfix release fixing following problems: o fixes a bug with Malformed Packets H263-1996 [RFC2190] (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6996) o fixes a crash when trying to open an rpcap: URL (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6922) ping?
Re: [Mageia-dev] Freeze push request: e17_themes
Am 16.04.2012 21:15, schrieb Florian Hubold: Am 15.04.2012 20:51, schrieb Anne Nicolas: Le 15/04/2012 17:06, Florian Hubold a écrit : Please submit e17_themes, it updates the selection of e17 themes to remove some non-working ones, and adds two new mageia themes, made from a new member of the artwork team: https://forums.mageia.org/en/viewtopic.php?f=11t=2061 submitted Please repush, Agust just sent me the final version of his new Moon-Mageia theme with animated background. So now we have 3 exclusive Mageia E17 themes :) ping?
Re: [Mageia-dev] Freeze push request: e17_themes
Am 17.04.2012 21:27, schrieb Anne Nicolas: Le 17/04/2012 21:24, Florian Hubold a écrit : Am 16.04.2012 21:15, schrieb Florian Hubold: Am 15.04.2012 20:51, schrieb Anne Nicolas: Le 15/04/2012 17:06, Florian Hubold a écrit : Please submit e17_themes, it updates the selection of e17 themes to remove some non-working ones, and adds two new mageia themes, made from a new member of the artwork team: https://forums.mageia.org/en/viewtopic.php?f=11t=2061 submitted Please repush, Agust just sent me the final version of his new Moon-Mageia theme with animated background. So now we have 3 exclusive Mageia E17 themes :) ping? submitted thanks for both submissions :)
[Mageia-dev] Freeze push request: wireshark
Please push wireshark-1.6.7, it's a bugfix release fixing following problems: o fixes a bug with Malformed Packets H263-1996 [RFC2190] (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6996) o fixes a crash when trying to open an rpcap: URL (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6922)
Re: [Mageia-dev] Freeze push request: e17_themes
Am 15.04.2012 20:51, schrieb Anne Nicolas: Le 15/04/2012 17:06, Florian Hubold a écrit : Please submit e17_themes, it updates the selection of e17 themes to remove some non-working ones, and adds two new mageia themes, made from a new member of the artwork team: https://forums.mageia.org/en/viewtopic.php?f=11t=2061 submitted Please repush, Agust just sent me the final version of his new Moon-Mageia theme with animated background. So now we have 3 exclusive Mageia E17 themes :)
[Mageia-dev] Freeze push request: e17_themes
Please submit e17_themes, it updates the selection of e17 themes to remove some non-working ones, and adds two new mageia themes, made from a new member of the artwork team: https://forums.mageia.org/en/viewtopic.php?f=11t=2061
Re: [Mageia-dev] Freeze push request: expedite
Am 15.04.2012 18:47, schrieb Philippe Reynes: Hi, Please submit expedite, it updates the argument of expedite, x11 is replaced by xlib. doktor5000, are you agree with this change ? Sure, as i suggested it on behalf of malo :) regards, trem
Re: [Mageia-dev] [RFC] How to proceed with seamonkey/iceape for security updates and freeze push
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 ;)
Re: [Mageia-dev] [RFC] How to proceed with seamonkey/iceape for security updates and freeze push
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.
Re: [Mageia-dev] [RFC] How to proceed with seamonkey/iceape for security updates and freeze push
Am 07.04.2012 21:25, schrieb Maarten Vanraes: 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... Well, when i pointed out those branding issues before, noone was interested either, here on this list ...
[Mageia-dev] help with update/testing needed / freeze exception for me-tv
Hi all, me-tv (a really nice and easy to-use DVB viewer with EPG guide) totally went under my radar and it has not been updated nor rebuild yet for cauldron since quite some time, seems i forgot to commit my local update to 2.x branch, and me-tv was not covered by check.mageia.org updates report, and i've to update it when i was still apprentice. But as me-tv development was suspended, and now restarted (2.0 branch was complete rewrite, with differing features, f.ex. server/client based) so that 1.4 branch is the followup to what we have in cauldron: https://launchpad.net/me-tv/+announcement/9377 FWIW, me-tv-1.3.6 in cauldron was built last time beginning of last july. I'd like to get some sort of freeze exception for me-tv, but primarily help with testing this in cauldron, i've just pushed a rebuild of it, could all who possess a DVB-receiver and a physical cauldron installation please test it, should be available soon, rebuild went through. Project page: https://launchpad.net/me-tv Thanks in advance.
Re: [Mageia-dev] [RFC] How to proceed with seamonkey/iceape for security updates and freeze push
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.
Re: [Mageia-dev] usb printers
Am 02.04.2012 21:20, schrieb zezinho: Em 02-04-2012 20:50, David W. Hodgins escreveu: Note that it is needed for some printers so if blacklisting by default is enabled, that should at least be pointed out in a README.urpmi file, so users of those printers will know how to un-blacklist it. Blacklisting only prevents automatic load of the module AFAIK. So a simple modprobe still works for printers needing it. The problem is that no list exists of printers that need it... FWIW i've already brought the blacklisting issue up at https://bugs.mageia.org/show_bug.cgi?id=4279#c7 usblp is needed at least for most canon and some samsung printers, a few kyoceras and for all usb-parallel converter. Everybody who uses something like that, will not be able to set up their printer from MCC, until they un-blacklist usblp. And from where would they know? A README.urpmi will not be displayed for initial Mageia installations, so people doing a fresh mga2 install will not even notice this change. So it also has to be put in release notes, if blacklisted.
Re: [Mageia-dev] [RFC] How to proceed with seamonkey/iceape for security updates and freeze push
Am 30.03.2012 11:41, schrieb Samuel Verschelde: Le mardi 27 mars 2012 21:10:04, Florian Hubold a écrit : So if noone volunteers and ensures to keep it updated for stable distros, i'm gonna drop it from cauldron next week, before it's too late. What about adding it to task-obsolete and then if no maintainer is found for Mageia 3 drop it completely? Samuel Well, dropping it means obsoleting it. It can be revived at any later time if someone feels up to it. Seems we mean the same thing, which was documented by boklm at https://wiki.mageia.org/en/Packaging_guidelines#Obsoleting_a_package Feel free to have a look if the servers are back up again ;)
Re: [Mageia-dev] Problems with flash 11.2
Am 31.03.2012 11:43, schrieb zezinho: Em 31-03-2012 10:46, JA Magallón escreveu: BTW, how can I check if html5 has hardware support ? CPU load? Maybe you want to check http://www.phoronix.com/scan.php?page=news_itempx=OTc4Nw or http://www.tomshardware.com/reviews/web-browser-performance-standard-html5,3013-10.html and for a performance test http://demos.hacks.mozilla.org/openweb/HWACCEL/ You should get 60+FPS as test result for the latter.
Re: [Mageia-dev] Problems with flash 11.2
Am 31.03.2012 21:03, schrieb Florian Hubold: Am 31.03.2012 11:43, schrieb zezinho: Em 31-03-2012 10:46, JA Magallón escreveu: BTW, how can I check if html5 has hardware support ? CPU load? Maybe you want to check http://www.phoronix.com/scan.php?page=news_itempx=OTc4Nw or http://www.tomshardware.com/reviews/web-browser-performance-standard-html5,3013-10.html and for a performance test http://demos.hacks.mozilla.org/openweb/HWACCEL/ You should get 60+FPS as test result for the latter. Ahh, forgot to tell, in Firefox you can check via about:support scroll to the bottom, and there you'll see your current graphics driver and the WebGL renderer.
Re: [Mageia-dev] Removal of sun java
Am 29.03.2012 19:35, schrieb David Walser: D.Morgan dmorganec@... writes: Hi, i removed java sun from non free repository as now we are not able to provide it anymore. Should we have openjdk obsolete it so this insecure thing gets removed from users systems who already have it installed? Actually i thought https://bugs.mageia.org/show_bug.cgi?id=3101#c10 to be a good idea. So we should now at least have it automatically removed from end-user machines, one way or another. This is not about babysitting, but caring for security of our users.
Re: [Mageia-dev] texlive missing files/apps in Mageia
Am 29.03.2012 00:39, schrieb simple w8: 2012/3/22 Thomas Spuhler tho...@btspuhler.com: On Wednesday, March 21, 2012 02:17:15 PM simple w8 wrote: 2012/3/21 Claire Robinson m...@gmail.com: On 21/03/12 15:25, simple w8 wrote: 2012/3/21 Oliver Burgeroliver@googlemail.com: Am 21.03.2012 14:33, schrieb simple w8: Hi, Today i have tried to package an updated wpa_supplicant (from git) and was not possible due to missing texlive features. [...] I can't find the format file `pdfjadetex.fmt'! make: *** [pdf] Error 9 Is jadetex installed? Oliver Yes This is probably related to bug 1538 https://bugs.mageia.org/show_bug.cgi?id=1538 jadetex is missing a require on texlive-texmf Try installing texlive-texmf and reinstalling jadetex. Claire All texlive packages are isntalled along with jadetex. For what i see there are missing apps from texlive, there are severall texlive packages, not just single source. Maybe texlive maintainer could check mandriva texlive packages and update mageia Mandriva is very different, they divide the texlive package into about 1,500 packages. The point is that are missing texlive files that for example are required to build wpa_supplicant documentation like i have previously pointed. Well, there's a manpage, what documentation are you missing? -- Best regards Thomas Spuhler
Re: [Mageia-dev] [RFC] How to proceed with seamonkey/iceape for security updates and freeze push
Am 29.03.2012 12:13, schrieb nicolas vigier: On Wed, 28 Mar 2012, Florian Hubold wrote: OK, so how do we handle this? As there is no explicit permission by Mozilla to have us ship officially branded Mozilla apps, as i've put up before, or at least i don't know of any explicit permission. It seems that if we don't have major changes, there should be no problem to have permission. So I think someone should ask for permission for firefox and thunderbird. Does anyone know where it should be asked ? Judging by https://bugzilla.mozilla.org/show_bug.cgi?id=555935 it should be done through Mozilla bugzilla, and they're going through each patch and every change. But i don't see chances that we'll get through this until release freeze, that's why i've tried to put this up before. I've just mailed Kev Needham (Mozilla Distribution Channel Manager) how to proceed with a trademark permission request and if there's an estimate how much time that would take.
Re: [Mageia-dev] Removal of sun java
Am 29.03.2012 22:23, schrieb Maarten Vanraes: 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. So you say that you really want to keep an outdated package with many security holes, which even the infamous Zeus bot is said to exploit? Sure, that's your choice and you're free to do this, but we can't keep our users susceptible to such problems. 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. That was the proposal, and that's what Ubuntu has done, IIRC, they blanked the existing packages and notified people, that they should either use OpenJDK or manually get Java from Oracle. (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] freeze push: wireshark
Am 28.03.2012 10:59, schrieb Guillaume Rousse: 1.6.6 is a bugfix release. Thanks for pushing, didn't have much time for packaging lately due to new dayjob. Greatly appreciated!
Re: [Mageia-dev] [RFC] How to proceed with seamonkey/iceape for security updates and freeze push
Am 26.03.2012 19:46, schrieb Florian Hubold: 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. As a followup, an answer from Justin Callek, seamonkey developer: Am 28.03.2012 19:02, schrieb Justin Wood (Callek): Florian Hubold wrote: Could you please expand on this, and tell me if we need to rebrand seamonkey if we want to ship it, and how far the rebrand has to go and under which conditions we need to do the rebrand. As i'm currently wondering why f.ex. Fedora can ship seamonkey without any rebranding, or do they have official approval? Top of my head I'm not sure on the Fedora situation, so I won't comment on that. You know whom i can ask about this? No pressing issue, though ... Would be nice if somebody could tell me wether the Fedora way is approved, because one of my options would be to drop iceape in it's current form as it's hassle to maintain, and to reimport seamonkey as Fedora packages it: http://pkgs.fedoraproject.org/gitweb/?p=seamonkey.git;a=tree Will address the rest of your message later, but this for now... I will thank Robert Kaiser for providing the wording for the answer of the following, not sure if he meant to send it directly to you as well, but this makes my reply soo much easier. `so far, we've handled those cases with a stance of if you have permission from Mozilla to ship an officially branded Firefox (and Thunderbird) with those code changes, you have permission to ship SeaMonkey with those same changes - if you don't modify the code or deactivate (major) features, you're always allowed to ship with official branding. As most of those distros offer Firefox and Thunderbird as well, usually with higher priorities as SeaMonkey, that has worked out fine so far without needing special additional rules. ` As said I'll skim the changes you mentioned, but if you are able to ship Firefox/Thunderbird with these changes and with official branding, consider it a 'go' from us. OK, so how do we handle this? As there is no explicit permission by Mozilla to have us ship officially branded Mozilla apps, as i've put up before, or at least i don't know of any explicit permission. As this applies to Firefox and Thunderbird as well ...
Re: [Mageia-dev] freeze push: wireshark
Am 28.03.2012 17:53, schrieb David Walser: nicolas vigier boklm@... writes: On Wed, 28 Mar 2012, Guillaume Rousse wrote: 1.6.6 is a bugfix release. Submitted. Should we update this for Mageia 1? Version 1.4.12 fixes the same vulnerabilities. They don't look too serious to me, but who am I to judge? I'll take a look tomorrow, thanks for the info ...
Re: [Mageia-dev] [RFC] How to proceed with seamonkey/iceape for security updates and freeze push
Am 26.03.2012 21:29, schrieb Samuel Verschelde: Le lundi 26 mars 2012 19:46:56, Florian Hubold a écrit : 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. The problem with dropping a package that was present in Mageia 1, in my opinion, is that it's too late to do so. By shipping it we implicitly promised to maintain it. Of course with that kind of logic we would never drop any package, but I just wanted to point out that dropping a package is not that an easy solution : when dropping something, there should be a note somewhere (in the errata?), there should be a warning before upgrade (ideally the following packages found on your system are no longer supported in Mageia 2 and will not get security updates. Do you want to continue?). I'm not volunteering to maintain it, so I won't strongly oppose dropping it, but if possible I'd like we actively looked for a maintainer first rather and drop it only as a last solution. Best regards Samuel Verschelde Well, i've put this up multiple times before, the rebrand and the missing security updates, now that nothing has happened, i've at least worked on a solution for Mageia 1. But we should try to keep it sustainable in the long term. So please not make that we should look for a maintainer as then IMHO nothing will happen by itself, but just propose to feed it to Cerberus. Wasn't the goal some time ago to have no packages maintained by infamous nobody? Now we have packages, which are not really maintained. This is quite a step back. Also please consider that nobody was interested about discussing a proposal for a policy about unresponsive maintainers, which is a really similar topic, IMHO. Quite sad overall, if you ask me, and much room for improvements. So if noone volunteers and ensures to keep it updated for stable distros, i'm gonna drop it from cauldron next week, before it's too late. PS: IMHO, we didn't promise to people we will maintain this collection of software eternally this is just not realistic and not possible, but we promised stable packages of a good quality. Neither is fulfilled in this case.
[Mageia-dev] [RFC] How to proceed with seamonkey/iceape for security updates and freeze push
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
Re: [Mageia-dev] [RFC] How to proceed with seamonkey/iceape for security updates and freeze push
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. Sorry, fingers were too fast, not attached, as it's quite big, but here's a pastebin of it if somebody is really interested: http://pastebin.com/LKVPEpgG ¹: 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
Re: [Mageia-dev] Freeze push: foomatic-filters
Am 20.03.2012 10:36, schrieb David Walser: Minor foomatic-filters update (4.0.14) contains just one change, should be safe to go in: * foomaticrip.c: If the input data is PDF but the driver requires PostScript, use the pdftops CUPS filter when CUPS is the spooler. This way we always use the same method to convert PDF to PostScript in the whole system, including any workarounds applied in the CUPS filter. Confirmed that it builds and installs fine locally. Well, does it also work just fine?
Re: [Mageia-dev] Freeze push: Thunderbird
Am 17.03.2012 17:41, schrieb Florian Hubold: Hi, could somebody please push thunderbird 10.0.3esr and thunderbird-l10n to cauldron? Thanks in advance. Ping?
Re: [Mageia-dev] Freeze push: Thunderbird
Am 21.03.2012 23:17, schrieb Manuel Hiebel: Le 21/03/2012 23:02, nicolas vigier a écrit : On Wed, 21 Mar 2012, Florian Hubold wrote: Am 17.03.2012 17:41, schrieb Florian Hubold: Hi, could somebody please push thunderbird 10.0.3esr and thunderbird-l10n to cauldron? Thanks in advance. Ping? Can you explain why push is needed ? What version we have now, and why we need a new version. same as in the 1 ... bug and security fix Sorry, thought that was obvious as we follow ESR branch and firefox 10.0.3esr was pushed before, and ESR releases are bugfix/security-only. But will provide proper reasons next time. For reference: http://www.mozilla.org/en-US/thunderbird/10.0.3/releasenotes/ and http://www.mozilla.org/security/known-vulnerabilities/thunderbirdESR.html#thunderbird10.0.3
[Mageia-dev] Freeze push: Thunderbird
Hi, could somebody please push thunderbird 10.0.3esr and thunderbird-l10n to cauldron? Thanks in advance.
Re: [Mageia-dev] Freeze push: Thunderbird
Am 17.03.2012 17:43, schrieb Funda Wang: Maybe you could push it into mageia 1 updates_testing at least. Hmmm? Why would i need a freeze push request for that? I've already asked Anssi via IRC for that, as my account hasn't been fitted with submissions rights yet :/ 2012/3/18 Florian Hubolddoktor5...@arcor.de: Hi, could somebody please push thunderbird 10.0.3esr and thunderbird-l10n to cauldron? Thanks in advance.
Re: [Mageia-dev] Freeze push: Thunderbird
Am 17.03.2012 17:43, schrieb Funda Wang: Maybe you could push it into mageia 1 updates_testing at least. Actually i like how you pushed thunderbird to updates_testing nuking the existing thunderbird-10.0.2, which hadn't completed validation yet and was about to get pushed to updates by sysadmins. Now users have to wait at least another week, so they get all the security fixes since Thunderbird 10 ... :/ 2012/3/18 Florian Hubold doktor5...@arcor.de: Hi, could somebody please push thunderbird 10.0.3esr and thunderbird-l10n to cauldron? Thanks in advance.
Re: [Mageia-dev] Default browser in LXDE
Am 11.03.2012 11:33, schrieb Oliver Burger: Hi there, as in the other DEs the default browser in LXDE is Firefox. On the one hand one might have the opinion, that having the same apps on all the DEs is a good choice, but actually LXDE is a Lightweight DE and Firefox may be many things but not lightweight. Quite to the contrary, it is a resource hungry monster. I would suggest now, to replace ff in task-lxde by midori, which is far lighter then ff and in my tests I didn't find any missing features. The next best solution would be chromium, which is a lot heavier then midori but doesn't lack any features and is still lighter then ff. What do you think? Oliver Well, when i did my last beta1 installation, doing custom selection and only adding LXDE and development category, the default launcher on the LXDE panel included Midori instead of Firefox, now i wonder if that's only a coincidence or maybe it has already been changed, maybe in rpmsrate?
Re: [Mageia-dev] [Freeze] please let in xonotic
Am 11.03.2012 17:58, schrieb Samuel Verschelde: Le dimanche 11 mars 2012 13:21:57, Michael Scherer a écrit : 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. Communication tip for the future : when such a policy change happens (this is a policy change, there were more exceptions in the past before package freeze, for leaf packages without weird deps and post/pre scripts and little impact), let's try to highlight it *before*. There was a communication effort to announce the freeze: I read freeze announce, was present at the last packager meeting. However it didn't struck me, it all looked like the usual end of release cycle, with their common-sense exceptions. A message such as contrarily as what happened in the past (this is the important part, highlight a *change*), there will be no exception even for leaf non-critical packages, so that you all focus on bugfixes, as we know that otherwise you will not fix bugs and continue updating your packages. Best regards Samuel I can only chime in with Stormi, in last packager meeting ennael said that new packages would be allowed during the freeze, but we should focus on bug fixes, which is comprehensible. Also misc didn't say anything that new packages are disallowed. So when did this change and who changed it? Or is it just that the reason given for xonotic was not enough? I'm just asking in advance, because i've not gotten around to properly testing qtsixa, which i wanted to add for Mageia 2 and to resolve https://bugs.mageia.org/show_bug.cgi?id=3362 Because i didn't want to import it untested, and another problem is that i can't spare a physical cauldron installation, which made testing a lot more difficult, it's not in Mageia yet. Also what about adding hardware support as e.g. needed for https://bugs.mageia.org/show_bug.cgi?id=4249 ? Also disallowed?
Re: [Mageia-dev] [changelog] [RPM] cauldron nonfree/release get-skype-2.2.0.35-18.mga2.nonfree
Am 08.03.2012 15:42, schrieb Guillaume Rousse: Le 08/03/2012 15:18, Sander Lepik a écrit : I was quite sure that Mageia would keep the usability bit that Mandriva had. But with our current direction Gentoo is soon easier to use for non-developer/sysadmin user. Gentoo is still too much user-friendly for my taste, I'd rather target LFS :) C'mon guy, stop the FUD, and write correct user-readable documentation instead of ressorting to this kind of dirty hacks. FWIW, we already have documentation about that for quite some time: https://forums.mageia.org/en/viewtopic.php?f=36t=1121 Feel free to give any proposals about improvements.
Re: [Mageia-dev] Deprecating startx
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.
Re: [Mageia-dev] [RFC] Nonresponsive or absent package maintainers policy discussion
Am 16.02.2012 10:25, schrieb Florian Hubold: Hi, due to the fact that this problem has already been encountered, it was brought up in yesterdays meeting that we need to discuss on a policy about how to handle unresponsive package maintainers, or if somebody is absent for a longer time (say more than a few days) we should also have guidelines or at least an official way to notify others of the absence. So to start and support the discussion, i've imported and adapted a Fedora policy on this subject into our wiki, the original version can be seen at: https://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers I've imported it to: https://wiki.mageia.org/en/Nonresponsive_package_maintainers Remember this is just a proposal, so details may need to be readjusted, For example in place of the FESCo (Fedora Engineering Steering Committee) i've put a placeholder packaging team leader/representative/member but maybe this could also be a task for the council, it's just that we have a basis for discussion of the policy. About the absence, or if somebody is on vacation, i've imported also https://wiki.mageia.org/en/Absent So please add an entry there if you will be absent from Mageia contribution or not responding to emails/IRC for more than a few days. Regards Maybe nonresponsive should have been removed from the subject, then it wouldn't have infected everyone else ... :/ No comments, objections or anything about that proposal in the wiki?
Re: [Mageia-dev] Drop kaffeine from repos?
Am 06.03.2012 16:54, schrieb Anssi Hannula: 06.03.2012 17:12, Oliver Burger kirjoitti: Hi, I am currently thinking about dropping kaffeine from the repositories for Mga2. The reason is some upstream bug - reported as #1934 in Mageia bugzilla and in several other distributions as well without any solution upstream. So kaffeine is rather instable right now and there seems not to be a real active development on it. In addition, there are many good alternatives for kaffeine, e.g. the different mplayer guis or vlc. Any opinions on it? Kaffeine has superior DVB support which works out-of-the-box (i.e. without manual command-line tinkering, just scan for channels via the GUI), that e.g. MPlayer GUIs or VLC do not have. I've not used kaffeine since a long time, i prefer me-tv, it's just as easy to use, maybe even easier and i like the embedded EPG shown in windowed mode. It's also actively developed.
Re: [Mageia-dev] Drop kaffeine from repos?
Am 06.03.2012 21:46, schrieb Oliver Burger: Am 06.03.2012 21:43, schrieb Florian Hubold: Am 06.03.2012 16:54, schrieb Anssi Hannula: 06.03.2012 17:12, Oliver Burger kirjoitti: Hi, I am currently thinking about dropping kaffeine from the repositories for Mga2. The reason is some upstream bug - reported as #1934 in Mageia bugzilla and in several other distributions as well without any solution upstream. So kaffeine is rather instable right now and there seems not to be a real active development on it. In addition, there are many good alternatives for kaffeine, e.g. the different mplayer guis or vlc. Any opinions on it? Kaffeine has superior DVB support which works out-of-the-box (i.e. without manual command-line tinkering, just scan for channels via the GUI), that e.g. MPlayer GUIs or VLC do not have. I've not used kaffeine since a long time, i prefer me-tv, it's just as easy to use, maybe even easier and i like the embedded EPG shown in windowed mode. It's also actively developed. As Anne showed with her link, kaffeine's development is moving on again. So let't leave it in the repos for now. Oliver For clarification, my comment was not for or against kaffeine, as i don't use it, i've got no strong opinion so far. Just wanted to present another alternative.
Re: [Mageia-dev] Versions freeze
Am 03.03.2012 21:55, schrieb Oliver Burger: Am 03.03.2012 21:10, schrieb Sander Lepik: On Mar 3, 2012 7:41 PM, Oliver Burger oliver@googlemail.com mailto:oliver@googlemail.com wrote: And in the last meeting logs for this channel, the reminder was said and discussed. Oliver Can this link be sent to list after meeting? Or is this too much asked? Or was it sent and i just missed it? Well, actually I'm sure it could. But why? All meeting logs are publicly available at https://meetbot.mageia.org/ I did send those links to the i18n list after meeting s there but most of the time, I just forgot. And I think looking at the meetbot page from time to time isn't all that hard and can be done by anyone. Cheers, Oliver On a related note, as i was absent from last meeting, which was announced by ennael on 29.02.2012 15:16, why can't i find the logs for that meeting assuming it did happen (as there's no follow-up posts to that meeting announce that meeting had been cancelled or delayed) Last meetbot log is from 15.02.2012 for #mageia-dev.
Re: [Mageia-dev] Rebuild failed on noarch for @211804:firefox-l10n-10.0.2-2.mga2.src.rpm
Am 27.02.2012 03:30, schrieb Anssi Hannula:
27.02.2012 02:22, Pascal Terjan kirjoitti:
On Mon, Feb 27, 2012 at 00:09, Pascal Terjan pter...@gmail.com wrote:
On Sun, Feb 26, 2012 at 23:12, Ulri the scheduler bot
mageia-sys...@mageia.org wrote:
Build of the following packages failed:
- @211804:firefox-l10n-10.0.2-2.mga2.src.rpm
Failure details available in
http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20120226231059.pterjan.valstar.5570/log
Reason:
@211804:firefox-l10n-10.0.2-2.mga2.src.rpm: build_failure
Log files generated:
http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20120226231059.pterjan.valstar.5570/log/chroot/initialize-1.0.20120226231100.log
http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20120226231059.pterjan.valstar.5570/log/firefox-l10n-10.0.2-2.mga2/rpm_qa.0.20120226231100.log
http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20120226231059.pterjan.valstar.5570/log/firefox-l10n-10.0.2-2.mga2/build.0.20120226231100.log
http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20120226231059.pterjan.valstar.5570/log/firefox-l10n-10.0.2-2.mga2/install_deps-1.0.20120226231100.log
I don't understand what's wrong here (it seems to forget about -zh-TW
and -zu packages, but it works fine if I manually build it in a iurt
chroot)
Ah actually it worked fine when I build it from a src.rpm I manually
generated after simplifying a bit the template (which would not change
anything) but not if I try to rebuild
http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20120226231059.pterjan.valstar.5570/@211804:firefox-l10n-10.0.2-2.mga2.src.rpm
Maybe the expanded spec got too long and simplifying the template fixed it?
Anyway, it is now built.
AFAIK there is/was a buffer size issue in rpm-build, causing
%{expand:foo} to fail if 'foo' is too long. Never got around to look at
it closer, though...
Yep, it's this one https://bugzilla.redhat.com/show_bug.cgi?id=431009
Not got around to re-report it yet, and it still happens, as you can see.
Re: [Mageia-dev] Default graphics software
Am 27.02.2012 14:01, schrieb Damien Lallement: Le 25/02/2012 15:46, Pascal Terjan a écrit : Currently rpmsrate lists: 5 !CAT_KDE !CAT_GNOME || CAT_XFCE gthumb 4 !CAT_KDE !CAT_GNOME !CAT_XFCE flphoto gtkam flphoto has been dead for years and gtkam is very limited (and not packaged currently), what about replacing them with gthumb? CAT_GNOME 5 !LIGHT inkscape I think inkscape should be installed in more environments than gnome, but maybe at level 4 rather than 5 Opinions? I would like to replace f-spot with shotwell f-spot is no longer developped and uses mono shotwell is a vala software. Fedora and Ubuntu have replaced f-spot with showell for 2 years now. Anybody against this? I maintain shotwell so I'm sure we are uptodate with this software. If it doesn't turn out like in Mandriva, replacing DigiKam with shotwell, sure, why not.
Re: [Mageia-dev] How to see the Suggests of a rpm package
Am 23.02.2012 09:12, schrieb Pascal Terjan:
On Thu, Feb 23, 2012 at 06:38, Remco Rijnders re...@webconquest.com wrote:
This question falls perhaps in the 'silly' category, but I haven't been able
to find the answer myself, even though I have searched for it.
How does one check the Suggests provided by a rpm package that is not
installed and only locally available? I know how to see the Requires, etc.
but have had no luck with the Suggests part of it.
rpm -qp --suggests foo.rpm
The long form would be
rpm -qp --queryformat %{SUGGESTS} foo.rpm
You can see all queriable tags via rpm --querytags
BTW: You can also use urpmf to query which package from the repos
suggests a given package/library foobar via urpmf --suggests foobar
[Mageia-dev] Something to replace Mandriva Seed - Rufus
Hi all, maybe we should consider offering a replacement for Mandriva Seed, which AFAIK is unmaintained and doesn't work on Windows 7 since some time. I've now stumbled over Rufus, the Reliable USB Formatting Utility (with Source) via http://reboot.pro/16374/ There are windows binaries available, it doesn't require installation, it's faster than most other tools like Unetbootin, there's source available and it's GPLv3-licensed. Might this be an option? Project page: http://rufus.akeo.ie/
Re: [Mageia-dev] printer-filter-utils
Am 20.02.2012 15:00, schrieb David Walser: Florian Hubold wrote: Am 19.02.2012 15:59, schrieb David Walser: Pascal Terjan wrote: I was looking at that package, which is a collection of drivers for some printers, not updated for years It is one of the two packages requiring automake1.4, because of the included drv_z42 Looking on http://www.openprinting.org/driver/drv_z42/ original website no longer exist, and even if openprinting now hosts it they say This driver is obsolete. Recommended replacement driver: gutenprint Should we drop it? Does anyone has enough time to see if other drivers in this package may still be needed? And actually, if we install this package. Also from openprinting, there are security issues fixed in the newest foomatic-filters (needs updated in Mageia 1 and Cauldron, see Bug 3979). They also have a new CUPS filters set that probably needs to be packaged. Upstream notes on it: Apple decided to not continue to develop and maintain the CUPS filters and backends which are not used by Mac OS X and moved them to OpenPrinting. They also did not accept the new filters for the PDF-based printing workflow as they are also not used by Mac OS X. All these filters we continue to maintain now in one package, the OpenPrinting CUPS Filters and announce here the first stable release of this package, versionn 1.0.1. As you mentioned it, there are far bigger changes coming than just adding a new cups filter package (which is still in beta state AFAIK) as that is just smaller fallout from changes explained in below links. http://thread.gmane.org/gmane.linux.printing.fsg/2020 http://cyberelk.net/tim/2012/02/06/cups-1-6-changes-ahead/ Yikes, thanks for the links Florian. The future removal of browsing and requirement of avahi is really unfortunate. So this work will be needed for when we move to CUPS 1.6, which will be after Mageia 2. Here's a good page that details the work we as a distro will need to do: http://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdf_as_standard_print_job_format That's just part of the work, and i've already tried to mention that a few times. Also in the future for print server discovery avahi would need to run on the client and on the server, BTW.
Re: [Mageia-dev] printer-filter-utils
Am 19.02.2012 15:59, schrieb David Walser: Pascal Terjan wrote: I was looking at that package, which is a collection of drivers for some printers, not updated for years It is one of the two packages requiring automake1.4, because of the included drv_z42 Looking on http://www.openprinting.org/driver/drv_z42/ original website no longer exist, and even if openprinting now hosts it they say This driver is obsolete. Recommended replacement driver: gutenprint Should we drop it? Does anyone has enough time to see if other drivers in this package may still be needed? And actually, if we install this package. Also from openprinting, there are security issues fixed in the newest foomatic-filters (needs updated in Mageia 1 and Cauldron, see Bug 3979). They also have a new CUPS filters set that probably needs to be packaged. Upstream notes on it: Apple decided to not continue to develop and maintain the CUPS filters and backends which are not used by Mac OS X and moved them to OpenPrinting. They also did not accept the new filters for the PDF-based printing workflow as they are also not used by Mac OS X. All these filters we continue to maintain now in one package, the OpenPrinting CUPS Filters and announce here the first stable release of this package, versionn 1.0.1. As you mentioned it, there are far bigger changes coming than just adding a new cups filter package (which is still in beta state AFAIK) as that is just smaller fallout from changes explained in below links. http://thread.gmane.org/gmane.linux.printing.fsg/2020 http://cyberelk.net/tim/2012/02/06/cups-1-6-changes-ahead/
[Mageia-dev] [RFC] Nonresponsive or absent package maintainers policy discussion
Hi, due to the fact that this problem has already been encountered, it was brought up in yesterdays meeting that we need to discuss on a policy about how to handle unresponsive package maintainers, or if somebody is absent for a longer time (say more than a few days) we should also have guidelines or at least an official way to notify others of the absence. So to start and support the discussion, i've imported and adapted a Fedora policy on this subject into our wiki, the original version can be seen at: https://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers I've imported it to: https://wiki.mageia.org/en/Nonresponsive_package_maintainers Remember this is just a proposal, so details may need to be readjusted, For example in place of the FESCo (Fedora Engineering Steering Committee) i've put a placeholder packaging team leader/representative/member but maybe this could also be a task for the council, it's just that we have a basis for discussion of the policy. About the absence, or if somebody is on vacation, i've imported also https://wiki.mageia.org/en/Absent So please add an entry there if you will be absent from Mageia contribution or not responding to emails/IRC for more than a few days. Regards
Re: [Mageia-dev] Packagers meeting
Am 14.02.2012 14:32, schrieb Anne nicolas: 2012/2/14 Anne nicolas enn...@mageia.org: Hi there As usual we will have our weekly meeting tomorrow on #mageia-dev. Here the list of topics: - Mageia 2 beta 1 release: release notes, isos QA, organization, list of focus for fixing Mageia - Version freeze reminder - Updates advisories - Use of new servers - gsoc 2012 (sorry misc) Cheers -- Anne http://www.mageia.org One topic i'd like to add would be how to deal with unresponsive maintainers.
Re: [Mageia-dev] size of iso dvds
Am 26.01.2012 20:56, schrieb Luc Menut: Le 25/01/2012 21:21, Juergen Harms a écrit : I just joined this list - therefore top-posting rather than replying. Seeing the discussion on space on isos, some data about differences between mageia 1 x86_64 DVD and mageia 2a3 x86_64 DVD: mageia 1 : 3730 Mo - 4630 packages mageia 2 : 4139 Mo - 4209 packages some new big packages in mga 2: - *eclipse* -+ 67 packages - +302 Mo + lots of new java packages (ant, maven, ...) - celtx* - + 7 packages - +132 Mo - e, e17_themes -+ 2 packages - +36 Mo - chromium-browser - + 2 packages - +23 Mo some packages bigger than in mga 1: - texlive* - + 95Mo (mga1 306Mo, mga2 401Mo) packages that we will be able to remove in mga2: - myspell* 39Mo (after hunspell migration) some major missing packages in mga2 DVD ISO: - lots of kde packages, - gstreamer0.10-pulse, - kernel-desktop-devel-latest, - kernel-server-devel-latest, - perhaps others :'( regards, Luc Somehow related, i just did some rpm size comparisons for thunderbird -l10n packages, to see what can be gained if we switch them back to uncompressing the (zipped) .xpi files and so let them profit from rpm binary payload compression. It's not much for a single package, but overall it's a reduction by 35%. Maybe this is a viable solution for other packages too, which currently carry files which are already compressed when building. Some numbers (total size of-l10n packages, followed by time output for the build to see the cost of this switch) .xpis unzipped - using rpm default compression _binary_payloadw5.lzdio $ LC_ALL=C du -ch mozilla-thunderbird-*rpm 11M total 182.92user 34.65system 3:55.54elapsed 92%CPU (0avgtext+0avgdata 188512maxresident)k 0inputs+482992outputs (0major+17025693minor)pagefaults 0swaps not unzipping .xpis: $ LC_ALL=C du -ch mozilla-thunderbird-*rpm 17M total 20.89user 7.27system 0:31.57elapsed 89%CPU (0avgtext+0avgdata 109264maxresident)k 0inputs+356720outputs (0major+3218040minor)pagefaults 0swaps Will commit for cauldron shortly, but it won't make it into beta1, sorry.
Re: [Mageia-dev] Putting meta-information in Mageia patches
Am 11.02.2012 18:41, schrieb Olav Vitters: It provides the following standard headers (quoting): - Description or Subject (required) - Origin (required except if Author is present) - Bug-Vendor or Bug (optional) - Forwarded (optional) Any value other than no or not-needed means that the patch has been forwarded upstream. Ideally the value is an URL proving that it has been forwarded and where one can find more information about its inclusion status. - Author or From (optional) - Reviewed-by or Acked-by (optional) - Last-Update (optional) - Applied-Upstream (optional) This field can be used to document the fact that the patch has been applied upstream. It may contain the upstream version expected to contain this patch, or the URL or commit identifier of the upstream commit (with commit identifiers prefixed with commit:, as in the Origin field), or both separated by a comma and a space. This specification basically does everything that I need and more. Is some kind of patch-tracking or meta-information used in Mageia? One of our policies needs this partly, too: https://wiki.mageia.org/en/KDE4_packaging_policy#Patch_policy
Re: [Mageia-dev] -- mozilla branding issues -- was [Seamonkey package]
Am 08.02.2012 04:59, schrieb andre999: Julien a écrit : Le Mon, 06 Feb 2012 21:04:05 +0100, Florian Hubolddoktor5...@arcor.de a écrit : Am 12.01.2012 16:55, schrieb Florian Hubold: Am 07.01.2012 18:36, schrieb Florian Hubold: Am 16.04.2011 16:05, schrieb Christiaan Welvaart: On Fri, 11 Mar 2011, Tux99 wrote: (...) Pinging again, because nobody replied. This should also be discussed at next packager meeting, together with the situation according the branding of other mozilla packages. Because we have branding enabled, which we shouldn't have as we can't use branding AND have modified builds (different than upstream tarball) without approval of all modifications from mozilla. For reference, here's the upstream report i was talking about, which i've recently found again: https://bugzilla.mozilla.org/show_bug.cgi?id=555935 -- resending because of maintainer mail adress typo FTR, the Mozilla trademark policy : https://www.mozilla.org/foundation/trademarks/policy.html the relevant part : Modifications If you're taking full advantage of the open-source nature of Mozilla's products and making significant functional changes, you may not redistribute the fruits of your labor under any Mozilla trademark, without Mozilla's prior written consent. For example, if the product you've modified is Firefox, you may not use Mozilla or Firefox, in whole or in part, in its name. Also, it would be inappropriate for you to say based on Mozilla Firefox. Instead, in the interest of complete accuracy, you could describe your executables as based on Mozilla technology, or incorporating Mozilla source code. In addition, you may want to read the discussion on the Powered by Mozilla logo. In addition, if you compile a modified version, as discussed above, with branding enabled (the default in our source code is branding disabled), you will require Mozilla's prior written permission. If it's not the unmodified installer package from www.mozilla.com, and you want to use our trademark(s), our review and approval of your modifications is required. You also must change the name of the executable so as to reduce the chance that a user of the modified software will be misled into believing it to be a native Mozilla product. Again, any modification to the Mozilla product, including adding to, modifying in any way, or deleting content from the files included with an installer, file location changes, added code, modification of any source files including additions and deletions, etc., will require our permission if you want to use the Mozilla Marks. If you have any doubt, just ask us at tradema...@mozilla.com. regards Julien The key words seem to be significant functional changes. If we use the Mozilla tarball, and just apply Mozilla patches, we shouldn't require any special permission for that. They do say that additionally we would require written permission to compile the source with branding enabled. Since the source tarball can be installed wherever the user wants, only changing the relative locations would potentially be problematic. In any case, I'm in favour of packaging all of Firefox/Thunderbird/Seamonkey, essentially unmodified, and in the extended support versions where available. (Not trying to say that we shouldn't package filerunner separately. Or add security patches not yet added by Mozilla. Both of which would require approval from Mozilla.) The suggested -ESR suffix for extended support releases seems a good idea. Alternately, we could tag them with the version, but that would be less evident. Please get your facts straight, most patches we apply are not mozilla patches, and we do significant modifications. And please don't compare this to installing the mozilla tarball, this just doesn't fly.
[Mageia-dev] [RFE] Bundled copies of system libraries - call for participation
I've just whipped up https://wiki.mageia.org/en/Packages_carrying_bundled_copies_of_system_libraries It's purpose is listing and maybe documenting the reasons why some packages carry bundled copies of system libraries. I've begun with ffmpeg, as it has a rather bad record for security updates on Mageia 1 IMHO, as some security updates would almost have been missed, some were delayed for a long time, and some wouldn't have been noticed unless by accident. Please, every packager participate, and list the packages you know about. Another good example would be xulrunner. PS: Maybe it should also be used to documented the packages which require some static linking, and the reasons, if there are any of these.
Re: [Mageia-dev] Cannot compile LLVM/Clang under Mageia 1
Am 07.02.2012 22:58, schrieb Dan Fandrich: On Tue, Feb 07, 2012 at 10:43:31PM +0100, Thierry Vignaud wrote: On 7 February 2012 20:02, Thomas Lottmann skipercoo...@gmail.com wrote: https://bugs.mageia.org/show_bug.cgi?id=4179 I do need this compiler and think it can be useful for programmers. I thank you by advance for your help. Thomas Lottmann aka Skiper. bugzilla is about Mageia bugs, not about your own compilation issues. So I closed this BR. The bug report was an RPM package request. The compile problem is really a side issue (although still relevant to whoever takes on the bug report eventually and packages clang). The bug report should be reopened unless it's deemed that clang is not to be packaged in Mageia at this time. Also it could be interesting why the error message displays: Consultez http://bugs.mageia.org/ pour plus de détail. Dan
Re: [Mageia-dev] Seamonkey mga1 package missing updates - mozilla branding issues -- was [Seamonkey package]
Am 12.01.2012 16:55, schrieb Florian Hubold: Am 07.01.2012 18:36, schrieb Florian Hubold: Am 16.04.2011 16:05, schrieb Christiaan Welvaart: On Fri, 11 Mar 2011, Tux99 wrote: I just downloaded the latest Seamonkey 2.0.12 SRPM from Mandriva cooker and rebuilt it on my Mageia VM and it built flawlessly, I only had to remove all the obsolete %if %mdkversion sections, but all dependecies are available in Mageia. So technically importing Seamonkey into Mageia seems straightforward, the only issue is licensing (as for Firefox). Christiaan I'm a newbie packager here at Mageia so personally I'd much prefer if you maintain this package for Mageia, it looks far too complex for me. :) I uploaded iceape 2.0.12 a few days ago, changing the name and icons/logo took me almost a month. Unfortunately there are still some bugs in this area: the release notes menu item for example currently still points to seamonkey. It should probably point to a mageia wiki page. Since I don't like the icons that is used for debian's iceape, I created a new icon based on the logo. It looks like it can still be improved, however, and the throbber is currently static. So it would be great if someone could re-do the icon (without creating a completely new design), and animate it for the throbber (he SVG files are in iceape-branding.tar in the source rpm and svn)... Christiaan As iceape for mga1 hasn't seen any update in the last 6 months, and there are multiple serious security issues that need fixing, how do we handle this? And i've found no real reason for this rebranding in the first place, and this seems also be the case for Fedora, and they have a strong legal department. http://pkgs.fedoraproject.org/gitweb/?p=seamonkey.git From what i read on bugreports between debian packagers and mozilla guys about that branding situation, the only thing that would need to be done to seamonkey (actually the same would need to be done for all our mozilla packages, unless we have permission to use the branding, which would imply that all our modifications on mozilla packages would need to be reviewed and ack-ed by mozilla to get the branding permission) would be to use --disable-official-branding configure option. Ping? Pinging again, because nobody replied. This should also be discussed at next packager meeting, together with the situation according the branding of other mozilla packages. Because we have branding enabled, which we shouldn't have as we can't use branding AND have modified builds (different than upstream tarball) without approval of all modifications from mozilla. For reference, here's the upstream report i was talking about, which i've recently found again: https://bugzilla.mozilla.org/show_bug.cgi?id=555935 -- resending because of maintainer mail adress typo
Re: [Mageia-dev] Seamonkey mga1 package missing updates - mozilla branding issues -- was [Seamonkey package]
Am 06.02.2012 21:43, schrieb Kamil Rytarowski: On 06.02.2012 21:04, Florian Hubold wrote: Am 12.01.2012 16:55, schrieb Florian Hubold: Am 07.01.2012 18:36, schrieb Florian Hubold: Am 16.04.2011 16:05, schrieb Christiaan Welvaart: On Fri, 11 Mar 2011, Tux99 wrote: I just downloaded the latest Seamonkey 2.0.12 SRPM from Mandriva cooker and rebuilt it on my Mageia VM and it built flawlessly, I only had to remove all the obsolete %if %mdkversion sections, but all dependecies are available in Mageia. So technically importing Seamonkey into Mageia seems straightforward, the only issue is licensing (as for Firefox). Christiaan I'm a newbie packager here at Mageia so personally I'd much prefer if you maintain this package for Mageia, it looks far too complex for me. :) I uploaded iceape 2.0.12 a few days ago, changing the name and icons/logo took me almost a month. Unfortunately there are still some bugs in this area: the release notes menu item for example currently still points to seamonkey. It should probably point to a mageia wiki page. Since I don't like the icons that is used for debian's iceape, I created a new icon based on the logo. It looks like it can still be improved, however, and the throbber is currently static. So it would be great if someone could re-do the icon (without creating a completely new design), and animate it for the throbber (he SVG files are in iceape-branding.tar in the source rpm and svn)... Christiaan As iceape for mga1 hasn't seen any update in the last 6 months, and there are multiple serious security issues that need fixing, how do we handle this? And i've found no real reason for this rebranding in the first place, and this seems also be the case for Fedora, and they have a strong legal department. http://pkgs.fedoraproject.org/gitweb/?p=seamonkey.git From what i read on bugreports between debian packagers and mozilla guys about that branding situation, the only thing that would need to be done to seamonkey (actually the same would need to be done for all our mozilla packages, unless we have permission to use the branding, which would imply that all our modifications on mozilla packages would need to be reviewed and ack-ed by mozilla to get the branding permission) would be to use --disable-official-branding configure option. Ping? Pinging again, because nobody replied. This should also be discussed at next packager meeting, together with the situation according the branding of other mozilla packages. Because we have branding enabled, which we shouldn't have as we can't use branding AND have modified builds (different than upstream tarball) without approval of all modifications from mozilla. For reference, here's the upstream report i was talking about, which i've recently found again: https://bugzilla.mozilla.org/show_bug.cgi?id=555935 -- resending because of maintainer mail adress typo In my opinion we can drop that package, and in its place have Firefox-ESR, next to standard Firefox. How are we supposed to drop seamonkey/iceape from a released distro? BTW: Do you use seamonkey/iceape, and know how it is different from a standalone browser like firefox?
Re: [Mageia-dev] Seamonkey package
Am 12.01.2012 16:55, schrieb Florian Hubold: Am 07.01.2012 18:36, schrieb Florian Hubold: Am 16.04.2011 16:05, schrieb Christiaan Welvaart: On Fri, 11 Mar 2011, Tux99 wrote: I just downloaded the latest Seamonkey 2.0.12 SRPM from Mandriva cooker and rebuilt it on my Mageia VM and it built flawlessly, I only had to remove all the obsolete %if %mdkversion sections, but all dependecies are available in Mageia. So technically importing Seamonkey into Mageia seems straightforward, the only issue is licensing (as for Firefox). Christiaan I'm a newbie packager here at Mageia so personally I'd much prefer if you maintain this package for Mageia, it looks far too complex for me. :) I uploaded iceape 2.0.12 a few days ago, changing the name and icons/logo took me almost a month. Unfortunately there are still some bugs in this area: the release notes menu item for example currently still points to seamonkey. It should probably point to a mageia wiki page. Since I don't like the icons that is used for debian's iceape, I created a new icon based on the logo. It looks like it can still be improved, however, and the throbber is currently static. So it would be great if someone could re-do the icon (without creating a completely new design), and animate it for the throbber (he SVG files are in iceape-branding.tar in the source rpm and svn)... Christiaan As iceape for mga1 hasn't seen any update in the last 6 months, and there are multiple serious security issues that need fixing, how do we handle this? And i've found no real reason for this rebranding in the first place, and this seems also be the case for Fedora, and they have a strong legal department. http://pkgs.fedoraproject.org/gitweb/?p=seamonkey.git From what i read on bugreports between debian packagers and mozilla guys about that branding situation, the only thing that would need to be done to seamonkey (actually the same would need to be done for all our mozilla packages, unless we have permission to use the branding, which would imply that all our modifications on mozilla packages would need to be reviewed and ack-ed by mozilla to get the branding permission) would be to use --disable-official-branding configure option. Ping? Pinging again, because nobody replied. This should also be discussed at next packager meeting, together with the situation according the branding of other mozilla packages. Because we have branding enabled, which we shouldn't have as we can't use branding AND have modified builds (different than upstream tarball) without approval of all modifications from mozilla. For reference, here's the upstream report i was talking about, which i've recently found again: https://bugzilla.mozilla.org/show_bug.cgi?id=555935
Re: [Mageia-dev] mkinitrd and Mageia2
Am 27.01.2012 16:35, schrieb Frank Griffin: On 01/27/2012 10:21 AM, Colin Guthrie wrote: I really don't think it's anything to do with HAL here. As I said, it's only urpmi stuff that uses HAL and I'm pretty certain the DE's long ago stopped doing that. So it appears that KDE is now delaying the mount until you tell it through the device popup that you want to run something it (KDE) knows requires the mount ? That is certainly going to screw up direct invocation (not using the device popup) of any such application. For reference, with a default setup KDE doesn't automatically mount removable media like GNOME does, this is the case since quite some time, IIRC it goes back to 4.0.
Re: [Mageia-dev] RPM filetrigger doesn't take effect on icon changes
Am 24.01.2012 10:23, schrieb Guillaume Rousse: Le 24/01/2012 10:18, Oliver Burger a écrit : Hi there, while working on https://bugs.mageia.org/show_bug.cgi?id=107 we noticed, our file triggers don't sometimes take effect on changes directly in /usr/share/icons. sometimes is problematic here: without a reproducible test case, a bug is quite difficult to understand. No filetriger currently fires when updating icons, which reside in /usr/share/icons, only for hicolor, gnome and oxygen subdirectories. You can check via grep -R '/usr/share/icons' /var/lib/rpm/filetriggers/
