Re: [Mageia-dev] PPA-like repos
2011/7/8 Michael Scherer m...@zarb.org: There is nothing planned yet. ( we do not even have enough servers to have a shell for packagers or others :/ ) The problem I see with ppa is they lack basic quality control, they often interfere with upgrade and when they break, people blame the distribution. There is also non user friendly inter-ppa requires. Maybe we could use build.opensuse.org to encourage people to host their own ppa.
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
On Fri, Jul 8, 2011 at 6:37 AM, Ahmad Samir ahmadsamir3...@gmail.com wrote:
Hello.
I've had a rather vague idea about standardising the virtual provides
in the distro, there should be:
Provides: %{name}-devel
Provides: lib%{name}-devel
either both of them in _all_ packages, or one of them in _all_
packages, so that we don't have to check urpmq --provides all the
time. Personally, I am more inclined on having them both, so as not to
break already working specs.
For example:
$ urpmq --provides lib64gudev1.0-devel-166-5.mga1.x86_64
libgudev-devel[== 166-5.mga1]
pkgconfig(gudev-1.0)[== 166]
devel(libgudev-1.0(64bit))
lib64gudev1.0-devel[== 166-5.mga1]
lib64gudev1.0-devel(x86-64)[== 166-5.mga1]
only libgudev-devel, so if I put BR gudev-devel in a spec it won't
work, whereas I'd expect it to work since some other packages have
such similar provides:
$ urpmq --provides lib64dbus-1-devel
libdbus-1-devel[== 1.4.1-3.mga1]
libdbus-devel[== 1.4.1-3.mga1]
dbus-devel[== 1.4.1-3.mga1]
[...]
WDYT?
(If we agree to go one way or the other, will just fix them gradually
over time).
--
Ahmad Samir
for me this is a +1 w/o hesitation
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
This thread has strayed far from the original question, which could be re-stated as: Should tainted free software and tainted nonfree software be commingled in a single tainted repository? Given Mageia's commitment to the promotion of free software, I believe that they should not. If Mageia wishes to distribute tainted nonfeee software, then that should be done through an additional separate tainted-nonfree repository. Jim
Re: [Mageia-dev] Updates testing
Le vendredi 8 juillet 2011 06:22:38, Ahmad Samir a écrit : On 7 July 2011 22:04, philippe makowski makowski.mag...@gmail.com wrote: 2011/7/7 nicolas vigier bo...@mars-attacks.org: Yes, for the test about the bug fixed. But isn't there tests to check for regressions ? when you push a new minor version (only bugfix) for softwares like LibreOffice, Postgresql or Firebird for example, will the Mageia QA team run tests for regression and for all bug fixed ? wh ! IMHO, for big packages like libreoffice, we'll have to rely on the free-cost-daily-usage QA, i.e. pushing it to Cauldron users for 1-2month, and waiting till the dust settles before pushing to older stable releases. The interesting part about packages like libreoffice, is they're multi-purpose, so there's no easy way to make sure every functionality works(tm), other than actually letting testes/cauldron-users use it. Pushing it also soon to updates_testing and letting it rest there some time will also allow to test it on the stable release too (and please the people that reported bugs). Samuel
Re: [Mageia-dev] Updates testing
On Fri, 08 Jul 2011 00:22:38 -0400, Ahmad Samir ahmadsamir3...@gmail.com wrote: IMHO, for big packages like libreoffice, we'll have to rely on the free-cost-daily-usage QA, i.e. pushing it to Cauldron users for 1-2month, and waiting till the dust settles before pushing to older stable releases. I don't agree with putting a minimum time limit on testing. Obviously, the qa team cannot test all software in an exhaustive manner. To me. as a member of the qa team, it's a matter of using common sense, on a case by case basis. Is the hardware widely available? If yes, wait for someone with that hardware test it. If not, confirm it installs on both platforms without conflicts, and at least one person with the hardware tests it, such as with the belgium card reader. In the case of security updates with no poc, just test that the package installs cleanly on both platforms, and basic functionality works, such as the iptables update. In the case of something like libreoffice, I would test that it installs cleanly, and each major function appears to work. I would not be testing to see if every possible formula in a spreadsheet works, just the basics. If every possible test had to be run, nothing would ever be updated. Trying to run every possible test in an automated manner would make the Mageia project look tiny by comparison. Regards, Dave Hodgins
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
2011/7/8 James Kerr j...@jkerr82508.free-online.co.uk: This thread has strayed far from the original question, which could be re-stated as: Should tainted free software and tainted nonfree software be commingled in a single tainted repository? How can tainted software be free software at the same time? -- wobo
Re: [Mageia-dev] Updates testing
Le vendredi 8 juillet 2011 10:20:16, Samuel Verschelde a écrit : Le vendredi 8 juillet 2011 06:22:38, Ahmad Samir a écrit : On 7 July 2011 22:04, philippe makowski makowski.mag...@gmail.com wrote: 2011/7/7 nicolas vigier bo...@mars-attacks.org: Yes, for the test about the bug fixed. But isn't there tests to check for regressions ? when you push a new minor version (only bugfix) for softwares like LibreOffice, Postgresql or Firebird for example, will the Mageia QA team run tests for regression and for all bug fixed ? wh ! IMHO, for big packages like libreoffice, we'll have to rely on the free-cost-daily-usage QA, i.e. pushing it to Cauldron users for 1-2month, and waiting till the dust settles before pushing to older stable releases. The interesting part about packages like libreoffice, is they're multi-purpose, so there's no easy way to make sure every functionality works(tm), other than actually letting testes/cauldron-users use it. Pushing it also soon to updates_testing and letting it rest there some time will also allow to test it on the stable release too (and please the people that reported bugs). I forgot to add that for this to work some testers have to use updates_testing as an update media, like I do myself. Samuel
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
2011/7/8 Thorsten van Lil tv...@gmx.de: Am 08.07.2011 10:42, schrieb Wolfgang Bornath: 2011/7/8 James Kerrj...@jkerr82508.free-online.co.uk: This thread has strayed far from the original question, which could be re-stated as: Should tainted free software and tainted nonfree software be commingled in a single tainted repository? How can tainted software be free software at the same time? Because free is a matter of license, while tainted is a matter of patents. For example, the libdvdcss2 is free, as the the source-code is open (GPL) but it touches the patent issue, so it's tainted. Yes, if you regard patents not as a criterium for free or non-free then this division makes sense. From that point of view we need the same structure as PLF (tainted-free and tainted-non-free). -- wobo
Re: [Mageia-dev] Updates testing
On Thu, 07 Jul 2011, andre999 wrote: nicolas vigier a écrit : On Thu, 07 Jul 2011, Damien Lallement wrote: Le 07/07/2011 14:18, nicolas vigier a écrit : On Wed, 06 Jul 2011, José Jorge wrote: Le mercredi 6 juillet 2011 18:12:44, nicolas vigier a écrit : Hello, A few package updates need testing on x86_64 (they have been tested on i586, thanks to Dave Hodgins) : https://bugs.mageia.org/show_bug.cgi?id=1944 https://bugs.mageia.org/show_bug.cgi?id=1485 https://bugs.mageia.org/show_bug.cgi?id=1892 https://bugs.mageia.org/show_bug.cgi?id=1939 All tested, but without a testcase, some are hard to test. Yes, testcase need to be done for each package. Maybe we could have a wiki page to save all test cases, and use them when the same package is updated again ? No need to put this on the wiki as it will be useless for 90% of them as an update request must have a test case for the bug fixed, not for the whole package. Yes, for the test about the bug fixed. But isn't there tests to check for regressions ? The general idea sounds good. But that would make a pretty big wiki page, if we especially if we include big apps like LibreOffice Postgresql. Maybe link each bigger app to a standing bugz report for that purpose ? It would be pretty hard to make even close to complete regression tests for bigger apps as well. (imagine 599 tests for LibreOffice ...) I think the goal is not to do full regression tests, as we don't have time for this. But do minimal testing, in 1 or 2 minutes, to check that basic functionality is still working, to check that the update didn't break everything. For LibreOffice that could be opening a test document. Most applications are easy to test. But some require knowledge of the software, or some configuration files, to test, so we could keep a list of test commands or things to do and config files.
[Mageia-dev] Mageia educational - part 2
Hi folks, thanks to mamming we've improved our wiki page [1]. It's always work in progress of course, new project entries and movement from to be packaged to package are always welcome :D Let's talk about what to do now, two main steps are: * add missing educational programs * group educational programs in specialized meta-packages For the first step every packagers, or padawans are welcome. stblack, pasmatt (matteo) and I will start working asap. Latter instead is a little bit complex, in that page there are projects like monodevelop, blander... that are not easy to group in. IMO we could have three starting meta-packages at the moment focused on students age -maybe on their related teacher as well- something like: pre-school 6 y.o. primary-school 6-10 y.o secondary-school 10-14 y.o I can't see how to group for people over (high school?) since in Italy for instance we have different kind of school addresses e.g. technical in computer science, in chemical, etc... Then another issue could be the desktop, or better, installing things either for qt or gtk for instance. And is it right to install more than one project doing similar things? Should we/Are we able to decide which is the best to be included in the meta-package? What do you think about this subject? Cheers, Angelo [1] http://mageia.org/wiki/doku.php?id=sigedu signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] Updates testing
2011/7/8 nicolas vigier bo...@mars-attacks.org: I think the goal is not to do full regression tests, as we don't have time for this. But do minimal testing, in 1 or 2 minutes, to check that basic functionality is still working, to check that the update didn't break everything. For LibreOffice that could be opening a test document. Most applications are easy to test. But some require knowledge of the software, or some configuration files, to test, so we could keep a list of test commands or things to do and config files. make sense Fedora have interesting rules about update/testing updates Once pushed to testing, people are able to +1/-1 the updates karma, based on whether or not it seems to be functional for them. If your update reaches a karma of 3, it will automatically be pushed to stable. Likewise, if it reaches -3, it will be automatically unpushed. If your update does not receive enough feedback to automatically push it to stable, you will have to submit it as a final update yourself. This can easily be done with the command-line tool, or with the web interface they also have proven tester https://fedoraproject.org/wiki/Proven_tester for critical path package
Re: [Mageia-dev] PPA-like repos
'Twas brillig, and Eugeni Dodonov at 07/07/11 22:38 did gyre and gimble: But as for QA, yes, this is true. Probably the best solution for it was Meego's one, in the n800 era - when you install something from non-official repo it shows a window saying 'You are installing something that could break everything, so you are on your own, good luck'. For install/update, perhaps it could be solved by adding some new installer/updater window which would check of enabled urpmi medias, and if there are any non-official one, it could show a warning or something like it as well. I think also the ppa-purge tool is quite useful (I've not used it myself, just read instructions of it's use) which can aid the purging of a given PPA's packages and the installation of the offical packages needed to solve any dependency holes left behind from uninstalling packages. This is still a power-user task IMO, but if (especially in the case of Wayland stuff) only power-users would attempt this. So while I too accept the QA issue (it's why I've spoken quite strongly against PPAs in the past), I do accept there are sometimes valid reasons to use them. If the tools are there to help, most of my concerns can be mitigated. Col PS, nice to see you here Eugeni :) -- Colin Guthrie mageia(at)colin.guthr.ie 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] PPA-like repos
Le 08/07/2011 12:28, Colin Guthrie a écrit : I think also the ppa-purge tool is quite useful (I've not used it myself, just read instructions of it's use) which can aid the purging of a given PPA's packages and the installation of the offical packages needed to solve any dependency holes left behind from uninstalling packages. I've used it for downgrade from gnome-shell to gnome 2.32. It works as well as possible, anything was breaked. -- Sandro Cazzaniga - https://lederniercoupdarchet.wordpress.com IRC: Kharec (irc.freenode.net) Software/Hardware geek Conceptor Magnum's Coordinator/editor (http://magnum.tuxfamily.org) Mageia and Mandriva contributor
[Mageia-dev] Out of town until 18/07
Hi, As seen on the blog, I will be at Libre Software Meeting and in holidays for a few days after, do not expect a fast answer from me nor much answer on irc until 18th July. I will also not be present in meeting during the week. -- Michael Scherer
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
On 08/07/11 06:37, Ahmad Samir wrote:
Hello.
I've had a rather vague idea about standardising the virtual provides
in the distro, there should be:
Provides: %{name}-devel
Provides: lib%{name}-devel
either both of them in _all_ packages, or one of them in _all_
packages, so that we don't have to check urpmq --provides all the
time. Personally, I am more inclined on having them both, so as not to
break already working specs.
WDYT?
Hi! YES!!!
As a Padawan, this was one of my first troubles, to find the correct
-devel package name. Some packages have even different --provides
according to the arch :-/
Both Provides are certainly the best, but we may recommend the usage
of only one of type in Requires: lib%{name}-devel?
Cheers,
Chris.
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
On 8 July 2011 13:44, EatDirt dirt...@gmail.com wrote:
On 08/07/11 06:37, Ahmad Samir wrote:
Hello.
I've had a rather vague idea about standardising the virtual provides
in the distro, there should be:
Provides: %{name}-devel
Provides: lib%{name}-devel
either both of them in _all_ packages, or one of them in _all_
packages, so that we don't have to check urpmq --provides all the
time. Personally, I am more inclined on having them both, so as not to
break already working specs.
WDYT?
Hi! YES!!!
As a Padawan, this was one of my first troubles, to find the correct -devel
package name. Some packages have even different --provides according to the
arch :-/
[..]
Both Provides are certainly the best, but we may recommend the usage of
only one of type in Requires: lib%{name}-devel?
Cheers,
Chris.
For new specs maybe, but for old ones, that would break compatibility
with other specs that already have BR: %{name}-devel. So since we
can't easily get rid of one or the other, better have both...
--
Ahmad Samir
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
On 08.07.2011 07:37, Ahmad Samir wrote:
Hello.
I've had a rather vague idea about standardising the virtual provides
in the distro, there should be:
Provides: %{name}-devel
Provides: lib%{name}-devel
either both of them in _all_ packages, or one of them in _all_
packages, so that we don't have to check urpmq --provides all the
time. Personally, I am more inclined on having them both, so as not to
break already working specs.
For example:
$ urpmq --provides lib64gudev1.0-devel-166-5.mga1.x86_64
libgudev-devel[== 166-5.mga1]
pkgconfig(gudev-1.0)[== 166]
devel(libgudev-1.0(64bit))
lib64gudev1.0-devel[== 166-5.mga1]
lib64gudev1.0-devel(x86-64)[== 166-5.mga1]
only libgudev-devel, so if I put BR gudev-devel in a spec it won't
work, whereas I'd expect it to work since some other packages have
such similar provides:
$ urpmq --provides lib64dbus-1-devel
libdbus-1-devel[== 1.4.1-3.mga1]
libdbus-devel[== 1.4.1-3.mga1]
dbus-devel[== 1.4.1-3.mga1]
[...]
WDYT?
(If we agree to go one way or the other, will just fix them gradually
over time).
I remember having this discussion in Mandriva when we dropped %major
from devel name. As a result the library policy (which we have on Mageia
as well) was altered so that all packages should have
- name-devel
- tarballname-devel
as provides, i.e. without lib%name-devel (except for existing pkgs).
This is what I've been using for any new packages I've packaged.
However, as usual, I'm fine with any consistent scheme (one or the other
or both).
--
Anssi Hannula
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
On Fri, 08 Jul 2011, Ahmad Samir wrote:
Hello.
I've had a rather vague idea about standardising the virtual provides
in the distro, there should be:
Provides: %{name}-devel
Provides: lib%{name}-devel
Good idea.
With version and release included :
Provides: %{name}-devel = %{version}-%{release}
Provides: lib%{name}-devel = %{version}-%{release}
[Mageia-dev] A tool to help spotting backports needs
Hi, Mageia App Db (still under development but already usable and making progress) has a new page which compares all packages in stable releases to the packages in the development branch (here, cooker). You can find it here : http://88.191.121.20/madb/mageia/index.php/package/comparison/ It also shows when there are newer versions from other distributions, using http://check.mageia.org/updates.html for that. It can be filtered with the common Mageia App Db filters. For example, my preferred view is the following one, focusing on games :) http://88.191.121.20/madb/mageia/index.php/package/comparison/distrelease/2/application/1/group/109%2C85%2C30%2C61%2C8%2C25%2C76%2C69%2C54/arch/1/source/1 Best regards Samuel Verschelde (Stormi)
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
Am 08.07.2011 17:31, schrieb nicolas vigier:
On Fri, 08 Jul 2011, Ahmad Samir wrote:
Hello.
I've had a rather vague idea about standardising the virtual provides
in the distro, there should be:
Provides: %{name}-devel
Provides: lib%{name}-devel
Good idea.
With version and release included :
Provides: %{name}-devel = %{version}-%{release}
Provides: lib%{name}-devel = %{version}-%{release}
/me fully supporting this proposal.
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
Le vendredi 08 juillet 2011 à 17:27 +0300, Anssi Hannula a écrit :
On 08.07.2011 07:37, Ahmad Samir wrote:
Hello.
I've had a rather vague idea about standardising the virtual provides
in the distro, there should be:
Provides: %{name}-devel
Provides: lib%{name}-devel
either both of them in _all_ packages, or one of them in _all_
packages, so that we don't have to check urpmq --provides all the
time. Personally, I am more inclined on having them both, so as not to
break already working specs.
For example:
$ urpmq --provides lib64gudev1.0-devel-166-5.mga1.x86_64
libgudev-devel[== 166-5.mga1]
pkgconfig(gudev-1.0)[== 166]
devel(libgudev-1.0(64bit))
lib64gudev1.0-devel[== 166-5.mga1]
lib64gudev1.0-devel(x86-64)[== 166-5.mga1]
only libgudev-devel, so if I put BR gudev-devel in a spec it won't
work, whereas I'd expect it to work since some other packages have
such similar provides:
$ urpmq --provides lib64dbus-1-devel
libdbus-1-devel[== 1.4.1-3.mga1]
libdbus-devel[== 1.4.1-3.mga1]
dbus-devel[== 1.4.1-3.mga1]
[...]
WDYT?
(If we agree to go one way or the other, will just fix them gradually
over time).
I remember having this discussion in Mandriva when we dropped %major
from devel name. As a result the library policy (which we have on Mageia
as well) was altered so that all packages should have
- name-devel
- tarballname-devel
as provides, i.e. without lib%name-devel (except for existing pkgs).
This is what I've been using for any new packages I've packaged.
However, as usual, I'm fine with any consistent scheme (one or the other
or both).
I would be in favor of keeping the compatibility with existing
practice.
--
Michael Scherer
Re: [Mageia-dev] Updates testing
philippe makowski a écrit : 2011/7/8 nicolas vigierbo...@mars-attacks.org: I think the goal is not to do full regression tests, as we don't have time for this. But do minimal testing, in 1 or 2 minutes, to check that basic functionality is still working, to check that the update didn't break everything. For LibreOffice that could be opening a test document. Most applications are easy to test. But some require knowledge of the software, or some configuration files, to test, so we could keep a list of test commands or things to do and config files. make sense I agree with a list of packages needing special consideration Fedora have interesting rules about update/testing updates Once pushed to testing, people are able to +1/-1 the updates karma, based on whether or not it seems to be functional for them. If your update reaches a karma of 3, it will automatically be pushed to stable. Likewise, if it reaches -3, it will be automatically unpushed. If your update does not receive enough feedback to automatically push it to stable, you will have to submit it as a final update yourself. This can easily be done with the command-line tool, or with the web interface I like that approach, in general. Although if it doesn't work for 1 user, but does for 4 others, it could end up being pushed despite still having a bug. (Likely if the bug depends on other apps installed, affecting only a subset of users.) they also have proven tester https://fedoraproject.org/wiki/Proven_tester for critical path package -- André
Re: [Mageia-dev] Mageia educational - part 2
Angelo Naselli a écrit : Hi folks, thanks to mamming we've improved our wiki page [1]. It's always work in progress of course, new project entries and movement from to be packaged to package are always welcome :D Let's talk about what to do now, two main steps are: * add missing educational programs * group educational programs in specialized meta-packages For the first step every packagers, or padawans are welcome. stblack, pasmatt (matteo) and I will start working asap. Latter instead is a little bit complex, in that page there are projects like monodevelop, blander... that are not easy to group in. IMO we could have three starting meta-packages at the moment focused on students age -maybe on their related teacher as well- something like: pre-school6 y.o. primary-school 6-10 y.o secondary-school 10-14 y.o I can't see how to group for people over (high school?) since in Italy for instance we have different kind of school addresses e.g. technical in computer science, in chemical, etc... In North America, your high school would be called middle school, which has more or less disappeared. primary is about 6-12 y secondary is about 13-18 y the range 10-14 y remains transitional, in terms of curriculum, however. Smarter kids near the end of primary would be more interested in secondary level (and the inverse, I would imagine). Maybe it would be better to designate by anticipated age range ? In any case, there should be a lot of overlap. (Just because someone turns 15 they won't suddenly loose interest in what they used before.) Then another issue could be the desktop, or better, installing things either for qt or gtk for instance. I might be mistaken, but wouldn't most of such apps be more or less desktop-agnostic ? If not, we should give alternatives -- a Gnome user probably wouldn't want to install half of KDE for one package, and the equivalent would apply to KDE users. And of course other desktops. And is it right to install more than one project doing similar things? Why not ? It gives a choice, which I think encourages a positive attitude toward the use of computers as a tool in their life. As long as we don't try to insist that they can't uninstall something they're not interested in. Should we/Are we able to decide which is the best to be included in the meta-package? We could make suggestions, but it seems difficult to decide what. There is such variation of interest and ability among the young (like everyone else), that it seems even more difficult to decide the best. For those of high school level and above, it might be an idea to have meta packages focused on the domaine of interert, such natural sciences or social sciences, etc. What do you think about this subject? It might be an idea to have a base meta package which includes LibreOffice, internet tools, and other apps good for all age groups interested in education ? Cheers, Angelo [1] http://mageia.org/wiki/doku.php?id=sigedu Regards -- André
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
Wolfgang Bornath a écrit : 2011/7/8 Thorsten van Liltv...@gmx.de: Am 08.07.2011 10:42, schrieb Wolfgang Bornath: 2011/7/8 James Kerrj...@jkerr82508.free-online.co.uk: This thread has strayed far from the original question, which could be re-stated as: Should tainted free software and tainted nonfree software be commingled in a single tainted repository? How can tainted software be free software at the same time? Because free is a matter of license, while tainted is a matter of patents. For example, the libdvdcss2 is free, as the the source-code is open (GPL) but it touches the patent issue, so it's tainted. Yes, if you regard patents not as a criterium for free or non-free then this division makes sense. From that point of view we need the same structure as PLF (tainted-free and tainted-non-free). As well, the question of patent claims is a totally hypothetical problem, in almost every country -- including the USA -- for mirrors that carry distros like Mageia. (In the USA, the patent office used to systematically refuse patent claims on software. And patents are only examined for conflicting US patents before being registered. Not for the acceptability of the patent itself.) So basically, tainted is for the benefit of those who would like to support software patents. As non-free is for the benefit of those who would like to support free software. -- André
