[gentoo-dev] Hackontest
Hi, I added the Gentoo project to Hackontest (for more information, visit http://hackontest.org/) . Developers and users are invited to add feature requests for Gentoo (preferably with links to bugzilla :-)). Hopefully, some of us developers can get together and implement them at the Hackontest - September this year, at Zurich. Regards, Anant -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: New developer : Markus Duft (mduft)
On Wed, Apr 30, 2008 at 12:22:21PM -0600, Ryan Hill wrote: INSANITY! You'll fit right in. Welcome. The voices in my head tell my to say Welcome Markus :-] cheers, Wernfried -- Wernfried Haas (amne) - amne (at) gentoo.org Gentoo Forums - http://forums.gentoo.org forum-mods (at) gentoo.org #gentoo-forums (freenode) pgpqE7RjXMart.pgp Description: PGP signature
[gentoo-dev] Upcoming infra work - Bugzilla, CVS/SVN/Git
Hi folks, Hopefully sometime THIS weekend, I'll be moving Bugzilla as well at our VCS services (CVS/SVN/Git on stork.gentoo.org) to new machines. I don't have a more accurate time estimate of when yet, but downtimes are going to be minimal, as the flips will be near-live. -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgptCwvw2EJ8P.pgp Description: PGP signature
Re: [gentoo-dev] RFC: language bindings as separate packages
Enrico Weigelt wrote: My suggestion: make those language bindings being separate packages. So, other packages can depend on them directly, instead of the current, build-breaking hack. I'm not advocating gentoo should do this step alone, but instead join in the upstream and solve it there. The issue is upstream related, we can workaround it using a way to express that requirement (usedeps, checks in pkg_setup, whatever), obviously trying to cooperate with upstream in order to get the optional bindings build w/out the main program would make our life simpler and probably their as well. Partial builds are quite a problem since they are anything but reliable. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Automagic dependencies in gegl
Hanno Böck wrote: Now, gegl has 13 optional dependencies that could be use-flagged. The pity is, it has no configure-option for most of them, they are autodetected. (It's about gtk, ruby, lua, cairo, pango, libpng, openexr, rsvg, sdl, asciidoc, enscript, graphviz and ffmpeg) whoah! Quite a large number!. My experience with the gimp developers in the past was that they weren't very pleased by bugs about automagic deps and I assume if I post them without patches, they'll get closed immediately. Now I always avoided to dig too deep into autotools, so I don't feel skilled enough for this task. Ping me and we could work out something, probably the best way would be hack a PKG_CONFIG_CONDITIONAL that does whatever the canned pkgconfig does+ adding the --enable option. Is there some brave gentoo dev (or non-dev, doesn't really matter) volunteering to send patches to gegl-upstream? We could teamwork having some autostuff monkey doing part of the work, you helping us trying out the result and whoever has better contact with upstream could try to get the thing there. Beside, I'm asking myself how to handle this situation. Hard-enable them all as long as there are no patches? Let the automagic go in the tree? Opinions welcome. Where is the ebuild, put it as is hardmasked with a note about this, then we could work together on it. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Automagic dependencies in gegl
Hanno Böck a écrit : Recently, GIMP got it's first development version based on gegl. Sweet :) Is there some brave gentoo dev (or non-dev, doesn't really matter) volunteering to send patches to gegl-upstream? I would really like to say that I can do it for you, but I'm very time limited, so my suggestion is to start off with the easy ones (ie, the ones that use pkg-config). Do one dependency, (contact me off list so I can help you get it right) and then it should be pretty easy to copy/paste to do the other ones. Getting the first one done is the hardest :) Beside, I'm asking myself how to handle this situation. Hard-enable them all as long as there are no patches? Let the automagic go in the tree? Opinions welcome. No automagic... that's a big no-no :) Cheers, Rémi -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Hackontest
Anant Narayanan [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 02 May 2008 11:40:06 +0530: I added the Gentoo project to Hackontest (for more information, visit http://hackontest.org/) . Cool! I'd read about it and wondered if Gentoo would be participating, so it's nice to see that yes, someone (you) added us and we are. =8^) -- 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 -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Automagic dependencies in gegl
* Luca Barbato [EMAIL PROTECTED] schrieb: Hi, Now, gegl has 13 optional dependencies that could be use-flagged. The pity is, it has no configure-option for most of them, they are autodetected. A good example for miserable design ;-P That's why I everything should be entirely built in sysroot. My experience with the gimp developers in the past was that they weren't very pleased by bugs about automagic deps and I assume if I post them without patches, they'll get closed immediately. Now I always avoided to dig too deep into autotools, so I don't feel skilled enough for this task. Ping me and we could work out something, probably the best way would be hack a PKG_CONFIG_CONDITIONAL that does whatever the canned pkgconfig does+ adding the --enable option. I strongly advise against this. The clean way is to fix the package. (it's build scripts). I'm doing so in the OSS-QM project, eg. for Mozilla ... This actually is one of the typical situations what I invented OSS-QM for: the upstream produces crap and is even learning resistent. Doing those cleanups within individual distros is not the right thing, because a) too much work for the distro maintainer and b) too much duplicate work, if every distro does it by it's own. I'd like to invite you to the OSS-QM project - let's do all the cleanups there and provide overlay by patch, so all distros now just have to pick their right configure args. http://oss-qm.metux.de/ cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: language bindings as separate packages
* Luca Barbato [EMAIL PROTECTED] schrieb: Enrico Weigelt wrote: My suggestion: make those language bindings being separate packages. So, other packages can depend on them directly, instead of the current, build-breaking hack. I'm not advocating gentoo should do this step alone, but instead join in the upstream and solve it there. The issue is upstream related, we can workaround it using a way to express that requirement (usedeps, checks in pkg_setup, whatever), obviously trying to cooperate with upstream in order to get the optional bindings build w/out the main program would make our life simpler and probably their as well. Partial builds are quite a problem since they are anything but reliable. ACK. These are just hacks to work around upstream's design problems. For me, working much embedded environments, those hacks are not an option, since builds MUST be reliable (the packages MUST work IMMEDIATELY after deployment, since there is no chance for doing things like revdep-rebuild). My vote is: declaring guidelines (or better: constraints) for clean builds and then working directly within the upstream to get it on the road. If the upstream really blocks it, do a fork / maintain a patchline (like OSS-QM project does). I'm already doing so with several packages. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: language bindings as separate packages
Enrico Weigelt a écrit : * Luca Barbato [EMAIL PROTECTED] schrieb: Enrico Weigelt wrote: My suggestion: make those language bindings being separate packages. So, other packages can depend on them directly, instead of the current, build-breaking hack. I'm not advocating gentoo should do this step alone, but instead join in the upstream and solve it there. The issue is upstream related, we can workaround it using a way to express that requirement (usedeps, checks in pkg_setup, whatever), obviously trying to cooperate with upstream in order to get the optional bindings build w/out the main program would make our life simpler and probably their as well. Partial builds are quite a problem since they are anything but reliable. ACK. These are just hacks to work around upstream's design problems. For me, working much embedded environments, those hacks are not an option, since builds MUST be reliable (the packages MUST work IMMEDIATELY after deployment, since there is no chance for doing things like revdep-rebuild). My vote is: declaring guidelines (or better: constraints) for clean builds and then working directly within the upstream to get it on the road. Best example on how to do that is gstreamer. All the plugins come in 3 tarballs but each can be built individually. Really clean. If the upstream really blocks it, do a fork / maintain a patchline (like OSS-QM project does). I'm already doing so with several packages. I've seen you talk about that project before but I don't feel comfortable going down that road. We want to work with upstream and let them know what our needs are. Maintaining patches is a lot of work and forking is even more work. Even though I'm still a relatively young Gentoo dev (only been here for 1.5 years), I have yet to see upstream projects reject build patches that make our lives easier. Cheers, Rémi -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: language bindings as separate packages
* Rémi Cardona [EMAIL PROTECTED] schrieb: Best example on how to do that is gstreamer. All the plugins come in 3 tarballs but each can be built individually. Really clean. ACK. That's how it always should be. All my own packages also work this way - ev'ry thing else doesnt get released ;-P If the upstream really blocks it, do a fork / maintain a patchline (like OSS-QM project does). I'm already doing so with several packages. I've seen you talk about that project before but I don't feel comfortable going down that road. We want to work with upstream and let them know what our needs are. Maintaining patches is a lot of work and forking is even more work. Right. Therefore OSS-QM is meant as just an intermedia step. To form a bridge between (virtually all) distros and upstream. Sometimes the upstream has even valid reasons for not having distro's or embedded needs as high priority, eg. if their primary goal are new features - many upstream folks are coding ONLY just for fun and simply don't want to care about stability. In those cases we simply should let them pass and avoid unnecessary conflicts. In fact we (as OSS-QM) would then maintain the stable branch, while the upstream is just the devel branch. Maybe you remember the discussions about stable vs. dev kernel branches: the kernel folks wanted to give up stable branches, leaving them to the individual distros and concentrate just on devel branch. A lot of people were totally unhappy with this idea, so they abondened the idea. Otherwise the kernel would have been the killer job for an project like OSS-QM. Even though I'm still a relatively young Gentoo dev (only been here for 1.5 years), I have yet to see upstream projects reject build patches that make our lives easier. Yeah, I've experienced this a lot of times and learned that it doesn't make sense trying to convice people to things they simply do not want. So I founded OSS-QM as an proxy/overlay project with the primary goals: reacting ASAP, providing things the distros need in an *generic* way, but not developing new features. The upstream gets announced about patches, but doesn't get penetrated with things they're obviously not interested in. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Automagic dependencies in gegl
Enrico Weigelt wrote: * Luca Barbato [EMAIL PROTECTED] schrieb: Hi, Now, gegl has 13 optional dependencies that could be use-flagged. The pity is, it has no configure-option for most of them, they are autodetected. A good example for miserable design ;-P That's why I everything should be entirely built in sysroot. My experience with the gimp developers in the past was that they weren't very pleased by bugs about automagic deps and I assume if I post them without patches, they'll get closed immediately. Now I always avoided to dig too deep into autotools, so I don't feel skilled enough for this task. Ping me and we could work out something, probably the best way would be hack a PKG_CONFIG_CONDITIONAL that does whatever the canned pkgconfig does+ adding the --enable option. I strongly advise against this. The clean way is to fix the package. (it's build scripts). I'm doing so in the OSS-QM project, eg. for Mozilla ... That is the plan, you produce a simple m4 macro that does for you once and then apply it every time you have a bare pkg check. I'd like to invite you to the OSS-QM project - let's do all the cleanups there and provide overlay by patch, so all distros now just have to pick their right configure args. http://oss-qm.metux.de/ I'll have a look soon. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Hackontest
Anant Narayanan wrote: Hi, I added the Gentoo project to Hackontest (for more information, visit http://hackontest.org/) . Developers and users are invited to add feature requests for Gentoo (preferably with links to bugzilla :-)). Hopefully, some of us developers can get together and implement them at the Hackontest - September this year, at Zurich. Nice, I thought of that too... I'll probably also prepare the booth again for the OpenExpo in Zurich :-) Cheers, Tiziano -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: language bindings as separate packages
Enrico Weigelt wrote: Maybe you remember the discussions about stable vs. dev kernel branches: the kernel folks wanted to give up stable branches, leaving them to the individual distros and concentrate just on devel branch. A lot of people were totally unhappy with this idea, so they abondened the idea. Otherwise the kernel would have been the killer job for an project like OSS-QM. What you mean by the stable branch, the 2.4.x, 2.6.16.x or something completely different? Cheers, -jkt -- gentoo-dev@lists.gentoo.org mailing list
