Re: [packagekit] [gentoo-dev] Inviting you to project PackageMap
On Saturday 13 June 2009, Sebastian Pipping wrote: One of the stronger points for collaborating at the source is that poeple who are not Gentoo devs (yet) and therefore have no write access to the Gentoo tree can still extend and fix the Gentoo packagemap entries. Doing it downstream would hurt the whole project in several ways. To drive the project forward and find cross-distro acceptance, the packagemap repo/server has to be the authorative source of information for distributions that participate. However, I see advantages in a distributed model to collect the information. Gentoo developers could feed cpe tags into the metadata.xml of the tree and do not need to sign up to commit to the third-party packagemap repository. Synchronizing changed tags to the packagemap repository should be easy to automate. Changes in the repository could be propagated back to the tree by a designated team of Gentoo developers interested in the packagemap project. I have a feeling other distributions might also favor a model where they have more control about the data without giving all their devs access to one big repo. Robert signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Versioned use flags and preferencing (eg. qt3 / qt4 on same package)
Hi all, https://bugs.gentoo.org/show_bug.cgi?id=274197 The above bug brings up 2 issues: First, hplip says one thing, but does another with qt3 and qt4 use-based dependencies. This is obviously a bug that needs to be fixed. As a user, the second issue it brings up for me is what is the policy applied to the rest of the tree with regards to packages that can use one or more of several options (eg. qt3 or qt4) and have both / all flags specified? Do packages that can use both/all always use both/all? When both/all flags are specified, which one takes preferences? Always the newer? Where is this documented (both from a users point of view, and from a policy point of view)? If hplip the only package that can only use one of qt3/qt4 and as such that's why it's the only one with local use flag descriptions, or are there more which just haven't been documented? AllenJB
Re: [gentoo-dev] Versioned use flags and preferencing (eg. qt3 / qt4 on same package)
On Mon, 15 Jun 2009 16:48:03 +0100 AllenJB gentoo-li...@allenjb.me.uk wrote: https://bugs.gentoo.org/show_bug.cgi?id=274197 The above bug brings up 2 issues: First, hplip says one thing, but does another with qt3 and qt4 use-based dependencies. This is obviously a bug that needs to be fixed. As a user, the second issue it brings up for me is what is the policy applied to the rest of the tree with regards to packages that can use one or more of several options (eg. qt3 or qt4) and have both / all flags specified? Do packages that can use both/all always use both/all? Probably. When both/all flags are specified, which one takes preferences? Always the newer? When this issue arose up for www-client/opera because of upcoming Qt4 builds of (binary only) Opera, the qt team advised to only provide a qt3 USE flag and (thereby) make qt4 the default. So only if USE=qt3, then you get a Qt3 build of Opera[1]. Contrarily, net-print/hplip-3.9.4b appears to make Qt3 the default, while it could do entirely without IUSE=qt4, just like www-client/opera. Kind regards, jer [1] Technically speaking, you sometimes do get a Qt3 build in preview releases, but this shouldn't happen with stable releases of Opera.
Re: [packagekit] [gentoo-dev] Inviting you to project PackageMap
Robert Buchholz wrote: On Saturday 13 June 2009, Sebastian Pipping wrote: One of the stronger points for collaborating at the source is that poeple who are not Gentoo devs (yet) and therefore have no write access to the Gentoo tree can still extend and fix the Gentoo packagemap entries. Doing it downstream would hurt the whole project in several ways. To drive the project forward and find cross-distro acceptance, the packagemap repo/server has to be the authorative source of information for distributions that participate. However, I see advantages in a distributed model to collect the information. Gentoo developers could feed cpe tags into the metadata.xml of the tree and do not need to sign up to commit to the third-party packagemap repository. Synchronizing changed tags to the packagemap repository should be easy to automate. Changes in the repository could be propagated back to the tree by a designated team of Gentoo developers interested in the packagemap project. I have a feeling other distributions might also favor a model where they have more control about the data without giving all their devs access to one big repo. Paul Wise of Debian also articulated interest in doing database building at distro level, so that's one more point /for/ your feeling. However there are a few more things to take into account, please have a look at my reply to Paul: http://lists.alioth.debian.org/pipermail/popcon-developers/2009-June/001759.html Sorry for not CC'ing you, I should have though of that. Thinking the other way around: Is there anything we could do to make the central place approach work and feel better for everybody? Sebastian
Re: [packagekit] [gentoo-dev] Inviting you to project PackageMap
On Monday 15 June 2009, Sebastian Pipping wrote: However there are a few more things to take into account, please have a look at my reply to Paul: http://lists.alioth.debian.org/pipermail/popcon-developers/2009-June/ 001759.html Sorry for not CC'ing you, I should have though of that. Thinking the other way around: Is there anything we could do to make the central place approach work and feel better for everybody? The consumers of the PackageMap will always only use the central database. It is only the populators of the database that would be distributed. I am convinced the project will be more viable if people can choose their level of contribution. Many developers just won't care enough to take the extra hassle. If you make it easy enough for them to contribute to the CPE mapping, i.e. update their debian/controls or metadata.xml, they will (or not :-). Other developers that care more can then extract the data and merge it at the database and do extra maintenance tasks such as updating the substition map. If you make merging easy, I don't see how this hurts the project. Robert signature.asc Description: This is a digitally signed message part.
Re: [packagekit] [gentoo-dev] Inviting you to project PackageMap
Robert Buchholz wrote: The consumers of the PackageMap will always only use the central database. I'm not sure about that. I rather assume it will happen. Especially use ignoring the substitution map. I am convinced the project will be more viable if people can choose their level of contribution. Many developers just won't care enough to take the extra hassle. Agreed. However, I don't see a huge difference in level of extra hassle. The most difficult thing is doing who's-the-vendor research in my eyes atm which is the same at both ends. Maybe collaborating at a central place can add some fun that adding some field I don't really care about downstream cannot. Btw on Gentoo putting it in metadata.xml might be adding to the risk of a checksum mismatch, at least for extra edits. No idea if QA tools will catch 90% of that happening. If you make merging easy, I don't see how this hurts the project. I don't see how easy merging compensates for the issues I brought up. Can I have a few more voices on this?: Would you clearly feel more comfortable and motivated to contribute to PackageMap if it works at your distro's source package? Sebastian
Re: [packagekit] [gentoo-dev] Inviting you to project PackageMap
Sebastian Pipping wrote: Can I have a few more voices on this?: Would you clearly feel more comfortable and motivated to contribute to PackageMap if it works at your distro's source package? You are somewhat missing the point. My point is that most developers probably don't want to care about what happens PackageMap upstream at all so unless you mandate something to metadata.xml you will be relying on others to keep the information between Portage and your service in sync. But if it's in metadata.xml as a mandatory attribute then developers will be automatically adding the value when they create a new pkg. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] [gsoc-status] portage backend for PackageKit
Hi, I'm working on a portage backend for PackageKit [1]. As I did not really present my project, you have to know PackageKit is an universal (distribution-wide) package manager. To do so, every package manager which wants to work with PackageKit have to follow an api. PackageKit is compatible with a lot of package managers. Actually, it's the default one in Fedora and some other distributions. The main advantage of using PackageKit is to have a simple application working in most distributions. It will be a great advantage to make Gentoo more user-friendly. With a USE-flag GUI manager, it could be really great. The main difficulties for this project is the source-based aspect of Gentoo and the verbosity of portage. I mean even if PackageKit is designed to fit every needs, portage backend is the first source-based distribution backend and we will have to adapt some things. In addition, some information provided by portage like ewarn and elog messages and new configuration files have to be prompted even when using PackageKit. So, where are we right now ? The planning says every basic features should be done June 15th. Actually, I still have to do 2 features : list update candidates and do update. Every other basic features (install, remove, sync, details, dep, reverse-dep, groups, ...) have been done. To my defense, that's three days I'm sick. In addition, as PackageKit refuses interactivity, I've pushed ACCEPT_LICENSE default value to remove interactivity from ebuilds using check_license function from eutils eclass. What's going to be done right now ? Repositories management have to be added. With zmedico, we were talking about doing this directly in the portage api. Basically, it will be merging layman into portage. It's not 100% sure right now but probable. Beginning the hard work of messages management and bug fixes. I will try, to add needed ebuilds in the tree this week to let people test PackageKit on Gentoo as it will be usable even if not recommended yet. That's what we call an alpha version I think ;) [1] http://packagekit.org/ Thanks, Mounir
Re: [gentoo-dev] [gsoc-status] portage backend for PackageKit
Mounir Lamouri wrote: So, where are we right now ? The planning says every basic features should be done June 15th. Actually, I still have to do 2 features : list update candidates and do update. Every other basic features (install, remove, sync, details, dep, reverse-dep, groups, ...) have been done. To my defense, that's three days I'm sick. In addition, as PackageKit refuses interactivity, I've pushed ACCEPT_LICENSE default value to remove interactivity from ebuilds using check_license function from eutils eclass. If there are interactive ebuilds that don't declare PROPERTIES=interactive, you can just compile a list and post it to gentoo-dev-announce telling maintainers to add it or you will do it at some date X a week from the announcement or later at your choosing. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [packagekit] Inviting you to project PackageMap
Hi, Sebastian Pipping webmas...@hartwork.org: I am convinced the project will be more viable if people can choose their level of contribution. Many developers just won't care enough to take the extra hassle. Agreed. However, I don't see a huge difference in level of extra hassle. The most difficult thing is doing who's-the-vendor research in my eyes atm which is the same at both ends. Maybe collaborating at a central place can add some fun that adding some field I don't really care about downstream cannot. I agree with Petteri here, adding the cpe information into our metadata.xml makes forgetting entry submissions to PackageMap really easy for everyone. Thus automatic extraction of information from your side from metadata.xml files should be one option to gather the information. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
[gentoo-dev] Re: Versioned use flags and preferencing (eg. qt3 / qt4 on same package)
Hi, AllenJB gentoo-li...@allenjb.me.uk: Do packages that can use both/all always use both/all? No, app-editors/emacs(-cvs) will chose GTK+ above all others (Motif, Athena) if USE=gtk is specified. This is in compliance with upstream's wishes to have GTK+ as the default. Otherwise we order by usefulness from our point of view. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Adding Nipper license to the tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin H. Johnson wrote: The website stills says GPL v3: http://nipper.titania.co.uk/licensing.php Yep, the website's going to be updated for version 1.0 (with the license change). ... I can't really comment on a lot of this, unfortunately. Similar to the TrueCrypt issue, I'd say do NOT commit any ebuild covered by this license until the matter is resolved. Yeah, that's what I was afraid of... ... legal comments ... Again, I'm afraid I can't really comment on these, but thank you for the analysis, it was much appreciated to have a second pair of eyes look this stuff over. Any patches or updates that the Licensee may develop for NIPPER must be immediately submitted to the Licensor. In addition, the Licensee will forthwith transfer without charge all current and future rights including copyrights and other intellectual property rights relating to such updates to the Licensor. Gentoo is NOT a licensee under any of the classes of use listed in the license. We don't use it, and we're not a commercial integrator. Ergo there is a loophole that allows us to patch it without losing our rights to the patches. HOWEVER, I'd be concerned that the context (non-modified) portions of the path are still bound by the original license, and would violate non-distribution. I'm not keen on relying on loopholes. If I did still want to try and get a version of this into the tree, would packaging the binary RPM seem a reasonable solution? It's a shame given that the sources are potentially available (primarily released for Gentoo) and no real problem with making an ebuild, it's just the legalese... 5:( So I'll leave the source version out of the tree, but I'd like thoughts on using RPM as a solution? Also I don't know whether an exception could be made for Gentoo, but equally I don't know how to phrase one of them either (Gentoo Foundation or all Gentoo developers), so I'm hesitant to ask. If anyone has any other ideas or possibilities, do let me know. Thanks... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAko24AoACgkQu7rWomwgFXqEKACgsibF2QEaIB8t+flrhA0wHMMp Y0gAn3qesB0Li4DmRrquiXCEmUkDfbA6 =nvtn -END PGP SIGNATURE-
Re: [gentoo-dev] Adding Nipper license to the tree
On Tue, 2009-06-16 at 00:58 +0100, Mike Auty wrote: So I'll leave the source version out of the tree, but I'd like thoughts on using RPM as a solution? Also I don't know whether an exception could be made for Gentoo, but equally I don't know how to phrase one of them either (Gentoo Foundation or all Gentoo developers), so I'm hesitant to ask. If anyone has any other ideas or possibilities, do let me know. Thanks... Drop it from the tree entirely. Leave it to them to provide ebuilds. Obviously they do not want this software to be packaged by you, if they did they wouldn't put this intricate obstacle course in your way. Sometimes life can be so simple. Mike 5:) Regards, Tony V. signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Adding Nipper license to the tree
Tony \Chainsaw\ Vroon chain...@gentoo.org posted 1245111501.11818.5.ca...@localhost, excerpted below, on Tue, 16 Jun 2009 01:18:21 +0100: On Tue, 2009-06-16 at 00:58 +0100, Mike Auty wrote: So I'll leave the source version out of the tree, but I'd like thoughts on using RPM as a solution? Also I don't know whether an exception could be made for Gentoo, but equally I don't know how to phrase one of them either (Gentoo Foundation or all Gentoo developers), so I'm hesitant to ask. If anyone has any other ideas or possibilities, do let me know. Thanks... Drop it from the tree entirely. Leave it to them to provide ebuilds. Obviously they do not want this software to be packaged by you, if they did they wouldn't put this intricate obstacle course in your way. Sometimes life can be so simple. I agree.[1] The intent of the license is clear enough, make it proprietary, with enough questions about the legal implications and effectiveness of said license that it's simply not worth the hassle and risk. I honestly don't know why he's trying to do this. As others have pointed out, either his software is valuable enough to be worth forking, and it WILL fork (with the entire community shipping the freedomware fork), or it's not, and he's effectively sentencing it to some likely obscure proprietaryware niche. The friendly dual-license route would seem much more effective at doing what he seems to want to do. shrug . [1] I wrote (and revised...) an earlier reply coming to about the same conclusion, but decided the SNR wasn't high enough to send and the revisions weren't helping, so I sent it to /dev/null. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi again. Jorge Manuel B. S. Vicetto wrote: Hello fellow developers and users. Nominations for the Gentoo Council 2009/2010 are now open for the next two weeks (until 23:59 UTC, 14/06/2009). The voting booth has now opened and his waiting for you in woodpecker. Be sure to run votify --help as suggested by the informative motd set by Shyam (fox2mike). Quick voting helper: $ votify --new council200906 [1] $ $(editor) .ballot-council200906 [2] $ votify --verify council200906 [3] $ votify --submit council200906 [4] [1] - create a ballot in your home dir with the name of all the devs running for the election [2] - rank devs according to your preference (names at the top have precedence over names at the bottom and all names in the same line have the same preference) [3] - important step to verify your ballot and ensure there is nothing wrong with it [4] - don't forget to submit your ballot or it won't count!!! * Voting is opened from June 16th 00H00 UTC to June 30th 23H59 UTC (there is one day of break between nominations and voting so the infra team has time to set up everything) As you may have noticed, this means there'll be 15 days to vote and not 14 days. As I made a mistake in the original mail, we'll let it run the extra day instead of causing any confusion by respecting the 14 days voting period - so there'll be one less excuse not to vote! ;-) The page listing all nominations is here: http://www.gentoo.org/proj/en/elections/council-200906-nominees.xml We'll update the page with links to the manifestos as they came in - devs running for the election wanting to provide a manifesto please send an email to the dev ml with the URL. If you don't know what the Gentoo Council is, you can read about it here: http://www.gentoo.org/proj/en/council/ If you want to ask a question or share your thoughts, contact any of the election officials: Jorge Manuel B. S. Vicetto (jmbsvicetto) Łukasz Damentko (rane) Roy Bamford (neddyseagoon) Shyam Mani (fox2mike) will be doing infra magic. You can send us an e-mail (gentoo-elections at gentoo dot org) or find us on Freenode (#gentoo-elections, #gentoo-dev, so on). For the elections team, - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / SPARC / KDE -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko3DHcACgkQcAWygvVEyAKDJQCfcW906WLMFWmZ/QKAIO8qh9ST xBIAnA+EHcnFlT0hY621hICfaOeJUVMh =IYZG -END PGP SIGNATURE-
