gmane.linux.gentoo.devel

License Interpretation

Jim Ramsay — 2008-08-20T19:10:18

IANAL, and I'm sure most of us aren't either, but I would appreciate some opinions on Bug https://bugs.gentoo.org/234542 and whether the binary patch proposed there conflicts with section 2.5.1 of the license agreement from Adobe: http://www.adobe.com/products/eulas/pdfs/Reader_Player_WWEULA-Combined-20060724_1430.pdf Specifically, here is the passage I'm wondering about: 2.5.1 You may not modify, adapt, translate or create derivative works based upon the Software. You may not reverse engineer, decompile, disassemble or otherwise attempt to discover the source code of the Software except to the extent you may be expressly permitted to decompile under applicable law, it is essential to do so in order to achieve operability of the Software with another software program, and you have first requested Adobe to provide the information necessary to achieve such operability and Adobe has not made such information available. I *think* I would be okay using this binary patch since: 1) This is specifically to mak

media-fonts/droid licensing: should fonts include Apache licensein tarball?

Peter Volkov — 2008-08-19T13:25:42

Hello. There are droid fonts package in the tree. Author states that they are apache licensed [1] (supposedly similar to google's android sdk) but license itself is not included in the package (only .ttf files are there). Should we RESTRICT="mirror" in such case or it's safe to drop such restriction? [1] http://damieng.com/blog/2007/11/14/droid-sans-mono-great-coding-font Thank you for any hints,

gnat-gpl-2008 has been SLOTted differently from -2008

George Shapovalov — 2008-08-19T12:13:14

Hi All. I have some information for those of you using Ada on this list (it appears there are quite a few, so, please drop those "all two people using.." jokes ;)). I have found that the recently released -2008 version has some "incompatible bugs" with the -2007 version (NB: this is gnat-gpl, the ACT varian), which, in itself, is rather usial. However, this time these bugs directly affect one of the Ada libs in the tree - qtada, prohibitimg me from releasing a new version (the qtada-1.0.4 still requires precisely gnat-gpl-2007, hopefully qtada-1.1 will be less picky, but I haven't tested it yet). Considering also, that many of you might want to test the latest ADA-2005 features but may very well have some projects similarly sensitive to these bugs, I decided to SLOT gnat-gpl-2008 differently from the -2007 version (they were in the same SLOT, as they both use the same gcc backend version). Now, the -2008 version has SLOT="4.1-2008" while the -2007 one simply "4.1" (not that this precise value

Packages up for grabs

Tony "Chainsaw" Vroon — 2008-08-18T15:18:53

Good afternoon fellow developers, There are three ebuilds that I used to maintain that I no longer have the hardware for. I'm hoping that one of you could give them some love. Do assign the bugs to yourself, and please drop me from the relevant metadata.xml once you do. They are: media-video/nvidia-settings x11-drivers/nvidia-drivers sys-auth/thinkfinger I used to have a Fujitsu-Siemens Lifebook E8410-nVidia with a 8400M G, but have switched to a Lifebook S6410 that has Intel graphics. Previous to said Lifebooks, I used to own a ThinkPad X41. While my new laptops have a fingerprint scanner, it is not of the type that thinkfinger prefers. Regards, Tony V. (Chainsaw)

[RFC] Add support for package.keywords in profiles?

Zac Medico — 2008-08-18T00:24:10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone, At least a few people have expressed a desire to have support for a package.keywords file in the profiles [1] as a means to add or subtract any number values to or from the KEYWORDS that apply to a given ebuild. This would allow a specific profile to alter which packages are visible to consumers of a given keyword. This is useful for profiles that differ from other profiles in some significant way despite sharing the same values for stable and unstable keywords. For example, embedded profiles which use uclibc instead of glibc. An alternative solution for some cases might be to introduce additional keywords values, such as those suggested in GLEP 22 [2]. However, the package.keywords approach may provide greater simplicity and flexibility which would allow it to serve as a solution for a larger number of use cases. For example, the uclibc profiles would not have to maintain separate keywords for every single package. Since older versions of portag

Automated Package Removal and Addition Tracker, for the week ending 2008-08-17 23h59 UTC

Robin H. Johnson — 2008-08-18T00:15:02

The attached list notes all of the packages that were added or removed from the tree, for the week ending 2008-08-17 23h59 UTC. Removals: games-arcade/blobwars 2008-08-16 20:31:23mr_bones_ games-arcade/project-starfighter2008-08-16 20:31:24mr_bones_ games-action/blobandconquer 2008-08-16 20:32:41mr_bones_ games-arcade/viruskiller 2008-08-16 22:32:38mr_bones_ Additions: profiles/default/linux/alpha 2008-08-11 17:14:10armin76 dev-tex/sketch 2008-08-12 17:30:57aballier media-plugins/vdr-bgprocess 2008-08-14 19:45:23zzam app-misc/gourmet 2008-08-15 03:09:28nixphoeni dev-libs/faxpp 2008-08-15 06:46:20dev-zero sys-fs/s3fs 2008-08-15 12:30:33caleb app-misc/beanstalkd 2008-08-15 21:24:34caleb sys-libs/e2fsprogs-libs 2008-08-16 04:42:13vapier media-libs/libpano13 2008-08-16 10:58:41maekke media-gfx/autopano-sift-C 2008-08-16 11:07:16maekke dev-python/pycou

News item: World file handling changes in Portage-2.2

Petteri Räty — 2008-08-16T19:39:41

As per glep 42 (http://www.gentoo.org/proj/en/glep/glep-0042.html) here is the required email for a new news item. This news item is important because otherwise users will be missing updates to the system set if they continue updating their system with the usual emerge --update --deep world. Unless objections come out the new news item will be committed at the same time as rc8 (rc8 will have an update man portage page describing world_sets). Title: World file handling changes in Portage-2.2 Author: Petteri Räty gentoo.org> Author: Zac Medico gentoo.org> Content-Type: text/plain Posted: 2008-XX-XX Revision: 1 News-Item-Format: 1.0 Display-If-Installed: >sys-apps/portage-2.2_rc8 As of Portage 2.2 the world set does not include the system set any more. If you want emerge --update --deep < at >world to update the system set too, you need to add < at >system to the new world_sets file in /var/lib/portage/. For more information on world_sets see man portage.

unwanted CVS keyword substitution on patch files

Alin Năstac — 2008-08-16T10:26:50

Every once in a while, I get bitten by the $Id keyword replacement done on patches in $FILESDIR. Can we do something to fix this annoyance? If repoman cannot add -kb for *.patch and *.diff files, at least it should verify you have added those files with this options.

Suggestion: remove app-office/borg from portage.

Aniruddha — 2008-08-16T07:17:10

Hi, Borg hasn't been updated in portage for a while despite the fact that new versions were released over a year ago (see http://bugs.gentoo.org/show_bug.cgi?id=184699 ). Therefor I suggest app-office/borg gets removed from portage. Regards, Aniruddha

imlib/imlib2 useflag inconsistency

Benedikt Morbach — 2008-08-14T19:56:16

app-office/magicpoint/magicpoint-1.12a-r1.ebuild app-office/magicpoint/magicpoint-1.13a.ebuild kde-base/kdegraphics/kdegraphics-3.5.9.ebuild media-gfx/gimageview/gimageview-0.2.27-r2.ebuild www-client/w3mmee/w3mmee-0.3.2_p24-r4.ebuild www-client/w3mmee/w3mmee-0.3.2_p24-r5.ebuild www-client/w3mmee/w3mmee-0.3.2_p24-r6.ebuild x11-misc/wmakerconf/wmakerconf-2.11.ebuild x11-terms/mlterm/mlterm-2.9.3-r1.ebuild x11-terms/mlterm/mlterm-2.9.4.ebuild x11-terms/mlterm/mlterm-2.9.4-r1.ebuild x11-wm/fvwm/fvwm-2.5.18-r1.ebuild x11-wm/fvwm/fvwm-2.5.19.ebuild x11-wm/fvwm/fvwm-2.5.21.ebuild x11-wm/fvwm/fvwm-2.5.25.ebuild x11-wm/fvwm/fvwm-2.5.26.ebuild x11-wm/icewm/icewm-1.2.30.ebuild x11-wm/icewm/icewm-1.2.30-r1.ebuild x11-wm/icewm/icewm-1.2.32.ebuild x11-wm/icewm/icewm-1.2.33.ebuild x11-wm/icewm/icewm-1.2.34.ebuild x11-wm/icewm/icewm-1.2.35.ebuild app-office/texmacs/texmacs-1.0.6.14.ebuild dev-libs/DirectFB-extra/DirectFB-extra-0.9.25.ebuild dev-libs/DirectFB-extra/DirectFB-extra-1.0.0.ebuild dev-libs/DirectFB-extra/DirectF

The Plethora of Patches

Andrew D Kirch — 2008-08-14T02:17:12

It has become abundantly clear that distribution maintainers should have as few patches as possible. Patches waste time due to duplicate work, resources (portage disk space and bandwidth), and as the Debian project recently found out after a major vulnerability was discovered in the OpenSSH packages (see http://www.milw0rm.com/exploits/6094, and http://www.securityfocus.com/bid/30276 among others), they can become a source of great embarrassment, and liability since they are not nearly so well audited as code in heavily used mainstream projects (an unintentional Cathedral if you will). I therefore propose the following changes: Patches in the metadata.xml should have some sort of status tracking for each patch, repoman should flag any that don't, and warn on any that have not been submitted upstream unless the status is signed off on by a herd leader (such as Gentoo specific patches). This would provide visual feedback for users and developers with regard to a pretty important metric on how

[GLEP 56] metadata.xml USE flag descriptions [Clarifications]

Doug Goldstein — 2008-08-13T17:11:35

Howdy all, Further questions regarding use.desc have come up with regard to this GLEP. My proposed solution would be a potential amendment to the GLEP to state that Would be allowed. This syntax is not actually disallowed or allowed by the current GLEP, but mentioning it would allow a metadata.xml contain all the USE flags that appear in IUSE, even the global ones. By using the above syntax, it would simply state that there is no additional descriptions or details but to just use the use.desc description. Further more, it would allow us in the future to make that mandatory and repoman would only have to check metadata.xml for your USE flag. Comments, Suggestions, Input are all welcome. -- Doug Goldstein Gentoo Developer

[RFC] What features should be included in EAPI 2?

Zac Medico — 2008-08-13T08:18:33

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello again, I'd like to get some feedback about what people would like to have in the final EAPI 2. In planning for this EAPI bump, we should strike a balance somewhere in between everything that we'd like to have and whatever we can implement in a short period of time. It doesn't really makes sense to delay the EAPI bump too much for implementation of new features, since those features can simply be reserved for a future EAPI bump. The latest experiment EAPI is 2_pre2, supported by [1] for addition information about the experimental EAPI extensions which are summarized here: * The 'doman' helper function recognizes language codes in man page source files, and uses them to generate an appropriate installation path. * Dependency atoms can be constrained to match specific USE flag states, including USE conditional expressions embedded within the atoms themselves. * The old src_compile phase function is split into separate src_configure and

One-Day Gentoo Council Reminder for August

Mike Frysinger — 2008-08-13T03:01:45

This is your one-day friendly reminder ! The monthly Gentoo Council meeting is tomorrow in #gentoo-council on irc.freenode.net. See the channel topic for the exact time (but it's probably 2000 UTC). If you're supposed to show up, please show up. If you're not supposed to show up, then show up anyways and watch your Council monkeys dance for you. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/

[RFC] Should we introduce PROPERTIES into the ebuild metadata cache on the rsync mirrors?

Zac Medico — 2008-08-13T00:01:40

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone, Please consider the introduction of a new "PROPERTIES" variable to the ebuild metadata cache that's distributed via the rsync mirrors and resides locally in the ${PORTDIR}/metadata/cache/ directory. This variable is intended to have identical syntax to the existing RESTRICT variable, including support for the USE conditional syntax that is also supported by the LICENSE, PROVIDE, SRC_URI, and *DEPEND variables. The idea to introduce the PROPERTIES variable arose from discussion about the introduction of a new RESTRICT value [1]. By using a new PROPERTIES variable instead of the existing RESTRICT variable, we will have two separate categories of boolean attributes. This will be useful since some boolean attributes, such as "primaruri" and "live-sources", have an inverted nomenclature when compared to the other boolean attributes that currently exist within the RESTRICT set, show here: binchecks - Disable all QA checks for binaries. bindist

best way to use profiles and package.use.mask?

Steve Dibb — 2008-08-12T18:00:17

Okay, this is something that I've wondered about for a while, but need to ask -- what is the best way (do we even have a policy) for using package.use.mask in profiles? A couple of specific questions: If I need to mask a use flag because of use flag dependencies that won't work on a particular arch, do I need to contact the arch teams to modify their package.use.mask profile? If the answer is yes, I can see that as a huge blocker since I'd have to wait on the arches to do something before I can even put an ebuild in the tree. I realize this is a per-arch question depending on how each one might respond, but a common consensus would be good. Are there ever any cases where we could just simply put the use flag as restricted in the global package.use.mask and then unrestrict them in the profiles ones if, for example, it only worked on one or a few arches? Or is the best policy always to mask it on each profile? As for a specific example, mplayer's dxr2/dxr3 use flag now pulls in a dependency

Last rites: dev-python/twisted-{pair, xish, flow} anddev-python/twibber (Removal due 11 October 2008)

Jesus Rivero — 2008-08-12T03:49:58

The following packages have been masked for removal in 30 days. dev-python/twisted-xish dev-python/twisted-pair dev-python/twisted-flow They are either unmaintained or deprecated and they force downgrade on the newly stable dev-python/twisted*-8.1.0 dev-python/twibber is also unmaintained and depends on twisted-xish that is to be removed. See bug #231675 for reference. Best regards, Jesus Rivero

Unmasking of qt 4.4?

Hanno Böck — 2008-08-11T15:26:07

Hi, I'm maintaining a package of merkaartor in gentoo, of which the latest version requires qt 4.4. I'll mask that for now, but I'm not really happy with that. I wanted to ask what are the showstoppers for qt 4.4 to get unmasked. The mask is commented with: "Masked for testing, various dependencies still need to be updated..." I don't like "masked for testing" comments (we have far to many of them), as it basically tells nothing. Testing what? How long? For the dependencies, I think this isn't a showstopper either, as if you don't have split dependencies on qt, it'll just take the metapackage and everything is like before. So question, what are the showstoppers for qt 4.4? And more general comment, especially on important packages that many people rely on, please provide more informative comments in package mask, e.g. bug numbers.

Automated Package Removal and Addition Tracker, for the week ending 2008-08-10 23h59 UTC

Robin H. Johnson — 2008-08-11T00:15:01

The attached list notes all of the packages that were added or removed from the tree, for the week ending 2008-08-10 23h59 UTC. Removals: www-apps/knowledgetree 2008-08-09 21:22:58hoffie dev-php4/ZendOptimizer 2008-08-09 21:53:34robbat2 dev-php4/adodb-ext 2008-08-09 21:53:34robbat2 dev-php4/creole 2008-08-09 21:53:35robbat2 dev-php4/eaccelerator 2008-08-09 21:53:36robbat2 dev-php4/ffmpeg-php 2008-08-09 21:53:36robbat2 dev-php4/jargon 2008-08-09 21:53:37robbat2 dev-php4/jpgraph 2008-08-09 21:53:38robbat2 dev-php4/pecl-apc 2008-08-09 21:53:38robbat2 dev-php4/pecl-crack 2008-08-09 21:53:39robbat2 dev-php4/pecl-fileinfo 2008-08-09 21:53:41robbat2 dev-php4/pecl-http 2008-08-09 21:53:41robbat2 dev-php4/pecl-id3 2008-08-09 21:53

Retirement

Ingmar Vanhassel — 2008-08-10T20:56:40

Hello list, As usual with this kind of mails, this has been long overdue, but it's about time that I retire from Gentoo. For a while Gentoo hasn't been going into a direction I like, and to me it doesn't look like that's about to change any time soon. Despite attempts to convince me of the contrary, I'm not sure I see the technical advancements that I'd like happening, in Gentoo. That aside there're numerous non-technical problems behind the scenes, that most devs probably acknowledge by now... There're other projects in the Free-Software world that I currently enjoy putting my time into more, I'm sure it's more than obvious to those of you who know me which... So long, Ingmar Vanhassel, ex-Gentoo KDE developer.

Retirement

Bo Ørsted Andresen — 2008-08-10T22:26:58

My retirement is probably long overdue as I haven't really been active for several months. It is now clear to me that Gentoo is not moving in the direction I had wished for and the last council election indicates that most current Gentoo developers appear to be satisfied with this current direction. Therefore farewell. If anybody wants to reach me I can be reached at bo.andresen at zlin.dk.