[gentoo-dev] Last rites: dev-php/ezc-*
# Ole Markus With olemar...@gentoo.org (04 Jan 2013) # No longer maintained. Replaced by Zeta Components, which also has yet # to have had any releases. # Masked for removal. dev-php/ezc-Archive dev-php/ezc-Authentication dev-php/ezc-AuthenticationDatabaseTiein dev-php/ezc-Cache dev-php/ezc-Configuration dev-php/ezc-ConsoleTools dev-php/ezc-Database dev-php/ezc-DatabaseSchema dev-php/ezc-Debug dev-php/ezc-Document dev-php/ezc-EventLog dev-php/ezc-EventLogDatabaseTiein dev-php/ezc-Execution dev-php/ezc-eZcomponents dev-php/ezc-Feed dev-php/ezc-File dev-php/ezc-GraphDatabaseTiein dev-php/ezc-ImageAnalysis dev-php/ezc-ImageConversion dev-php/ezc-Mail dev-php/ezc-MvcAuthenticationTiein dev-php/ezc-MvcFeedTiein dev-php/ezc-MvcMailTiein dev-php/ezc-MvcTemplateTiein dev-php/ezc-MvcTools dev-php/ezc-PersistentObject dev-php/ezc-PersistentObjectDatabaseSchemaTiein dev-php/ezc-PhpGenerator dev-php/ezc-Search dev-php/ezc-SignalSlot dev-php/ezc-SystemInformation dev-php/ezc-Template dev-php/ezc-TemplateTranslationTiein dev-php/ezc-Translation dev-php/ezc-TranslationCacheTiein dev-php/ezc-Tree dev-php/ezc-TreeDatabaseTiein dev-php/ezc-TreePersistentObjectTiein dev-php/ezc-Url dev-php/ezc-UserInput dev-php/ezc-Webdav dev-php/ezc-Workflow dev-php/ezc-WorkflowDatabaseTiein dev-php/ezc-WorkflowEventLogTiein dev-php/ezc-WorkflowSignalSlotTiein
Re: [gentoo-dev] configuration-doc.eclass: an eclass to install a CONFIGURATION doc file and show an elog message first time package is installed
El jue, 03-01-2013 a las 17:11 -0600, William Hubbs escribió:
[...]
But, how to share CONFIGURATION_INSTRUCTIONS contents then for
create_doc and print_elog? The idea is to share the same message, and
using global variable for this purpose is already done with
kernel-2.eclass (I noticed it when doing last tuxonice-sources bumps)
Does kernel-2.eclass save the message somewhere or just print it? If it
just prints it I can see that, but since you are saving it to a file, I
was just thinking that there is no need to keep a global variable
around.
It just print it via elog, but I don't see the difference when it's
saved to a file. Anyway, there is no problem on setting it at pkg_setup
of src_prepare phases for example.
[...]
# @FUNCTION: configuration_print_elog
# @DESCRIPTION:
# Print elog messages with CONFIGURATION_INSTRUCTIONS contents.
# Usually called at pkg_postinst phase.
configuration_print_elog() {
debug-print-function ${FUNCNAME} ${@}
if [[ -n ${CONFIGURATION_INSTRUCTIONS} ]]; then
I would recommend using the CONFIGURATION file here, as follows:
if [ -f ${T}/CONFIGURATION ]; then
That is interesting as ensures file was created, but, will it be still
there at pkg_postinst phase?
Yes, it should be.
In that case I will try it, thanks for the tip
if ! [[ ${REPLACING_VERSIONS} ]]; then
This is an issue if I want to add display some tips that have changed
between different versions of the software. I would propose not trying
to do this, but let the user call this function.
This is intentional because the kind of messages that are always the
same and, then, need to only be shown with elog first time the package
is installed need this checking. From packages I have seen, those
messages that are related with updating from version XXX should still
be handled manually.
Say I have foobar-1 installed, and it has configuration instructions.
Now, foobar-2 comes along with different configuration instructions
that do not work for foobar-1.
What happens to the CONFIGURATION file when I upgrade? Does it now have
foobar-2's instructions? If not, this is a bug.
William
With current eclass design, you will need to handle it at ebuild itself
(as done currently), and handle that way proper version checking that
will change depending on each package. Anyway, eclass could be enhanced
to also handling this cases but, before that:
- we need to agree what is the proper way of using REPLACING_VERSIONS
for version checking (some ebuilds use / operators, while others
rely on versionator.eclass)
- I need to think how to handle both cases :|
- I guess you want to save in CONFIGURATION file that kind of messages
version-dependent ONLY when people updates from older versions and,
then, once people re-emerge the package, that part will be removed (as
is done currently with elog messages that are, for example, behind:
if [[ ${REPLACING_VERSIONS} ]] [[ ${REPLACING_VERSIONS} XX ]]; then
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig
On 01/03/2013 02:58 AM, Samuli Suominen wrote: On 02/01/13 15:29, Luca Barbato wrote: last I checked prefix didn't have issues with the pkg-config bootstrap either. there is no circular deps either. check glib deps iirc some non-glibc platforms have few problems with it. not if you enable USE=internal-glib. i've added the USE flag on request from vapier mostly, so we could punt pkg-config-lite from Portage. it should not depend on any of the stuff embedded (uclibc) has problems with anymore. as for anything other than uclibc, glibc, i'd like to see an bug, there isn't one Doesn't that violate our policy on bundled libraries? I would like to see us switch after Diego is happy with tinderbox testing. That would put us in a position to eliminate glib from many non-GNOME systems, provided that we kill the glib dependency in udev/eudev. That is something worth exploring. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig
On 01/04/2013 05:31 AM, Richard Yao wrote: On 01/03/2013 02:58 AM, Samuli Suominen wrote: On 02/01/13 15:29, Luca Barbato wrote: last I checked prefix didn't have issues with the pkg-config bootstrap either. there is no circular deps either. check glib deps iirc some non-glibc platforms have few problems with it. not if you enable USE=internal-glib. i've added the USE flag on request from vapier mostly, so we could punt pkg-config-lite from Portage. it should not depend on any of the stuff embedded (uclibc) has problems with anymore. as for anything other than uclibc, glibc, i'd like to see an bug, there isn't one Doesn't that violate our policy on bundled libraries? I would like to see us switch after Diego is happy with tinderbox testing. That would put us in a position to eliminate glib from many non-GNOME systems, provided that we kill the glib dependency in udev/eudev. That is something worth exploring. Scratch that. The glib dependency in udev/eudev is purely optional. The only dependency is in pkg-config. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] What did we achieve in 2012? What are our resolutions for 2013?
Coming to my mind: There have been continued regular releases of genkernel integrating patches from various people: http://git.overlays.gentoo.org/gitweb/?p=proj/genkernel.git;a=tags And there has been a constant stream of people asking for user overlay hosting or getting an existing overlay being added to the layman registry that we could serve. Ben, I hope you have the time to make a news post from this thread's collection? Best, Sebastian
Re: [gentoo-dev] Re: Wordiness
On 05:31 Fri 21 Dec , Matt Turner wrote: My point is that you consistently write long essays that I, and apparently most others, don't bother to read. I'm not sure if you're aware of this. Someone said on IRC this morning in response to this thread the tragic thing is that guy would be able to make valuable contributions if it weren't for the excessive length of his mails So, your emails are way too long. A huge percentage of recipients don't bother to read them. I don't know whether you just enjoy writing (you must!) or if you hope to actually be heard, but as it stands now you're not being heard by most. Just coming back from Christmas vacation, but ... Yeah. Duncan, you need to learn how to be pithy. Invest the effort to cut your writing down to its essence; consider the time of the 100s/1000s who read it. Your value and impact will increase exponentially. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgpR4IRW1xeQ_.pgp Description: PGP signature
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 10:26 Sat 22 Dec , Pacho Ramos wrote: Hello After seeing: https://bugs.gentoo.org/show_bug.cgi?id=440214 Looking to a lot of its blockers shows that we are using elog messages for informing people about configuration (like pointing people to external links to get proper way of configuring things, tell them to add to some system groups...). I thought that maybe this kind of information could be simply included in a canonical file under /usr/share/doc/ package dir called, for example, CONFIGURATION or SETUP. We would them point people (now with a news item, for the long term provably a note to handbook to newcomers would be nice) to that file to configure their setups. The main advantages I see: - We will flood less summary.log ;) - The information to configure the package is always present while package is installed, now, if we remove merge produced logs, people will need to reemerge the package or read directly the ebuild What do you think? Bikeshedding ... would go with README.gentoo, because people are already used to looking for README files. Every time we can eliminate Gentoo-specific weirdness, we should. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgp3sbsAFBIVY.pgp Description: PGP signature
Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)
On 10:43 Mon 17 Dec , Markos Chandras wrote: On 16 December 2012 18:53, Andreas K. Huettel dilfri...@gentoo.org wrote: How to do this, however, and what software to target should probably be decided by people who know more than me... and in the end it all boils down to who has the time and motivation. Outsource it to someone who has the knowledge and interest in doing this. The foundation has the funds to support it, and none of us actually have the time to invest in a complete webpage redesign. I did much of the design work nearly 2 years ago: http://dev.gentoo.org/~dberkholz/gentoo_website/gentoo_landing_black.png http://dev.gentoo.org/~dberkholz/gentoo_website/gentoo_landing_install.png http://dev.gentoo.org/~dberkholz/gentoo_website/gentoo_landing_handbook.png http://dev.gentoo.org/~dberkholz/gentoo_website/gentoo_landing_handbook2.png Some early work on it using Bootstrap: http://a3li.li/~alex/g.o/ That said, why the hell are we wasting time implementing our own website backend when we should be using a CMS? We're here to make a distro, not a website framework. No reason we should care, day to day, about anything but frontend theming and content. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgpSKkhPZZeQ4.pgp Description: PGP signature
