Re: [Mageia-dev] Packagers meeting
Op dinsdag 26 juni 2012 21:40:51 schreef Anne nicolas: Hi there Our meeting will happen tomorrow evening at 19hUTC. Here are the proposed topics: - pending security updates - Mageia 3 features - Backports policy For the 2 last topics please read following links *before* meeting: https://www.mageia.org/pipermail/mageia-dev/2012-June/016819.html https://www.mageia.org/pipermail/mageia-dev/2012-June/016855.html Cheers can we have another talk of bug 2317? to find people willing to make a new patch that's quite more complex? ideally bug 2317 should be fixed before backports opens
Re: [Mageia-dev] Idea to fix Way too many languages to choose from for spell checking in FF and TB mga#6125
On 27/06/2012 01:38, n...@gmx.com wrote: Hello! I have got an idea to fix this bug with a new drak tool (DrakSpell?). It would be an assistant with a list of all available languages with all their variants to select and install. And the trick: it will install a package (like hunspell-en) and remove (rm -f) the unselected dicts (en_CA, en_GB ...). This seems to be against rules.. but would be a solution. And this seems to be much better than producing (and maintaining!) 1000 packages with single dicts. What do you think? Sounds great, I'm willing to test :) As a workaround for now, can we just remove all /usr/share/hunspell/*.aff /usr/share/hunspell/*.dic except for the ones we want to keep?
Re: [Mageia-dev] Backports Summary
Op dinsdag 26 juni 2012 23:15:16 schreef Sander Lepik: 26.06.2012 22:25, Thomas Backlund kirjutas: * backports is supported as long as the rest of the release Comments? Questions ? I think we should change the wording from supported to tested. Currently we can support backport with a newer version of the backport. But i don't think it's a wise move to mark backports repo as an updates repo. So i don't see how we can _support_ backports. And QA has no time to deal with updates for backports (i mean to search for security holes in backports). But this can be discussed tomorrow. i agree, this is only a wording change, but is imho substantially different from complete support, which is impossible.
Re: [Mageia-dev] Mageia 3 feature proposals review
Op dinsdag 26 juni 2012 22:43:44 schreef Olav Vitters: On Mon, Jun 25, 2012 at 08:59:43PM -0400, David Walser wrote: Fedora plans are here: http://mjg59.dreamwidth.org/12368.html?style=light Ubuntu plans are here: https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035445.html Interesting. So the main reason people have complained about us not using GRUB2 is poor interaction when trying to dual boot with other distros that do use it, namely Ubuntu. If Ubuntu isn't going to use it by default, is it really mandatory that we switch to it? You cannot use the Ubuntu method, they plan their Ubuntu-only certificate. Fedora way is by using Grub 2 and having a small boot bit which is certified. So Grub2 seems the way to go. I thought they were planning on signing all the stuff after grub2 as well? I have no trouble having signed bootloader. but i would prefer it to be from a completely free CA. ie: NOT from microsoft. above signing from microsoft, I would even prefer to have a documentation that requests to disable Secure Boot, then generate your own key and adding that, and then setting up Secure Boot again, with your own personal signed stuff. of course, if there was an independant org that had it's CA in all hardware, and signed all free OSes, that would be alot better.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release perl-HTML-HTML5-Entities-0.3.0-1.mga3
On 27 June 2012 06:22, kharec buildsystem-dae...@mageia.org wrote: Name : perl-HTML-HTML5-Entities Relocations: (not relocatable) Version : 0.3.0 Vendor: Mageia.Org Release : 1.mga3 Build Date: Wed Jun 27 06:21:45 2012 Install Date: (not installed) Build Host: jonund.mageia.org Group : Development/Perl Source RPM: (none) Size : 69102 License: GPL+ or Artistic Signature : (none) Packager : kharec kharec URL : http://search.cpan.org/dist/HTML-HTML5-Entities Summary : Drop-in replacement for HTML::Entities Description : This is a drop-in replacement for the HTML::Entities manpage, providing the character entities defined in HTML5. Some caveats: * * The implementation is pure perl, hence in some cases slower, especially decoding. * * It will not work in Perl 5.8.1. This has nothing to do in description. Worse, we have perl5.8 for 10 years...
Re: [Mageia-dev] Slowly pushing GNOME 3.5.3
On Wed, Jun 27, 2012 at 12:15:07AM +0200, Dexter Morgan wrote: where is the tarball ? https://fedorahosted.org/releases/l/i/libpwquality/ -- Regards, Olav
Re: [Mageia-dev] Slowly pushing GNOME 3.5.3
On 27.06.2012 09:28, Olav Vitters wrote: On Wed, Jun 27, 2012 at 12:15:07AM +0200, Dexter Morgan wrote: where is the tarball ? https://fedorahosted.org/releases/l/i/libpwquality/ I'll check this one..
Re: [Mageia-dev] Backports Summary
Thomas Backlund a écrit : Thomas Backlund skrev 26.6.2012 22:25: So, we have been discussing this many times, and not gotten any satisfactory decision to go ahead yet... First off, we decided long ago that backports will be better supported than during mdv times, meaning security and bugfixes and has to pass QA. Now for references: * we have the backports policy: https://wiki.mageia.org/en/Backports_policy * Last discussions started by Stormi: * [Mageia-dev] Backports policy clarification (and discussion) https://www.mageia.org/pipermail/mageia-dev/2012-June/016265.html * [Mageia-dev] Proposed Feature:Backports_update_applet https://www.mageia.org/pipermail/mageia-dev/2012-June/016263.html * It also came up in the discussion about fixing bug 2317: * [Mageia-dev] bug 2317 revisited: --update option should behave like --search-media https://www.mageia.org/pipermail/mageia-dev/2012-June/016692.html People seem to agree on most things, but there is a few questions that need to be decided how to handle. Lets start with the summary and suggestion of how to get it started: (addendum / refinements / important points of current backports policy) * backports is supported as long as the rest of the release * packages must always be in cauldron first * if you want to backport a package someone else is maintainer for, you need to discuss with maintainer first. if he dont want the package to be backported _and_ have valid reasons, respect that. (if you disagree, you can still ask council) * if you backport anything, (regardless if you are the real maintainer or not) you accept the responsibility of handling the bugreports against the backport and make sure it gets patched (or upgraded) to get security fixes. * cherrypicking backports must work, so requires need to be checked and be strict to make sure they work * nothing in backports must require the use of --nodeps or --force to get it to install * QA will do basic tests to make sure it works and obeys the rules * QA can deny package(s) to be backported if it breaks the policy * QA has /updates as priority, and /backports will be handled if/when there is time, so if you want faster response, join QA to help out with the workload. Now a point that got raised during discussion of bug 2317: * if a backport break because of something ending up in /updates it's a bug to be reported against the backport (and not against the released update) as packages ending up in /updates are only validated against /release and /updates (and rightfully so as thats how they are built too) And some important points to avoid making backports_testing a dumping ground for package(r)s trying to avoid the policy: * after submitting anything to backports_testing you have 48 hours to file/assign a Backport to validate at bugs.mageia.org. * package needs to be validated within 1 month (or shorter/longer time if QA wants that) * failure to match any of the two timelimits will get the package removed from updates_testing again. (I understand this This should have stated backports_testing will get some questions, but if we cant get people to help out with QA we might as well never open backports) And then the questions we need to decide on: (substitute mga1/mga2 for any future release...) 1. Do we support backporting package with higher version than package in the following next mageia release has ? (meaning if mga1 has v12, and mga2 has v14, is it ok to backport v16 to mga1?) * PRO: more uptodate package in backports * CON: can cause trouble during distro upgrade * imho both technically ok as long as we make sure its documented so people know what to expect. 2. If one want to backport a package to mga1, does it mean it must be backported to mga2 in order to preserve upgrade path (unless already in mga2, depending on question 1)? And since we can continue this what/if discussion forever, and thereby delay backports even more here is my take on it: my suggestions to decide on question 1 and 2: 1. backporting bigger version to mga1 than mga2 has is allowed as it will otherwise restrict backporting too much. (and since its leaf packages, it should not break (too much)). Lets just make it clear to everyone using backports. 2. we cant really require that as the one backporting the package to mga1 has to backport it to mga2 too as he/she might not be using mga2 at all. if someone wants/needs the backport for mga2, they need to request that. (in reality, going by how backports got handled in mdv most backports will end up in all supported releases anyway) I would favour adding the requirement that the dependancies of the backport must be available in the next release. So that we would expect that the backport would continue to function properly on an
Re: [Mageia-dev] Backports Summary
AL13N a écrit : Op dinsdag 26 juni 2012 23:15:16 schreef Sander Lepik: 26.06.2012 22:25, Thomas Backlund kirjutas: * backports is supported as long as the rest of the release Comments? Questions ? I think we should change the wording from supported to tested. Currently we can support backport with a newer version of the backport. But i don't think it's a wise move to mark backports repo as an updates repo. So i don't see how we can _support_ backports. And QA has no time to deal with updates for backports (i mean to search for security holes in backports). But this can be discussed tomorrow. i agree, this is only a wording change, but is imho substantially different from complete support, which is impossible. Or we could say partially supported, or low-priority support. Since the support is more than just testing. Nominally, it is almost as much as regular packages, but with a lower priority. (Some might argue that we don't offer complete support for regular packages, as we don't garantee a response within 24 hours.) -- André
[Mageia-dev] updating sshd kill ssh connection
I was updating remotly my build machine when: 192/254: openssh-server # Migrating sysvinit service 'sshd' to systemd native unit 'sshd.service' via systemd install rules. Connection to cauldron64.latmos.ipsl.fr closed by remote host. Connection to cauldron64.latmos.ipsl.fr closed. This must _never_ happend if the update goes wrong you completly loose the hand on the computer. BTW: restarting sshd never shutdown pending ssh connection. Please remove or fix this. Let's see the state of machine now I was disconnected during urpmi... -- Olivier Thauvin CNRS - LATMOS ♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖ pgpUqptclvcnD.pgp Description: PGP signature
Re: [Mageia-dev] Backports Summary
27.06.2012 10:56, andre999 kirjutas: Or we could say partially supported, or low-priority support. Since the support is more than just testing. How is it more than testing? QA will test if the package installs w/o conflicts + will check that it at least starts. But that's about it. No deeper testing like with Firefox or with LibreOffice. Nominally, it is almost as much as regular packages, but with a lower priority. Regular packages get updates in special repo. Backports won't - so can't agree here either. :) -- Sander
Re: [Mageia-dev] updating sshd kill ssh connection
* Sander Lepik (sander.le...@eesti.ee) wrote: 27.06.2012 11:06, Olivier Thauvin kirjutas: I was updating remotly my build machine when: 192/254: openssh-server # Migrating sysvinit service 'sshd' to systemd native unit 'sshd.service' via systemd install rules. Connection to cauldron64.latmos.ipsl.fr closed by remote host. Connection to cauldron64.latmos.ipsl.fr closed. This must _never_ happend if the update goes wrong you completly loose the hand on the computer. BTW: restarting sshd never shutdown pending ssh connection. Please remove or fix this. Let's see the state of machine now I was disconnected during urpmi... Check your /etc/ssh/sshd_config - you must use UsePAM yes there. https://wiki.mageia.org/en/Mageia_2_Errata#SSH_daemon_issues We already use PAM in ssh (because ldap)... -- Sander -- Olivier Thauvin CNRS - LATMOS ♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖ pgp96oNc9U6tz.pgp Description: PGP signature
Re: [Mageia-dev] Backports Summary
Sander Lepik skrev 26.6.2012 23:15: 26.06.2012 22:25, Thomas Backlund kirjutas: * backports is supported as long as the rest of the release Comments? Questions ? I think we should change the wording from supported to tested. Currently we can support backport with a newer version of the backport. But i don't think it's a wise move to mark backports repo as an updates repo. So i don't see how we can _support_ backports. And QA has no time to deal with updates for backports (i mean to search for security holes in backports). But this can be discussed tomorrow. Well, It's the backporters job to make sure its fixed for security issues as stated by: * if you backport anything, (regardless if you are the real maintainer or not) you accept the responsibility of handling the bugreports against the backport and make sure it gets patched (or upgraded) to get security fixes. It's not supposed to be flagged as an update repo as that would make it upgrade all packages it find in the system with matching backports packages. So we need to either create a backports update applet or extend current update applet. (or worst case until we get it automated tell the user of backported packages to make sure they check if a new/fixed rpm is available in backports) And there will still be some advisory notifying people of new backports, just like we do for security and bugfix updates now. -- Thomas
Re: [Mageia-dev] ANN: GCC-4.7.1 landing on Cauldron
Thomas Backlund skrev 26.6.2012 23:48: So, GCC-4.7.1 was released upstream on 2012-06-14, and it has now passed my builds and testing on both i586 and x86_64. So it's time to push it to Cauldron. I will rebuild core packages: gcc, binutils, glibc, kernel and kmod-* packages so you might want to wait with updating your local caldron install until all packages are available. I'll post a follow-up when it's done. It should now be safe to upgrade as the rebuilt core packages and kernels are now available ... -- Thomas
Re: [Mageia-dev] updating sshd kill ssh connection
'Twas brillig, and Olivier Thauvin at 27/06/12 09:17 did gyre and gimble: * Sander Lepik (sander.le...@eesti.ee) wrote: 27.06.2012 11:06, Olivier Thauvin kirjutas: I was updating remotly my build machine when: 192/254: openssh-server # Migrating sysvinit service 'sshd' to systemd native unit 'sshd.service' via systemd install rules. Connection to cauldron64.latmos.ipsl.fr closed by remote host. Connection to cauldron64.latmos.ipsl.fr closed. This must _never_ happend if the update goes wrong you completly loose the hand on the computer. BTW: restarting sshd never shutdown pending ssh connection. Please remove or fix this. Let's see the state of machine now I was disconnected during urpmi... Check your /etc/ssh/sshd_config - you must use UsePAM yes there. https://wiki.mageia.org/en/Mageia_2_Errata#SSH_daemon_issues We already use PAM in ssh (because ldap)... Then check your /etc/pam.d/system-auth (or /etc/pam.d/sshd which should include system-auth). The system-auth we ship includes: -sessionoptional pam_systemd.so This ensures that user processes inside sshd are not marked as processes of the service and thus do not get reaped. So it looks like something has not been propagated properly there on upgrade (system-auth should be modified appropriately, but perhaps sshd is custom or some other changes are messing things up). There is certainly not a fundamental error, so it must be configuration in some regard: [colin@jimmy ~]$ ssh marley Last login: Wed Jun 27 09:23:42 2012 from jimmy.rasta.guthr.ie [colin@marley ~]$ sudo -i [root@marley ~]# systemctl restart sshd.service [root@marley ~]# logout Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] Backports Summary
Thomas Backlund a écrit : Sander Lepik skrev 26.6.2012 23:15: 26.06.2012 22:25, Thomas Backlund kirjutas: * backports is supported as long as the rest of the release Comments? Questions ? I think we should change the wording from supported to tested. Currently we can support backport with a newer version of the backport. But i don't think it's a wise move to mark backports repo as an updates repo. So i don't see how we can _support_ backports. And QA has no time to deal with updates for backports (i mean to search for security holes in backports). But this can be discussed tomorrow. Well, It's the backporters job to make sure its fixed for security issues as stated by: * if you backport anything, (regardless if you are the real maintainer or not) you accept the responsibility of handling the bugreports against the backport and make sure it gets patched (or upgraded) to get security fixes. It's not supposed to be flagged as an update repo as that would make it upgrade all packages it find in the system with matching backports packages. So we need to either create a backports update applet or extend current update applet. I would favour extending the current update tools, and then flagging backport repos as updates, so that newer backports would be treated as updates to already installed backports at the same time as other updates. (or worst case until we get it automated tell the user of backported packages to make sure they check if a new/fixed rpm is available in backports) And there will still be some advisory notifying people of new backports, just like we do for security and bugfix updates now. +1 -- Thomas -- André
Re: [Mageia-dev] updating sshd kill ssh connection
* Colin Guthrie (mag...@colin.guthr.ie) wrote: 'Twas brillig, and Olivier Thauvin at 27/06/12 09:17 did gyre and gimble: * Sander Lepik (sander.le...@eesti.ee) wrote: 27.06.2012 11:06, Olivier Thauvin kirjutas: I was updating remotly my build machine when: 192/254: openssh-server # Migrating sysvinit service 'sshd' to systemd native unit 'sshd.service' via systemd install rules. Connection to cauldron64.latmos.ipsl.fr closed by remote host. Connection to cauldron64.latmos.ipsl.fr closed. This must _never_ happend if the update goes wrong you completly loose the hand on the computer. BTW: restarting sshd never shutdown pending ssh connection. Please remove or fix this. Let's see the state of machine now I was disconnected during urpmi... Check your /etc/ssh/sshd_config - you must use UsePAM yes there. https://wiki.mageia.org/en/Mageia_2_Errata#SSH_daemon_issues We already use PAM in ssh (because ldap)... Then check your /etc/pam.d/system-auth (or /etc/pam.d/sshd which should include system-auth). The system-auth we ship includes: -sessionoptional pam_systemd.so My system-auth is pushed via puppet to setup ldap authentication. So at time I'll add this to sshd pam config file. I wonder how other sys admin does to automated setup of their servers. Thanks. -- Olivier Thauvin CNRS - LATMOS ♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖ pgpt9OBJ9QmqL.pgp Description: PGP signature
Re: [Mageia-dev] Packagers meeting
On 27 June 2012 08:11, AL13N al...@rmail.be wrote: Our meeting will happen tomorrow evening at 19hUTC. Here are the proposed topics: - pending security updates - Mageia 3 features - Backports policy For the 2 last topics please read following links *before* meeting: https://www.mageia.org/pipermail/mageia-dev/2012-June/016819.html https://www.mageia.org/pipermail/mageia-dev/2012-June/016855.html Cheers can we have another talk of bug 2317? to find people willing to make a new patch that's quite more complex? ideally bug 2317 should be fixed before backports opens No, it's not related since you can't garanty that every user will get the update prior to use backports. So there's no need to rush...
Re: [Mageia-dev] Backports Summary
Sander Lepik a écrit : 27.06.2012 10:56, andre999 kirjutas: Or we could say partially supported, or low-priority support. Since the support is more than just testing. How is it more than testing? QA will test if the package installs w/o conflicts + will check that it at least starts. But that's about it. No deeper testing like with Firefox or with LibreOffice. Ok, testing by QA is less detailed. After preliminary testing before reaching QA, which presumably is more involved. Complex packages like Firefox or LibreOffice necessarily need more testing in any case. But don't forget that the packager is committed to providing security updates and bug fixes, much as for regular packages. Which is more than just testing. Nominally, it is almost as much as regular packages, but with a lower priority. Regular packages get updates in special repo. Backports won't - so can't agree here either. :) The advantage of separate release repos when looking for updates, is that scanning all the (much more numerous) release packages is avoided. Otherwise (as far as updates are concerned), one could put the release and regular updates in the same repo. Backports will be relatively limited in number, and the release repo for backports would be necessarily empty. So there is no point in two repos for backports. Backports are essentially updates. (Albeit a special kind.) That is, changes from the release. We only want to install a backport if expressly selected, or a corresponding backport is already installed. Much as we would only want to install a package from an update repo if it is expressly selected, or a corresponding update or release package is already installed. -- Sander -- André
Re: [Mageia-dev] Backports Summary
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 27/06/2012 10:23, Thomas Backlund ha scritto: It's not supposed to be flagged as an update repo as that would make it upgrade all packages it find in the system with matching backports packages. Why not? Just let the user to decide, who does want it, just enable it. Who wants cherry-peeking it just enable the bp repo and disable it after. The real problem is how to make people understanding that a bp has been released as bug or security fixing of an already backported package... No problems if you enable bp as updates, while you have problems if you cherry-peek a package... Angelo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/q2U8ACgkQqEs9DA4DquCFawCdHTQXC0L4cxQCgEo8a1relOyc ZEIAnibkaY/4PAlvpHmfsKCyu2LECDzZ =pf4G -END PGP SIGNATURE-
Re: [Mageia-dev] Backports Summary
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 27/06/2012 10:23, Thomas Backlund ha scritto: And there will still be some advisory notifying people of new backports, just like we do for security and bugfix updates now. This could solve my last :) Angelo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/q2aUACgkQqEs9DA4DquAOtQCeOhh3fe50vUIXtJvZT8BU/EpR +XsAoJnQTSCYSJ6vOQKhXdZ2NViCnXkb =0tRa -END PGP SIGNATURE-
Re: [Mageia-dev] Packagers meeting
On 27 June 2012 11:52, Thomas Backlund t...@mageia.org wrote: So as a carrot (or a whip) to get someone to try to fix #2317, one could say it needs to be fixed before opening backports No it's still orthogonal: not every people will have installed the needed updates packages...
[Mageia-dev] Meeting on Thursday 28th at 17.30 UTC
Hi, As Oliver proposed in the “Mageia 2 post-mortem” topic on this mailing list, our team meeting will be held tomorrow, on Thursday 28th at 17.30 UTC (that is 18h30 London time and 19h30 Paris time, search for the correspondance with your timezone here[1] if you don't know what is the Δt in your case). As usual the meeting will be on Freenode's #mageia-i18n IRC channel. We will discuss quite important topics for our team and workflow so please try to attend. The topics will be: 1) Mageia 2 post-mortem: see this mail[2] for the various feedback and suggestions. 2) Transifex replacement; clarification of the workflow until we replace Tx with something else. 3) Wiki translation: this has been discussed yesterday in the documentation team meeting. I will try to see with Marja and Oliver what is the current status. 4) Feel free to suggest other topics. See you tomorrow! Regards, Rémi / Akien [1] http://www.timeanddate.com/worldclock/ [2] https://www.mageia.org/pipermail/mageia-i18n/2012-June/002988.html
Re: [Mageia-dev] Meeting on Thursday 28th at 17.30 UTC
Wrong ML, sorry ;) 2012/6/27 Rémi Verschelde r...@verschelde.fr: Hi, As Oliver proposed in the “Mageia 2 post-mortem” topic on this mailing list, our team meeting will be held tomorrow, on Thursday 28th at 17.30 UTC (that is 18h30 London time and 19h30 Paris time, search for the correspondance with your timezone here[1] if you don't know what is the Δt in your case). As usual the meeting will be on Freenode's #mageia-i18n IRC channel. We will discuss quite important topics for our team and workflow so please try to attend. The topics will be: 1) Mageia 2 post-mortem: see this mail[2] for the various feedback and suggestions. 2) Transifex replacement; clarification of the workflow until we replace Tx with something else. 3) Wiki translation: this has been discussed yesterday in the documentation team meeting. I will try to see with Marja and Oliver what is the current status. 4) Feel free to suggest other topics. See you tomorrow! Regards, Rémi / Akien [1] http://www.timeanddate.com/worldclock/ [2] https://www.mageia.org/pipermail/mageia-i18n/2012-June/002988.html
Re: [Mageia-dev] Remove upgrade functionnality in installer
Anne nicolas a écrit : But using a DVD to upgrade an already installed system is a good way to get around the fact that many packages, including nonfree firmware, are missing from the DVD. If one does a clean install, one has to try to find a lot of missing packages, because they are no longer installed. This impacts considerably the usability of the system. (Considering what the user had installed.) All one has to do after the upgrade install, is reboot and do a normal upgrade with rpmdrake (selecting all updates and all packages), and almost everything works well. (For me upgrade to mga1 worked perfectly. The last 2 upgrades with mdv had some problems, due to other factors. A clean install has always caused me a lot of problems.) With a clean install, it can be problematic to find all the missing packages, as well as missing firmware. I'm not saying we remove all upgrade ways as we still have mgaapplet. We experienced *a lot* of problem during QA tests using DVD to upgrade. Really I don't understand your point... Well maybe I'm not understanding your proposal. Initially I thought it was to remove the update option at the end of the upgrade process with the DVD. Then a post earlier in this thread said that you didn't mean that, and seemed to say that you were suggesting removing the upgrade install option with the DVD, leaving only the clean install. If so, I am strongly opposed, as in my experience, for the reasons cited, it has been by far the best upgrade path for myself, and I'm sure for many others. However, maybe I'm misunderstanding your proposal ? Maybe the introduction of systemd introduced a one-time transition problem which will not normally be encountered with a DVD upgrade install ? Note that I don't use mgaapplet after an upgrade install, since it doesn't give me all the information I want, to help me decide if I should drop some packages that were installed. This is not the role of this tool. Sorry, just trying to put my approach in context. It may be that using mgaapplet after an upgrade install is the weak link in the chain. And certainly urpmi is not a convenient tool at this point. (Although I use it a lot at other times.) So because mgaapplet is buggy for upgrades, we should just let it down and use DVD ? That is not the same thing as saying that we should *prevent* using the DVD for upgrades. In any case, with the reliability of Internet connexions available at my location, it is highly unlikely that I could make an upgrade without the DVD. And during a DVD upgrade, I don't have Internet access. (My Internet supplier usually cuts the connexion if not active for 5 minutes, which always happens with a DVD upgrade.) Note also that with upgrade install, even firmware that is missing from the release (and not only the DVD) remains installed. So there are cases where an upgrade install necessarily produces a better functioning system. So in sum, in my view, removing upgrade install for DVDs would be an important regression. But maybe we should suggest rebooting and using rpmdrake after such an install. This is non sense... Either the upgrade tool does its job properly or not... How can we say Mageia is easy when you propose such process? Sorry, but I think that even the least computer-savy user could easily use this approach. Simply 1) Do upgrade with DVD 2) Reboot 3) Do update with MCC/software/package_installer (rpmdrake) or update_system (mgaapplet) Since an upgrade install only removes packages that are replaced, nonfree firmware stays installed. Also packages not on the DVD stay installed, even though not updated until step 3. Note that on Microsoft systems, it is generally recommended to reboot after installing, even for relatively minor upgrades. Instead of only after a release upgrade. If the user has reliable Internet access during upgrade, of course it would be advantageous to do it in one step. Note also that at least in North America, users can usually download a DVD for free at their local library, even if they don't have a good Internet connexion at home. And in other regions, users could obtain a copy of the DVD without having to download it themselves. So the DVD upgrade install has its' place. Regards :) -- André
Re: [Mageia-dev] Packagers meeting
Thierry Vignaud skrev 27.6.2012 13:09: On 27 June 2012 11:52, Thomas Backlund t...@mageia.org wrote: So as a carrot (or a whip) to get someone to try to fix #2317, one could say it needs to be fixed before opening backports No it's still orthogonal: not every people will have installed the needed updates packages... Well, technically yes, but as the purpose of this carrot is exactly if user want to get backports repos opened then user need to help fix #2317 (or help find someone that can) :) Point is that we are slowly killing QA, wich means at some point it will stop working - we might as well stop doing releases. And people are also dreaming of LTS, wich with current resources will never happend. So we _really_ need to help QA minimize their workload as much as possible. -- Thomas
Re: [Mageia-dev] Backports Summary
Le mercredi 27 juin 2012 11:06:49 Sander Lepik a écrit : 27.06.2012 10:56, andre999 kirjutas: Or we could say partially supported, or low-priority support. Since the support is more than just testing. How is it more than testing? QA will test if the package installs w/o conflicts + will check that it at least starts. But that's about it. No deeper testing like with Firefox or with LibreOffice. It should be obvious : support is not just testing, it's also commitment from the packager to fix future bugs and security issues. Don't you see the difference ? Nominally, it is almost as much as regular packages, but with a lower priority. Regular packages get updates in special repo. Backports won't - so can't agree here either. :) An update for an update is in the same media as the previous update. Same as backports. Thomas is right.
Re: [Mageia-dev] Backports Summary
Thomas Backlund a écrit : Sander Lepik skrev 26.6.2012 23:15: 26.06.2012 22:25, Thomas Backlund kirjutas: * backports is supported as long as the rest of the release Comments? Questions ? I think we should change the wording from supported to tested. Currently we can support backport with a newer version of the backport. But i don't think it's a wise move to mark backports repo as an updates repo. So i don't see how we can _support_ backports. And QA has no time to deal with updates for backports (i mean to search for security holes in backports). But this can be discussed tomorrow. Well, It's the backporters job to make sure its fixed for security issues as stated by: * if you backport anything, (regardless if you are the real maintainer or not) you accept the responsibility of handling the bugreports against the backport and make sure it gets patched (or upgraded) to get security fixes. It's not supposed to be flagged as an update repo as that would make it upgrade all packages it find in the system with matching backports packages. So we need to either create a backports update applet or extend current update applet. I would favour extending the current update tools, and then flagging backport repos as updates, so that newer backports would be treated as updates to already installed backports at the same time as other updates. actually, since the applet will have to works like this: (cf bug 2317) 1. mark media to get updates from 2. mark seachmedia to get it's dependencies from (release) 3. do updates extending this to backports does the following: 1. mark update media + backport media 2. mark search media to get it's dependencies from (release) 3. do updates With regard to dependencies, this means we'd be including backports too, which means we could use my patch for bug 2317 anyway. If you don't want this, you'd have to do the updates and backports separately. which is again quite some complexity. (besides, if we do have strict requires, to make cherry-picking work, the problems we'd get from using the patch would go away anyway. (or worst case until we get it automated tell the user of backported packages to make sure they check if a new/fixed rpm is available in backports) And there will still be some advisory notifying people of new backports, just like we do for security and bugfix updates now. +1 -- Thomas -- André
Re: [Mageia-dev] Packagers meeting
On 27 June 2012 08:11, AL13N al...@rmail.be wrote: Our meeting will happen tomorrow evening at 19hUTC. Here are the proposed topics: - pending security updates - Mageia 3 features - Backports policy For the 2 last topics please read following links *before* meeting: https://www.mageia.org/pipermail/mageia-dev/2012-June/016819.html https://www.mageia.org/pipermail/mageia-dev/2012-June/016855.html Cheers can we have another talk of bug 2317? to find people willing to make a new patch that's quite more complex? ideally bug 2317 should be fixed before backports opens No, it's not related since you can't garanty that every user will get the update prior to use backports. So there's no need to rush... QA team told me that it would increase their workload dramatically, so i think there is need rush.
Re: [Mageia-dev] Packagers meeting
[...] So as a carrot (or a whip) to get someone to try to fix #2317, one could say it needs to be fixed before opening backports :-)
Re: [Mageia-dev] Backports Summary
andre999 skrev 27.6.2012 10:47: Thomas Backlund a écrit : Thomas Backlund skrev 26.6.2012 22:25: And then the questions we need to decide on: (substitute mga1/mga2 for any future release...) 1. Do we support backporting package with higher version than package in the following next mageia release has ? (meaning if mga1 has v12, and mga2 has v14, is it ok to backport v16 to mga1?) * PRO: more uptodate package in backports * CON: can cause trouble during distro upgrade * imho both technically ok as long as we make sure its documented so people know what to expect. 2. If one want to backport a package to mga1, does it mean it must be backported to mga2 in order to preserve upgrade path (unless already in mga2, depending on question 1)? And since we can continue this what/if discussion forever, and thereby delay backports even more here is my take on it: my suggestions to decide on question 1 and 2: 1. backporting bigger version to mga1 than mga2 has is allowed as it will otherwise restrict backporting too much. (and since its leaf packages, it should not break (too much)). Lets just make it clear to everyone using backports. 2. we cant really require that as the one backporting the package to mga1 has to backport it to mga2 too as he/she might not be using mga2 at all. if someone wants/needs the backport for mga2, they need to request that. (in reality, going by how backports got handled in mdv most backports will end up in all supported releases anyway) I would favour adding the requirement that the dependancies of the backport must be available in the next release. So that we would expect This is esentially stating that we cant backport any bigger version to mga2 /backports than mga3 will havein /release wich means when we hit version freeze for mga3, it also freezes mga2 /backports... that the backport would continue to function properly on an update to the next release, but we don't require that it be tested, so it may not. -ENOTCOMPUTE continue to function properly vs don't require that it be tested This is a relatively simple to check, so it won't have a big impact on QA, but should increase significantly the reliability of backports. Nothing is simple if it's supposed to continue to function properly as it then must be tested. If we can agree on this as a start, we can open backports soon so we get actual facts of how backports policy and process works. Then we rewiew backports policy and process in ~6 months, and adjust it if needed. Comments? Questions ? I would favour tagging backports as update repos, so that in the event of a newer backport for security or bug fixes, that it will be automatically presented with other updates. No. as the update applet currently works it would show the backport as an update even if you dont have an earlier backport installed, defeating the purpose of having separate /updates vs /backports This would require some modification to update tools, so it seems to me ok to open backports beforehand, with the understanding that the update tools would be changed to accommodate this. Tools must work before the backports repo affect them. -- Thomas
Re: [Mageia-dev] Backports Summary
AL13N skrev 27.6.2012 09:17: Op dinsdag 26 juni 2012 23:15:16 schreef Sander Lepik: 26.06.2012 22:25, Thomas Backlund kirjutas: * backports is supported as long as the rest of the release Comments? Questions ? I think we should change the wording from supported to tested. Currently we can support backport with a newer version of the backport. But i don't think it's a wise move to mark backports repo as an updates repo. So i don't see how we can _support_ backports. And QA has no time to deal with updates for backports (i mean to search for security holes in backports). But this can be discussed tomorrow. i agree, this is only a wording change, but is imho substantially different from complete support, which is impossible. Well, it's supposed to be supported with security and bugfixes. The support is about _providing_ the fixed packages. As to wether people install them or not, it's sort of the same as current /updates. we provide them and suggest them to be updated, but we dont force anyone to install the updates. -- Thomas
Re: [Mageia-dev] Packagers meeting
27.06.2012 13:29, Thomas Backlund kirjutas: Well, technically yes, but as the purpose of this carrot is exactly if user want to get backports repos opened then user need to help fix #2317 (or help find someone that can) :) Point is that we are slowly killing QA, wich means at some point it will stop working - we might as well stop doing releases. I still don't understand where's the big problem if we enable release media for updates. It's not updated, so it shouldn't slow down updating too much. Hardware that can run DEs today should have no problems with release media enabled for updates. QA is proposing this solution again and again. Is this really that hard to change? -- Sander
Re: [Mageia-dev] Packagers meeting
2012/6/27 Sander Lepik sander.le...@eesti.ee: I still don't understand where's the big problem if we enable release media for updates. It's not updated, so it shouldn't slow down updating too much. Hardware that can run DEs today should have no problems with release media enabled for updates. QA is proposing this solution again and again. Is this really that hard to change? The _simplest_ solution (conceptually speaking) would be to use a condition which would enable release media for updates _if_ one or more of the dependancies cannot be found in the updates media. But I guess that it's not that simple in the code if it still has not been considered otherwise than conceptually.
Re: [Mageia-dev] Remove upgrade functionnality in installer
On Sat, 23 Jun 2012, Anne Nicolas wrote: Hi there I'd like to propose this one: https://wiki.mageia.org/en/Feature:RemoveUpgradeInstaller If we are removing upgrade from installer, we can maybe replace it with something in mgaapplet to allow offline upgrades, similar to what is doing Fedora : https://fedoraproject.org/wiki/Features/OfflineSystemUpdates mgaapplet could have an option to : - download all updated packages - reboot the system in special system update mode - snapshot filesystems (optionally) - install all updated packages - reboot on the upgraded system, or restore snapshot if upgrade failed
Re: [Mageia-dev] Packagers meeting
2012/6/27 Sander Lepik sander.le...@eesti.ee: I still don't understand where's the big problem if we enable release media for updates. It's not updated, so it shouldn't slow down updating too much. Hardware that can run DEs today should have no problems with release media enabled for updates. QA is proposing this solution again and again. Is this really that hard to change? Don't forget that upgrades work similarly. The _simplest_ solution (conceptually speaking) would be to use a condition which would enable release media for updates _if_ one or more of the dependancies cannot be found in the updates media. But I guess that it's not that simple in the code if it still has not been considered otherwise than conceptually. I think the simplest solution (code-wise) is to make sure that where-ever you're looking for dependencies, is to have strict requires so that it will always get the correct one.
Re: [Mageia-dev] Packagers meeting
On 27/06/12 12:13, AL13N wrote: 2012/6/27 Sander Lepiksander.le...@eesti.ee: I still don't understand where's the big problem if we enable release media for updates. It's not updated, so it shouldn't slow down updating too much. Hardware that can run DEs today should have no problems with release media enabled for updates. QA is proposing this solution again and again. Is this really that hard to change? Don't forget that upgrades work similarly. The _simplest_ solution (conceptually speaking) would be to use a condition which would enable release media for updates _if_ one or more of the dependancies cannot be found in the updates media. But I guess that it's not that simple in the code if it still has not been considered otherwise than conceptually. I think the simplest solution (code-wise) is to make sure that where-ever you're looking for dependencies, is to have strict requires so that it will always get the correct one. That would have no effect. If the any recursive require was in Release media, it would fail. It includes if a Tainted package recursively requires something from Core Release. Plus if there is an added suggest that has recursive requires in Release media then an upgrade will also fail, we recently found. Claire
Re: [Mageia-dev] Backports Summary
Thomas Backlund a écrit : andre999 skrev 27.6.2012 10:47: Thomas Backlund a écrit : Thomas Backlund skrev 26.6.2012 22:25: And then the questions we need to decide on: (substitute mga1/mga2 for any future release...) 1. Do we support backporting package with higher version than package in the following next mageia release has ? (meaning if mga1 has v12, and mga2 has v14, is it ok to backport v16 to mga1?) * PRO: more uptodate package in backports * CON: can cause trouble during distro upgrade * imho both technically ok as long as we make sure its documented so people know what to expect. 2. If one want to backport a package to mga1, does it mean it must be backported to mga2 in order to preserve upgrade path (unless already in mga2, depending on question 1)? And since we can continue this what/if discussion forever, and thereby delay backports even more here is my take on it: my suggestions to decide on question 1 and 2: 1. backporting bigger version to mga1 than mga2 has is allowed as it will otherwise restrict backporting too much. (and since its leaf packages, it should not break (too much)). Lets just make it clear to everyone using backports. 2. we cant really require that as the one backporting the package to mga1 has to backport it to mga2 too as he/she might not be using mga2 at all. if someone wants/needs the backport for mga2, they need to request that. (in reality, going by how backports got handled in mdv most backports will end up in all supported releases anyway) I would favour adding the requirement that the dependancies of the backport must be available in the next release. So that we would expect This is esentially stating that we cant backport any bigger version to mga2 /backports than mga3 will havein /release wich means when we hit version freeze for mga3, it also freezes mga2 /backports... I'm not following this point. What I mean is that if backport xx for mga1 requires yy version 12 in mga1, but yy is version 13 in mga2, we would define the requires for yy to accept versions 12 to 13 (or maybe wider). If the user updates to mga2, yy would be updated to version 13, and the backport would still be expected to work (without being tested). Of course it is possible that it doesn't for some reason, as it hasn't been tested. But adding this requirement makes it much more likely to work. If there is a further update to mga3, the backport would be replaced by what was the cauldron package, which would have the appropriate requires. that the backport would continue to function properly on an update to the next release, but we don't require that it be tested, so it may not. -ENOTCOMPUTE continue to function properly vs don't require that it be tested See my explanation above. This is a relatively simple to check, so it won't have a big impact on QA, but should increase significantly the reliability of backports. Nothing is simple if it's supposed to continue to function properly as it then must be tested. My point is simply that if we ensure that the backport requires match what is available in the next release, then it is more likely to work than if we don't meet this condition. I'm not saying that it must continue to function properly, only that it is more likely to. There are many cases where the available packages change, and it required packages are no longer available, it could be more prudent to deny the backport. Just a suggestion. If we can agree on this as a start, we can open backports soon so we get actual facts of how backports policy and process works. Then we rewiew backports policy and process in ~6 months, and adjust it if needed. Comments? Questions ? I would favour tagging backports as update repos, so that in the event of a newer backport for security or bug fixes, that it will be automatically presented with other updates. No. as the update applet currently works it would show the backport as an update even if you dont have an earlier backport installed, defeating the purpose of having separate /updates vs /backports This is conditional on first modifying the update tools, as suggested next. A backport should only update an already installed backport. (Similarly for nonfree and tainted, if that is not already the case.) This would require some modification to update tools, so it seems to me ok to open backports beforehand, with the understanding that the update tools would be changed to accommodate this. Tools must work before the backports repo affect them. I agree that it would be very much better to modify the tools first. Just suggesting that as an alternative, if we are in a hurry to open backports. -- Thomas -- André
Re: [Mageia-dev] Packagers meeting
On 27 June 2012 12:38, Maarten Vanraes maarten.vanr...@gmail.com wrote: can we have another talk of bug 2317? to find people willing to make a new patch that's quite more complex? ideally bug 2317 should be fixed before backports opens No, it's not related since you can't garanty that every user will get the update prior to use backports. So there's no need to rush... QA team told me that it would increase their workload dramatically, so i think there is need rush. Again, there's no rush to change mgaapplet as anyway, not all users will use it. We cannot break those systems... We have to continue supporting those. Once a release is released, we've to support it. It's done.
Re: [Mageia-dev] ANN: GCC-4.7.1 landing on Cauldron
Will there be rebuilding robot for cauldron so that we could detect build failures due to new tool chain? 2012/6/27 Thomas Backlund t...@mageia.org: Thomas Backlund skrev 26.6.2012 23:48: So, GCC-4.7.1 was released upstream on 2012-06-14, and it has now passed my builds and testing on both i586 and x86_64. So it's time to push it to Cauldron. I will rebuild core packages: gcc, binutils, glibc, kernel and kmod-* packages so you might want to wait with updating your local caldron install until all packages are available. I'll post a follow-up when it's done. It should now be safe to upgrade as the rebuilt core packages and kernels are now available ... -- Thomas
Re: [Mageia-dev] ANN: GCC-4.7.1 landing on Cauldron
On 27 June 2012 13:48, Funda Wang fundaw...@gmail.com wrote: Will there be rebuilding robot for cauldron so that we could detect build failures due to new tool chain? Not until we upgrade glibc first. So we've still to wait a month.
Re: [Mageia-dev] Backports Summary
Le mardi 26 juin 2012 22:25:10 Thomas Backlund a écrit : And since we can continue this what/if discussion forever, and thereby delay backports even more here is my take on it: my suggestions to decide on question 1 and 2: 1. backporting bigger version to mga1 than mga2 has is allowed as it will otherwise restrict backporting too much. (and since its leaf packages, it should not break (too much)). Lets just make it clear to everyone using backports. Ok for me, but would be better if before upgrade a warning is raised because of backports that cannot be updated and could possibily prevent the upgrade of other packages. 2. we cant really require that as the one backporting the package to mga1 has to backport it to mga2 too as he/she might not be using mga2 at all. if someone wants/needs the backport for mga2, they need to request that. (in reality, going by how backports got handled in mdv most backports will end up in all supported releases anyway) Thinking of when upgrade tools will allow to take backports into account for upgrade, I'd rather require that packages be backported to both mga2 and mga1 so that upgrade always works, but until then if people prefer your option I won't speak against. Ok, and people join QA to test backports if you really want them ! :) Samuel
Re: [Mageia-dev] ANN: GCC-4.7.1 landing on Cauldron
Funda Wang skrev 27.6.2012 14:48: Will there be rebuilding robot for cauldron so that we could detect build failures due to new tool chain? Not yet. In order to avoid a dual rebuild we will wait for GLIBC 2.16 to land on cauldron too. GLIBC 2.16 is scheduled to be released on first week of july. The other thing I haven't decided on yet is if we should upgrade binutils to 2.22.52.0.4 (wich is a beta) to get better support for the new x32 arch or wait for 2.23 to be released... Of course if someone want to set up a local rebuild set to test already, and report breakages already that's ok to... -- Thomas
Re: [Mageia-dev] ANN: GCC-4.7.1 landing on Cauldron
On 2012.06.27, at 13:58, Thomas Backlund wrote: Funda Wang skrev 27.6.2012 14:48: Will there be rebuilding robot for cauldron so that we could detect build failures due to new tool chain? Not yet. In order to avoid a dual rebuild we will wait for GLIBC 2.16 to land on cauldron too. GLIBC 2.16 is scheduled to be released on first week of july. The other thing I haven't decided on yet is if we should upgrade binutils to 2.22.52.0.4 (wich is a beta) to get better support for the new x32 arch or wait for 2.23 to be released... Of course if someone want to set up a local rebuild set to test already, and report breakages already that's ok to... As always happens with CUDA, new gcc breaks CUDA. I will post a patch in a bug report against CUDA. -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free
Re: [Mageia-dev] Slowly pushing GNOME 3.5.3
On 27.06.2012 00:16, Olav Vitters wrote: On Tue, Jun 26, 2012 at 10:55:00AM +0200, Olav Vitters wrote: - various new dependencies If someone could package: pwquality for me.. appreciated :-) Imported.
Re: [Mageia-dev] Packagers meeting
'Twas brillig, and Anne nicolas at 26/06/12 20:40 did gyre and gimble: Hi there Our meeting will happen tomorrow evening at 19hUTC. Here are the proposed topics: - pending security updates - Mageia 3 features - Backports policy For the 2 last topics please read following links *before* meeting: https://www.mageia.org/pipermail/mageia-dev/2012-June/016819.html https://www.mageia.org/pipermail/mageia-dev/2012-June/016855.html Sadly I'm not around this evening. Please let me know before 5:30pm if there is anything you specifically want to ask me. Cheers Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] Backports Summary
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 27/06/2012 12:46, Thomas Backlund ha scritto: I would favour tagging backports as update repos, so that in the event of a newer backport for security or bug fixes, that it will be automatically presented with other updates. No. as the update applet currently works it would show the backport as an update even if you dont have an earlier backport installed, defeating the purpose of having separate /updates vs /backports hmm, only if it is enabled as update by default. Again, let the user decide, he knows if he wants all the backports (and updated) or just cherry-peeked | Enable | Update |Type | | X||Backport | or | Enable | Update |Type | | X|X |Backport | Usually Update is blocked, but once it was clickable by User I know we can change it by editing configuration files, I propose to let the user enable again it at least for backports... Angelo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/rCFcACgkQqEs9DA4DquBHuACgn5YzqworNBED2KzOJBt5MDrm T7YAn1bRhX29i1d9CwXCbi3RaU1Vuzzt =0qjS -END PGP SIGNATURE-
Re: [Mageia-dev] What is Mageia's policy reagarding filesize display? (units/base 2 vs base 10)
On 26 June 2012 22:36, Olav Vitters o...@vitters.nl wrote: glib/gtk+/nautilus/transmission (it shows me base 10) Note that Windows is inconsistent. It sometimes shows base 10, sometimes base 2. Furthermore, the only reason they left it as base 2 was because other OSes did (was once in a MSDN blog). Suggesting Windows as comparison is pretty arbitrary. In any case, my main point is that I don't see why development should be done within a distribution. E.g. you're advocating changing this, but this is basically repeating a discussion that has been held upstream various times. +1 This cannot be applied until accepted upstream. You're basically forcing your preferences whereas current displaying is fine with other people.
Re: [Mageia-dev] Packagers meeting
Anne nicolas ennael@... writes: Our meeting will happen tomorrow evening at 19hUTC. Here are the proposed topics: - pending security updates There are a few things to talk about here. I believe Anne wanted to talk about the fact that there's a ton of security updates assigned to QA. QA is doing a good job with these, but they could always use more help. There are some other issues too. There are a few security updates that have been pushed to QA that they have found some issues with, and I need help correcting these issues. I don't want to make executive decisions about changing things in packages I don't know much about when I'm just trying to push security updates, and I could use some input from more experienced people. Bug 6379 - groff (groffer command in groff package needs groff-perl) https://bugs.mageia.org/show_bug.cgi?id=6379 Bug 6469 - krb5 (problems with kadmin and/or krlogin) https://bugs.mageia.org/show_bug.cgi?id=6469 Bug 6544 - tftp (problems with xinetd service configuration) https://bugs.mageia.org/show_bug.cgi?id=6544 Bug 6548 - firefox (gnome-python-gtkmozembed segfaulting) https://bugs.mageia.org/show_bug.cgi?id=6548 Finally, there are several other needed security updates for which no update has been built yet and I have CC'd other packagers, but in many cases haven't received any input on yet. Thanks in advance for any help anyone can offer.
Re: [Mageia-dev] Backports Summary
On Wed, 27 Jun 2012, andre999 wrote: Thomas Backlund a écrit : andre999 skrev 27.6.2012 14:40: Thomas Backlund a écrit : andre999 skrev 27.6.2012 10:47: I would favour adding the requirement that the dependancies of the backport must be available in the next release. So that we would expect This is esentially stating that we cant backport any bigger version to mga2 /backports than mga3 will havein /release wich means when we hit version freeze for mga3, it also freezes mga2 /backports... I'm not following this point. What I mean is that if backport xx for mga1 requires yy version 12 in mga1, but yy is version 13 in mga2, we would define the requires for yy to accept versions 12 to 13 (or maybe wider). Point is what if you backport version 14 to mga1, and mga2 has version 13, then upgrade path breaks. No problem. If the requirements of version 14 are present in mga2, then the backport will (very likely) continue to work normally. If the versions of the required packages change, they will be updated with the upgrade. Since version 13 of mga2 is less than the version 14 of the backport, it won't be installed. There is no guaranty that requirements of version 14 mga1 backports are all available in mageia 2. If it is linked with libsomething.so.1, but mageia 2 only has libsomething.so.2, then there is a problem.
Re: [Mageia-dev] Backports Summary
On Wed, 27 Jun 2012, andre999 wrote: I would favour tagging backports as update repos, so that in the event of a newer backport for security or bug fixes, that it will be automatically presented with other updates. No. as the update applet currently works it would show the backport as an update even if you dont have an earlier backport installed, defeating the purpose of having separate /updates vs /backports This is conditional on first modifying the update tools, as suggested next. A backport should only update an already installed backport. (Similarly for nonfree and tainted, if that is not already the case.) We should not change the behaviour of medias tagged as update repo. If we want a different behaviour for backports then we should tag those medias as backport, not update.
Re: [Mageia-dev] Backports Summary
nicolas vigier a écrit : On Wed, 27 Jun 2012, andre999 wrote: Thomas Backlund a écrit : andre999 skrev 27.6.2012 14:40: Thomas Backlund a écrit : andre999 skrev 27.6.2012 10:47: I would favour adding the requirement that the dependancies of the backport must be available in the next release. So that we would expect This is esentially stating that we cant backport any bigger version to mga2 /backports than mga3 will havein /release wich means when we hit version freeze for mga3, it also freezes mga2 /backports... I'm not following this point. What I mean is that if backport xx for mga1 requires yy version 12 in mga1, but yy is version 13 in mga2, we would define the requires for yy to accept versions 12 to 13 (or maybe wider). Point is what if you backport version 14 to mga1, and mga2 has version 13, then upgrade path breaks. No problem. If the requirements of version 14 are present in mga2, then the backport will (very likely) continue to work normally. If the versions of the required packages change, they will be updated with the upgrade. Since version 13 of mga2 is less than the version 14 of the backport, it won't be installed. There is no guaranty that requirements of version 14 mga1 backports are all available in mageia 2. If it is linked with libsomething.so.1, but mageia 2 only has libsomething.so.2, then there is a problem. That was my point. I was suggesting that it be required that backport requires be compatible with newer releases. In your example, cauldron would probably require the libsomething.so.2, so if the backport requires could be adjusted to work with libsomething.so.1, we would keep the requires compatible with libsomething.so.2. If that isn't possible, then it wouldn't be accepted. I'm no expert of course, but it seems to me that it would be generally possible as long as there weren't important code changes made to make the backport work. So it would largely be a question of appropriately adjusting the specified requires. -- André
Re: [Mageia-dev] Backports Summary
Le mercredi 27 juin 2012 16:08:10 nicolas vigier a écrit : On Wed, 27 Jun 2012, andre999 wrote: I would favour tagging backports as update repos, so that in the event of a newer backport for security or bug fixes, that it will be automatically presented with other updates. No. as the update applet currently works it would show the backport as an update even if you dont have an earlier backport installed, defeating the purpose of having separate /updates vs /backports This is conditional on first modifying the update tools, as suggested next. A backport should only update an already installed backport. (Similarly for nonfree and tainted, if that is not already the case.) We should not change the behaviour of medias tagged as update repo. If we want a different behaviour for backports then we should tag those medias as backport, not update. Fully agreed
Re: [Mageia-dev] Slowly pushing GNOME 3.5.3
On Wed, Jun 27, 2012 at 03:53:01PM +0300, Jani Välimaa wrote: On 27.06.2012 00:16, Olav Vitters wrote: On Tue, Jun 26, 2012 at 10:55:00AM +0200, Olav Vitters wrote: - various new dependencies If someone could package: pwquality for me.. appreciated :-) Imported. Thanks! For some reason gnome-disk-utility still doesn't build, cannot link against pwquality, don't get why... no time atm to figure it out. pwquality is also needed for gnome-control-center, but that one is complicated upgrade. First need new systemd, evolution stuff, etc. -- Regards, Olav
Re: [Mageia-dev] Slowly pushing GNOME 3.5.3
On 27.06.2012 17:40, Olav Vitters wrote: On Wed, Jun 27, 2012 at 03:53:01PM +0300, Jani Välimaa wrote: On 27.06.2012 00:16, Olav Vitters wrote: On Tue, Jun 26, 2012 at 10:55:00AM +0200, Olav Vitters wrote: - various new dependencies If someone could package: pwquality for me.. appreciated :-) Imported. Thanks! For some reason gnome-disk-utility still doesn't build, cannot link against pwquality, don't get why... no time atm to figure it out. Yes, I noticed and I'm on it. I'll push gnome-disk-utility too after I've fixed pwquality issue.
Re: [Mageia-dev] Backports Summary
nicolas vigier a écrit : On Wed, 27 Jun 2012, andre999 wrote: I would favour tagging backports as update repos, so that in the event of a newer backport for security or bug fixes, that it will be automatically presented with other updates. No. as the update applet currently works it would show the backport as an update even if you dont have an earlier backport installed, defeating the purpose of having separate /updates vs /backports This is conditional on first modifying the update tools, as suggested next. A backport should only update an already installed backport. (Similarly for nonfree and tainted, if that is not already the case.) We should not change the behaviour of medias tagged as update repo. If we want a different behaviour for backports then we should tag those medias as backport, not update. The idea is, once the tools are appropriately adjusted, to tag the backport repos as update media, as in rpmdrake. But alternately we could get the update tools to automatically treat backport repos as update media for backports. The concept is that backports would be presented for update along with other updates. Backport updates would only replace backports, but backports could be replaced by regular updates, if the version is equal or higher. -- André
Re: [Mageia-dev] Backports Summary
On Wed, 27 Jun 2012, andre999 wrote: nicolas vigier a écrit : On Wed, 27 Jun 2012, andre999 wrote: Thomas Backlund a écrit : andre999 skrev 27.6.2012 14:40: Thomas Backlund a écrit : andre999 skrev 27.6.2012 10:47: I would favour adding the requirement that the dependancies of the backport must be available in the next release. So that we would expect This is esentially stating that we cant backport any bigger version to mga2 /backports than mga3 will havein /release wich means when we hit version freeze for mga3, it also freezes mga2 /backports... I'm not following this point. What I mean is that if backport xx for mga1 requires yy version 12 in mga1, but yy is version 13 in mga2, we would define the requires for yy to accept versions 12 to 13 (or maybe wider). Point is what if you backport version 14 to mga1, and mga2 has version 13, then upgrade path breaks. No problem. If the requirements of version 14 are present in mga2, then the backport will (very likely) continue to work normally. If the versions of the required packages change, they will be updated with the upgrade. Since version 13 of mga2 is less than the version 14 of the backport, it won't be installed. There is no guaranty that requirements of version 14 mga1 backports are all available in mageia 2. If it is linked with libsomething.so.1, but mageia 2 only has libsomething.so.2, then there is a problem. That was my point. I was suggesting that it be required that backport requires be compatible with newer releases. And how do you check that it is compatible, without testing ? And how do you test that it will be compatible with a newer release that is not yet released ? Maybe we can also require that backports are bugfree, so we don't have to manage backport updates. In your example, cauldron would probably require the libsomething.so.2, so if the backport requires could be adjusted to work with libsomething.so.1, we would keep the requires compatible with libsomething.so.2. If that isn't possible, then it wouldn't be accepted. We cannot link a program with both libsomething.so.1 and libsomething.so.2. I'm no expert of course, but it seems to me that it would be generally possible as long as there weren't important code changes made to make the backport work. So it would largely be a question of appropriately adjusting the specified requires. A lot of requires are generated automatically, we cannot change them (and changing them would probably be wrong). And a lot of requires are not versionned, but implicitly require the version available in the same mageia release, without any guaranty that it works with a different version.
Re: [Mageia-dev] Backports Summary
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 27/06/2012 15:41, nicolas vigier ha scritto: There is no guaranty that requirements of version 14 mga1 backports are all available in mageia 2. If it is linked with libsomething.so.1, but mageia 2 only has libsomething.so.2, then there is a problem. Our library policy allows both libraries on the system, so even if not upgradable well the system should continue working anyway... Or upgrading, packages will be removed cause of their dependencies... Angelo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/rHwwACgkQqEs9DA4DquCDMQCfc6LXmgO4N9LnCMeO+uabJNAL 8JcAnRKPU6PUhu4jl6k7SY5FMqqv93e7 =j6EP -END PGP SIGNATURE-
Re: [Mageia-dev] Backports Summary
On Wed, 27 Jun 2012, andre999 wrote: nicolas vigier a écrit : On Wed, 27 Jun 2012, andre999 wrote: I would favour tagging backports as update repos, so that in the event of a newer backport for security or bug fixes, that it will be automatically presented with other updates. No. as the update applet currently works it would show the backport as an update even if you dont have an earlier backport installed, defeating the purpose of having separate /updates vs /backports This is conditional on first modifying the update tools, as suggested next. A backport should only update an already installed backport. (Similarly for nonfree and tainted, if that is not already the case.) We should not change the behaviour of medias tagged as update repo. If we want a different behaviour for backports then we should tag those medias as backport, not update. The idea is, once the tools are appropriately adjusted, to tag the backport repos as update media, as in rpmdrake. But alternately we could get the update tools to automatically treat backport repos as update media for backports. backports are not updates, why should we tag them as update ?
Re: [Mageia-dev] Packagers meeting
On 27 June 2012 12:38, Maarten Vanraes maarten.vanr...@gmail.com wrote: can we have another talk of bug 2317? to find people willing to make a new patch that's quite more complex? ideally bug 2317 should be fixed before backports opens No, it's not related since you can't garanty that every user will get the update prior to use backports. So there's no need to rush... QA team told me that it would increase their workload dramatically, so i think there is need rush. Again, there's no rush to change mgaapplet as anyway, not all users will use it. We cannot break those systems... We have to continue supporting those. Once a release is released, we've to support it. It's done. i was under the impression that we would be fixing this for both mgaapplet and urpmi --update (by changing perl-urpm; like my patch does) and that we would submit these as updates, so the QA workload goes down immediately.
Re: [Mageia-dev] Slowly pushing GNOME 3.5.3
On 27.06.2012 17:44, Jani Välimaa wrote: On 27.06.2012 17:40, Olav Vitters wrote: On Wed, Jun 27, 2012 at 03:53:01PM +0300, Jani Välimaa wrote: On 27.06.2012 00:16, Olav Vitters wrote: On Tue, Jun 26, 2012 at 10:55:00AM +0200, Olav Vitters wrote: - various new dependencies If someone could package: pwquality for me.. appreciated :-) Imported. Thanks! For some reason gnome-disk-utility still doesn't build, cannot link against pwquality, don't get why... no time atm to figure it out. Yes, I noticed and I'm on it. I'll push gnome-disk-utility too after I've fixed pwquality issue. Fixed pwquality and pushed gnome-disk-utility. BTW, there's a missing semicolon in gnome-disk-image-mounter.desktop: http://pkgsubmit.mageia.org/uploads/rejected/cauldron/core/release/20120627150640.wally.valstar.758.youri Didn't patch it, but used desktop-file-install to fix it automatically.
Re: [Mageia-dev] Mageia 3 feature proposals review
On Wednesday 27 June 2012 08:35, AL13N wrote: I thought they were planning on signing all the stuff after grub2 as well? They are. The Secure Boot feature requires the kernel and all drivers to be signed. http://mjg59.dreamwidth.org/12368.html -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] Mageia 3 feature proposals review
On Wed, Jun 27, 2012 at 08:35:35AM +0200, AL13N wrote: I thought they were planning on signing all the stuff after grub2 as well? I have no trouble having signed bootloader. but i would prefer it to be from a completely free CA. ie: NOT from microsoft. Then you need to convince all the hardware manufacturers to put your key in their hardware, as explained in the blogpost. Seems really unlikely to happen. above signing from microsoft, I would even prefer to have a documentation that requests to disable Secure Boot, then generate your own key and adding that, and then setting up Secure Boot again, with your own personal signed stuff. Thought disabling secure boot means first booting? of course, if there was an independant org that had it's CA in all hardware, and signed all free OSes, that would be alot better. There is none. -- Regards, Olav
Re: [Mageia-dev] Idea to fix Way too many languages to choose from for spell checking in FF and TB mga#6125
Le 27 juin 2012 08:16, Marja van Waes marj...@xs4all.nl a écrit : On 27/06/2012 01:38, n...@gmx.com wrote: Hello! I have got an idea to fix this bug with a new drak tool (DrakSpell?). It would be an assistant with a list of all available languages with all their variants to select and install. And the trick: it will install a package (like hunspell-en) and remove (rm -f) the unselected dicts (en_CA, en_GB ...). This seems to be against rules.. but would be a solution. And this seems to be much better than producing (and maintaining!) 1000 packages with single dicts. What do you think? Sounds great, I'm willing to test :) As a workaround for now, can we just remove all /usr/share/hunspell/*.aff /usr/share/hunspell/*.dic except for the ones we want to keep? I would like to delete these disctionnaries but i do nt know how, i have 16 varietés of english and i found only a couple of files for english. I think en and en_ca , i am not 100% sure because i am not at home now. However, if there is a solution to delete manualy the dictionnaries , it is fine for me.
Re: [Mageia-dev] Backports Summary
nicolas vigier a écrit : On Wed, 27 Jun 2012, andre999 wrote: nicolas vigier a écrit : On Wed, 27 Jun 2012, andre999 wrote: Thomas Backlund a écrit : andre999 skrev 27.6.2012 14:40: Thomas Backlund a écrit : andre999 skrev 27.6.2012 10:47: I would favour adding the requirement that the dependancies of the backport must be available in the next release. So that we would expect This is esentially stating that we cant backport any bigger version to mga2 /backports than mga3 will havein /release wich means when we hit version freeze for mga3, it also freezes mga2 /backports... I'm not following this point. What I mean is that if backport xx for mga1 requires yy version 12 in mga1, but yy is version 13 in mga2, we would define the requires for yy to accept versions 12 to 13 (or maybe wider). Point is what if you backport version 14 to mga1, and mga2 has version 13, then upgrade path breaks. No problem. If the requirements of version 14 are present in mga2, then the backport will (very likely) continue to work normally. If the versions of the required packages change, they will be updated with the upgrade. Since version 13 of mga2 is less than the version 14 of the backport, it won't be installed. There is no guaranty that requirements of version 14 mga1 backports are all available in mageia 2. If it is linked with libsomething.so.1, but mageia 2 only has libsomething.so.2, then there is a problem. That was my point. I was suggesting that it be required that backport requires be compatible with newer releases. And how do you check that it is compatible, without testing ? And how do you test that it will be compatible with a newer release that is not yet released ? You split in the middle of the point. (The above sentence could have been better worded.) See below. Maybe we can also require that backports are bugfree, so we don't have to manage backport updates. That would be nice, if you can see how to do it :D In your example, cauldron would probably require the libsomething.so.2, so if the backport requires could be adjusted to work with libsomething.so.1, we would keep the requires compatible with libsomething.so.2. If that isn't possible, then it wouldn't be accepted. We cannot link a program with both libsomething.so.1 and libsomething.so.2. If the spec file requires cannot be adjusted to accept linking with whichever of the 2 is available, then in that case the backport wouldn't be accepted - if my suggested restriction is accepted. I'm no expert of course, but it seems to me that it would be generally possible as long as there weren't important code changes made to make the backport work. So it would largely be a question of appropriately adjusting the specified requires. A lot of requires are generated automatically, we cannot change them (and changing them would probably be wrong). And a lot of requires are not versionned, but implicitly require the version available in the same mageia release, without any guaranty that it works with a different version. You mean generated automatically in the spec file ? Surprising. If the require isn't versioned, since it would work in cauldron, and also works in the backport release, then I would expect that it would work in interim releases. If it doesn't, that is in the risk of a backport. Don't forget, my suggestion is to increase the _probability_ that a backport will work in interim releases. Not to garantee that it will. In my experience, it is essentially the unavailability of required packages that makes a package from an older release stop working. A backport would fit in this mold, except it will be a variation of what is already working in cauldron. Collectively we may think it is not worth the increased reliability of backports, but I think that for little effort we see an important gain. -- André
Re: [Mageia-dev] Idea to fix Way too many languages to choose from for spell checking in FF and TB mga#6125
On 27/06/2012 19:13, Dimitrios Glentadakis wrote: Le 27 juin 2012 08:16, Marja van Waes marj...@xs4all.nl mailto:marj...@xs4all.nl a écrit : On 27/06/2012 01:38, n...@gmx.com mailto:n...@gmx.com wrote: Hello! I have got an idea to fix this bug with a new drak tool (DrakSpell?). It would be an assistant with a list of all available languages with all their variants to select and install. And the trick: it will install a package (like hunspell-en) and remove (rm -f) the unselected dicts (en_CA, en_GB ...). This seems to be against rules.. but would be a solution. And this seems to be much better than producing (and maintaining!) 1000 packages with single dicts. What do you think? Sounds great, I'm willing to test :) As a workaround for now, can we just remove all /usr/share/hunspell/*.aff /usr/share/hunspell/*.dic except for the ones we want to keep? I would like to delete these disctionnaries but i do nt know how, i have 16 varietés of english and i found only a couple of files for english. I think en and en_ca , i am not 100% sure because i am not at home now. However, if there is a solution to delete manualy the dictionnaries , it is fine for me. Firefox seems to get all the languages it sees from /usr/share/hunspell/ It is mostly links in that folder, the ones I had for English are shown below. I just removed a lot of such links, and after restarting Firefox, my list of languages to choose from was much shorter. All the removed ones have disappeared. I haven't restarted Thunderbird yet, so I don't know whether the effect will be the same there lrwxrwxrwx 1 root root 9 mai 23 17:50 en_AG.aff - en_GB.aff lrwxrwxrwx 1 root root 9 mai 23 17:50 en_AG.dic - en_GB.dic lrwxrwxrwx 1 root root 9 mai 23 17:50 en_AU.aff - en_GB.aff lrwxrwxrwx 1 root root 9 mai 23 17:50 en_AU.dic - en_GB.dic lrwxrwxrwx 1 root root 9 mai 23 17:50 en_BS.aff - en_GB.aff lrwxrwxrwx 1 root root 9 mai 23 17:50 en_BS.dic - en_GB.dic lrwxrwxrwx 1 root root 9 mai 23 17:50 en_BW.aff - en_GB.aff lrwxrwxrwx 1 root root 9 mai 23 17:50 en_BW.dic - en_GB.dic lrwxrwxrwx 1 root root 9 mai 23 17:50 en_BZ.aff - en_GB.aff lrwxrwxrwx 1 root root 9 mai 23 17:50 en_BZ.dic - en_GB.dic -rw-r--r-- 1 root root3115 mars 20 02:30 en_CA.aff -rw-r--r-- 1 root root 535896 mars 20 02:30 en_CA.dic lrwxrwxrwx 1 root root 9 mai 23 17:50 en_DK.aff - en_GB.aff lrwxrwxrwx 1 root root 9 mai 23 17:50 en_DK.dic - en_GB.dic -rw-r--r-- 1 root root 27471 mars 20 02:29 en_GB.aff -rw-r--r-- 1 root root 527336 mars 20 02:29 en_GB.dic lrwxrwxrwx 1 root root 9 mai 23 17:50 en_GH.aff - en_GB.aff lrwxrwxrwx 1 root root 9 mai 23 17:50 en_GH.dic - en_GB.dic lrwxrwxrwx 1 root root 9 mai 23 17:50 en_HK.aff - en_GB.aff lrwxrwxrwx 1 root root 9 mai 23 17:50 en_HK.dic - en_GB.dic lrwxrwxrwx 1 root root 9 mai 23 17:50 en_IE.aff - en_GB.aff lrwxrwxrwx 1 root root 9 mai 23 17:50 en_IE.dic - en_GB.dic lrwxrwxrwx 1 root root 9 mai 23 17:50 en_IN.aff - en_GB.aff lrwxrwxrwx 1 root root 9 mai 23 17:50 en_IN.dic - en_GB.dic lrwxrwxrwx 1 root root 9 mai 23 17:50 en_JM.aff - en_GB.aff lrwxrwxrwx 1 root root 9 mai 23 17:50 en_JM.dic - en_GB.dic lrwxrwxrwx 1 root root 9 mai 23 17:50 en_NA.aff - en_GB.aff lrwxrwxrwx 1 root root 9 mai 23 17:50 en_NA.dic - en_GB.dic lrwxrwxrwx 1 root root 9 mai 23 17:50 en_NG.aff - en_GB.aff lrwxrwxrwx 1 root root 9 mai 23 17:50 en_NG.dic - en_GB.dic lrwxrwxrwx 1 root root 9 mai 23 17:50 en_NZ.aff - en_GB.aff lrwxrwxrwx 1 root root 9 mai 23 17:50 en_NZ.dic - en_GB.dic lrwxrwxrwx 1 root root 9 mai 23 17:50 en_PH.aff - en_US.aff lrwxrwxrwx 1 root root 9 mai 23 17:50 en_PH.dic - en_US.dic lrwxrwxrwx 1 root root 9 mai 23 17:50 en_SG.aff - en_GB.aff lrwxrwxrwx 1 root root 9 mai 23 17:50 en_SG.dic - en_GB.dic lrwxrwxrwx 1 root root 9 mai 23 17:50 en_TT.aff - en_GB.aff lrwxrwxrwx 1 root root 9 mai 23 17:50 en_TT.dic - en_GB.dic -rw-r--r-- 1 root root3115 mars 20 02:30 en_US.aff -rw-r--r-- 1 root root 534077 mars 20 02:30 en_US.dic lrwxrwxrwx 1 root root 9 mai 23 17:50 en_ZA.aff - en_GB.aff lrwxrwxrwx 1 root root 9 mai 23 17:50 en_ZA.dic - en_GB.dic lrwxrwxrwx 1 root root 9 mai 23 17:50 en_ZW.aff - en_GB.aff lrwxrwxrwx 1 root root 9 mai 23 17:50 en_ZW.dic - en_GB.dic
Re: [Mageia-dev] Backports Summary
On Wed, 27 Jun 2012, andre999 wrote: In your example, cauldron would probably require the libsomething.so.2, so if the backport requires could be adjusted to work with libsomething.so.1, we would keep the requires compatible with libsomething.so.2. If that isn't possible, then it wouldn't be accepted. We cannot link a program with both libsomething.so.1 and libsomething.so.2. If the spec file requires cannot be adjusted to accept linking with whichever of the 2 is available, then in that case the backport wouldn't be accepted - if my suggested restriction is accepted. It's not adjusted in the spec file, it's built against the version that is available in the repository when building the package, and require is added automatically. I'm no expert of course, but it seems to me that it would be generally possible as long as there weren't important code changes made to make the backport work. So it would largely be a question of appropriately adjusting the specified requires. A lot of requires are generated automatically, we cannot change them (and changing them would probably be wrong). And a lot of requires are not versionned, but implicitly require the version available in the same mageia release, without any guaranty that it works with a different version. You mean generated automatically in the spec file ? Surprising. Generated by rpm find-requires scripts. But discussing this if you don't know the basic functionning of rpm is a waste of time, so end of discussion for me.
Re: [Mageia-dev] Backports Summary
nicolas vigier a écrit : On Wed, 27 Jun 2012, andre999 wrote: nicolas vigier a écrit : On Wed, 27 Jun 2012, andre999 wrote: I would favour tagging backports as update repos, so that in the event of a newer backport for security or bug fixes, that it will be automatically presented with other updates. No. as the update applet currently works it would show the backport as an update even if you dont have an earlier backport installed, defeating the purpose of having separate /updates vs /backports This is conditional on first modifying the update tools, as suggested next. A backport should only update an already installed backport. (Similarly for nonfree and tainted, if that is not already the case.) We should not change the behaviour of medias tagged as update repo. If we want a different behaviour for backports then we should tag those medias as backport, not update. The idea is, once the tools are appropriately adjusted, to tag the backport repos as update media, as in rpmdrake. But alternately we could get the update tools to automatically treat backport repos as update media for backports. backports are not updates, why should we tag them as update ? If you are talking about the packages themselves, of course _backports packages_ should be tagged as backports, and regular update packages as updates. However talking about _backport repos_, exactly how we tag them is arbitrary. Although obviously backports are updates relative to the initial release in question, so it is not unreasonable to tag the backport repos as updates. -- André
Re: [Mageia-dev] Idea to fix Way too many languages to choose from for spell checking in FF and TB mga#6125
On 27/06/2012 19:50, Marja van Waes wrote: On 27/06/2012 19:13, Dimitrios Glentadakis wrote: I would like to delete these disctionnaries but i do nt know how, i have 16 varietés of english and i found only a couple of files for english. I think en and en_ca , i am not 100% sure because i am not at home now. However, if there is a solution to delete manualy the dictionnaries , it is fine for me. Firefox seems to get all the languages it sees from /usr/share/hunspell/ It is mostly links in that folder I just removed a lot of such links, and after restarting Firefox, my list of languages to choose from was much shorter. All the removed ones have disappeared. I haven't restarted Thunderbird yet, so I don't know whether the effect will be the same there The effect is the same in TB: after removing all links in that folder and after restarting Thunderbird, I have only 13 languages instead of 176 languages to choose from. I'm happy :-D
Re: [Mageia-dev] Backports Summary
On Wed, 27 Jun 2012, andre999 wrote: nicolas vigier a écrit : On Wed, 27 Jun 2012, andre999 wrote: nicolas vigier a écrit : On Wed, 27 Jun 2012, andre999 wrote: I would favour tagging backports as update repos, so that in the event of a newer backport for security or bug fixes, that it will be automatically presented with other updates. No. as the update applet currently works it would show the backport as an update even if you dont have an earlier backport installed, defeating the purpose of having separate /updates vs /backports This is conditional on first modifying the update tools, as suggested next. A backport should only update an already installed backport. (Similarly for nonfree and tainted, if that is not already the case.) We should not change the behaviour of medias tagged as update repo. If we want a different behaviour for backports then we should tag those medias as backport, not update. The idea is, once the tools are appropriately adjusted, to tag the backport repos as update media, as in rpmdrake. But alternately we could get the update tools to automatically treat backport repos as update media for backports. backports are not updates, why should we tag them as update ? If you are talking about the packages themselves, of course _backports packages_ should be tagged as backports, and regular update packages as updates. packages themselves are not tagged as backports or updates. However talking about _backport repos_, exactly how we tag them is arbitrary. Although obviously backports are updates relative to the initial release in question, so it is not unreasonable to tag the backport repos as updates. backports and updates repos need to be handled differently by urpmi/rpmdrake. So they should be tagged differently. Is it so hard to understand ?
Re: [Mageia-dev] Backports Summary
nicolas vigier a écrit : On Wed, 27 Jun 2012, andre999 wrote: nicolas vigier a écrit : On Wed, 27 Jun 2012, andre999 wrote: nicolas vigier a écrit : On Wed, 27 Jun 2012, andre999 wrote: I would favour tagging backports as update repos, so that in the event of a newer backport for security or bug fixes, that it will be automatically presented with other updates. No. as the update applet currently works it would show the backport as an update even if you dont have an earlier backport installed, defeating the purpose of having separate /updates vs /backports This is conditional on first modifying the update tools, as suggested next. A backport should only update an already installed backport. (Similarly for nonfree and tainted, if that is not already the case.) We should not change the behaviour of medias tagged as update repo. If we want a different behaviour for backports then we should tag those medias as backport, not update. The idea is, once the tools are appropriately adjusted, to tag the backport repos as update media, as in rpmdrake. But alternately we could get the update tools to automatically treat backport repos as update media for backports. backports are not updates, why should we tag them as update ? If you are talking about the packages themselves, of course _backports packages_ should be tagged as backports, and regular update packages as updates. packages themselves are not tagged as backports or updates. However talking about _backport repos_, exactly how we tag them is arbitrary. Although obviously backports are updates relative to the initial release in question, so it is not unreasonable to tag the backport repos as updates. backports and updates repos need to be handled differently by urpmi/rpmdrake. So they should be tagged differently. Is it so hard to understand ? Backport packages and update packages need to be handled differently. This can be more reliably dealt with by tagging the backport packages themselves. As a user could copy the backport to any location, it won't necessarily be installed from a backport repo. Which I and others have already suggested numerous times in previous threads. By tagging the package in the name (someone suggested using bp), it could be readily determined by any user that a package is a backport. My suggestion of tagging the backport repos as updates was recognizing an obvious fact, which apparently is used by installer tools. (Otherwise why bother ?) And indeed, backports will be used as updates, albeit only to already installed backports. -- André
Re: [Mageia-dev] Mageia 3 feature proposals review
Op woensdag 27 juni 2012 18:45:10 schreef Olav Vitters: On Wed, Jun 27, 2012 at 08:35:35AM +0200, AL13N wrote: I thought they were planning on signing all the stuff after grub2 as well? I have no trouble having signed bootloader. but i would prefer it to be from a completely free CA. ie: NOT from microsoft. Then you need to convince all the hardware manufacturers to put your key in their hardware, as explained in the blogpost. Seems really unlikely to happen. above signing from microsoft, I would even prefer to have a documentation that requests to disable Secure Boot, then generate your own key and adding that, and then setting up Secure Boot again, with your own personal signed stuff. Thought disabling secure boot means first booting? there's likely a bios setting or jumper than can disable secure boot for desktops. of course, if there was an independant org that had it's CA in all hardware, and signed all free OSes, that would be alot better. There is none. yes, i don't think there is one, but that doesn't mean it can't be done. And it's ideally the perfect way for every distro. if RH and Canonical both had worked together with some independant entity (like cacert.org ) it could've been handled alot better.
Re: [Mageia-dev] Mageia 3 feature proposals review
On Mon, 25 Jun 2012, David Walser wrote: nicolas vigier boklm@... writes: We have reviewed this morning with ennael all feature proposal submitted on the wiki. You can find the results on this page : https://wiki.mageia.org/en/FeatureMageia3_Review The features policy didn't list Resources as one of the required sections: https://wiki.mageia.org/en/Features_policy#Criteria_used_to_choose_features Which is probably why it was left out on a lot of proposals including mine. Resources is also a strange, unintuitive name for that section. Yes, maybe the resources part was not clear enough. It should list the name of people who plan to be involved in the feature. The goal is to list only features which have good chances to be done, so it needs to have enough people who plans to be involved in that feature. For mine, it was obvious without explicitly listing it, and the comment here: https://wiki.mageia.org/en/FeatureMageia3_Review makes it pretty clear it was obvious. Regardless, I have added it now: https://wiki.mageia.org/en/Feature:ChronyDefaultNTP So what is still missing is someone to implement the drakx changes ? Or you think you can do that part too ?
Re: [Mageia-dev] ANN: For the brave. systemd v185 in cauldron updates_testing
On Mon, Jun 18, 2012 at 12:15:40AM +0100, Colin Guthrie wrote: I've just submitted systemd v185 to updates_testing. It boots! :P Following is a bit weird: $ uptime 21:30:07 up 8 min, 1 user, load average: 2.53, 2.85, 1.61 $ systemd-analyze plot plot.svg Bootup is not yet finished. Please try again later. Never really tried making a plot quickly after booting, but 8min should be enough to have every service started. -- Regards, Olav
Re: [Mageia-dev] Backports Summary
Angelo Naselli a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 27/06/2012 20:27, andre999 ha scritto: By tagging the package in the name (someone suggested using bp), it could be readily determined by any user that a package is a backport. And as i told already, changing the name is not a good thing. because we need to manage the update (yes *update*) from the installed version because foo-1.0 is not upgraded by bp-foo.1.1 just because it has 1.1 into the name... I meant in the file name of the package, in the revision/subversion field would be good. Not the package name part. Angelo -- André
Re: [Mageia-dev] Slowly pushing GNOME 3.5.3
On Tue, Jun 26, 2012 at 10:55:00AM +0200, Olav Vitters wrote: - various new dependencies Another package request: colord-gtk-0.1.22.tar.xz http://www.freedesktop.org/software/colord/releases/ needed for gnome-color-manager -- Regards, Olav
[Mageia-dev] BACKPORTS: Resources needed to do the actual work
Now that we've finally agreed upon updates during meeting ( http://meetbot.mageia.org/mageia-dev/2012/mageia-dev.2012-06-27-19.11.html ), the following needs to be done: 1. QA needs to make updated backport process (Stormi) 2. mailing list for backport announce (???) 3. add warning when activating backports in drakrpm-edit-media for mga1 and mga2 as updates, this needs to have a checkbox that it doesn't warn anymore. (???) 4. we need to ensure the upgrade works even if it fails for the installed backported packages. The user could be warned when this happens (???) 5. bug 2317 MUST be fixed before backports are opened (???) 6. we need to add support for automatic updates of installed backports either in mgaapplet, or a new one. (???) 7. sysadmin will likely need to open things up (???) All these needs to be done. At the very least need people who know the existing code. and preferably some more who want to learn. Personally, i'm willing to help, but i can't do it without help from people who know the code.
Re: [Mageia-dev] ANN: For the brave. systemd v185 in cauldron updates_testing
On Wed, Jun 27, 2012 at 09:31:44PM +0200, Olav Vitters wrote: Never really tried making a plot quickly after booting, but 8min should be enough to have every service started. Due to mysqld/mariadb not starting Loads of repeating messages in the logs: Jun 27 21:56:03 bkor systemd[1]: mysqld.service holdoff time over, scheduling restart. Jun 27 21:56:03 bkor systemd[1]: Job pending for unit, delaying automatic restart. I uninstalled mariadb and it went through. Before that tried a chkconfig mysqld off, but that didn't seem to help. -- Regards, Olav
[Mageia-dev] UiAbstraction4mcc feature proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm back to this subject, because, as you probably know, the proposal[1] has been accepted[2] and has to be merged with mine[3] and discussed a bit to understand what we have to do and who can help. Il 13/06/2012 14:35, Steven Tucker ha scritto: This proposal may be a bit different to the several others you have seen in that a lot of the heavy lifting has already been done. The Ui layer is provided by libYui and friends, and the logic is already there in mcc. With the perl bindings to libYui the effort is no where near as large as a rewrite, which I imagine the several other proposals were. I would prefer it all to be written in C++, but that would be more work than adapting the current perl code, so you see it's not just pie in the sky, I have actually put some thought into it. In a first read i understood the idea was to provide a new gui abstraction layer, and you told me the suggested libYui library is written in C++ with some script bindings (one for all perl) and since I'm not a perl programmer and i know C++ and QT (something on GTk also) i could help. So should i assume you want to rewrite all? Steven, can you please point me and other potential contributors to your plans? Planning is also needed to our proposal to be definitely accepted :) I don't have a lot of spare time, but i will help as much as possible. Matteo Pasotti is adding libyui to mageia repository so we could start using it, I do also believe he's going to help us as well :) Let's start this new adventure... Cheers, Angelo [1] https://wiki.mageia.org/en/Feature:UiAbstraction4mcc [2] https://wiki.mageia.org/en/FeatureMageia3_Review [3] https://wiki.mageia.org/en/Feature:DrakXtoolsReview -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/rgusACgkQqEs9DA4DquAJcQCgnYoldmMq1+EdON9q3DhXazVe pi0An0UUHGGMnJ+X33UVmwi92AHgXM1u =wdCu -END PGP SIGNATURE-
Re: [Mageia-dev] UiAbstraction4mcc feature proposal
Hi Angelo, great to see you put your hand up. My position at the moment, is to get through this week at work, then starting Monday begin work on this project. The first step is to port the relevant libYui and related libraries which is what I had planned to work on next week, but if Matteo is working on this then that will work out great (I am just an apprentice with only 2 packages to date, so perhaps not the best person for that job). To begin with, I planned to make a basic proof of concept Control Centre, so just simply a copy of the current main window of MCC but without any functionality, just to see it work across the widget sets. Then work on a single module to work out some standards and documentation, how to make it as easy as possible for others to come along and add a module. I understand the desire to have everything in the one language (and the obvious choice is perl due to inertia), however I am not personally against individual modules being in python/perl/C++, the reason is that there are people who potentially would add a module but don't want to use a language they are not familiar with and would only use for that module and nothing else. So I guess I would like to give options so that entry to contribution is as easy as it can be. This all started for me when I looked into writing a module I wanted but found very little documentation, and realised it would be more work to make my module available in curses as well at gtk. As far as other contributors, I only have one willing to dive into code, but it is very convenient as we work together (We just finished setting up our new Mageia Cluster and so now are ready for more Mageia goodness :-P ) so a very small group at the moment, but to be honest, I think that is probably a good thing in the early stages. As I said, I have to get through this week at work first, a week of deadlines, but then I can start writing some more concrete plans, and start playing with the code. I'll make contact again in a few days when I am ready to get going. Cheers Tuxta On 28/06/12 08:02, Angelo Naselli wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm back to this subject, because, as you probably know, the proposal[1] has been accepted[2] and has to be merged with mine[3] and discussed a bit to understand what we have to do and who can help. Il 13/06/2012 14:35, Steven Tucker ha scritto: This proposal may be a bit different to the several others you have seen in that a lot of the heavy lifting has already been done. The Ui layer is provided by libYui and friends, and the logic is already there in mcc. With the perl bindings to libYui the effort is no where near as large as a rewrite, which I imagine the several other proposals were. I would prefer it all to be written in C++, but that would be more work than adapting the current perl code, so you see it's not just pie in the sky, I have actually put some thought into it. In a first read i understood the idea was to provide a new gui abstraction layer, and you told me the suggested libYui library is written in C++ with some script bindings (one for all perl) and since I'm not a perl programmer and i know C++ and QT (something on GTk also) i could help. So should i assume you want to rewrite all? Steven, can you please point me and other potential contributors to your plans? Planning is also needed to our proposal to be definitely accepted :) I don't have a lot of spare time, but i will help as much as possible. Matteo Pasotti is adding libyui to mageia repository so we could start using it, I do also believe he's going to help us as well :) Let's start this new adventure... Cheers, Angelo [1] https://wiki.mageia.org/en/Feature:UiAbstraction4mcc [2] https://wiki.mageia.org/en/FeatureMageia3_Review [3] https://wiki.mageia.org/en/Feature:DrakXtoolsReview -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/rgusACgkQqEs9DA4DquAJcQCgnYoldmMq1+EdON9q3DhXazVe pi0An0UUHGGMnJ+X33UVmwi92AHgXM1u =wdCu -END PGP SIGNATURE-
Re: [Mageia-dev] [soft-commits] [4436] german keyboard: default to variant with enabled deadkeys instead of nodeadkeys variant ( mga#3791)
On 10 May 2012 00:21, Christian Lohmaier lohmaier+mag...@googlemail.com wrote: german keyboard: default to variant with enabled deadkeys instead ofnodeadkeys variant (mga#3791) Oups, why that? As far as I'm concerned no deadkeys is the default for German users and that's good! Any reasons for this change? Call it Competitive analysis if you want. Keyboards comes with those little keys that are meant to produce accented characters in combination with regular letters, and this how it works on Windows, the platform most users will migrate from, and also on Mac OS X. Regular users don't have any use of stand-alone-accent-characters. And even with deadkeys it is easy to produce the standalone accent by just pressing the key twice (so you can get backticks easily). If you're a programmer and are using a nodeadkeys variant for that reason, you're not the target population of a suggested default. (If you know what is meant with deadkeys and nodeadkeys, you're not in target of that dialog, and have the knowledge to not accept the default, but choose the nodeadkeys variant that is listed right next to the regular variant). The variant with deadkeys is called German without any addition for a reason. If nodeadkeys were the expected/more common choice, then it would be German (international) or German (deadkeys), like it is the case for the US-variants. So Olivier, do you agree with that change or not?
Re: [Mageia-dev] Backports Summary
On Wednesday 27 June 2012 20:05, andre999 wrote: However talking about _backport repos_, exactly how we tag them is arbitrary. The fact that this stirs a huge conversation surely serves to show that it is Not arbitrarely how we tag them. Although obviously backports are updates relative to the initial release in question, so it is not unreasonable to tag the backport repos as updates. No, it is Not obvious. It is called Backports for a reason. It is software that is not part of the release, and is to be treated as experimental/beta software, as it could wery well break your system if you don't know what you are doing. -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
