[gentoo-dev] Last rites: www-plugins/weave
# Mounir Lamouri volk...@gentoo.org (18 Sep 2011) # Masked for removal in 30 days. Use Firefox 4 or higher instead. www-plugins/weave
[gentoo-dev] Last rites for net-misc/asterisk-chan_unicall, media-libs/libsupertone, net-libs/libmfcr2 and net-libs/libunicall
# Mounir Lamouri volk...@gentoo.org (20 Sep 2009) # media-libs/libsupertone fails with =media-libs/spandsp-0.0.5, bug 273995 # net-misc/asterisk-chan_unicall needs media-libs/libsupertone # net-libs/libmfcr2 needs libsupertone and only needed by asterisk-chan_unicall # net-libs/libunicall is only needed by libmfcr2 and asterisk-chan_unicall # net-libs/libunicall has also QA issues, bug 277783 # Masked for removal in 30 days. net-misc/asterisk-chan_unicall media-libs/libsupertone net-libs/libmfcr2 net-libs/libunicall
Re: [gentoo-dev] Last rites for net-misc/asterisk-chan_bluetooth
Christian Bricart wrote: Mounir Lamouri schrieb: # Mounir Lamouri volk...@gentoo.org (30 Jul 2009) # Masked for removal in 60 days. # Upstream's unactive since 2005. Do not support asterisk versions in tree. # bug 279383 net-misc/asterisk-chan_bluetoot may be replaced by (unpackaged) chan_mobile? -- http://www.chan-mobile.org/ Christian Actually, chan_mobile should be available via asterisk-addons-1.6*. (sorry for the delay) -- Mounir
[gentoo-dev] Last rites for net-misc/asterisk-app_rtxfax
# Mounir Lamouri volk...@gentoo.org (21 Sep 2009) # net-misc/asterisk-app_rtxfax fails with =media-libs/spandsp-0.0.3, bug 180318 # Masked for removal in 30 days. net-misc/asterisk-app_rtxfax
Re: [gentoo-dev] [RFC] Add operator + for licenses (EAPI-4 ?)
Zac Medico wrote: Sebastian Pipping wrote: I propose support for license groups in ebuilds then, I guess. That seems like a reasonable solution. So, an ebuild can do something like LICENSE=@GPL-2+ and that will expand to whatever the definition of the GPL-2+ license group happens to be. When a new version of GPL license comes out, we simple add it to that group, and none of the corresponding ebuilds have to be updated. I suppose adding group license support in ebuilds will fix the problem too. But I see a few disadvantages like: - new behavior for @ operator: it will not only expand a group but also adding a || operator (only for LICENSE) - devs will have to maintain new groups - group support in LICENSE has no other need that managing versioned licenses In an other hand, it will prevent us adding a new operator. And Sébastian, I don't understand you when you said GPL-2+ will be confusing for the user as it's a term commonly used in the FOSS world. But if everybody think groups are better, that will be fine. For those who think this feature is useless because we are not lawyers and ebuilds don't care about licenses, I just want to add it will not be a new _requirement_ but a new _possibility_. As Ciaran's said, you already have to check for licenses at the moment. So even if some devs do mistake (or do not update the info) as said Jeremy, we have at least this information. If you know a package is GPL-2 licensed, you can set LICENSE=GPL-2, it's valid, IMO. If you want to go far than that and check if it's GPL-2+, it's better but not _needed_. It's a small feature and it can help. Thanks, Mounir
Re: [gentoo-dev] [RFC] Add operator + for licenses (EAPI-4 ?)
Rémi Cardona wrote: Le 01/09/2009 00:12, Mounir Lamouri a écrit : Hi, As you should know, GLEP 23 [1] introduced USE flags conditions in LICENSE variable and || operator in addition of licenses groups and ACCEPT_LICENSE variable. [1] http://www.gentoo.org/proj/en/glep/glep-0023.html /me still thinks LICENSE should be informational _at_best_. Users who rely on LICENSE to build an FSF-approved system will simply be mislead. If we want to support this sort of things properly, we should have a treewide license audit. Anything short of that will just be a disservice to our users. I don't think your argument is valid. LICENSE is not informational so we have to deal with it and as GLEP-23 has an issue, we should fix it. I know even with this feature building a free-only system with ACCEPT_LICENSE will not be easy but the tree cleaning or anything else is a next step. Let's focus on what we can do now and what I propose is clearly doable and it will not break anything. -- Mounir
Re: [gentoo-dev] [RFC] Add operator + for licenses (EAPI-4 ?)
Sebastian Pipping wrote: Mounir Lamouri wrote: It's even worst when we try to use ACCEPT_LICENSE to have a free operating system. Let's suppose 'free' in fsf free and osf free, LGPL-2.1 is free for both but LGPL-2 isn't and we can suppose, most LGPL-2 licensed packages in the tree are LGPL-2+ actually. Are you aware that we have license groups like @FSF-APPROVED? It's set up in /usr/portage/profiles/license_groups. Groups are not fixing the problem even for free aspect. If I have a package licensed to LGPL-2, it's not free approved but if it's LGPL-2+, it is. So I can't add LGPL-2 to @FSF-APPROVED, we agree ? So, what I propose is to let a license to be suffixed by the + operator. In this case, if a newer license is accepted by ACCEPT_LICENSE, the PM should not filter the package. My vote is against it. It feels like black magic to me and many licenses are not versioned, at least not their reference names in Gentoo. However I do notice that GPL-2+ could make things easier. Why not introduce a license group for it like @GPL-2+ or so, instead? That would be transparent and use existing means. What do you think? I don't understand where the black magic is. I agree not so much licenses are versioned but they probably are the most used (LGPL, GPL, MPL, Apache, ...). GPL-2+ as a group make the filtering with ACCEPT_LICENSE easy (even if we have to suppose license groups are always up-to-date. However, a group will not add the information in the ebuild. In other words, I will have GPL-2 and GPL-3 with GPL-2+ in ACCEPT_LICENSE but I will not have GPL-2+ packages if i set only GPL-3 in ACCEPT_LICENSE. Anyway, I've seen an issue for licenses already named foo-NUMBER because with this feature, PM will consider them as versioned. Not a big deal for most of them but it could be weird like BSD-2+ to have BSD-2 and BSD-4. ls | grep -e -[0123456789.]*$ in the licenses directory to see the concerned licenses As it has to come with a new EAPI, we can rename some licenses before. -- Mounir
Re: [gentoo-dev] Re: [RFC] Add operator + for licenses (EAPI-4 ?)
Duncan wrote: Sebastian Pipping posted on Tue, 01 Sep 2009 04:21:49 +0200 as excerpted: However I do notice that GPL-2+ could make things easier. Why not introduce a license group for it like @GPL-2+ or so, instead? That would be transparent and use existing means. I've always thought Gentoo needed plus versions of the versioned licenses, anyway. GPL-2, GPL-2+, GPL-3, and GPL-3+, should all be different licenses, because really, they are. AFAIK, GPL-2 and GPL-2+ are not different, may you tell me more about that ? Thanks, Mounir
Re: [gentoo-dev] Re: [RFC] Add operator + for licenses (EAPI-4 ?)
Rémi Cardona wrote: Le 03/09/2009 23:10, Mounir Lamouri a écrit : Duncan wrote: Sebastian Pipping posted on Tue, 01 Sep 2009 04:21:49 +0200 as excerpted: However I do notice that GPL-2+ could make things easier. Why not introduce a license group for it like @GPL-2+ or so, instead? That would be transparent and use existing means. I've always thought Gentoo needed plus versions of the versioned licenses, anyway. GPL-2, GPL-2+, GPL-3, and GPL-3+, should all be different licenses, because really, they are. AFAIK, GPL-2 and GPL-2+ are not different, may you tell me more about that ? GPL-2+ means GPL-2 GPL-3 GPL-4 ... Not quite the same thing as just GPL-2 But the content of the license is the same. That only means you can use a newer one. I mean we do not need a new license file for that. It's up to upstream to write somewhere if it's GPL-2 or GPL-2+, am I right ? -- Mounir
Re: [gentoo-dev] [RFC] USE flags requirements (EAPI-4 ?)
Nirbheek Chauhan wrote:
There's also bug 251179[1], which is ugly at first glance, but shows
that we don't really need an extra variable to control dependencies
between USE-flags (it *is* after all a dependency).
So, we can either use
use1? ( =${CATEGORY}/${PVR}[use2,use3,use4] )
which will probably require less changes to portage's resolver; or
something else like
use1? ( use2 use3 use4 )
The latter is unambiguous because it's not a package atom (no / ).
Either of these will work great when portage gets automatic
USE-dependency enabling.
Indeed, this is doable but I don't think it's clear enough. In addition,
speaking of PM, it will force it to be able to detect use1? ( use2 ) and
use1? ( cat/pkg ). Speaking of ebuild readability it's also not a good
thing because that's not real a dependency.
If needed, we can put this in IUSE variable actually. I've nothing
against even if I prefer IUSE_REQUIREMENTS because it's clearer: we
define IUSE vars somewhere and how to handle them somewhere else.
--
Mounir
Re: [gentoo-dev] [RFC] USE flags requirements (EAPI-4 ?)
Ciaran McCreesh wrote: Is the less expressive solution you're describing still useful enough to make it worthwhile? When we were doing this for Exherbo, we identified five types of inter-use-flag dependency: Actually, I said in my email I was looking for opinions about the feature not really about the syntax. It was just an example but as no-one jump to say it was useless and stupid, let's try with a clearer syntax. * if a then b IUSE_REQUIREMENTS=a? ( b ) * if a then not b IUSE_REQUIREMENTS=a? ( -b ) * at least one of a b c, possibly only if d IUSE_REQUIREMENTS=d? ( || ( a b c ) ) * exactly one of a b c, possibly only if d IUSE_REQUIREMENTS=d? ( || ( a b c ) ) a ? ( -b -c ) b ? ( -a -c ) c? ( -a -b ) * at most one of a b c, possibly only if d IUSE_REQUIREMENTS=d? ( a? ( -b -c) b? ( -a -c ) c? ( -a -b) ) if needed we can add IUSE_REQUIREMENTS=!d? ( -a -b -c) Does Gentoo make use of all of these, and are there any cases that the above doesn't cover? How would you express each of the above using USE_REQUIREMENTS? From a package manager perspective, it's much easier to give good advice to the user if we're told by the ebuild exactly what's going on. So I think we can satisfy all use cases with the classic Gentoo syntax even if new operators could be appreciated ;) -- Mounir
Re: [gentoo-dev] [RFC] USE flags requirements (EAPI-4 ?)
Ciaran McCreesh wrote: On Mon, 31 Aug 2009 20:15:37 +0200 Mounir Lamouri volk...@gentoo.org wrote: * at least one of a b c, possibly only if d IUSE_REQUIREMENTS=d? ( || ( a b c ) ) Moderately eww... * exactly one of a b c, possibly only if d IUSE_REQUIREMENTS=d? ( || ( a b c ) ) a ? ( -b -c ) b ? ( -a -c ) c? ( -a -b ) Really eww... * at most one of a b c, possibly only if d IUSE_REQUIREMENTS=d? ( a? ( -b -c) b? ( -a -c ) c? ( -a -b) ) Similarly eww. From a package manager perspective, it's much easier to give good advice to the user if we're told by the ebuild exactly what's going on. So I think we can satisfy all use cases with the classic Gentoo syntax even if new operators could be appreciated ;) How do we translate the above into nice friendly messages for the user? Taking the exactly one case, it's much better to say to the user: * If 'd' is enabled, exactly one of 'a', 'b' or 'c' must be enabled Than: * If 'd' is enabled, at least one of 'a', 'b' or 'bc' must be enabled Then when the user turns on all three: * If 'd' is enabled, if 'a' is enabled, 'b' must not be enabled * If 'd' is enabled, if 'a' is enabled, 'c' must not be enabled * If 'd' is enabled, if 'b' is enabled, 'a' must not be enabled * If 'd' is enabled, if 'b' is enabled, 'c' must not be enabled * If 'd' is enabled, if 'c' is enabled, 'a' must not be enabled * If 'd' is enabled, if 'c' is enabled, 'b' must not be enabled And in the general case, there's no way of translating the latter into the former. Much easier for everyone if you just say what you mean rather than converting it into some convoluted (but theoretically equivalent) less expressive syntax. We don't see this feature the same way. I don't want to add a feature that will prevent the maintainer to die if we can't found another way. I want the package manager do make some decisions before calling the ebuild. For example: * if a then b IUSE_REQUIREMENTS=a? ( b ) if USE=-a b is used, the package manager should enable a because it's needed for b and it should show this. We could say we also can disable b but we can't know if a USE flag is disabled or just not enabled (in other words, because every USE flags is disabled by default). In addition, we can consider if someone want to enable a feature it should be more important than disabling another. * if a then not b IUSE_REQUIREMENTS=a? ( -b ) if USE=a b, b should be disabled by the PM. It's up to the maintainer to choose a default behavior by setting the relation between USE flags (b? ( -a ) is equivalent but will disable a). * at least one of a b c, possibly only if d IUSE_REQUIREMENTS=d? ( || ( a b c ) ) if USE=d, the PM will enable a. * exactly one of a b c, possibly only if d IUSE_REQUIREMENTS=d? ( || ( a b c ) ) a? ( -b -c ) b? ( -a -c ) c? ( -a -b ) if USE=d, same as before. if USE=d a, nothing if USE=d a b, it's harder because a? ( -b -c ) and b? ( -a -c ). We can imagine to disable b because a is the first value in || ( a b c ) but it's not satisfying. We can imagine another operator like | to represent this dependency: d? ( | ( a b c ) ) * at most one of a b c, possibly only if d IUSE_REQUIREMENTS=d? ( a? ( -b -c) b? ( -a -c ) c? ( -a -b) ) it's quite similar to the previous one but here it's harder to guess which one should be keep if USE=d a b. As previously, we can imagine another operator like d? ( ||| ( a b c ) ) But if we want to move to a really generic specification, we can introduce something similar to Exherbos syntax: exactly-N, max-N, min-N with N as a positive integer. So, we could write: d? ( exactly-1? ( a b c ) ) d? ( max-1? ( a b c ) ) d? ( min-1? ( a b c ) ) With this syntax, it's easy to consider first values as one to use by default for the PM (so, never failing). The only big issue I see with this syntax is it will make exactly-N, max-N and min-N no valid USE flags. But we can prevent that by prefixing the name by an illegal character like ||exactly-1. About the dying thing, I just want to precise I don't want to add a feature that will only die with a cool message. Maintainers can do that. The idea is to prevent maintainers to do that without silently enabling a feature or moving to an unstable state (because of EAPI-2 use dependencies). It will let maintainers to die if they want. They will not have to set a? ( b ) if they really think a shouldn't be enabled (even with possible user knowledge) if b is enabled. In this case, the classic die statement will be ok. Thanks, Mounir
Re: [gentoo-dev] [RFC] USE flags requirements (EAPI-4 ?)
dev-ran...@mail.ru wrote: On Mon, Aug 31, 2009 at 07:27:32PM +0100, Ciaran McCreesh wrote: Then when the user turns on all three: * If 'd' is enabled, if 'a' is enabled, 'b' must not be enabled * If 'd' is enabled, if 'a' is enabled, 'c' must not be enabled * If 'd' is enabled, if 'b' is enabled, 'a' must not be enabled * If 'd' is enabled, if 'b' is enabled, 'c' must not be enabled * If 'd' is enabled, if 'c' is enabled, 'a' must not be enabled * If 'd' is enabled, if 'c' is enabled, 'b' must not be enabled And in the general case, there's no way of translating the latter into the former. Much easier for everyone if you just say what you mean rather than converting it into some convoluted (but theoretically equivalent) less expressive syntax. I suggest alternative syntax, less powerfull but more expressive: groups of use-flags. Guess we define the following flags in IUSE: 3d.nvidia 3d.ati 3d.intel or 3d+nvidia 3d+ati 3d+intel or 3d:nvidia 3d:ati 3d:intel In first case we may enable any number of those flags. In second case we must enable at least one of them. In third case we must enable exactly one of them. In all 3 cases, if (and only if) flag '3d' itself exist in IUSE, those flags are ignored when it is unset. For convenience, user may use '.' as middle-character in config in all 3 cases (or, perhaps, even omit it and everything before it), but in output of PM he will see proper character and understand dependencies between flags without any explanation in English. If we add flag which depends on nvidia (e.g. cg), we name it 3d.nvidia.cg, and it will be ignored (perhaps with warning) if flag 3d.nvidia is unset As you said, it's not enough powerful. It's going to be hard if foo flags depends on 3d and bar. In addition, I don't think the real issues is the friendliness of the syntax but the powerful aspect. Indeed, it shouldn't be shown to the user and more the syntax is powerful less the user will be annoyed. -- Mounir
[gentoo-dev] [RFC] Add operator + for licenses (EAPI-4 ?)
Hi, As you should know, GLEP 23 [1] introduced USE flags conditions in LICENSE variable and || operator in addition of licenses groups and ACCEPT_LICENSE variable. [1] http://www.gentoo.org/proj/en/glep/glep-0023.html I want to show an issue in ACCEPT_LICENSE that have to be fixed with a new operator in LICENSE variable. Imagine we have ACCEPT_LICENSE=GPL-3, every ebuilds without GPL-3 in LICENSE variable will be filtered even ebuilds with LICENSE=GPL-2 and a lot of packages are actually GPL-2+, not GPL-2 strict. That means they should be shown if ACCEPT_LICENSE=GPL-3. It's even worst when we try to use ACCEPT_LICENSE to have a free operating system. Let's suppose 'free' in fsf free and osf free, LGPL-2.1 is free for both but LGPL-2 isn't and we can suppose, most LGPL-2 licensed packages in the tree are LGPL-2+ actually. So, what I propose is to let a license to be suffixed by the + operator. In this case, if a newer license is accepted by ACCEPT_LICENSE, the PM should not filter the package. I think it's not a hard modification and it will only need an amend to GLEP 23 (in addition of implementations in PM's). Thanks, Mounir
[gentoo-dev] [RFC] USE flags requirements (EAPI-4 ?)
Hi, While writing and using some ebuilds, I had to deal with (pseudo) USE flags requirements. For example, if you install mplayer with USE=encode the result will depend on other USE flags: if you have USE=encode mp3, it will install lame for example. I know a few ebuilds behave like that in the tree. We can also see some ebuilds that will force an option if you set another one: if you set USE=-foo +bar and bar needs foo, it will silently set --enable-foo. Finally, they are some ebuilds like =ekiga-3 that will just fail if you have two USE flags conflicting: kontact needs kde so USE=kde -kontact and USE=kde kontact are okay but USE=-kde kontact will fail. In my opinion, we can't keep auto-enabling some options because the user has enabled another option without telling him and without telling the package manager. For example, I'm a lambda user, I've set USE=kontact but I don't know it's related to KDE, I don't have a KDE desktop and I don't want one. With the regular behavior in the tree, kde will be enabled silently and the user will don't have a clue about it like the package manager. This last one is even worst because if we imagine a library ebuild with this behavior used by other ebuilds in the tree, EAPI-2 use dependencies will break. (foo ebuild depends on ekiga[kde], user will have to rebuild ekiga if it has been built with USE=-kde kontact even if ekiga has been built with kde support or foo ebuild depends on mplayer[mp3] should be mplayer[encode,mp3]. However, dying is probably not the best solution too. So I think we should add a new feature in PMS already used in Exherbo EAPI, USE flags requirements [1]. That means an ebuild should be able to say a USE flag is available only if some other ones are in a specific state. Let's take the mplayer example, if we have a line like this: USE_REQUIREMENTS=encode? ( mp2 mp3 faac x264 xvid ), PM should be able to show the user USE=mp3 will be ignored because he didn't set USE=encode and the PM will disable this USE flag by himself. The same way, for ekiga: USE_REQUIREMENTS=kde? ( kontact ), PM should be able to show the user if he set USE=kontact, kde USE flag is enabled and the PM will enable this USE flag by himself. I think this new feature should help everyones life. We can also imagine great features like a minimal USE-flag that will be something like: USE_REQUIREMENTS=minimal? ( foo bar ) to set a list of USE flags to disable if minimal USE flag is enabled. Combined to EAPI-1 auto-enabled USE flags, it could help disabling all auto-enabled USE flags for some uses... That's just an idea. I'm not writing a GLEP draft so don't try to found an issue in the syntax used, it's only to know if this kind of feature will be appreciated by other users/devs than me and if it could be added to EAPI-4 and worth to work on it. I can write the GLEP and implement the feature in portage. [1] http://www.exherbo.org/docs/exheres-for-smarties.html#myoptions Thanks, Mounir
[gentoo-dev] Post-GSoC project document
Hi, My Google Summer of Code project was about writing a portage backend for PackageKit. Before beginning the work we knew it will not be easy. So I tried to write the backend as much complete as possible and I did a few changes to portage to help that. But this work helped me to see all the features we were not able to implement because of some limitations in the API involving. As this part of the work can't be seen in the code, I've wrote a document about what where the difficulties and what we will have to work on for the next steps: http://dev.gentoo.org/~volkmar/post-gsoc-packagekit-portage.html Hope it will be interesting. Thanks, Mounir
Re: [gentoo-dev] New media-libs/jpeg-7 and how to deal with it.
Samuli Suominen wrote: Ciaran McCreesh wrote: On Sat, 22 Aug 2009 16:01:47 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: media-libs/jpeg-7 installs .so.7.0.0 so this causes some headacke for binary applications: Doesn't this mean you should slot it? No. I only want the .so.62 for binary apps, thus the ebuild won't install anything but the shared libs You wrote a header was now private so it will probably make a lot of ebuilds incompatible with 7.0. Maybe slotting could be useful even for them. Mounir
[gentoo-dev] ACCEPT_PROPERTIES in portage trunk
Hi, I would like to inform you in addition of ACCEPT_KEYWORDS and somewhat new ACCEPT_LICENSE, portage now uses ACCEPT_PROPERTIES. As for LICENSE, this var let the user mask some packages considering the PROPERTIES line. Contrary to ACCEPT_LICENSE, the default value is *. This means every PROPERTIES value will be accepted. Actually, the only usage I know is for interactive: if you want to mask interactive ebuilds, you will just have to set ACCEPT_PROPERTIES=-interactive then emerge/portage will consider the ebuild is not visible. You can also set /etc/portage/package.properties to have a per-package configuration. It was needed to fix a blocker for packagekit with interactive ebuilds. So, it's a bit selfish ;) Thanks, Mounir
[gentoo-dev] Re: [gsoc-status] portage backend for PackageKit
Mounir Lamouri wrote: So, this week, I will add a ACCEPT_PROPERTIES feature to portage. I was thinking of filtering interactive PROPERTIES in my backend but zac told me he was planning to add this feature. It should be available soon (one or two days) and the gnome-packagekit ebuild will be the next step. So, you should have it in two or three days. Depends on the difficulty. If the build system is clean as the PackageKit one was, it will be hard and I've no commit access to gnome-packagekit unfortunately. gnome-packagekit is now availabe in the gnome overlay. And ACCEPT_PROPERTIES is available in portage trunk. I'm now fixing some bugs so if you found some, let me know ! Mounir
[gentoo-dev] Last rites for net-misc/asterisk-chan_bluetooth
# Mounir Lamouri volk...@gentoo.org (30 Jul 2009) # Masked for removal in 60 days. # Upstream's unactive since 2005. Do not support asterisk versions in tree. # bug 279383 net-misc/asterisk-chan_bluetooth
[gentoo-dev] Re: [gsoc-status] portage backend for PackageKit
Arne Babenhauserheide wrote: Am Montag, 15. Juni 2009 22:51:52 schrieb Mounir Lamouri: I'm working on a portage backend for PackageKit. Could you give us a small status update? Does your backend already work? Best wishes, Arn Hi, It has been a while without weekly updates even if my mentor suffers^W benefits of frequent updates, I didn't get really interesting things to be said here. Actually, I had some issues with the last functions I had to re-write. The backend is now ready. You should be able to do anything in a beta/realease candidate quality. Even if I think there are still two features that can (timely speaking) and need (user's point of view speaking) to be added: - configuration file update - messages / warning / errors show They are not critical for testing but only for a daily usage. I've already done the portage work for the first feature but I will have to add signal to packagekit because even if debian also needs it, it hasn't been implemented yet. The bad thing is GUI will probably not manage this feature since a quite long time. The second feature shouldn't be really hard. About the packaging. I've worked on a packagekit ebuild and even if I didn't take time to add it to the tree it could be done without a lot of work but there is not real need at the moment because -as I said before- without a GUI, packagekit is quite useless and last version of gnome-packagekit needs a version gnome-policykit that is not in the tree. As the backend should now be working correctly for a real usage it will probably add packagekit live ebuild in the tree but if you want to test the backend, I recommand you to clone packagekit and gnome-packakit repositories, it will be easier ;) After these two features, I will probably have some small things and bugs and I will move to big things for packagekit or portage needed to make the backend better. Indeed, there are a lot of things I've listed that are not really needed for a working backend and too big to be part of the gsoc. For example, merging layman into portage (actually, API will be easy but UI probably less) and having a non-verbose portage API because backends are using stdout for signals. If by any chance, you test the backend, do not hesitate to contact me for bug reports or comments. Thanks, Mounir
Re: [gentoo-dev] [gsoc-status] portage backend for PackageKit
Nirbheek Chauhan wrote: On Sat, Jul 4, 2009 at 5:05 AM, Steve Dommettst...@st4vs.net wrote: I'm no Python programmer, and I haven't even read the code involved, but in the interests of minimising duplication of effort, I thought you'd be interested to know that Sabayon, a Gentoo based binary distro, look like they may be one step ahead of you on this one: http://gitweb.sabayon.org/?p=playground/packagekit-entropy.git;a=summary It's a stub import (no real code). And the git import is also done incorrectly, he's imported .libs/ and .deps/ which are build-time files. So, I'd say he looked at *this* project and decided to try writing a backend for Entropy as well. Like Nirbheek said, there is no real code so I'm not sure they are one step ahead of me on this project. In addition, they should ask for a packagekit git access. It's easy to get one and surely better than working in your own playground. Mounir
Re: [gentoo-portage-dev] Portage API questions
Hi, My 2 cents: Sebastian Pipping wrote: - installed packages with version numbers vardb = portage.db[portage.settings[ROOT]][vartree].dbapi vardb.cpv_all() will return cat/package-version vardb.cp_all() will return cat/package of installed packages - entries for /var/lib/portage/world You should think about world + system : for s in (system, world): set = portage._sets.base.InternalPackageSet( initial_atoms=rootconfig.setconfig.getSetAtoms(s)) for cp in set: print cp # print cat/package in world/system Good luck :) Mounir
[gentoo-dev] [gsoc-status] portage backend for PackageKit (2)
Hi, Here I come again with another gsoc update. Nearly weekly (10 days) but still better than nothing ;) Last time, I was talking about an ebuild for packagekit soon. Actually, packagekit is not useful without a pretty frontend. I am using gnome-packagekit but packagekit and gnome-packagekit moved to policykit-0.92 and gnome-policykit-0.92 which are new. Policykit-0.92 is masked in the tree (thanks mrpouet) but gnome-policykit is nowhere at the moment. So as I'm not able to add gnome-policykit. Ebuilds are going to wait. A probable fix will be to add packagekit masked in the tree and gnome-packagekit with gnome-policykit in gnome-overlay. We will see. So, where is portage support in packagekit ? We know have a support for all functionalities. Even repository management with layman api. By the way, with zmedico, we were talking about a possible merge of layman in portage (ie. have a repository management system directly in portage). It could be done maybe at the end of the gsoc or even after. Now, I'm working on having a clean and best as possible portage management with packagekit. For example, packagekit is having a filter system which help user to filter showed content (mostly when searching something). Some filters proposed by packagekit can't be added now because portage/ebuilds don't support them but they could be good adds for Gentoo ebuilds. I will speak about them in a further email. They are not needed for my gsoc because that's clearly not key features but for further developments, that would be great to have them. So, next developments are going to improve integration for search-* and get-* functions. Basically, every non-critical functions. That will be done by discussing portage needs and adding messages / errors specific to portage if needed. After that, install-* and update-* functions will have to be improved. That will surely be a bigger work. Thanks for reading. Mounir
[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] packages up for grabs
Raúl Porcel wrote: Since i don't have too much time nor motivation to fix packages(i prefer doing arch work), i'm asking someone to take the following packages, i'm dumping them to net-p2p atm, but its just Betelgeuse and me, so feel free to maintain them. net-p2p/deluge net-p2p/qbittorrent net-libs/rb_libtorrent I was planning to work on btg and dependencies (so rb_libtorrent) when I will have some time. Probably after my GSOC. Mounir
Re: [gentoo-dev] New metadata fields
Jeremy Olexa wrote: On Wed, Jun 3, 2009 at 9:38 AM, Steve Dibb bean...@gentoo.org wrote: I had an idea for some new fields to go in metadata.xml. Not sure if we would need a GLEP for this or not? Anyway, what do you guys think: Two things I can think of adding that would be useful: - ChangeLog URL - Bug Tracker I know I hate hunting down the two of them, and both of them could be useful references for developers and users. Plus, not every upstream has them, so they can of course be optional fields. Steve mraudsepp pointed this out in irc (I didn't know about it either): http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=4 You are allowed to use changelog and bugs-to So...have fun ;) -Jeremy I think Jeremy just proposed to add these fields in metadata.xml gentoo-syntax template for vim. That's a great idea Jeremy, it will surely help more devs to fill these fields ! :) Mounir
Re: [gentoo-dev] New global USE flags (network, 3dnowext, static-libs, mtp)
Samuli Suominen wrote: Mart Raudsepp wrote: On K, 2009-06-03 at 02:13 +0300, Samuli Suominen wrote: USE network is used by 9 ebuilds, and one is using USE networking which can be converted, that'd be 10. USE network Enable networking support Maybe network and net could be merged ? Mounir
Re: [gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)
Nirbheek Chauhan wrote: On Wed, Jun 3, 2009 at 1:22 AM, Mounir Lamouri volk...@gentoo.org wrote: Nirbheek Chauhan wrote: Most licenses aren't for usage, but for distribution -- surely you mean EULAs? License and EULA is the same for most users and it's exactly the same for ebuilds/portage. EULA is an End-User license agreement, and is to be agreed upon by the *user*. Not the person installing the program. This means they're (or should be) prompted at first start-up, not at install. If they're prompted at install, it's broken. I don't get your point. check_license() is used to print the license (it's probably only used for EULA's actually) and wait for user approval before resume the merge process. The printed license is the license from LICENSE var. Since they're prompted at install, *that* behaviour needs to be changed, not worked around. It should be prompted for every user, probably by using a config file in ~/.config/eulas + a wrapper which checks for the EULA having been accepted. I don't think EULA's have to be accepted by users when launching the program but when installing it. It's the way it's done in most cases in Windows and it has to be done because some EULA's add limitation on numbers of installations (mostly games). I admit End User should be the real user but you can't install a program if you do not agree to EULA in most cases. That's funny but some FOSS on Windows also prompt GPL to make sure the user accept it before installing. Mounir
Re: [gentoo-dev] Monthly Gentoo Council Reminder for June
Mike Frysinger wrote: This is your monthly friendly reminder ! Same bat time (typically the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ irc.freenode.net) ! If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. Following Richard recommandation [1] I propose to vote for default ACCEPT_LICENSE value sets to: ACCEPT_LICENSE=* -...@eula with @EULA a license group including every licenses considered as EULA which means needing approval by user. This is including most commercial licenses. At least, every packages using check_license() from eutils.eclass should have their license add in @EULA group license. Why this default value ? My initial post [2] mentioned 3 values. I choose the one I described the worst because of issues reported. Indeed, Richard [3] reported he didn't want to have a too restrictive value. This one is the less restrictive we can have. In addition, Ciaran McCreesh reported an issue with badly licensed ebuilds like most X packages [4]. This issue was a blocker for a too restrictive default value. With the proposed value, bad licensed packages will not be blocked. At least, by default. Setting this default value as soon as possible is the best compromise. It will put this feature in portage and let people use it. Packages needing user approval will be blocked and then fix bug 152593 [5]. In addition, users setting ACCEPT_LICENSE to a more restrictive value will help to catch bad licensed ebuilds by filing bugs. Finally, it is removing a reason for interactiveness (via check_license()) into ebuilds. This could be a first step for a new default value in the future (when all licenses will be fixed). So, may the council vote on this default value for ACCEPT_LICENSE ? [1] can't find something in gmame nor in archives.g.o, you should add the year after the reminder for $month ;) [2] http://archives.gentoo.org/gentoo-dev/msg_d5c1e7285399ebc27a74bdd02cb4d037.xml [3] http://archives.gentoo.org/gentoo-dev/msg_f391139d825eb793cf0694add4f39d93.xml [4] http://archives.gentoo.org/gentoo-dev/msg_d5c1e7285399ebc27a74bdd02cb4d037.xml [5] https://bugs.gentoo.org/show_bug.cgi?id=152593 Thanks, Mounir
Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
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). I would like to nominate: darkside scarabeus tanderson Mounir
Re: [gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)
Nirbheek Chauhan wrote: On Tue, Jun 2, 2009 at 3:56 AM, Mounir Lamouri volk...@gentoo.org wrote: This feature (ACCEPT_LICENSE) is important to remove check_license() call from ebuilds which need user input while merging. Interaction in ebuild should be avoided and it is a blocker for a fully functional portage backend for packagekit (my gsoc project). Most licenses aren't for usage, but for distribution -- surely you mean EULAs? License and EULA is the same for most users and it's exactly the same for ebuilds/portage. I don't get your point. check_license() is used to print the license (it's probably only used for EULA's actually) and wait for user approval before resume the merge process. The printed license is the license from LICENSE var. I'm sorry if I misunderstood something. Thanks, Mounir
Re: [gentoo-portage-dev] netbeans-6.7-rc1 (only reporting)
Hi,
You should file a bug to bugs.gentoo.org instead of posting your bug
report to a mailing list.
In addition, gentoo-portage-dev is only about portage development.
Thanks,
Mounir
Zhu Sha Zang wrote:
Problems in installation.
arch: i386
netbeans flags:
[ebuild U ] dev-util/netbeans-6.7_rc1 [6.7_beta-r7] USE=-debug
-doc LINGUAS=pt_BR -ar% -cs -de -es -fr -gl% -id% -it -ja -ko -nl
-pl -ru -sq -sv% -tr -zh_CN -zh_TW NETBEANS_MODULES=apisupport cnd
dlight enterprise ergonomics groovy harness ide identity java mobility
nb php profiler webcommon websvccommon -ruby 0
PROBLEM:
release:
[nbmerge] Failed to build target: all-libs.bytelist
BUILD FAILED
/usr/local/var/tmp/portage/dev-util/netbeans-6.7_rc1/work/nbbuild/build.xml:664:
The following error occurred while executing this line:
/usr/local/var/tmp/portage/dev-util/netbeans-6.7_rc1/work/nbbuild/build.xml:659:
The following error occurred while executing this line:
/usr/local/var/tmp/portage/dev-util/netbeans-6.7_rc1/work/nbbuild/build.xml:694:
The following error occurred while executing this line:
/usr/local/var/tmp/portage/dev-util/netbeans-6.7_rc1/work/nbbuild/build.xml:677:
The following error occurred while executing this line:
/usr/local/var/tmp/portage/dev-util/netbeans-6.7_rc1/work/nbbuild/build.xml:659:
The following error occurred while executing this line:
/usr/local/var/tmp/portage/dev-util/netbeans-6.7_rc1/work/nbbuild/build.xml:694:
The following error occurred while executing this line:
/usr/local/var/tmp/portage/dev-util/netbeans-6.7_rc1/work/nbbuild/build.xml:677:
The following error occurred while executing this line:
/usr/local/var/tmp/portage/dev-util/netbeans-6.7_rc1/work/nbbuild/build.xml:659:
The following error occurred while executing this line:
/usr/local/var/tmp/portage/dev-util/netbeans-6.7_rc1/work/nbbuild/build.xml:706:
The following error occurred while executing this line:
/usr/local/var/tmp/portage/dev-util/netbeans-6.7_rc1/work/nbbuild/templates/projectized.xml:189:
Could not find file
/usr/local/var/tmp/portage/dev-util/netbeans-6.7_rc1/work/libs.bytelist/external/bytelist-0.1.jar
to
copy
Total time: 3 minutes 16 seconds
*
* ERROR: dev-util/netbeans-6.7_rc1 failed.
* Call stack:
* ebuild.sh, line 49: Called src_compile
* environment, line 4470: Called eant
'-Dstop.when.broken.modules=true' '-Dpermit.jdk6.builds=true'
'-Dbuild.compiler.deprecation=false'
'-Dnb.clusters.list=nb.cluster.platform,nb.cluster.apisupport,nb.cluster.cnd,nb.cluster.dlight,nb.cluster.enterprise,nb.cluster.ergonomics,nb.cluster.groovy,nb.cluster.harness,nb.cluster.ide,nb.cluster.identity,nb.cluster.java,nb.cluster.mobility,nb.cluster.nb,nb.cluster.php,nb.cluster.profiler,nb.cluster.webcommon,nb.cluster.websvccommon'
'-f' 'nbbuild/build.xml'
'build-nozip'
* environment, line 973: Called
die
* The specific snippet of
code:
* ant ${antflags} $...@} || die eant
failed
* The die
message:
* eant
failed
*
* If you need support, post the topmost build error, and the call
stack if
relevant.
* A complete build log is located at
'/usr/local/var/tmp/portage/dev-util/netbeans-6.7_rc1/temp/build.log'.
* The ebuild environment file is located at
'/usr/local/var/tmp/portage/dev-util/netbeans-6.7_rc1/temp/environment'.
*
!!! When you file a bug report, please include the following
information:
Re: [gentoo-dev] Monthly Gentoo Council Reminder for June
Mike Frysinger wrote: This is your monthly friendly reminder ! Same bat time (typically the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ irc.freenode.net) ! If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. Keep in mind that every GLEP *re*submission to the council for review must first be sent to the gentoo-dev mailing list 7 days (minimum) before being submitted as an agenda item which itself occurs 7 days before the meeting. Simply put, the gentoo-dev mailing list must be notified at least 14 days before the meeting itself. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/ Hi, I would like to get ACCEPT_LICENSE default value [1] discussed in the next Council. If I can even get it widely discussed in gentoo-dev before the council, a vote will be great. But it looks like it is not interesting so much people out there. [1] http://archives.gentoo.org/gentoo-dev/msg_d5c1e7285399ebc27a74bdd02cb4d037.xml Mounir
Re: [gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)
Ciaran McCreesh wrote: On Fri, 29 May 2009 19:17:03 +0200 Mounir Lamouri volk...@gentoo.org wrote: Most of GLEP 23 features have already been implemented in portage. Some since a long time (at least in stable portage) like multiple licenses and conditional licenses. License group and ACCEPT_LICENSE is already implemented in portage 2.2 (masked). The main show-stopper for this last time it came up was all those X packages using their package name as a licence. Have you thought of how to get that glaring QA issue addressed? That's a very bad issue I never heard about before. I would say there is the easy workaround: we fix ACCEPT_LICENSE=* -...@eula and this issue will never pop with a default configuration. But I don't like it because anyone setting ACCEPT_LICENSE to anything will stuck in in. So, why not creating a Generic-Free-License that could be set for packages with no clear/clean license but still free. The con of this solution is we will surely lost some information because we can set LICENSE=Generic-Free-License or LICENSE=|| ( Generic-Free-License MyCreepyLicense ) because we need to have at least LICENSE=Generic-Free-License. I see no other options. If anyone has an idea or suggestion... Mounir
Re: [gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)
Ciaran McCreesh wrote: On Mon, 01 Jun 2009 23:01:04 +0200 Mounir Lamouri volk...@gentoo.org wrote: The main show-stopper for this last time it came up was all those X packages using their package name as a licence. Have you thought of how to get that glaring QA issue addressed? That's a very bad issue I never heard about before. I see no other options. If anyone has an idea or suggestion... Honestly, I suggest you find some poor sucker to do what the xorg team should have done two years ago. It's a fair bit of work to fix all the licences, but it's the best long term solution. Perhaps you could ask the Council to see if they could nominate it as a special priority project and encourage every developer to fix one package. I agree it's the best long term solution but I've the feeling this is going to take a very long time. This feature (ACCEPT_LICENSE) is important to remove check_license() call from ebuilds which need user input while merging. Interaction in ebuild should be avoided and it is a blocker for a fully functional portage backend for packagekit (my gsoc project). Maybe cleaning licenses should be done before making this feature available/mandatory but we should avoid creating a never-ending task. Mounir
Re: [gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)
Richard Freeman wrote: Mounir Lamouri wrote: It looks like some licenses need acceptance. I prefer the wording: some software vendors claim that their licenses must be accepted to use the software. I'm not aware of any law which requires a license to use software - at least not inside the USA (your jurisdiction may vary). I'm not a lawyer so I can't say for sure some software _need_ explicit license acceptance to be used. However, I'm quite sure using a software means accept the license. Someone experienced in this area is welcome for clarifications. A license is certainly required to distribute software - hence RESTRICT=mirror or USE=bindist. Users typically do not distribute software, therefore users typically do not need a license to use it. I think this vision is too simple. Some licenses add rules and rights users should know. Some applications can use your personal data (like picasa) or forbid you to try to do reverse engineering even if authorized in your country (can't remember name). So, even if most users don't care, we should at least help them know. Because, at the moment, I can install something with a license saying i can use personal data you put in this app without even have a clue. Frankly, I'd like to see ACCEPT_LICENSE=* be the default. If some are concerned about the legal issues then have the default be ACCEPT_LICENSE = * -...@eula and let users trim it down to * on their own. Portage should not set arbitrary restrictions on preventing accepting *. I'd definitely like the default to be that packages are accepted unless a dev somehow indicates otherwise. The overwhelming majority of packages out there do not have EULA issues. Keep in mind that licensing is a legal issue, and legal issues are determined by the law, and the law is determined by where you live. If a user lives in a country that says you can sell Windows CD-Rs at a Lemonade stand, it isn't the job of Gentoo to step in and tell them otherwise. We want to give users the tools they need to help stay compliant with the laws that govern them - we don't want to assume the responsibility for their compliance. Sure, licensing is somewhat linked with where you live but I don't think that's helping your point. By auto-enabling only a set of licenses we can be sure at 99% users will be safe. By auto-enabling everything, we can put our users in an illegal situation where he is living. Better to be a little bit restrictive than too comprehensive. I think except for flash plugin and graphic drivers our users will not be too annoyed by a restrictive ACCEPT_LICENSE. There is only a few app widely use on GNU/Linux which aren't free. I can only see Skype. And maybe it will help users to think about alternatives before using proprietary software. Mounir
[gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)
Hi, In the context of my GSOC [1] I need to get GLEP 23 [2] fully implemented and this means get ACCEPT_LICENSE used with a default value and bug 152593 [3] fixed. = GLEP 23 summary = Most of GLEP 23 features have already been implemented in portage. Some since a long time (at least in stable portage) like multiple licenses and conditional licenses. License group and ACCEPT_LICENSE is already implemented in portage 2.2 (masked). = ACCEPT_LICENSE = Please, have a look at GLEP 23 [2] and read how ACCEPT_LICENSE and license groups work (it's the main topic). I will repeat some things above but not everything. ACCEPT_LICENSE, as ACCEPT_KEYWORDS, will mask/unmask packages based on the license. User will explicitely know why the package is masked and which license to accept to have it unmasked. The path of the license is showed to incite him read it. This feature should help bug 152593 [3] because if he accepts the license, we can assume he known what he was doing (ie. we can assume he read the license) but we will see that in the last part. = ACCEPT_LICENSE default value = The ACCEPT_LICENSE default value will impact users, devs and Gentoo. Users: ebuilds will be masked if their license(s) is(are) not in ACCEPT_LICENSE Devs: they will have to maintain license groups and if a specific group is allowed by default (or not allowed by default) they will have to make sure new ebuilds are correctly (un)masked. Gentoo: we can consider (at least I) that such a value is important and linked to our social contract. Are we going to support FSF approved licenses ? OSI approved ? both ? union of them ? or event more licenses ? This decision is probably more than only user/dev issue. There are two ways to see the default value: set it to a set of groups which will allow automatically a set of licenses or set it to everything excluding a set of groups. In other words: accept_licen...@approved or ACCEPT_LICENSE=* -...@need_to_be_accepted That's a main difference because if not checked, an ebuild will be automatically masked for license in the first way and automatically unmasked in the second. There are some proposition of ACCEPT_LICENSE values for both ways. * accept_licen...@non_eula With this value, every license that is not an EULA will have to be in @NON_EULA group to let the ebuild available. PRO: easy for user, except for a few licenses, he will never notice this new feature. CON: difficult to maintain for devs: @NON_EULA will be big and you will have to think about adding a license to @NON_EULA when pushing it to the tree. * ACCEPT_LICENSE=* -...@eula That's actually the unique reason to use the second way (ie. all licenses accepted except some): masks all EULA. For the user, it's exactly the same if everything is done correctly by devs but if the dev forget to add a license to the right group, consequences will be different. With this default value, the package will be unmasked by default. In my opinion, the previous default value proposition is in all ways better than this one. It's probably better to have a forgotten license masked than unmasked because users will surely complain/file a bug if the package is masked. * accept_licen...@gentoo_approved @GENTOO_APPROVED will be a group of approved licenses. It will be different from NON_EULA as it could be a more restrictive set of licenses like a combination between @FSF_APPROVED and @OSI_APPROVED. In other words, what general people call free software. According to our social contract [4] we support free software and want Gentoo related work to be licensed in OSI approved license. And still according to this page, someone (who ?) is thinking about restrict Gentoo related work to OSI approved _and_ FSF approved licenses. Why not set ACCEPT_LICENSE to this same licenses ? It will be more consistent with our social contract. PRO: more consistent with social contract less work for dev than accept_licen...@non_eula as we can suppose @OSI_APPROVED and/or @FSF_APPROVED will not change often CON: users will probably have more masked packages because of licenses [5] = About licenses which needs explicit acceptance = This is not the main topic, but it could be interesting to have your opinions. It looks like some licenses need acceptance. I was thinking using a software means accepting the license. If we really need to make a user accept a license, printing the license path is enough ? He still can add the license name in ACCEPT_LICENSE without even reading it. However, I suppose adding the license name will be enough for an approval. This leads me to think ACCEPT_LICENSE=* should be forbidden. The point of this message is to get opinions of devs to reach a consensus then have this default value approved by the Council. So, what's your opinion ? [1] My GSOC is about writing a portage's backend for PackageKit. I will try to send a message about it in the next days. [2] http://www.gentoo.org/proj/en/glep/glep-0023.html [3]
Re: [gentoo-dev] rfc: Accessibility on our release media
William Hubbs wrote: [snip] My question for the group is, how do you feel about speech software being on our minimal cd as well as our live cd? I agree, it should be in our minimal and live CD's. There is no reason to consider blind persons out of the minimal CD. Mounir
[gentoo-dev] DESCRIPTION size
Hi, According to devmanunal [1], DESCRIPTION should be 80 characters max but according to repoman, DESCRIPTION should be 100 characters max. I'm confused, who should I believe ? :) [1] http://devmanual.gentoo.org/ebuild-writing/variables/index.html Thanks, Mounir
Re: [gentoo-dev] DESCRIPTION size
Ulrich Mueller wrote: The devmanual also says Where possible, try to keep lines no wider than 80 positions. which would limit DESCRIPTION to 66 characters. These are guidelines, not strict rules. Keep it shorter if it's reasonably possible. Even guidelines should be consistent. If devmanual recommand 80 and repoman 100, in my opinion, someone is wrong. repoman should recommand 80 or devmanual should recommand 100. That's surely not a major issue even far from that but having some consistency in those guidelines is a minimum. IMHO, repoman should be updated to 80. Mounir
Re: [gentoo-dev] license issue with fretsonfire
Arun Raghavan wrote: On Sat, 2009-05-02 at 18:17 +0200, Mounir Lamouri wrote: [...] I think the code can be considered GPL-2 (i will check if there is no header specifying something else) and for the fonts, I will have to add 2 licenses not in the tree at the moment. But what to do with the songs ? I suppose it's not the first GPL game having non very clear license about data. How games team is managing that ? The fonts license seems to be the same as licenses/BitstreamVera which is in-tree. As for the songs, does it make sense to put that in a separate package that the code package depends on? The package can have the restrictive license it is distributed under and RESTRICT=mirror bindist. -- Arun I've contacted upstream and I sent me the Debian bug [1] about fretsonfire. They suffered from similar issues. To solve fonts issue, I think we can fix that like Debian: using other fonts. We can even using the same ones. To solve the songs issue, I see two solutions: 1. removing songs from the tarball (should we do/mirror a new tarball ?) and adding packages with free songs (Debian's solution) 2. using RESTRICT=mirror bindist as Arun proposed (btw, is bindist really for binary because it's in python so there is no binary) I don't know if we can solve the song issue with a separated package. Because this songs are following the Toesto (Finish organization to protect artists work iirc) rules they must be bundled with the game. We probably should do the same. Or maybe RESTRICT=fetch can solve this ? I think the real issue with the songs is there is no real license linked with it except you can't do anything with them except listening to. I think even with the most restrictive parameters, we can't deal with that. Am I right ? I think the most secure way for Gentoo is to do as Debian is doing. May be even using Debian's package. I would appreciate some help/advice here as I'm not a lawyer :) [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=383316 Thanks, Mounir
Re: [gentoo-dev] Passing arguments to eqmake3
Nikos Chantziaras wrote:
I have a package that uses qmake (from Qt 3) as its build system and
that installs into /usr/local by default (as any well packaged
software should do). This of course can be overridden at build time.
In this case, with:
qmake PREFIX=/usr projectfile.pro
In order to install into /usr (as any well written ebuild should do.)
In the ebuild however, eqmake3 doesn't seem to accept any arguments.
This:
eqmake3 PREFIX=/usr projectfile.pro | die qmake failed
results in:
* Project .pro file PREFIX=/usr does not exists
* qmake cannot handle non-existing .pro files
when trying to emerge. What can I do?
eqmake is taking arguments but you have to set the .pro file first like:
eqmake3 projectfile.pro PREFIX=/usr || die eqmake3 failed
By the way, you may want to set PREFIX=${D}/usr
Thanks,
Mounir
Re: [gentoo-dev] New global USE flag: gsm
Mounir Lamouri wrote: Description : Adds support for the gsm lossy speech compression codec Alternative description : Adds support for the gsm lossy speech compression codec (via media-sound/gsm) This use flag is used by: media-libs/gst-plugins-bad media-libs/mediastreamer media-plugins/gst-plugins-farsight media-video/ffmpeg net-im/ekg2 net-irc/kvirc net-voip/linphone net-voip/yate net-misc/xsupplicant net-wireless/wpa_supplicant For a total of 10. But only 8 are really using the global description. The 2 last ones are using gsm use flag to enable an authentication algorithm. I've just fixed bug 254677 [1] who was blocking gsm USE flag globalization. This means xsupplicant and wpa_supplicant are now using eap-sim instead of gsm USE flag. We now have 8 packages using the USE flag for the same purpose. So, I will wait a few days for hypothetical disagreement and I will do the change. [1] http://bugs.gentoo.org/show_bug.cgi?id=254677 Thanks, Mounir
Re: [gentoo-dev] license issue with fretsonfire
Arun Raghavan wrote: The fonts license seems to be the same as licenses/BitstreamVera which is in-tree. One of them, yes. But the two others fonts license are more difficult to get. As for the songs, does it make sense to put that in a separate package that the code package depends on? The package can have the restrictive license it is distributed under and RESTRICT=mirror bindist. Yes, I can do a fretsonfire package and a fretsonfire-data package like nwn. It makes sense for licensing but it will force us to mirror self-splitted packages. But even if doing that, what will be the LICENSE for fretsonfire-data ? Distribution, modification or commercial usage of the songs is not allowed is not really a license ;) (and I will have to add the 3 fonts license with 2 unknown) By the way, I have contacted upstream about this issue and I didn't get any answer. For information, copying file is here : http://dev.gentoo.org/~volkmar/fretsonfire_copying.txt Thanks, Mounir
Re: [gentoo-dev] Retiring
Markos Chandras wrote: On Tuesday 05 May 2009 19:26:23 Sergio D. Rodríguez Inclan wrote: Could be a good idea publish a status of each Gentoo project and see what is needed, so the users/devs can offer some help. [snip] Some one could say Post it on gentoo.org homepage. I wonder if users ever visit that page to read gentoo news :\ There is already such a place [1] but I think not so much people knows about it. [1] http://www.gentoo.org/proj/en/devrel/staffing-needs/ Mounir
Re: [gentoo-dev] Re: Training points for users interested in helping out with ebuild development
George Prowse wrote: I think you are missing the point. If you sit and wait for them to join you will always be understaffed. Go on a big dev drive! Announce it all over all the Gentoo's normal communication channels and other generic linux places! Email some linux magazines, talk to distrowatch, message some large LUGs. Get people talking about it. Whatever happens, dont just sit on your hands. Tell the users that Gentoo needs them and that they can make a difference! If you make it a big and special occasion which is planned correctly with a sufficient number of current developers who are willing to walk people through how and what it means to be a Gentoo Developer then the influx could create a new backbone of new developers who will hopefully be here for years to come. I agree with you. Gentoo is not doing enough publicity on needed help (I sincerely think the related page in gentoo.org is out of date) and we can read too often in gentoo.org recruitment pages that user should not ask and should wait to be asking. I'm not sure most devs are looking to users as potential new devs. It's clearly not a good recruitment policy. Maybe when we are full staffed but surely not when we are understaffed like it looks like. An active recruitment policy like a recruitment campaign should be very positive and I would be glad to help with that. Regards, Mounir
[gentoo-dev] license issue with fretsonfire
Hi, I was going to put frets on fire into the tree when I realized the license of this game [1] is not very easy to get. The source code is GPL-2 (with this note some source files derived from other sources might have differing licenses.), 3 fonts files have specific licenses and the songs follow this rule Distribution, modification or commercial usage of the songs is not allowed.. I think the code can be considered GPL-2 (i will check if there is no header specifying something else) and for the fonts, I will have to add 2 licenses not in the tree at the moment. But what to do with the songs ? I suppose it's not the first GPL game having non very clear license about data. How games team is managing that ? [1] http://dev.gentoo.org/~volkmar/fretsonfire_copying.txt Thanks, Mounir
[gentoo-dev] New global USE flag: gsm
Description : Adds support for the gsm lossy speech compression codec Alternative description : Adds support for the gsm lossy speech compression codec (via media-sound/gsm) This use flag is used by: media-libs/gst-plugins-bad media-libs/mediastreamer media-plugins/gst-plugins-farsight media-video/ffmpeg net-im/ekg2 net-irc/kvirc net-voip/linphone net-voip/yate net-misc/xsupplicant net-wireless/wpa_supplicant For a total of 10. But only 8 are really using the global description. The 2 last ones are using gsm use flag to enable an authentication algorithm. If no one disagree I will add it in a few days / a week. Thanks, Mounir
Re: [gentoo-dev] New global USE flag: gsm
Mounir Lamouri wrote: [snip] net-misc/xsupplicant net-wireless/wpa_supplicant [snip] The 2 last ones are using gsm use flag to enable an authentication algorithm. Will the mobile herd agree to change the 'gsm' USE flag of wpa_supplicant and xsupplicant from 'gsm' to 'gsm-auth' or 'eap-sim' (or global 'smartcard') ? Thanks, Mounir
[gentoo-dev] Last rites: net-im/tapiocad, net-im/tapioca-xmpp, net-im/tapiocaui
# Mounir Lamouri volk...@gentoo.org (22 Apr 2009) # Masked for removal in 60 days. See bug 248008. # Tapioca is unmaintained and they are officially abandoned subprojects. # In addition, tapioca-xmpp has been superseeded by telepathy-gabble. net-im/tapiocad net-im/tapioca-xmpp net-im/tapiocaui
[gentoo-dev] Last rites: net-libs/zapata
# Mounir Lamouri volk...@gentoo.org (08 Apr 2009) # This lib is not used by any package and it doesn't work on amd64 # Upstream doesn't maintain this package anymore # See bug 180757. Masked for removal in 30 days net-libs/zapata
Re: [gentoo-dev] EAPI 3's default src_install needs bikeshedding
Daniel Pielmeier wrote:
Ciaran McCreesh schrieb am 30.03.2009 18:43:
On Mon, 30 Mar 2009 18:33:48 +0200
Thomas Sachau to...@gentoo.org wrote:
else
for x in AUTHORS ChangeLog NEWS README; do
if [ -e ${x} ]; then
Is -e really better than -s?
I think -s should be used here. I have seen projects out there which
don't use the mandatory autotools files (INSTALL, NEWS, README, AUTHORS,
ChangeLog, COPYING) at all or use other files than these. So they just
place an empty file there to make automake happy instead of using the
--foreign option. Besides that it makes no sense to install empty
documentation files at all.
portage don't install empty files (they are ignored) so it would be
painless.
Mounir
Re: [gentoo-dev] please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
On Sun, Mar 22, 2009 at 1:18 PM, Ulrich Mueller u...@gentoo.org wrote:
On Sun, 22 Mar 2009, mrness wrote:
Please do not apply patches that have ${P} prefix in other ebuild
versions than ${PV}.
Is that hard to create a new patch with a proper name?
And multiply number and total size of files in ${FILESDIR}?
Ulrich
Or just rename it ${PN}-bar.patch instead of ${P}-bar.patch if it is a
patch for more than one ebuild version.
But older ebuild has to be changed to make it works.
Mounir
Re: [gentoo-dev] Should that file be a License ?
On Mon, Feb 23, 2009 at 10:44 AM, Marijn Schouten (hkBst)
hk...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mounir Lamouri wrote:
Hi,
I was writing a trivial version bump for net-voip/gnugk-2.2.8 (bug
#258518) but upstream added a file named p2pnat_license.txt (see
http://dpaste.com/123376/) This file looks to authorize gnugk project
(and users) to use p2pnat technology. gnugk is already licensed under
GPL-2 and I was wondering if this new file should be considered as
another license and if it has to be in the LICENSE line ? In this case,
should the file be added like he is in the gnugk tarball or should it be
templatized like most licenses ?
Thanks,
Mounir
That paste is gone/expired.
Marijn
- --
Sarcasm puts the iron in irony, cynicism the steel.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmixHYACgkQp/VmCx0OL2wURgCff8WSLE9PHXfO/HI+GdrE1W3J
0/kAoLpB4oFEwOx5Dk+ceo70vCueZgbk
=hKRC
-END PGP SIGNATURE-
I attached it to this email.
Mounir
P2Pnat Technology license (H.460.23/24)
In relation to any work derived from the Point to Point through NAT
Specification
(P2Pnat Technology), International Secure Virtual offices (Asia) Pte Ltd
ISVO
(together with his successors and assignees) will grant a royalty-free,
non-exclusive license with reciprocity to Qualified Parties to use the P2Pnat
Technology
solely to the extent necessary to implement and practice such as in compliance
with the
P2Pnat Specification. As used herein, Qualified Parties means a party who has
not,
does not and will not assert, in litigation or otherwise, including in
licensing discussions,
any patent or other intellectual property right against ISVO of any nature. Any
license to
a Qualified Party shall terminate at once if such party: (a) asserts a patent
or other
intellectual property right against ISVO as set forth above; or (b) if
applicable,
fails to properly implement the disclosure flag described in the P2Pnat
Specification
in a truthful manner. This license also extends to cover users and furthur
development
of the licensee's implementation only as far as the use does not violate the
licensee's
own licensing terms and conditions, where apon a user is in breach of the
licensee's license
then they shall be deemed to be breach of this license. ISVO will grant
non-exclusive licenses
to Non-Qualified Parties on reasonable and reciprocal terms and conditions.
The GnuGk project (www.gnugk.org) is hereby granted non-exclusive royalty-free
license of
Point to Point through NAT (P2Pnat Technology) to be used with the GnuGk
project.
Users and developers of GnuGk are hereby also granted non-exclusive
royalty-free license of
P2Pnat Technology as long as the use of GnuGk and/or any derived work
containing this technology
is used and/or issued under the same terms and conditions as the GnuGk project.
Failure to comply
with the GnuGk license shall automatically be deemed a violation of this
license.
[gentoo-dev] Should that file be a License ?
Hi, I was writing a trivial version bump for net-voip/gnugk-2.2.8 (bug #258518) but upstream added a file named p2pnat_license.txt (see http://dpaste.com/123376/) This file looks to authorize gnugk project (and users) to use p2pnat technology. gnugk is already licensed under GPL-2 and I was wondering if this new file should be considered as another license and if it has to be in the LICENSE line ? In this case, should the file be added like he is in the gnugk tarball or should it be templatized like most licenses ? Thanks, Mounir
