[gentoo-dev] Lastrites: net-proxy/paros, net-misc/ups-monitor, app-emulation/mol, net-wireless/fsam7400, net-wireless/acx, net-wireless/acx-firmware, net-wireless/linux-wlan-ng-modules, net-wireless/l
# Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Violates java packaging policy (#168867), no release since # 2006, it would require jdic in the tree but that needs huge # work to be done and someone wanting to do that. # Removal in a month. net-proxy/paros # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Fails to install (#195030), ELF installed into /usr/share (#297140) # upstream is dead for a long time, no other distribution is still # supplying it. Removal in a month. net-misc/ups-monitor # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Upstream is dead, doesn't build against latest kernels (#199294). # Removal in a month. app-emulation/mol # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Upstream is dead, doesn't build with recent kernels (#201922), # kernel-3.6 shouldn't need it. Removal in a month. net-wireless/fsam7400 # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Upstream dead for ages, multiple opened bug, possible legal # problems (#211846). Removal in a month. net-wireless/acx net-wireless/acx-firmware # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Doesn't build against recent kernels (#247898), all its supported # devices are not supported by latest kernels. Removal in a month. net-wireless/linux-wlan-ng-modules net-wireless/linux-wlan-ng-utils net-wireless/linux-wlan-ng-firmware net-wireless/linux-wlan-ng # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Doesn't compile (#270269), it's also hardware specific and, then, # needs a dedicated maintainer. Removal in a month. net-wireless/rfswitch # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Runtime problems (#272751), no update since 2005 (bluez-3 times), # removal in a month. net-wireless/opd # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Fails to build for a long time (#277164), removal in a month. app-crypt/bestcrypt # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Overflow issues (#277459), upstream lost interest on it. # Removal in a month. net-irc/xchat-xsys # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # This project has been superseeded by G'MIC. Removal in a month. media-plugins/gimp-greycstoration # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Fails to launch (#294013), depends on nethack that has security # issues. Removal in a month games-roguelike/noegnud-nethack # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Fails to build with latest kernels (#294813), upstream dead since # 2007. Removal in a month. net-dialup/openadsl # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Fails to build for years (#294822), getting it updated needs # a total rework in ebuilds (and splitting) that nobody looks to # have time to do. Removal in a month. sci-electronics/chipmunksystem # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Fails to build (#318775). Removal in a month. media-tv/v4l-dvb-hg # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Dead for ages and collides with dev-libs/ppl (#320413). # Removal in a month. net-misc/partysip # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Not needed for a long time and now neither for BSDs (#321261#c9), # bugs not fixed due upstream dead (#321261). Removal in a month. sys-apps/915resolution # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Not compatible with recent telepathy versions as upstream no longer # develops it (#326117). Removal in a month. dev-util/telepathy-inspector # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Fails to build with automake-1.11 (#328201), nothing in the tree # needs it. Removal in a month. dev-libs/yaz++ # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Fails to build (#332793), nothing in the tree needs it. # Removal in a month. dev-lang/sr # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Can be treecleaned as talked with upstream, use app-laptop/pommed # instead. Removal in a month. app-laptop/macbook-backlight # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Overflow issues (#338936) and cannot start. Removal in a month. x11-misc/bbacpi # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Lots of bug report, use version from science overlay as pointed # in bug #339364#c3 . Removal in a month sci-mathematics/scilab # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Upstream dead for more than 2 years and replaced by nmcli # (from NetworkManager) (#339664). Removal in a month. net-misc/cnetworkmanager # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Doesn't build with current kernels (#344889). People needs to # migrate to x11-drivers/xf86-video-fbdev and be sure they have # CONFIG_STUB_POULSBO enabled in their kernels. # Removal in a month. x11-drivers/psb-kmod x11-drivers/xf86-video-psb # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Doesn't build with current kernels (#351225), some work is done # by Ubuntu users but a lot of mantainance work is still needed # and nobody will take care of it now (#351225#c7). # Removal in a month. net-dialup/hsfmodem # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Upstream dead for ages and fails to build (#351449). # Removal in a month. x11-terms/hanterm
Re: [gentoo-dev] Lastrites: net-proxy/paros, net-misc/ups-monitor, app-emulation/mol, net-wireless/fsam7400, net-wireless/acx, net-wireless/acx-firmware, net-wireless/linux-wlan-ng-modules, net-wirele
El sáb, 24-11-2012 a las 18:47 -0500, James Cloos escribió: The percentage of bogosity is nicely small, but there are a couple in there which shouldn't be dropped. # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Lots of bug report, use version from science overlay as pointed # in bug #339364#c3 . Removal in a month sci-mathematics/scilab The version in portage (scilab 4) works fine here; I've never gotten scilab 5 (the version in sci) to build. So that should remain. You can find, apart of pointed bug report, the following problems with scilab versions in the tree: https://bugs.gentoo.org/buglist.cgi?quicksearch=scilablist_id=1403328 Much worse, however, is this insanity: # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Fail to start due missing fonts (bugs 395353, 402713, 429234). # Removal in a month. x11-misc/bbdate x11-misc/bbweather x11-misc/bbsload So, you advocate removing x11 client packages because, oooh, they require *server-side fonts*. AGH! Seriously, it is bug-reports 395353 and 402713 which are flawed, not the packages. And 429234, requesting stabilization, should get it. -JimC Even in that stabilization bug 429234 it's pointed by arch testers that package cannot be stabilized due that runtime errors and they also suggest to punt it, even after installing fonts that should fix it, also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592108 is pointed in addition signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Lastrites: net-proxy/paros, net-misc/ups-monitor, app-emulation/mol, net-wireless/fsam7400, net-wireless/acx, net-wireless/acx-firmware, net-wireless/linux-wlan-ng-modules, net-wirele
El dom, 25-11-2012 a las 08:03 +0100, Pacho Ramos escribió: [...] Much worse, however, is this insanity: # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Fail to start due missing fonts (bugs 395353, 402713, 429234). # Removal in a month. x11-misc/bbdate x11-misc/bbweather x11-misc/bbsload So, you advocate removing x11 client packages because, oooh, they require *server-side fonts*. AGH! Seriously, it is bug-reports 395353 and 402713 which are flawed, not the packages. And 429234, requesting stabilization, should get it. -JimC Even in that stabilization bug 429234 it's pointed by arch testers that package cannot be stabilized due that runtime errors and they also suggest to punt it, even after installing fonts that should fix it, also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592108 is pointed in addition We continue on each bug report, ok? ;) signature.asc Description: This is a digitally signed message part
[gentoo-dev] Some packages up for grabs
Swegener recently moved away from the following packages: app-admin/eselect-pinentry app-crypt/pinentry Thanks for taking care of them if you want signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Some packages up for grabs
El lun, 26-11-2012 a las 18:58 +0100, Pacho Ramos escribió: Swegener recently moved away from the following packages: app-admin/eselect-pinentry app-crypt/pinentry Thanks for taking care of them if you want And: net-dns/avahi signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs due apache herd removal
After discussing it at: http://www.gossamer-threads.com/lists/gentoo/dev/262834 dev-libs/apr-util dev-libs/apr www-apache/mod_auth_cookie_mysql2 www-apache/mod_xml2enc www-misc/multisort app-admin/apachetop dev-libs/libhome net-libs/libopkele www-apache/libapreq2 www-apache/mod_access_dnsbl www-apache/mod_anonymize_ip www-apache/mod_auth_imap2 www-apache/mod_auth_kerb www-apache/mod_auth_openid www-apache/mod_auth_tkt www-apache/mod_authn_sasl www-apache/mod_authn_pam www-apache/mod_authnz_external www-apache/mod_backtrace www-apache/mod_bw www-apache/mod_chroot www-apache/mod_common_redirect www-apache/mod_cplusplus www-apache/mod_depends www-apache/mod_diagnostics www-apache/mod_dnsbl_lookup www-apache/mod_dnssd www-apache/mod_evasive www-apache/mod_extract_forwarded www-apache/mod_fastcgi www-apache/mod_fastcgi_handler www-apache/mod_flvx www-apache/mod_ftpd www-apache/mod_geoip2 www-apache/mod_gnutls www-apache/mod_layout www-apache/mod_ldap_userdir www-apache/mod_loadavg www-apache/mod_log_rotate www-apache/mod_log_sql www-apache/mod_loopback www-apache/mod_macro www-apache/mod_musicindex www-apache/mod_pcgi2 www-apache/mod_proxy_fcgi www-apache/mod_proxy_html www-apache/mod_qos www-apache/mod_roaming www-apache/mod_rpaf www-apache/mod_scgi www-apache/mod_spin www-apache/mod_suphp www-apache/mod_tcl www-apache/mod_tidy www-apache/mod_transform www-apache/mod_umask www-apache/mod_vdbh www-apache/mod_vhost_ldap www-apache/mod_vhs www-apache/mod_watch www-apache/mod_whatkilledus www-apache/pwauth www-apps/scgi www-misc/log-toolkit www-misc/mergelog If you want to take one of them, feel free to add yourself to metadata.xml Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Apache team is inactive
El dom, 18-11-2012 a las 11:45 +, Markos Chandras escribió: On Sun, Nov 18, 2012 at 10:28 AM, Pacho Ramos pa...@gentoo.org wrote: apache team is currently composed by nelchael (that is inactive since May 2012) and trapni (that is not taking care of that packages) If you are interested please join. If it's still inactive in next week, I will assign apache bugs to maintainer-needed (I am still unsure about if, in that case, apache herd should be kept in CC for an hypothetical future resurrection or the herd should be dropped entirely) I'd say drop the herd. Like we dropped www-servers. Individual maintainers can take over the packages. Done signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Lastrites: net-proxy/paros, net-misc/ups-monitor, app-emulation/mol, net-wireless/fsam7400, net-wireless/acx, net-wireless/acx-firmware, net-wireless/linux-wlan-ng-modules, net-wirele
El vie, 30-11-2012 a las 14:19 +0200, Petteri Räty escribió: On 24.11.2012 23.12, Pacho Ramos wrote: # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Doesn't build against recent kernels (#247898), all its supported # devices are not supported by latest kernels. Removal in a month. net-wireless/linux-wlan-ng-modules net-wireless/linux-wlan-ng-utils net-wireless/linux-wlan-ng-firmware net-wireless/linux-wlan-ng Thanks for the work. You could link here for to provide users information on the replacement modules: http://wiki.debian.org/linux-wlan-ng Regards, Petteri + 30 Nov 2012; Pacho Ramos pa...@gentoo.org package.mask: + Improve mask message for linux-wlan-ng (thanks to Petteri Räty for providing + it) + signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs due lavajoe retirement
media-gfx/xv sys-apps/more media-sound/logitechmediaserver-bin - this package is special, it's maintained by a proxy maintainer but it was reassigned to maintainer-needed instead of proxy-maint herd. Was reviewing to reassign it when I saw: https://bugs.gentoo.org/show_bug.cgi?id=251494 that I have no idea about how to handle :| signature.asc Description: This is a digitally signed message part
[gentoo-dev] Help on adapting cman init scripts to kernels with things built in instead of modules
Hello Looks like cman stabilization (that is needed to stabilize newer lvm2, that is needed to stabilize newer udev...) is blocked by its init.d script wanting to load modules even on kernels without modules: https://bugs.gentoo.org/show_bug.cgi?id=442512#c5 Arch team people think that this should be handled before but... how should it be handled? Do you know about some similar case that I could look for possible solutions to it? Thanks a lot for your help signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] Defaulting desktop profiles to net-nds/openldap[minimal]
El dom, 02-12-2012 a las 07:58 -0800, Diego Elio Pettenò escribió: On 02/12/2012 00:43, Michał Górny wrote: How about splitting the ebuild into separate library and server and fixing the deps? It would be cleaner for people, and we'd just release a news message that those who need an LDAP server, need to put it in their @world. How about no? Split packages are a pain for maintainers and users alike. Maybe the easiest option would be to keep current defaults and simply include a news item when libreoffice starts to pull in openldap on a lot of systems remembering admins that they can safely enable minimal USE flag for openldap if they won't use server capabilities signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [RFC] Defaulting desktop profiles to net-nds/openldap[minimal]
El dom, 02-12-2012 a las 11:54 -0500, Michael Orlitzky escribió: [...] The USE=server solution is fine with me; the whole openldap thing was really tangential to the point I was trying to make. And for some reason it's not as fun to argue in the morning as it is at 2am, so thanks for working on it, it's dropped =) Didn't see 'server solution' before, that also looks fine to me ;) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Cleaning tree of outdated packages
El jue, 13-12-2012 a las 12:31 -0600, Jory A. Pratt escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As many of us are aware the tree is growing to a size that is really unacceptable for many. We have many packages that have excessive amounts of versions laying around that are not used any more. Many of these packages with excessive revisions most likely do not work with modern code any longer, or have security exploits or just dead upstreams that do not support them any longer that have been replaced with newer packages. Well these packages are around for stable at the moment when a newer package replaces the old and makes stable branch we need to remove the dead package. This is nothing but an attempt to start reducing the size of the tree and supported packages as a whole to improve the quality of Gentoo as a WHOLE. All packages of course need to be handled in a manner that works with maintainers/herd and the community as a whole. Jory I think Ago had a script for doing that task... but each team/herd will need to give him permission for cleaning old versions I think ;) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Cleaning tree of outdated packages
El jue, 13-12-2012 a las 13:10 -0600, William Hubbs escribió: I think another good reason for treecleaning a package is if upstream for the package stops supporting their package and recommends that you use a new package. In this situation, once the new package hits stable, there is really not a reason to keep the old package around. Instead, any necessary transition to the new package should be done and the old package should be treecleaned. William I think we already try to do that... the problem is that sometimes some packages are forgotten :S signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Cleaning tree of outdated packages
El jue, 13-12-2012 a las 21:51 -0600, William Hubbs escribió: [...] I'm wondering if packages assigned to maintainer-needed should be looked at and removed since no one cares about them after they have sat there for a certain amount of time? They are, aren't they? treecleaners has been doing a pretty good job of that iirc. At least, those that have had bugs filed against them without being addressed... There seems to be a pretty high number of unmaintained packages in the tree if you look at hwoarang's response to this thread, so I'm not sure how that is going. William Regarding maintainers-needed packages, I am in its mail alias to try to take care of them (there are more developers in its alias doing really nice work with them) and, since I am also in treecleaners team, we try to remember to lastrite packages under maintainer-needed umbrella when an important bug for them is reported and there is no way to fix them. Then, from maintainer-needed packages point of view, I think they are pretty clean when talking about broken packages still living in the tree. Regarding its old stable versions, I think I talked about this with Ago time ago and he cleaned a bunch of old versions. The only problem I see with amount of packages under maintainer-needed umbrella is that... would be nice to get specific maintainer/proxy-maintainers for them or more people joining to maintainer-needed mail alias to fix their bugs when have enough time ;) signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs due nelchael retirement
app-editors/scite app-i18n/man-pages-pl dev-cpp/gflags dev-libs/protobuf dev-python/python-gflags net-misc/openntpd net-misc/pump net-misc/sipcalc sys-block/mpt-status sys-power/hibernate-script sys-power/ncpufreqd www-apache/mod_cband x11-terms/mrxvt Thanks for taking care of them signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)
El dom, 16-12-2012 a las 12:49 -0500, Damien Levac escribió: I completely agree, myself, I want to become a developer, but since the information looks so scattered, I decided to wait until summer to have all the required time to find/read all relevant documentation and foillow up with the recruitment process (which seems to be somehow 'non-trivial'). As an aside, which may or may not reflect the view of other potential candidates, even though I use git for my personal projects, having to learn CVS would not be an issue if I'm already willing to learn everything else. (However, if there is no guarantee that this will be useful, why is it a requirement in the first place?) Damien For now, I think you should simply go to devmanual: http://devmanual.gentoo.org/ You will need to read it sooner and later... and I am sure that you will read it faster as you think once you start to read ;) Best regards! :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Defaulting for debug information in profiles
El lun, 17-12-2012 a las 08:55 -0500, Rich Freeman escribió: [...] I usually keep a debug file in /etc/portage/env.d and symlink it to anything I'm working on. Rich I do the same, for example, I had end.d files for all evince related packages to get proper backtraces as I was getting crashes from time to time for some files signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Portage sets support Was: Defaulting for debug information in profiles
El jue, 20-12-2012 a las 12:23 -0800, Zac Medico escribió: On 12/20/2012 12:09 PM, Rich Freeman wrote: On Wed, Dec 19, 2012 at 4:43 AM, Zac Medico zmed...@gentoo.org wrote: On 12/18/2012 11:58 PM, Duncan wrote: I didn't know that. Last I knew, stable portage had special-case acceptance of @system and @world to prepare the way, but I hadn't seen that full /etc/portage/sets/* and /var/lib/portage/world_sets support was stabilized. If indeed it is as you say, I've even more to rejoice about! =:^) Yeah, it's only been in stable for a few months now, so lots of people aren't aware of it yet. The current list available in portage-2.1.10.x, reported by emerge --list-sets is: preserved-rebuild If @preserved-rebuild and the corresponding FEATURES=preserve-libs are now stable, we should create a news item about this. Otherwise people will still be running revdep-rebuild a decade from now, as this feature was never formally announced as far as I'm aware, and all the mentions of it were ages ago and not available to stable users at the time. It's not enabled by default yet though. In the following blog post I've mentioned that I would like to wait for EAPI 5 and automatic rebuilds (via sub-slots and slot-operators) to gain widespread adoption before preserve-libs is enabled by default: http://blogs.gentoo.org/zmedico/2012/09/21/preserve-libs-available-in-portage-2-1/ The reason that I want to wait is that EAPI 5 automatic rebuilds provide solutions for known problems with @preserved-rebuild. These problems include symbol collisions [1] and unnecessary rebuilding of packages that are eligible for removal by emerge --depclean [2]. [1] http://blog.flameeyes.eu/2008/06/a-few-risks-i-see-related-to-the-new-portage-2-2-preserve-libs-behaviour [2] https://bugs.gentoo.org/show_bug.cgi?id=364425 Regarding symbol collisions, they would appear when people don't rebuild packages after updating (and that would be solved with eapi5, no? But, it's not exactly the same as is occurring currently if people forget to run revdep-rebuild (or if it's partially run)? signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs
Due araujo no longer taking care of them: dev-lang/gnu-smalltalk dev-lang/gwydion-dylan-bin dev-lang/pike dev-lang/io signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Time based retirements
El jue, 20-12-2012 a las 21:21 -0600, Doug Goldstein escribió: I'm curious who had the brain dead idea to retire Gentoo developers that are still interested in the distro, that maintain low activity packages for herds that are stretched way too thin, and are still contributing to the distro in many ways other than direct CVS commits (e.g. overlays, user support, providing hardware to other devs, etc). I could MAYBE understand it if they're consuming some valuable resource that we need to free up by retiring them. But instead they get a nasty-gram about their impending retirement and decide if that's how they are to be treated that they can be retired. When they finally want to contribute again they have the lovely uphill of our dreadfully painful recruitment process. I'm really just trying to understand the sense in this. I have just explained it at: https://bugs.gentoo.org/show_bug.cgi?id=101792#c17 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Time based retirements
El jue, 20-12-2012 a las 21:21 -0600, Doug Goldstein escribió: I'm curious who had the brain dead idea to retire Gentoo developers that are still interested in the distro, that maintain low activity packages for herds that are stretched way too thin, and are still contributing to the distro in many ways other than direct CVS commits (e.g. overlays, user support, providing hardware to other devs, etc). I could MAYBE understand it if they're consuming some valuable resource that we need to free up by retiring them. But instead they get a nasty-gram about their impending retirement and decide if that's how they are to be treated that they can be retired. When they finally want to contribute again they have the lovely uphill of our dreadfully painful recruitment process. I'm really just trying to understand the sense in this. I have just explained it at: https://bugs.gentoo.org/show_bug.cgi?id=101792#c17 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Time based retirements
El jue, 20-12-2012 a las 21:30 -0800, Paweł Hajdan, Jr. escribió: On 12/20/12 7:21 PM, Doug Goldstein wrote: I'm curious who had the brain dead idea to retire Gentoo developers that are still interested in the distro, that maintain low activity packages for herds that are stretched way too thin, and are still contributing to the distro in many ways other than direct CVS commits (e.g. overlays, user support, providing hardware to other devs, etc). Dough, thank you for rising the issue. I'm receiving the undertakers@ e-mail, so I have a pretty good view of what's happening. I have several suggestions how we can improve things: 1. 3 months is too short period anyway. 2. Think through what the goals are. We do not want to retire as many people as possible. We do not want to frustrate people who do contribute to Gentoo. We do not want to discourage people who consider becoming new developers. At least I don't. 3. I think what's important is to keep packages maintained. I consider maintainership to be a duty, not a privilege. If someone is listed in metadata.xml, but is not really maintaining the package, that creates a formal illusion that the package is maintained, and may prevent other people from stepping up and taking maintenance of that package. 4. I suggest that we focus on the above: keeping packages maintained. Taking packages out of hands of inactive/overworked maintainers is good. They can always become _more_ active, which is easier if they retain cvs access. If they make a single commit every 3-6 months, I'm fine with that as long as things are maintained properly. 5. Remember that cvs/bugzilla activity is not the only way of contributing. It's probably most tanglible and very needed, but let's not reduce real people and their real world situations, and their effort to contribute to just dates and numbers. Paweł Also I must note that I am currently only looking to people with 0 commits AND bugs assigned to them, if they don't have unresolved bugs for a long time I usually tend to leave them. Also, before sending first mail, I also send them a mail to set their devaway message and handle his bugs and if they don't have time to reassign his packages, I do it for them. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El dom, 23-12-2012 a las 13:36 -0800, Zac Medico escribió: On 12/23/2012 08:35 AM, Brian Dolbec wrote: On Sun, 2012-12-23 at 08:58 -0500, Alexandre Rostovtsev wrote: On Sun, 2012-12-23 at 12:20 +, Markos Chandras wrote: But like I said, elog messages are already saved in /var/log/portage/elog/$cat/$pf so people can read these. Isn't this the same with what you suggest? Is that by default? And when was that default added? I certainly do not have /var/log/portage/elog/$cat/$pf on my machine (using portage-2.2.0_alpha149), and in fact have never heard of this log file before your email. No, they are not saved there by default. They must be enabled. /var/log/portage/elog/summary.log is enabled by default though, and portage installs /etc/logrotate.d/elog-save-summary to manage it. But I remember to, for example, this kind of message: elog elog Please consult the upstream wiki if you need help elog configuring your system elog http://e4rat.sourceforge.net/wiki/index.php/Main_Page; elog The idea would be to make it to be only shown at first message and, later, rely on people reading /usr/share/doc/e4rat-xxx/CONFIGURATION file if they want to remember that tip signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El lun, 24-12-2012 a las 00:17 +0100, Diego Elio Pettenò escribió: On 23/12/2012 23:54, Pacho Ramos wrote: The idea would be to make it to be only shown at first message and, later, rely on people reading /usr/share/doc/e4rat-xxx/CONFIGURATION file if they want to remember that tip So you want in the main documentation a request to read the package documentation on where to find the upstream documentation? I want to have a permanent reference of current elog messages simply showing configuration tips to: 1. Show them via elog messages only first time package is installed 2. Not need to read ebuild directly once people remove summary.log signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] tools-portage herd unmaintained packages
El mar, 06-11-2012 a las 12:35 -0600, Paul Varner escribió: All: The following packages in the tools-portage herd are effectively unmaintained packages and need a maintainer to step up and maintain them. app-portage/deltup app-portage/epm app-portage/maintainer-helper app-portage/splat app-portage/ufed If no one steps up in the next 30 days, I will be moving them out of the herd and to maintainer-needed and they will be candidates for the treecleaners. Regards, Paul Varner tools-portage lead What did occur finally with them? signature.asc Description: This is a digitally signed message part
[gentoo-dev] Lastrites: media-sound/logitechmediaserver-bin, net-dialup/misdn, net-dialup/misdnuser, net-misc/asterisk-chan_misdn, www-apache/mod_authn_pam, www-apache/mod_cplusplus, net-dialup/ltmode
# Pacho Ramos pa...@gentoo.org (25 Dec 2012) # Will be maintained in squeezebox overlay, please switch to it. # See bug #251494. Removal from the tree in a month. media-sound/logitechmediaserver-bin # Pacho Ramos pa...@gentoo.org (25 Dec 2012) # Doesn't compile with recent kernels (#265581) and is not needed on # them. Removal in a month. net-dialup/misdn net-dialup/misdnuser net-misc/asterisk-chan_misdn # Pacho Ramos pa...@gentoo.org (25 Dec 2012) # Upstream dead, some problems (#277348), one possible replacement # includes mod_authnz_external. Removal in a month. www-apache/mod_authn_pam # Pacho Ramos pa...@gentoo.org (25 Dec 2012) # Patrick Lauer patr...@gentoo.org (16 Oct 2012) # upstream dead since 2008, doesn't build # See bug #282479. Removal in a month. www-apache/mod_cplusplus # Pacho Ramos pa...@gentoo.org (25 Dec 2012) # Incompatible with recent kernels (#300047) , upstream dead, # net-dialup/martian-modem can be used instead in most cases. # Removal in a month. net-dialup/ltmodem # Pacho Ramos pa...@gentoo.org (25 Dec 2012) # Old SLOT is not maintained by upstream for a long time, # nothing requires it (#311497). Removal in a month. =dev-libs/gmime-2.2.27-r1 # Pacho Ramos pa...@gentoo.org (25 Dec 2012) # Fails to build (#326799), upstream dead. Removal in a month. www-apache/mod_spin # Pacho Ramos pa...@gentoo.org (25 Dec 2012) # Tests freeze (#343663), upstream dead, could be broken with # some python versions. Removal in a month. www-apache/mod_python # Pacho Ramos pa...@gentoo.org (25 Dec 2012) # Dead stuff that shouldn't be used and that is required by # nothing (#407697). Removal in a month. dev-dotnet/galago-sharp sys-apps/galago-daemon dev-libs/libgalago # Pacho Ramos pa...@gentoo.org (25 Dec 2012) # Really old snapshot that is not compatible with apache-2.4, # upstream looks dead (#411465). Removal in a month. www-apache/mod_transform # Pacho Ramos pa...@gentoo.org (25 Dec 2012) # Upstream dropped them (#435842). Removal in a month. dev-util/monodevelop-java dev-util/monodevelop-python dev-util/monodevelop-vala # Pacho Ramos pa...@gentoo.org (25 Dec 2012) # Fails to build with libav-9 (#443238). Removal in a month. media-libs/libdlna media-video/ushare # Pacho Ramos pa...@gentoo.org (25 Dec 2012) # As distfiles are no longer provided by upstream and license # doesn't let us mirror them, it will be removed in a month (#444322). app-admin/flexlm # Pacho Ramos pa...@gentoo.org (25 Dec 2012) # EOL for a long time as Cisco dropped its support in favor of Anyconnect, # it no longer works with current kernels (#20). Removal in a month. net-misc/cisco-vpnclient-3des # Pacho Ramos pa...@gentoo.org (25 Dec 2012) # Upstream dead for ages, numerous bubgs, uses old tcl (#445206). # Removal in a month. app-emulation/systemsim-cell # Pacho Ramos pa...@gentoo.org (25 Dec 2012) # Fails to build, always links statically (#448288). Removal in a month. sys-block/gcloop # Pacho Ramos pa...@gentoo.org (25 Dec 2012) # Fails to launch (#294013), abandoned, ancient NotEye # replaced it long time ago (#447848). Removal in a month. games-roguelike/noegnud-data games-roguelike/noegnud-nethack games-roguelike/noegnud-slashem signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: [gentoo-dev-announce] Lastrites: media-sound/logitechmediaserver-bin, net-dialup/misdn, net-dialup/misdnuser, net-misc/asterisk-chan_misdn, www-apache/mod_authn_pam, www-apache/mod_cp
El mié, 26-12-2012 a las 17:14 +, Markos Chandras escribió: On Dec 25, 2012 8:33 PM, Pacho Ramos pa...@gentoo.org wrote: # Pacho Ramos pa...@gentoo.org (25 Dec 2012) # Fails to build with libav-9 (#443238). Removal in a month. media-libs/libdlna media-video/ushare This is not a valid reason to remove it. I use it every day. Please remove the masking. You should have contacted me first as I think I am on metadata (haven't checked yet) You were contacted at: https://bugs.gentoo.org/show_bug.cgi?id=443238#c1 But no problem with dropping the mask... the only doubt, should we keep libdlna too or drop optional ushare support for it? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-dev-announce] Lastrites: media-sound/logitechmediaserver-bin, net-dialup/misdn, net-dialup/misdnuser, net-misc/asterisk-chan_misdn, www-apache/mod_authn_pam, www-apache/mo
El mié, 26-12-2012 a las 19:46 +0100, Pacho Ramos escribió: El mié, 26-12-2012 a las 17:14 +, Markos Chandras escribió: On Dec 25, 2012 8:33 PM, Pacho Ramos pa...@gentoo.org wrote: # Pacho Ramos pa...@gentoo.org (25 Dec 2012) # Fails to build with libav-9 (#443238). Removal in a month. media-libs/libdlna media-video/ushare This is not a valid reason to remove it. I use it every day. Please remove the masking. You should have contacted me first as I think I am on metadata (haven't checked yet) You were contacted at: https://bugs.gentoo.org/show_bug.cgi?id=443238#c1 But no problem with dropping the mask... the only doubt, should we keep libdlna too or drop optional ushare support for it? + 26 Dec 2012; Pacho Ramos pa...@gentoo.org package.mask: + Unmask libdlna/ushare as it's still soon to kill libav-9 incompatible + packages (that is still hardmasked) + signature.asc Description: This is a digitally signed message part
[gentoo-dev] app-text/dbacl is up for grabs
Steev contacted me few hours ago to tell me he won't maintain dbacl anymore and, then, it's now up for grabs. Thanks for taking care of it signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El lun, 24-12-2012 a las 00:30 +0100, Pacho Ramos escribió: El lun, 24-12-2012 a las 00:17 +0100, Diego Elio Pettenò escribió: On 23/12/2012 23:54, Pacho Ramos wrote: The idea would be to make it to be only shown at first message and, later, rely on people reading /usr/share/doc/e4rat-xxx/CONFIGURATION file if they want to remember that tip So you want in the main documentation a request to read the package documentation on where to find the upstream documentation? I want to have a permanent reference of current elog messages simply showing configuration tips to: 1. Show them via elog messages only first time package is installed 2. Not need to read ebuild directly once people remove summary.log More examples I saw today when updating: - lm_sensors - shows configuration tips every time it's merged, the idea would be to show it via elog only at first merge and, later, rely on /usr/share/doc file - nvidia-drivers - things like telling people to add them to video group could be treated in the same way, the same probably for eselect instructions. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El dom, 30-12-2012 a las 00:09 +0100, Pacho Ramos escribió:
[...]
I want to have a permanent reference of current elog messages simply
showing configuration tips to:
1. Show them via elog messages only first time package is installed
2. Not need to read ebuild directly once people remove summary.log
This would be the idea (applied in this example to acpid package)
--- /home/pacho/gentoo-x86/sys-power/acpid/acpid-2.0.17.ebuild
2012-11-26 09:20:15.0 +0100
+++ ./acpid-2.0.17.ebuild 2012-12-31 14:18:41.0 +0100
@@ -37,6 +37,13 @@
newconfd ${FILESDIR}/${PN}-2.0.16-conf.d ${PN}
systemd_dounit ${FILESDIR}/systemd/${PN}.{service,socket}
+
+ cat CONFIGURATION -EOF
+ You may wish to read the Gentoo Linux Power Management Guide,
+ which can be found online at:
+ http://www.gentoo.org/doc/en/power-management-guide.xml
+ EOF
+ dodoc CONFIGURATION
}
pkg_postinst() {
Some improvements I am not sure how to implement just now:
- What would be the proper way to elog contents
of /usr/share/doc/${PF}/CONFIGURATION.bz2 and, then, allow the following
to be shorter:
if ! has_version 'sys-power/acpid'; then
elog
elog You may wish to read the Gentoo Linux Power Management
Guide,
elog which can be found online at:
elog http://www.gentoo.org/doc/en/power-management-guide.xml;
elog
fi
?
Thanks for your help
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] What did we achieve in 2012? What are our resolutions for 2013?
El lun, 31-12-2012 a las 22:17 +0800, Ben de Groot escribió: Happy New Year to all of you! Looking back at 2012, I wonder what we consider our achievements for this past year. What is the state of Gentoo? How have we brought it forward and improved it this past year? And what do we want to see in the coming year? How can we make Gentoo more awesome in 2013? I will add my own thoughts later. I first would like to hear from you. EAPI5 and preserve-libs portage feature more near to stable ;) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El lun, 31-12-2012 a las 14:53 -0800, Zac Medico escribió:
On 12/31/2012 05:21 AM, Pacho Ramos wrote:
pkg_postinst() {
Some improvements I am not sure how to implement just now:
- What would be the proper way to elog contents
of /usr/share/doc/${PF}/CONFIGURATION.bz2 and, then, allow the following
to be shorter:
if ! has_version 'sys-power/acpid'; then
elog
elog You may wish to read the Gentoo Linux Power Management
Guide,
elog which can be found online at:
elog http://www.gentoo.org/doc/en/power-management-guide.xml;
elog
fi
?
Thanks for your help
It seems that you're allowed to call the unpack() function in any phase,
so something like this should work:
cd ${T}
cp ${EROOT}/usr/share/doc/${PF}/CONFIGURATION* ./
[ -f ./CONFIGURATION ] || unpack ./CONFIGURATION*
elog $( ./CONFIGURATION)
Thanks a lot for the tip :)
On the other hand, I have seen another way of doing that looking at
kernel-2.eclass:
--- /home/pacho/gentoo-x86/sys-power/acpid/acpid-2.0.17.ebuild
2012-11-26 09:20:15.0 +0100
+++ ./acpid-2.0.17.ebuild 2013-01-01 14:30:18.0 +0100
@@ -17,6 +17,11 @@
RDEPEND=selinux? ( sec-policy/selinux-apm )
DEPEND=${RDEPEND}
+CONFIGURATION_INSTRUCTIONS=
+ You may wish to read the Gentoo Linux Power Management Guide,
+ which can be found online at:
+ http://www.gentoo.org/doc/en/power-management-guide.xml;
+
src_configure() {
econf --docdir=/usr/share/doc/${PF}
}
@@ -37,6 +42,9 @@
newconfd ${FILESDIR}/${PN}-2.0.16-conf.d ${PN}
systemd_dounit ${FILESDIR}/systemd/${PN}.{service,socket}
+
+ echo ${CONFIGURATION_INSTRUCTIONS} | fmt CONFIGURATION
+ dodoc CONFIGURATION
}
pkg_postinst() {
@@ -48,6 +56,8 @@
elog
fi
+ echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do
elog ${ELINE}; done
+
# files/systemd/acpid.socket - ListenStream=/run/acpid.socket
mkdir -p ${ROOT}/run
This could probably be moved to eutils.eclass to use it on this kind of
ebuilds
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El mar, 01-01-2013 a las 14:32 +0100, Pacho Ramos escribió:
[...]
--- /home/pacho/gentoo-x86/sys-power/acpid/acpid-2.0.17.ebuild
2012-11-26 09:20:15.0 +0100
+++ ./acpid-2.0.17.ebuild 2013-01-01 14:30:18.0 +0100
@@ -17,6 +17,11 @@
RDEPEND=selinux? ( sec-policy/selinux-apm )
DEPEND=${RDEPEND}
+CONFIGURATION_INSTRUCTIONS=
+ You may wish to read the Gentoo Linux Power Management Guide,
+ which can be found online at:
+ http://www.gentoo.org/doc/en/power-management-guide.xml;
+
src_configure() {
econf --docdir=/usr/share/doc/${PF}
}
@@ -37,6 +42,9 @@
newconfd ${FILESDIR}/${PN}-2.0.16-conf.d ${PN}
systemd_dounit ${FILESDIR}/systemd/${PN}.{service,socket}
+
+ echo ${CONFIGURATION_INSTRUCTIONS} | fmt CONFIGURATION
+ dodoc CONFIGURATION
}
pkg_postinst() {
@@ -48,6 +56,8 @@
elog
fi
+ echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do
elog ${ELINE}; done
+
# files/systemd/acpid.socket - ListenStream=/run/acpid.socket
mkdir -p ${ROOT}/run
This could probably be moved to eutils.eclass to use it on this kind of
ebuilds
Well, elog part should be behind:
if ! has_version ${CATEGORY}/${PN}; then
echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do elog
${ELINE}; done
fi
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El mar, 01-01-2013 a las 16:01 -0800, Zac Medico escribió:
On 01/01/2013 05:39 AM, Pacho Ramos wrote:
El mar, 01-01-2013 a las 14:32 +0100, Pacho Ramos escribió:
pkg_postinst() {
@@ -48,6 +56,8 @@
elog
fi
+ echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do
elog ${ELINE}; done
+
# files/systemd/acpid.socket - ListenStream=/run/acpid.socket
mkdir -p ${ROOT}/run
This could probably be moved to eutils.eclass to use it on this kind of
ebuilds
Well, elog part should be behind:
if ! has_version ${CATEGORY}/${PN}; then
echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do elog
${ELINE}; done
fi
Not that `has_version ${CATEGORY}/${PN}` is always true in
pkg_postinst, since the package is already installed. So, you should
choose one of these alternatives for it to work as intended:
1) call has_version in pkg_preinst
2) use [[ ${REPLACING_VERSIONS} ]] instead
Yeah, that is true (and looks like current acpid ebuild is buggy in
this). I wouldn't have any problem on either solution, but using first
one would work in all eapis, is there any reason for printing this kind
of messages in pkg_postinst?
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] app-text/dbacl is up for grabs
El jue, 27-12-2012 a las 21:40 +0100, Amadeusz Żołnowski escribió: Quoting Pacho Ramos (2012-12-27 12:20:11) Steev contacted me few hours ago to tell me he won't maintain dbacl anymore and, then, it's now up for grabs. Thanks for taking care of it If nobody is interested I can take it. I guess nobody will take it in the near future, feel free to edit its metadata (I fixed some days ago his opened bugs, it's now clean then ;) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ship app-arch/pbzip2 instead of app-arch/bzip2
El lun, 29-10-2012 a las 10:39 -0400, Rich Freeman escribió: On Mon, Oct 29, 2012 at 10:13 AM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: I'm confident no one would attempt to block my adding eselect-bzip2 to the tree (aside from my poor coding skills), ++ but would anyone be interested in blocking using lbzip2 by default? It seems pretty safe and I've done dozens of full system builds etc. Why not just make it an option to start, advertise it by all means, and then see how it turns out with volunteers before we make it the default. Going from nobody-has-heard-of-it to default overnight seems a bit much. Rich How this ended finally? :/ Thanks for the info! signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: About unresolved bugs assigned to voip for ages
El jue, 11-10-2012 a las 08:13 +0200, Pacho Ramos escribió: El mié, 10-10-2012 a las 20:11 -0400, Jesus Rivero (Neurogeek) escribió: On Wed, Oct 10, 2012 at 5:53 PM, Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Pacho Ramos schrieb: I am noticing for a long time that bugs related with ekiga, opal, yate... are completely unattended by voip team for years. If nobody from that team is willing to maintain them, please move them to maintainer-needed to, at least, reflect reality. Any news here? I can move that packages to maintainer-needed if you send me the list of packages you don't want to maintain. Also, maybe telepathy stuff could be moved to its own herd (that is basically gnome team + tester... or maybe tester could join gnome team ;)) There is now one proxy maintainer for a couple of packages, he is currently waiting for voip overlay access in bug 437538. He will take care of linphone and related packages (see bug 399735 and its dependencies). Regarding the packages that can be moved to maintainer-needed: I think a good heuristic is if the package has several open bugs with no maintainer reaction, and hasn't been touched by anyone from voip herd in over a year. This would include the ekiga, opal and yate packages mentioned above. I'd gladly take maintainership of opal and ekiga, if nobody wants them. Cheers, Would be nice as they need a lot of bumps and pending work Looks like finally you added yourself to metadata but with instructions to bug-wranglers to CC you and assign to herd. I would like to confirm this way of assigning things with both as voip herd people didn't touch ekiga related packages and, also, would be better to clarify things before me going to their bugs and assigning them properly to comply current metadatas (as I have seen some ekiga bugs still only assigned to voip herd without you CCed) Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
El mar, 25-09-2012 a las 10:21 -0300, Alexis Ballier escribió: On Sun, 23 Sep 2012 16:49:13 +0200 Thomas Sachau to...@gentoo.org wrote: It is not hard by itself to inherit an eclass. There is just the limitation, that occurs with an eclass, e.g.: -the one from mgorny only does it for autotools based ebuilds only and even there only for libraries, headers and binaries are not done. While one may create the same for cmake based ones, those are still only for a subset of packages, since not all do use autotools/cmake or are satisfied with a libs only solution -the multilib-native eclass does extend it way more, but still has its limitations, e.g. what happens with a new target ABI (like x32 on the amd64 profile) or how are dependencies handled? multilib-portage is the answer to those limitations, since it does work for any target with multilib cross-compile support, can handle things like the dependencies internally and can even work on not prepared/modified ebuilds. So before i invest even more time in getting this official, we should better get to some conclusion, if we either go the route with eclass based multilib cross-compile support with its limitations or if we move this up to the package manager level. Can't we get something in between ? Unless I'm mistaken, portage-multilib has its limitations also: - I have package foo and package bar, both depending on ffmpeg and canditates for a multilib build. However, package foo does not link to ffmpeg but simply spawns the 'ffmpeg' binary to process some files, package bar links to libavcodec. You need ffmpeg[multilib] for a multilib build of bar but not for foo. How do you distinguish between the two ? - When an out-of-tree build is possible, it is more efficient to do it that way while multilib-portage will probably run the full src_* phases twice. mgorny's eclass is a solution to this for autotools-utils based ebuilds. I have added basic support for this in freebsd-lib some time ago also. However, it is clear that USE=multilib is limited too. What we probably need, as I read in the draft you posted some time ago, is a MULTILIB_ABI use-expand. Keep a list of all the MULTILIB_ABIs in an eclass, add them to IUSE of multilib-enabled packages and then you can use the USE-deps. When a new ABI gets added, add it to the list in the eclass and be done. You already have PM support for this :) You can leverage the generic multilib building code you have to an eclass, so that you don't need to spec it; spec-ing it has its problems too: what happens if next year pkg-config is deprecated and now we shall all use foo-config ? your spec adjusts PKG_CONFIG_PATH but not FOO_CONFIG_PATH. You probably need a small EAPI change to be able to implement sanely a generic solution into an eclass though. My question to you would be: what are we missing from current EAPIs to be able to perfectly support multilib builds ? A. What finally occurred with this? What would be the problem of opting by this mixed solution (eclass for some packages and PM features requiring newer eapi for others)? Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Make connman a global USE flag
El sáb, 21-07-2012 a las 13:51 +0200, Pacho Ramos escribió: Several packages are using it with the same sense (support connman), maybe we should move it from local to global USEs, what do you think? Will proceed then ;) signature.asc Description: This is a digitally signed message part
[gentoo-dev] About *ECLASS_ONCE_* stuff at top of some eclasses but not others
What is the purpose of this stuff:
if [[ ${___ECLASS_ONCE_EUTILS} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_EUTILS=recur -_+^+_- spank
and similar in some eclasses (like eutils, multilib) but not others
(like python-single-r1 that I was looking some days ago for learning how
to use it)?
Thanks a lot for the info
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Re: About unresolved bugs assigned to voip for ages
El jue, 03-01-2013 a las 00:43 +0100, Chí-Thanh Christopher Nguyễn escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pacho Ramos schrieb: Looks like finally you added yourself to metadata but with instructions to bug-wranglers to CC you and assign to herd. I would like to confirm this way of assigning things The difference is almost inconsequential in practice. Bugmail will be sent to both assignee and CC:. Only for maintainers without bugzilla privileges they need to ping their proxy to make certain updates to the bug. x11 team has similar instructions in the metadata for their proxy maintained package. Best regards, Chí-Thanh Christopher Nguyễn Well, I was referring to this exact case as voip team already pointed they weren't looking to ekiga stuff and, then, didn't had much sense to me to see bugs assigned to them instead of real maintainer (will commit access) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About *ECLASS_ONCE_* stuff at top of some eclasses but not others
El mié, 02-01-2013 a las 18:59 -0500, Mike Gilbert escribió:
On 1/2/2013 6:54 PM, Mike Gilbert wrote:
On 1/2/2013 6:41 PM, Pacho Ramos wrote:
What is the purpose of this stuff:
if [[ ${___ECLASS_ONCE_EUTILS} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_EUTILS=recur -_+^+_- spank
and similar in some eclasses (like eutils, multilib) but not others
(like python-single-r1 that I was looking some days ago for learning how
to use it)?
Thanks a lot for the info
It prevents eclasses from being sourced more than once. It is meant as a
performance enhancement for when eclasses inherit other eclasses. vapier
posted some stats on this list a while back.
We have a similar thing in python-single-r1. We call it
_PYTHON_SINGLE_R1 and assign a value of 1 at the bottom of the eclass.
Here's the thread.
http://archives.gentoo.org/gentoo-dev/msg_18dab542c1c59873f8cb68c96cdf6619.xml
OK thanks, maybe this should be added to devmanual as looks like it's
not documented apart of gentoo-dev list :/
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Re: About unresolved bugs assigned to voip for ages
El jue, 03-01-2013 a las 12:41 +0100, Pacho Ramos escribió: [...] Well, I was referring to this exact case as voip team already pointed they weren't looking to ekiga stuff and, then, didn't had much sense to me to see bugs assigned to them instead of real maintainer (will commit access) will - with signature.asc Description: This is a digitally signed message part
[gentoo-dev] configuration-doc.eclass: an eclass to install a CONFIGURATION doc file and show an elog message first time package is installed
This comes from the following gentoo-dev thread:
http://www.gossamer-threads.com/lists/gentoo/dev/264888
Its usage will lead to the installation of a CONFIGURATION file
under /usr/share/doc/${PF} and show of elog messages with its content
first time package is installed, relying in doc file for future
installations or people simply going there to review configuration tips.
I also attach acpid ebuild as example.
Currently I have doubts about how to handle formatting, it is now using
fmt as kernel-2.eclass to format it and, then, you can set:
CONFIGURATION_INSTRUCTIONS=
You may wish to read the Gentoo Linux Power Management Guide,
which can be found online at:
http://www.gentoo.org/doc/en/power-management-guide.xml;
and it will be properly formatted at the end. The problem is that I find
no way to force a jump to a new line (for example if somebody want to
show a command to run in a new line).
Other option would be to simply add quotes to:
echo ${CONFIGURATION_INSTRUCTIONS}
and drop fmt usage.
It will respect formatting specified in ebuild, but this needs to be
taken into account as, for example, acpid ebuild used as example should
be changed to use:
CONFIGURATION_INSTRUCTIONS=You may wish to read the Gentoo Linux Power
Management Guide,
which can be found online at:
http://www.gentoo.org/doc/en/power-management-guide.xml;
or people will get an empty line at the top of the messages.
Maybe an option to toggle fmt/formatting usage could be used, but I am
unsure about how to handle it at eclass level in a short way (I could
add some ifs running either variant (with quotes or without them and
fmt usage), but not sure if a shorter way could be used)
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: configuration-doc
# @MAINTAINER:
# Pacho Ramos pa...@gentoo.org
# @AUTHOR:
# Author: Pacho Ramos pa...@gentoo.org
# @BLURB: An eclass for installing a CONFIGURATION doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
# @DESCRIPTION:
# An eclass for installing a CONFIGURATION doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
if [[ ${___ECLASS_ONCE_CONFIGURATION_DOC} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_CONFIGURATION_DOC=recur -_+^+_- spank
inherit eutils
case ${EAPI:-0} in
0|1|2|3)
die Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}
;;
4|5)
# EAPI=4 is required for REPLACING_VERSIONS preventing us
# from needing to export another pkg_preinst phase to save
has_version
# result. Also relies on EAPI =4 default src_install phase.
;;
*)
die Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}
;;
esac
EXPORT_FUNCTIONS src_install pkg_postinst
# @FUNCTION: configuration_create_doc
# @DESCRIPTION:
# Create doc file with CONFIGURATION_INSTRUCTIONS contents.
# Usually called at src_install phase.
configuration_create_doc() {
debug-print-function ${FUNCNAME} ${@}
if [[ -n ${CONFIGURATION_INSTRUCTIONS} ]]; then
eshopts_push
set -f
echo ${CONFIGURATION_INSTRUCTIONS} | fmt CONFIGURATION
eshopts_pop
dodoc CONFIGURATION
fi
}
# @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
if ! [[ ${REPLACING_VERSIONS} ]]; then
eshopts_push
set -f
echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read
-r ELINE; do elog ${ELINE}; done
eshopts_pop
fi
fi
}
# @FUNCTION: configuration-doc_src_install
# @DESCRIPTION:
# Show elog messages from CONFIGURATION_INSTRUCTIONS variable, that will be
# shared with /usr/share/doc/${PF}/CONFIGURATION content.
configuration-doc_src_install() {
debug-print-function ${FUNCNAME} ${@}
default
configuration_create_doc
}
# @FUNCTION: configuration-doc_pkg_postinst
# @DESCRIPTION:
# Show elog messages from CONFIGURATION_INSTRUCTIONS variable, that will be
# shared with /usr/share/doc/${PF}/CONFIGURATION content.
configuration-doc_pkg_postinst() {
debug-print-function ${FUNCNAME} ${@}
configuration_print_elog
}
fi
# Copyright 1999-2012 Gentoo Foundation
# Distributed under
Re: [gentoo-dev] Re: About unresolved bugs assigned to voip for ages
El jue, 03-01-2013 a las 09:33 -0500, Jesus Rivero (Neurogeek) escribió: On Jan 3, 2013 6:54 AM, Pacho Ramos pa...@gentoo.org wrote: El jue, 03-01-2013 a las 12:41 +0100, Pacho Ramos escribió: [...] Well, I was referring to this exact case as voip team already pointed they weren't looking to ekiga stuff and, then, didn't had much sense to me to see bugs assigned to them instead of real maintainer (will commit access) will - with Pacho, I have been taking care of ekiga, ptlib and opal. Feel free to make me the assignee for bugs in those packages. I should be on metadata for those... Thanks, will then assign to you and CC herd, if voip people want to completely drop, please talk! signature.asc Description: This is a digitally signed message part
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 14:29 -0600, William Hubbs escribió:
[...]
case ${EAPI:-0} in
0|1|2|3)
die Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}
;;
4|5)
# EAPI=4 is required for REPLACING_VERSIONS preventing us
# from needing to export another pkg_preinst phase to save
has_version
# result. Also relies on EAPI =4 default src_install phase.
;;
*)
die Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}
;;
esac
Why does it matter if the unsupported eapi is too old or unknown? I
think you can combine the first and last branches of this case
statement.
Well, I saw it in other eclasses and thought the distinction was
preferred, but have no problems on changing it
On the other hand, if you don't export phase functions, you don't have
to worry about EAPIS; you can just allow ebuild developers to call your
functions directly. This is what I see happening in your sample ebuild
below.
It exports src_install and pkg_postinst, at least the second one could
be used in other ebuilds that are only setting a package specific one
for showing this kind of messages (for example bumblebee ebuilds).
For src_install case, probably some other ebuilds could benefit, but
didn't find them when I fast checked yesterday :/. Its purpose is to
ensure doc CONFIGURATION file is created, the ideal would be to be able
to only add it to create it and leave other eclasses or eapi defaults to
handle the rest of src_install, but I think it's not possible :| (and,
then, it will behave like eapi = 4 default src_install phase + creating
the file)
Anyway, EAPI = 4 is still needed for REPLACING_VERSIONS usage, that
allows to simplify things preventing us from needing to set pkg_preinst
also
EXPORT_FUNCTIONS src_install pkg_postinst
Drop this export_functions call. You don't need it based on what I see
in your ebuild.
They can be needed if ebuild doesn't need to have a custom
src_install/pkg_postinst only for this purposes
# @FUNCTION: configuration_create_doc
# @DESCRIPTION:
# Create doc file with CONFIGURATION_INSTRUCTIONS contents.
# Usually called at src_install phase.
You can pass in the content as $1 instead of using a global variable for
it:
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)
configuration_create_doc() {
debug-print-function ${FUNCNAME} ${@}
if [[ -n ${1} ]]; then
eshopts_push
set -f
echo ${CONFIGURATION_INSTRUCTIONS} | fmt CONFIGURATION
I would use ${T}/CONFIGURATION here.
echo ${1} | fmt ${T}CONFIGURATION
eshopts_pop
dodoc CONFIGURATION
Again, ${T}/CONFIGURATION
I have no problem but, what is its advantage? (to remember it more
easily next time). Thanks :)
fi
}
# @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?
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.
The eclass could, of course, be handled to also handle this cases, but I
would like to keep the automatic way of it showing the message only
first time package is installed.
[...]
CONFIGURATION_INSTRUCTIONS=
You may wish to read the Gentoo Linux Power Management Guide,
which can be found online at:
http://www.gentoo.org/doc/en/power-management-guide.xml;
Delete this and make it a local below if you want the variable,
otherwise pass it as a constant.
sorry for the ignorance but, how should I pass it as a constant? Using
readonly? Also, I am not using here any external tool and, then,
global scope shouldn't be discouraged
src_configure() {
econf --docdir=/usr/share/doc/${PF}
}
src_install() {
emake DESTDIR=${D} install
newdoc kacpimon/README
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] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El lun, 07-01-2013 a las 10:34 +0100, Pacho Ramos escribió:
[...]
This will install a README.gentoo file
But there are still pending issues I don't know how to handle:
- Eclass was originally oriented to cover those kind of messages that
could be shown by elog first time the package is merged and, later, rely
on people reading that README.gentoo
- William asked for version checking support, in that case, what kind of
version checking should be covered?
- Should I rely on versionator.eclass or use /? I can see both forms
in the tree right now
- There are also a lot of exotic version checkings in the tree (please
grep looking for REPLACING_VERSIONS to see them) that I doubt we should
cover in eclass but, in that case, how to cover them also?
- A suggestion about looking for ${FILESDIR}/README.gentoo has also
raised, in that case, should eclass look for either option (now
DOC_CONTENTS variable or ${FILESDIR}/README.gentoo)
This changes the name of eclass to readme.gentoo.eclass and gets
information from ${FILESDIR}/README.gentoo
Please take a look to it
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: readme.gentoo
# @MAINTAINER:
# Pacho Ramos pa...@gentoo.org
# @AUTHOR:
# Author: Pacho Ramos pa...@gentoo.org
# @BLURB: An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
# @DESCRIPTION:
# An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
if [[ ${___ECLASS_ONCE_README_GENTOO} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_README_GENTOO=recur -_+^+_- spank
inherit eutils
case ${EAPI:-0} in
0|1|2|3)
die Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}
;;
4|5)
# EAPI=4 is required for REPLACING_VERSIONS preventing us
# from needing to export another pkg_preinst phase to save has_version
# result. Also relies on EAPI =4 default src_install phase.
;;
*)
die Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}
;;
esac
EXPORT_FUNCTIONS src_install pkg_postinst
# @FUNCTION: readme.gentoo_create_doc
# @DESCRIPTION:
# Create doc file with ${FILESDIR}/README.gentoo contents.
# Usually called at src_install phase.
readme.gentoo_create_doc() {
debug-print-function ${FUNCNAME} ${@}
if [[ -f ${FILESDIR}/README.gentoo ]]; then
touch ${T}/README.gentoo.src_install
dodoc ${FILESDIR}/README.gentoo
else
die ${FILESDIR}/README.gentoo doesn't exist!
fi
}
# @FUNCTION: readme.gentoo_print_elog
# @DESCRIPTION:
# Print elog messages with DOC_CONTENTS contents.
# Usually called at pkg_postinst phase.
readme.gentoo_print_elog() {
debug-print-function ${FUNCNAME} ${@}
if [[ -f ${FILESDIR}/README.gentoo ]]; then
if ! [[ ${REPLACING_VERSIONS} ]]; then
eshopts_push
set -f
if [ -f ${T}/README.gentoo.src_install ]; then
cat ${FILESDIR}/README.gentoo | fmt | while read -r ELINE; do elog ${ELINE}; done
else
die ${T}/README.gentoo.src_install is missing, did you forget to call readme.gentoo_create_doc function?
fi
eshopts_pop
fi
else
die ${FILESDIR}/README.gentoo doesn't exist!
fi
}
# @FUNCTION: readme.gentoo_src_install
# @DESCRIPTION:
# Show elog messages from DOC_CONTENTS variable, that will be
# shared with /usr/share/doc/${PF}/README.gentoo content.
readme.gentoo_src_install() {
debug-print-function ${FUNCNAME} ${@}
default
readme.gentoo_create_doc
}
# @FUNCTION: readme.gentoo_pkg_postinst
# @DESCRIPTION:
# Show elog messages from DOC_CONTENTS variable, that will be
# shared with /usr/share/doc/${PF}/README.gentoo content.
readme.gentoo_pkg_postinst() {
debug-print-function ${FUNCNAME} ${@}
readme.gentoo_print_elog
}
fi
# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/sys-power/acpid/acpid-2.0.17.ebuild,v 1.7
2013/01/03 12:59:15 miska Exp $
EAPI=4
inherit systemd readme.gentoo
DESCRIPTION=Daemon for Advanced Configuration and Power Interface
HOMEPAGE=http://tedfelix.com/linux/acpid-netlink.html;
SRC_URI=http://tedfelix.com/linux/${P}.tar.xz;
LICENSE=GPL-2
SLOT=0
KEYWORDS=amd64 ia64 -ppc x86
IUSE=selinux
RDEPEND=selinux? ( sec-policy/selinux-apm )
DEPEND=${RDEPEND}
src_configure() {
econf --docdir=/usr/share/doc/${PF}
}
src_install() {
emake DESTDIR=${D} install
newdoc kacpimon/README README.kacpimon
dodoc -r samples
rm -f ${D}/usr/share/doc/${PF}/COPYING
exeinto /etc/acpi
newexe ${FILESDIR}/${PN}-1.0.6-default.sh default.sh
insinto /etc/acpi/events
newins ${FILESDIR
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El mié, 09-01-2013 a las 12:04 -0800, Zac Medico escribió:
On 01/09/2013 11:53 AM, Pacho Ramos wrote:
This changes the name of eclass to readme.gentoo.eclass and gets
information from ${FILESDIR}/README.gentoo
What if there are multiple versions/slots that have different
README.gentoo content? Maybe the eclass should accommodate that somehow?
I would go for versioning it as ${FILESDIR}/README.gentoo-${PV} but,
in that case, I wouldn't know how to make it pick major
README.gentoo-${PV} to prevent people from needing to have one
README.gentoo-${PV} per version :S
Different slots shouldn't need any special handling as their docs should
be installed in their docdir/${PF}
But the anterior variable idea looks to solve this problem much
better :|
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El mié, 09-01-2013 a las 22:15 +0100, Pacho Ramos escribió:
El mié, 09-01-2013 a las 12:04 -0800, Zac Medico escribió:
On 01/09/2013 11:53 AM, Pacho Ramos wrote:
This changes the name of eclass to readme.gentoo.eclass and gets
information from ${FILESDIR}/README.gentoo
What if there are multiple versions/slots that have different
README.gentoo content? Maybe the eclass should accommodate that somehow?
I would go for versioning it as ${FILESDIR}/README.gentoo-${PV} but,
in that case, I wouldn't know how to make it pick major
README.gentoo-${PV} to prevent people from needing to have one
README.gentoo-${PV} per version :S
Different slots shouldn't need any special handling as their docs should
be installed in their docdir/${PF}
But the anterior variable idea looks to solve this problem much
better :|
Maybe the best option would be to:
1. At first look for variable in ebuild
2. If not set, look for ${FILESDIR}/README.gentoo
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El mié, 09-01-2013 a las 12:04 -0800, Zac Medico escribió:
On 01/09/2013 11:53 AM, Pacho Ramos wrote:
This changes the name of eclass to readme.gentoo.eclass and gets
information from ${FILESDIR}/README.gentoo
What if there are multiple versions/slots that have different
README.gentoo content? Maybe the eclass should accommodate that somehow?
This should work, it will read DOC_CONTENTS variable from ebuild and, if
not set, rely on common ${FILESDIR}/README.gentoo
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: readme.gentoo
# @MAINTAINER:
# Pacho Ramos pa...@gentoo.org
# @AUTHOR:
# Author: Pacho Ramos pa...@gentoo.org
# @BLURB: An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
# @DESCRIPTION:
# An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
if [[ ${___ECLASS_ONCE_README_GENTOO} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_README_GENTOO=recur -_+^+_- spank
inherit eutils
case ${EAPI:-0} in
0|1|2|3)
die Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}
;;
4|5)
# EAPI=4 is required for REPLACING_VERSIONS preventing us
# from needing to export another pkg_preinst phase to save has_version
# result. Also relies on EAPI =4 default src_install phase.
;;
*)
die Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}
;;
esac
EXPORT_FUNCTIONS src_install pkg_postinst
# @FUNCTION: readme.gentoo_create_doc
# @DESCRIPTION:
# Create doc file with ${DOC_CONTENTS} variable and, if not set,
# with ${FILESDIR}/README.gentoo contents.
# Usually called at src_install phase.
readme.gentoo_create_doc() {
debug-print-function ${FUNCNAME} ${@}
if [[ -n ${DOC_CONTENTS} ]]; then
eshopts_push
set -f
echo ${DOC_CONTENTS} | fmt ${T}/README.gentoo
eshopts_pop
dodoc ${T}/README.gentoo
else
if [[ -f ${FILESDIR}/README.gentoo ]]; then
cp ${FILESDIR}/README.gentoo ${T}/README.gentoo
dodoc ${T}/README.gentoo
else
die You are not specifying README.gentoo contents!
fi
fi
}
# @FUNCTION: readme.gentoo_print_elog
# @DESCRIPTION:
# Print elog messages with ${T}/README.gentoo contents.
# Usually called at pkg_postinst phase.
readme.gentoo_print_elog() {
debug-print-function ${FUNCNAME} ${@}
if [[ -f ${T}/README.gentoo ]]; then
if ! [[ ${REPLACING_VERSIONS} ]]; then
eshopts_push
set -f
cat ${T}/README.gentoo | fmt | while read -r ELINE; do elog ${ELINE}; done
eshopts_pop
fi
else
die README.gentoo wasn't created at src_install!
fi
}
# @FUNCTION: readme.gentoo_src_install
# @DESCRIPTION:
# Show elog messages from DOC_CONTENTS variable, that will be
# shared with /usr/share/doc/${PF}/README.gentoo content.
readme.gentoo_src_install() {
debug-print-function ${FUNCNAME} ${@}
default
readme.gentoo_create_doc
}
# @FUNCTION: readme.gentoo_pkg_postinst
# @DESCRIPTION:
# Show elog messages from DOC_CONTENTS variable, that will be
# shared with /usr/share/doc/${PF}/README.gentoo content.
readme.gentoo_pkg_postinst() {
debug-print-function ${FUNCNAME} ${@}
readme.gentoo_print_elog
}
fi
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El sáb, 12-01-2013 a las 02:01 -0800, Zac Medico escribió:
On 01/12/2013 01:46 AM, Pacho Ramos wrote:
El mié, 09-01-2013 a las 12:04 -0800, Zac Medico escribió:
On 01/09/2013 11:53 AM, Pacho Ramos wrote:
This changes the name of eclass to readme.gentoo.eclass and gets
information from ${FILESDIR}/README.gentoo
What if there are multiple versions/slots that have different
README.gentoo content? Maybe the eclass should accommodate that somehow?
This should work, it will read DOC_CONTENTS variable from ebuild and, if
not set, rely on common ${FILESDIR}/README.gentoo
You might add a loop to search for a version-specific README.gentoo,
like this:
file=
for suffix in -${PV} -${PV}-${PR} ; do
[[ -f ${FILESDIR}/README.gentoo${suffix} ]] \
file=${FILESDIR}/README.gentoo${suffix} break
done
if [[ ${file} ]] ; then
cp ${file} ${T}/README.gentoo
dodoc ${T}/README.gentoo
fi
Thank for explaining me how to do that. The problem is that I doubt if
it would really be useful as we usually won't need whan README.gentoo
per version, only to update if for some special cases from time to
time :/
For example: foo-1.0 relies on common README.gentoo file, foo-1.1 adds
new feature and, then, would use README.gentoo-1.1 file... but foo-1.2
will probably use the same README.gentoo-1.1 file :|
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El sáb, 12-01-2013 a las 11:34 +0100, Pacho Ramos escribió: [...] Thank for explaining me how to do that. The problem is that I doubt if it would really be useful as we usually won't need whan README.gentoo per version, only to update if for some special cases from time to time :/ [...] whan - one :S signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El sáb, 12-01-2013 a las 04:49 -0800, Zac Medico escribió:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/12/2013 02:34 AM, Pacho Ramos wrote:
El sáb, 12-01-2013 a las 02:01 -0800, Zac Medico escribió:
On 01/12/2013 01:46 AM, Pacho Ramos wrote:
El mié, 09-01-2013 a las 12:04 -0800, Zac Medico escribió:
On 01/09/2013 11:53 AM, Pacho Ramos wrote:
This changes the name of eclass to readme.gentoo.eclass and
gets information from ${FILESDIR}/README.gentoo
What if there are multiple versions/slots that have
different README.gentoo content? Maybe the eclass should
accommodate that somehow?
This should work, it will read DOC_CONTENTS variable from
ebuild and, if not set, rely on common
${FILESDIR}/README.gentoo
You might add a loop to search for a version-specific
README.gentoo, like this:
file= for suffix in -${PV} -${PV}-${PR} ; do [[ -f
${FILESDIR}/README.gentoo${suffix} ]] \
file=${FILESDIR}/README.gentoo${suffix} break done if [[
${file} ]] ; then cp ${file} ${T}/README.gentoo dodoc
${T}/README.gentoo fi
Thank for explaining me how to do that. The problem is that I doubt
if it would really be useful as we usually won't need whan
README.gentoo per version, only to update if for some special cases
from time to time :/
For example: foo-1.0 relies on common README.gentoo file, foo-1.1
adds new feature and, then, would use README.gentoo-1.1 file... but
foo-1.2 will probably use the same README.gentoo-1.1 file :|
Still, it maybe it would be reasonable to use a different
README.gentoo for each SLOT, it there's more than one? Maybe it makes
more sense to have another variable like DOC_CONTENTS, but have it
refer to a filename? Then you should have multiple revisions of an
ebuild refer to the same file, without having to have duplicate
CONTENTS settings.
- --
Thanks,
Zac
What about this approach?
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: readme.gentoo
# @MAINTAINER:
# Pacho Ramos pa...@gentoo.org
# @AUTHOR:
# Author: Pacho Ramos pa...@gentoo.org
# @BLURB: An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
# @DESCRIPTION:
# An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
if [[ ${___ECLASS_ONCE_README_GENTOO} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_README_GENTOO=recur -_+^+_- spank
inherit eutils
case ${EAPI:-0} in
0|1|2|3)
die Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}
;;
4|5)
# EAPI=4 is required for REPLACING_VERSIONS preventing us
# from needing to export another pkg_preinst phase to save has_version
# result. Also relies on EAPI =4 default src_install phase.
;;
*)
die Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}
;;
esac
EXPORT_FUNCTIONS src_install pkg_postinst
# @FUNCTION: readme.gentoo_create_doc
# @DESCRIPTION:
# Create doc file with ${DOC_CONTENTS} variable and, if not set,
# with ${FILESDIR}/README.gentoo contents.
# Usually called at src_install phase.
readme.gentoo_create_doc() {
debug-print-function ${FUNCNAME} ${@}
if [[ -n ${DOC_CONTENTS} ]]; then
eshopts_push
set -f
echo ${DOC_CONTENTS} | fmt ${T}/README.gentoo
eshopts_pop
dodoc ${T}/README.gentoo
else
if [[ -f ${FILESDIR}/README.gentoo-${SLOT} ]]; then
cp ${FILESDIR}/README.gentoo-${SLOT} ${T}/README.gentoo
dodoc ${T}/README.gentoo
else
if [[ -f ${FILESDIR}/README.gentoo ]]; then
cp ${FILESDIR}/README.gentoo ${T}/README.gentoo
dodoc ${T}/README.gentoo
else
die You are not specifying README.gentoo contents!
fi
fi
fi
}
# @FUNCTION: readme.gentoo_print_elog
# @DESCRIPTION:
# Print elog messages with ${T}/README.gentoo contents.
# Usually called at pkg_postinst phase.
readme.gentoo_print_elog() {
debug-print-function ${FUNCNAME} ${@}
if [[ -f ${FILESDIR}/README.gentoo-${SLOT} ]]; then
if [[ -f ${T}/README.gentoo ]]; then
if ! [[ ${REPLACING_VERSIONS}:${SLOT} ]]; then
eshopts_push
set -f
cat ${T}/README.gentoo | fmt | while read -r ELINE; do elog ${ELINE}; done
eshopts_pop
fi
else
die README.gentoo wasn't created at src_install!
fi
else
if [[ -f ${T}/README.gentoo ]]; then
if ! [[ ${REPLACING_VERSIONS} ]]; then
eshopts_push
set -f
cat ${T}/README.gentoo | fmt | while read -r ELINE; do elog ${ELINE}; done
eshopts_pop
fi
else
die README.gentoo wasn't created at src_install!
fi
fi
}
# @FUNCTION: readme.gentoo_src_install
# @DESCRIPTION:
# Show elog messages from DOC_CONTENTS variable
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El dom, 13-01-2013 a las 04:54 -0800, Zac Medico escribió:
On 01/13/2013 04:18 AM, Pacho Ramos wrote:
What about this approach?
You should use ${SLOT%/*}, in order to exclude the sub-slot, because you
don't care about the sub-slot and the slash would cause problems.
Thanks, updated eclass attached
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: readme.gentoo
# @MAINTAINER:
# Pacho Ramos pa...@gentoo.org
# @AUTHOR:
# Author: Pacho Ramos pa...@gentoo.org
# @BLURB: An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
# @DESCRIPTION:
# An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
if [[ ${___ECLASS_ONCE_README_GENTOO} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_README_GENTOO=recur -_+^+_- spank
inherit eutils
case ${EAPI:-0} in
0|1|2|3)
die Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}
;;
4|5)
# EAPI=4 is required for REPLACING_VERSIONS preventing us
# from needing to export another pkg_preinst phase to save has_version
# result. Also relies on EAPI =4 default src_install phase.
;;
*)
die Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}
;;
esac
EXPORT_FUNCTIONS src_install pkg_postinst
# @FUNCTION: readme.gentoo_create_doc
# @DESCRIPTION:
# Create doc file with ${DOC_CONTENTS} variable and, if not set,
# with ${FILESDIR}/README.gentoo contents.
# Usually called at src_install phase.
readme.gentoo_create_doc() {
debug-print-function ${FUNCNAME} ${@}
if [[ -n ${DOC_CONTENTS} ]]; then
eshopts_push
set -f
echo ${DOC_CONTENTS} | fmt ${T}/README.gentoo
eshopts_pop
dodoc ${T}/README.gentoo
else
if [[ -f ${FILESDIR}/README.gentoo-${SLOT%/*} ]]; then
cp ${FILESDIR}/README.gentoo-${SLOT%/*} ${T}/README.gentoo
dodoc ${T}/README.gentoo
else
if [[ -f ${FILESDIR}/README.gentoo ]]; then
cp ${FILESDIR}/README.gentoo ${T}/README.gentoo
dodoc ${T}/README.gentoo
else
die You are not specifying README.gentoo contents!
fi
fi
fi
}
# @FUNCTION: readme.gentoo_print_elog
# @DESCRIPTION:
# Print elog messages with ${T}/README.gentoo contents.
# Usually called at pkg_postinst phase.
readme.gentoo_print_elog() {
debug-print-function ${FUNCNAME} ${@}
if [[ -f ${FILESDIR}/README.gentoo-${SLOT%/*} ]]; then
if [[ -f ${T}/README.gentoo ]]; then
if ! [[ ${REPLACING_VERSIONS}:${SLOT%/*} ]]; then
eshopts_push
set -f
cat ${T}/README.gentoo | fmt | while read -r ELINE; do elog ${ELINE}; done
eshopts_pop
fi
else
die README.gentoo wasn't created at src_install!
fi
else
if [[ -f ${T}/README.gentoo ]]; then
if ! [[ ${REPLACING_VERSIONS} ]]; then
eshopts_push
set -f
cat ${T}/README.gentoo | fmt | while read -r ELINE; do elog ${ELINE}; done
eshopts_pop
fi
else
die README.gentoo wasn't created at src_install!
fi
fi
}
# @FUNCTION: readme.gentoo_src_install
# @DESCRIPTION:
# Show elog messages from DOC_CONTENTS variable, that will be
# shared with /usr/share/doc/${PF}/README.gentoo content.
readme.gentoo_src_install() {
debug-print-function ${FUNCNAME} ${@}
default
readme.gentoo_create_doc
}
# @FUNCTION: readme.gentoo_pkg_postinst
# @DESCRIPTION:
# Show elog messages from DOC_CONTENTS variable, that will be
# shared with /usr/share/doc/${PF}/README.gentoo content.
readme.gentoo_pkg_postinst() {
debug-print-function ${FUNCNAME} ${@}
readme.gentoo_print_elog
}
fi
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Lifting the HOMEPAGE requirement for ebuilds
El lun, 14-01-2013 a las 18:15 +0100, hasufell escribió: [...] +1 to allow empty/missing HOMEPAGE variable dead homepage = useless http://gentoo.org = useless https://bugs.gentoo.org = too obvious An empty homepage usually means the package is dead. I'd rather see the cvs/git/svn url being used as HOMEPAGE in case your tiny little script has no proj page at all. No, an empty homepage just means upstream is dead. There are numerous examples of years old packages still working fine without a single update. Other option is to use gentoo.org as HOMEPAGE for that packages (as some of them are already doing). But, since people think it's useless, why not use as HOMEPAGE http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/... ? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Lifting the HOMEPAGE requirement for ebuilds
El lun, 14-01-2013 a las 15:49 -0500, Ian Stakenvicius escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 14/01/13 03:15 PM, Pacho Ramos wrote: El lun, 14-01-2013 a las 18:15 +0100, hasufell escribió: [...] +1 to allow empty/missing HOMEPAGE variable dead homepage = useless http://gentoo.org = useless https://bugs.gentoo.org = too obvious An empty homepage usually means the package is dead. I'd rather see the cvs/git/svn url being used as HOMEPAGE in case your tiny little script has no proj page at all. No, an empty homepage just means upstream is dead. There are numerous examples of years old packages still working fine without a single update. Other option is to use gentoo.org as HOMEPAGE for that packages (as some of them are already doing). But, since people think it's useless, why not use as HOMEPAGE http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/... ? Or what about a URL to a wiki.gentoo.org page for dead upstream packages? Well, the advantage of using sources.gentoo.org is that people will find there patches and stuff related with the package :/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El lun, 14-01-2013 a las 01:29 -0800, Zac Medico escribió:
On 01/13/2013 04:59 AM, Pacho Ramos wrote:
El dom, 13-01-2013 a las 04:54 -0800, Zac Medico escribió:
On 01/13/2013 04:18 AM, Pacho Ramos wrote:
What about this approach?
You should use ${SLOT%/*}, in order to exclude the sub-slot, because you
don't care about the sub-slot and the slash would cause problems.
Thanks, updated eclass attached
Here are a few problems I see with readme.gentoo_print_elog:
1) contains duplication of code
2) [[ -f ${FILESDIR}/README.gentoo-${SLOT%/*} ]] condition seems
wrong, shouldn't it just use [[ -f ${T}/README.gentoo ]] since the
file was copied to ${T}/README.gentoo iby readme.gentoo_create_doc?
Yeah, probably both can be merged as checking for PACKAGENAME:SLOT
should be enough, the problem is how to check it :S
3) [[ ${REPLACING_VERSIONS}:${SLOT%/*} ]] condition seems wrong
because SLOT is always non-empty and that means the condition is always
true.
Is there a way to check if category/package_name:$SLOT was installed
before merging?
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El jue, 17-01-2013 a las 07:47 -0800, Zac Medico escribió:
[...]
Here are a few problems I see with readme.gentoo_print_elog:
1) contains duplication of code
2) [[ -f ${FILESDIR}/README.gentoo-${SLOT%/*} ]] condition seems
wrong, shouldn't it just use [[ -f ${T}/README.gentoo ]] since the
file was copied to ${T}/README.gentoo iby readme.gentoo_create_doc?
Yeah, probably both can be merged as checking for PACKAGENAME:SLOT
should be enough, the problem is how to check it :S
3) [[ ${REPLACING_VERSIONS}:${SLOT%/*} ]] condition seems wrong
because SLOT is always non-empty and that means the condition is always
true.
Is there a way to check if category/package_name:$SLOT was installed
before merging?
REPLACING_VERSIONS always refers to packages with identical SLOT to the
current package So, if ${REPLACING_VERSIONS} is non-empty, then the
current package replaces another package with identical SLOT.
Another try ;)
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: readme.gentoo
# @MAINTAINER:
# Pacho Ramos pa...@gentoo.org
# @AUTHOR:
# Author: Pacho Ramos pa...@gentoo.org
# @BLURB: An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
# @DESCRIPTION:
# An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
if [[ ${___ECLASS_ONCE_README_GENTOO} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_README_GENTOO=recur -_+^+_- spank
inherit eutils
case ${EAPI:-0} in
0|1|2|3)
die Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}
;;
4|5)
# EAPI=4 is required for REPLACING_VERSIONS preventing us
# from needing to export another pkg_preinst phase to save has_version
# result. Also relies on EAPI =4 default src_install phase.
;;
*)
die Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}
;;
esac
EXPORT_FUNCTIONS src_install pkg_postinst
# @FUNCTION: readme.gentoo_create_doc
# @DESCRIPTION:
# Create doc file with ${DOC_CONTENTS} variable and, if not set,
# look for ${FILESDIR}/README.gentoo contents. You can use
# ${FILESDIR}/README.gentoo-${SLOT} also.
# Usually called at src_install phase.
readme.gentoo_create_doc() {
debug-print-function ${FUNCNAME} ${@}
if [[ -n ${DOC_CONTENTS} ]]; then
eshopts_push
set -f
echo ${DOC_CONTENTS} | fmt ${T}/README.gentoo
eshopts_pop
dodoc ${T}/README.gentoo
else
if [[ -f ${FILESDIR}/README.gentoo-${SLOT%/*} ]]; then
cp ${FILESDIR}/README.gentoo-${SLOT%/*} ${T}/README.gentoo
dodoc ${T}/README.gentoo
else
if [[ -f ${FILESDIR}/README.gentoo ]]; then
cp ${FILESDIR}/README.gentoo ${T}/README.gentoo
dodoc ${T}/README.gentoo
else
die You are not specifying README.gentoo contents!
fi
fi
fi
}
# @FUNCTION: readme.gentoo_print_elog
# @DESCRIPTION:
# Print elog messages with ${T}/README.gentoo contents.
# Usually called at pkg_postinst phase.
readme.gentoo_print_elog() {
debug-print-function ${FUNCNAME} ${@}
if [[ -f ${T}/README.gentoo ]]; then
if ! [[ ${REPLACING_VERSIONS} ]]; then
eshopts_push
set -f
cat ${T}/README.gentoo | while read -r ELINE; do elog ${ELINE}; done
eshopts_pop
fi
else
die README.gentoo wasn't created at src_install!
fi
}
# @FUNCTION: readme.gentoo_src_install
# @DESCRIPTION:
# Install generated doc file automatically.
readme.gentoo_src_install() {
debug-print-function ${FUNCNAME} ${@}
default
readme.gentoo_create_doc
}
# @FUNCTION: readme.gentoo_pkg_postinst
# @DESCRIPTION:
# Show elog messages from from just generated doc file.
readme.gentoo_pkg_postinst() {
debug-print-function ${FUNCNAME} ${@}
readme.gentoo_print_elog
}
fi
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El jue, 17-01-2013 a las 11:54 -0500, Ian Stakenvicius escribió:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 17/01/13 11:00 AM, Pacho Ramos wrote:
Another try ;)
There doesn't seem to be any logic here to check if the README.gentoo
that was previously installed has differed from the one that will be
installed (if they differ then the changes should be shown, no?)
Didn't think in this feature :/
I think logic similar to the following could be added to ensure this
occurs, though:
readme.gentoo_check_update() {
if [[ ${REPLACING_VERSIONS} ]] ; then
if diff -q ${T}/README.gentoo \
${EROOT}/usr/share/doc/${PF}/README.gentoo /dev/null; then
How could we handle different compressors people can use? Depending on
that README.gentoo will change its name ending with gz, bz2, xz... Maybe
we could use README.gentoo*...
touch ${T}/README.gentoo.show
fi
else
touch ${T}/README.gentoo.show
fi
}
readme.gentoo_pkg_preinst() {
debug-print-function ${FUNCNAME} ${@}
readme.gentoo_check_update
}
Then, export the pkg_preinst phase too, and and in
readme.gentoo_print_elog , swap the conditional
! [[ ${REPLACING_VERSIONS} ]] with [[ -e ${T}/README.gentoo.show ]]
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF0EAREIAAYFAlD4LKoACgkQ2ugaI38ACPCRvwD/Ub4EBc4ypYgfSItCSXc+ma2C
nrNUySPoHE0Him8vwZkA+LXvVUCNYpwD+DRh/Q5wl5Le8yiDql5F3BuUN0EQU9g=
=JbM2
-END PGP SIGNATURE-
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El jue, 17-01-2013 a las 12:11 -0500, Ian Stakenvicius escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 17/01/13 12:02 PM, Pacho Ramos wrote: How could we handle different compressors people can use? Depending on that README.gentoo will change its name ending with gz, bz2, xz... Maybe we could use README.gentoo*... Right; I didn't consider how the README.gentoo file might be compressed by dodoc .. OK, more logic required. But, since it's compressed diff will always think it's different, then, I am unsure if this could be implemented :| signature.asc Description: This is a digitally signed message part
[gentoo-dev] Lastrites: app-misc/secure-delete, app-misc/ccal, www-apache/mod_vhs, app-portage/epm, www-apps/online-bookmarks, sys-apps/i2c
# Pacho Ramos pa...@gentoo.org # Dead since 2003, doesn't work with journaling filesystems. # Also collides with dev-util/smem (#288721). Removal in a month. app-misc/secure-delete # Pacho Ramos pa...@gentoo.org # No upstream, doesn't work well (#350559). Removal in a month. app-misc/ccal # Pacho Ramos pa...@gentoo.org # Upstream dead for a long time, broken php support (#356841). # Removal in a month. www-apache/mod_vhs # Pacho Ramos pa...@gentoo.org # Multiple bugs (#449458). No maintained at all and upstream # dead. Removal in a month. app-portage/epm # Pacho Ramos pa...@gentoo.org # Still uses depend.php (#449820), upstream dead for ages and # newer versions don't work. Removal in a month. www-apps/online-bookmarks # Pacho Ramos pa...@gentoo.org # It's for kernel-2.4 only (#450594). Removal in a month. sys-apps/i2c signature.asc Description: This is a digitally signed message part
[gentoo-dev] New policy for retirements
Hello After long discussion in mail alias we have modified current policy of start pinging people for status and retirement if inactive after two months of inactivity to the following: 1. You will get a mail suggesting you to update your status and get your packages reassigned when appropriate if two or more months has passed without you committing anything and unattended bugs are assigned to you. 2. You will get first retirement mail after 6 months of total inactivity. 3. You will get second retirement mail one month after that. For more information, please take a look to updated: http://www.gentoo.org/proj/en/devrel/undertakers/ Best regards signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Lastrites: app-misc/secure-delete, app-misc/ccal, www-apache/mod_vhs, app-portage/epm, www-apps/online-bookmarks, sys-apps/i2c
El jue, 17-01-2013 a las 22:25 +0200, Maxim Kammerer escribió: On Thu, Jan 17, 2013 at 9:21 PM, Pacho Ramos pa...@gentoo.org wrote: # Pacho Ramos pa...@gentoo.org # Dead since 2003, doesn't work with journaling filesystems. # Also collides with dev-util/smem (#288721). Removal in a month. app-misc/secure-delete Is this a good enough reason for removal? There are no open bugs besides the collision one (easy to solve with a rename?), and issues with journaling filesystems / wear leveling / whatnot are generic problems with secure deletion that can't be solved in userspace anyway. He, I thought this would occur: https://bugs.gentoo.org/show_bug.cgi?id=288721#c6 In summary, what does occur when people try to use it with journaling systems? signature.asc Description: This is a digitally signed message part
[gentoo-dev] About dropping comm-fax herd
Only one package is inside it: net-misc/capi4hylafax It should probably be moved to kingtaco (if he is still interested... are you?) or maintainer-needed until any other steps up as maintainer. What do you think about removing this herd? signature.asc Description: This is a digitally signed message part
[gentoo-dev] About dropping hppa-kernel herd
Hello Looks like no package is inside this herd, I think would be safe to drop it. What do you think? Thanks signature.asc Description: This is a digitally signed message part
[gentoo-dev] About completely dropping lcd herd
Looks like it's still listed in herds.xml even being empty and with no packages inside it. Probably it's time to safely remove it completely. OK with that? Best regards signature.asc Description: This is a digitally signed message part
[gentoo-dev] About dropping mips-kernel herd
Looks like no package is included in it, I think we should drop that herd then Do you agree? signature.asc Description: This is a digitally signed message part
[gentoo-dev] About dropping ppc-kernel herd
Looks like no package is included in it, I think we should drop that herd then Do you agree? signature.asc Description: This is a digitally signed message part
[gentoo-dev] About dropping sparc-kernel herd
Looks like no package is included in it, I think we should drop that herd then Do you agree? signature.asc Description: This is a digitally signed message part
[gentoo-dev] theology herd is empty
If we agree on keeping this herd instead of trying to find one maintainer per package, somebody should join. Otherwise I will move their packages to maintainer-needed in a week Thanks signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs due spock retirement
dev-python/pycuda media-gfx/bootsplash-themes media-gfx/fbgrab media-gfx/fbida media-gfx/fblogo media-gfx/quat media-gfx/splash-themes-gentoo media-gfx/splashutils sys-apps/v86d Thanks for taking care of them signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs
Due swegener focusing in less packages until he has more time: x11-misc/x11vnc - maybe net-libs/libvncserver could be interested in this signature.asc Description: This is a digitally signed message part
[gentoo-dev] net-news herd is empty
Feel free to join for taking care of its packages. If nobody joins, will move that packages to maintainer-needed in a week Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El jue, 17-01-2013 a las 08:31 -0800, Zac Medico escribió:
On 01/17/2013 08:00 AM, Pacho Ramos wrote:
Another try ;)
Looks good to me.
+ 20 Jan 2013; Pacho Ramos pa...@gentoo.org +readme.gentoo.eclass:
+ Finally commit readme.gentoo.eclass to create a README.gentoo doc
file
+ recording tips shown via elog messages first time the package is
merged.
+
About handling more exotic cases (like different tips per version),
please should set DOC_CONTENTS instead of relying in
${FILESDIR}/README.gentoo* files (that are harder to make as flexible as
all this cases would require)
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] readme.gentoo.eclass: Add a readme.gentoo_force_print_elog function to force elog printing
This can be useful when, for example, doc contents are modified. You can
then rely on using REPLACING_VERSIONS in your ebuild to print messages
when people updates from versions using old docs
Patch to review attached
--- readme.gentoo.eclass 2013-01-20 12:42:30.0 +0100
+++ /usr/portage/eclass/readme.gentoo.eclass 2013-01-21 22:06:46.0 +0100
@@ -66,6 +66,18 @@
fi
}
+# @FUNCTION: readme.gentoo_force_print_elog
+# @DESCRIPTION:
+# For elog message printing. This can be useful when, for example,
+# DOC_CONTENTS is modified. You can then rely on using REPLACING_VERSIONS
+# in your ebuild to print messages when people updates from versions
+# still providing old message.
+# Should be called before pkg_postinst phase.
+readme.gentoo_force_print_elog() {
+ debug-print-function ${FUNCNAME} ${@}
+ touch ${T}/README.gentoo.force_print_elog
+}
+
# @FUNCTION: readme.gentoo_print_elog
# @DESCRIPTION:
# Print elog messages with ${T}/README.gentoo contents.
@@ -74,7 +86,7 @@
debug-print-function ${FUNCNAME} ${@}
if [[ -f ${T}/README.gentoo ]]; then
- if ! [[ ${REPLACING_VERSIONS} ]]; then
+ if ! [[ ${REPLACING_VERSIONS} ]] || [[ -f ${T}/README.gentoo.force_print_elog ]]; then
eshopts_push
set -f
cat ${T}/README.gentoo | while read -r ELINE; do elog ${ELINE}; done
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] readme.gentoo.eclass: Add a readme.gentoo_force_print_elog function to force elog printing
El mar, 22-01-2013 a las 08:16 +0100, Tomáš Chvátal escribió: 2013/1/21 Pacho Ramos pa...@gentoo.org: This can be useful when, for example, doc contents are modified. You can then rely on using REPLACING_VERSIONS in your ebuild to print messages when people updates from versions using old docs Patch to review attached Would'nt be better to just set some variable in the ebuild, rather than call function that touches empty file? Tom I think it can be done in either way... but I don't see the advantage of any over the other :/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] readme.gentoo.eclass: Add a readme.gentoo_force_print_elog function to force elog printing
El mar, 22-01-2013 a las 10:33 +0100, Tomáš Chvátal escribió:
2013/1/22 Pacho Ramos pa...@gentoo.org:
El mar, 22-01-2013 a las 08:16 +0100, Tomáš Chvátal escribió:
Would'nt be better to just set some variable in the ebuild, rather
than call function that touches empty file?
Tom
I think it can be done in either way... but I don't see the advantage of
any over the other :/
Just few I can think of right now:
You can set the variable in the ebuilds global scope somewhere on top easily.
You can actually do more magic later based on what content user puts
to the variable if we want to (all msgs, important ones only, ...)
You actually allow user to enforce this behaviour in make conf for all
packages if he desires to do so.
Also I never seen this being handled by touching files in any other eclasses
:-)
Tom
I agree, thanks for pointing it. Just attached patch should handle it.
--- readme.gentoo.eclass 2013-01-20 12:42:30.0 +0100
+++ /usr/portage/eclass/readme.gentoo.eclass 2013-01-22 19:36:12.0 +0100
@@ -68,13 +68,20 @@
# @FUNCTION: readme.gentoo_print_elog
# @DESCRIPTION:
-# Print elog messages with ${T}/README.gentoo contents.
+# Print elog messages with ${T}/README.gentoo contents. They will be
+# shown only when package is installed at first time.
# Usually called at pkg_postinst phase.
+#
+# If you want to show them always, please set FORCE_PRINT_ELOG to a non empty
+# value in your ebuild before this function is called.
+# This can be useful when, for example, DOC_CONTENTS is modified, then, you can
+# rely on specific REPLACING_VERSIONS handling in your ebuild to print messages
+# when people update from versions still providing old message.
readme.gentoo_print_elog() {
debug-print-function ${FUNCNAME} ${@}
if [[ -f ${T}/README.gentoo ]]; then
- if ! [[ ${REPLACING_VERSIONS} ]]; then
+ if ! [[ ${REPLACING_VERSIONS} ]] || [[ ${FORCE_PRINT_ELOG} ]]; then
eshopts_push
set -f
cat ${T}/README.gentoo | while read -r ELINE; do elog ${ELINE}; done
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
El mié, 23-01-2013 a las 15:14 +0200, Samuli Suominen escribió: please review this news item, seems we need one after all Why don't you drop ~ from: CONFIG_CHECK=~DEVTMPFS to ensure people really changes it in their kernel and prevent breakage? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
El mié, 23-01-2013 a las 23:45 +0200, Samuli Suominen escribió: On 23/01/13 23:21, Pacho Ramos wrote: El mié, 23-01-2013 a las 15:14 +0200, Samuli Suominen escribió: please review this news item, seems we need one after all Why don't you drop ~ from: CONFIG_CHECK=~DEVTMPFS to ensure people really changes it in their kernel and prevent breakage? That won't work because the host you run the package isn't necessarily same as the one you are building it on The build host doesn't need DEVTMPFS And couldn't that be done at install time? I mean, you can build and package new udev but installation will die if udev is going to be installed on a system without DEVTMPFS signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] readme.gentoo.eclass: Add a readme.gentoo_force_print_elog function to force elog printing
El mar, 22-01-2013 a las 19:42 +0100, Tomáš Chvátal escribió:
Dne Út 22. ledna 2013 19:37:12, Pacho Ramos napsal(a):
I agree, thanks for pointing it. Just attached patch should handle it.
Still not nice enough for me :D
Use the ECLASS_VARIABLE to describe it @DEFAULT_UNSET is what you seek, see
git-2.eclass.
Tom
What about this one?
--- readme.gentoo.eclass 2013-01-20 12:42:30.0 +0100
+++ /usr/portage/eclass/readme.gentoo.eclass 2013-01-24 21:30:09.0 +0100
@@ -36,6 +36,11 @@
EXPORT_FUNCTIONS src_install pkg_postinst
+# @ECLASS-VARIABLE: FORCE_PRINT_ELOG
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# If non-empty this variable forces elog messages to be printed.
+
# @FUNCTION: readme.gentoo_create_doc
# @DESCRIPTION:
# Create doc file with ${DOC_CONTENTS} variable (preferred) and, if not set,
@@ -68,13 +73,20 @@
# @FUNCTION: readme.gentoo_print_elog
# @DESCRIPTION:
-# Print elog messages with ${T}/README.gentoo contents.
+# Print elog messages with ${T}/README.gentoo contents. They will be
+# shown only when package is installed at first time.
# Usually called at pkg_postinst phase.
+#
+# If you want to show them always, please set FORCE_PRINT_ELOG to a non empty
+# value in your ebuild before this function is called.
+# This can be useful when, for example, DOC_CONTENTS is modified, then, you can
+# rely on specific REPLACING_VERSIONS handling in your ebuild to print messages
+# when people update from versions still providing old message.
readme.gentoo_print_elog() {
debug-print-function ${FUNCNAME} ${@}
if [[ -f ${T}/README.gentoo ]]; then
- if ! [[ ${REPLACING_VERSIONS} ]]; then
+ if ! [[ ${REPLACING_VERSIONS} ]] || [[ ${FORCE_PRINT_ELOG} ]]; then
eshopts_push
set -f
cat ${T}/README.gentoo | while read -r ELINE; do elog ${ELINE}; done
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] readme.gentoo.eclass: Add a readme.gentoo_force_print_elog function to force elog printing
El jue, 24-01-2013 a las 21:42 +0100, Tomáš Chvátal escribió:
Dne Čt 24. ledna 2013 21:33:45, Pacho Ramos napsal(a):
El mar, 22-01-2013 a las 19:42 +0100, Tomáš Chvátal escribió:
Dne Út 22. ledna 2013 19:37:12, Pacho Ramos napsal(a):
I agree, thanks for pointing it. Just attached patch should handle it.
Still not nice enough for me :D
Use the ECLASS_VARIABLE to describe it @DEFAULT_UNSET is what you seek,
see
git-2.eclass.
Tom
What about this one?
- if ! [[ ${REPLACING_VERSIONS} ]] || [[ ${FORCE_PRINT_ELOG}
]]; then
+ if ! [[ -n ${REPLACING_VERSIONS} || -n ${FORCE_PRINT_ELOG}
]]; then
But thats just cosmetic
Tom
Done, and committed
+ 24 Jan 2013; Pacho Ramos pa...@gentoo.org readme.gentoo.eclass:
+ Include FORCE_PRINT_ELOG variable to for printing of messages when
desired.
+ Thanks to Tomáš Chvátal for his suggestions.
+
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] Confusing tmpfs information in udev news item
I got today the udev news item and found: - The need of CONFIG_DEVTMPFS=y in the kernel; need to verify the fstype for possible /dev line in /etc/fstab is devtmpfs (and not, for example, tmpfs) Does it apply to /dev/shm? That is the line I have in my fstab: shm /dev/shmtmpfs nodev,nosuid,noexec 0 0 Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Confusing tmpfs information in udev news item
El vie, 25-01-2013 a las 14:22 -0500, Rich Freeman escribió: On Fri, Jan 25, 2013 at 2:05 PM, Pacho Ramos pa...@gentoo.org wrote: Does it apply to /dev/shm? That is the line I have in my fstab: shm /dev/shmtmpfs nodev,nosuid,noexec 0 0 No. It applies ONLY to /dev - if you even have a /dev line, and if you don't that is OK. Rich Fine, thanks a lot! signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations
El dom, 27-01-2013 a las 00:26 +0100, Andreas K. Huettel escribió: Just to keep everyone updated, ... FYI, the new 13.0 profiles are now all available in profiles.desc, for now all with status dev (i.e. repoman includes them only when you request developer profile checking). This means the procedure below is complete up to and including point 5) now. Please consider changing your profile symlink manually and testing the new profile tree. In case of problems, please file a bug and assign it to me (or tell me if I'm around). If all goes well, we'll continue in a week. A small bug in repoman turned up when testing the EAPI=5 profiles, and therefore we will wait for the next stable portage version before the 10.0 profiles are deprecated. So, another 3-4 weeks to go maybe. [The only alternative would be to require all devs to run at least ~arch portage, since the bug only affects repoman, not emerge.] Cheers, Andreas Maybe other option would be to have a portage version like current stable + repoman fix and fast stabilize as soon as possible signature.asc Description: This is a digitally signed message part
[gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable
Currently, when people uses DOC_CONTENTS variable to place their desired
messages, they are automatically reformatted by fmt to get proper
messages (for example, splitting long lines).
But, in some cases, may be useful to disable this behavior and respect
strictly how DOC_CONTENTS was formatted, for example in that kind of
messages telling people to run a command and, then, requiring a new line
to be used. This can also be useful to append extra information to
DOC_CONTENTS when, for example, additional info is needed when enabling
a USE flag.
--- /home/pacho/gentoo-x86/eclass/readme.gentoo.eclass 2013-01-24 22:38:41.0 +0100
+++ ./readme.gentoo.eclass 2013-01-27 14:51:58.0 +0100
@@ -36,6 +36,12 @@
EXPORT_FUNCTIONS src_install pkg_postinst
+# @ECLASS-VARIABLE: DISABLE_AUTOFORMATTING
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# If non-empty, DOC_CONTENTS information will be strictly respected,
+# not getting it automatically formatted by fmt.
+
# @ECLASS-VARIABLE: FORCE_PRINT_ELOG
# @DEFAULT_UNSET
# @DESCRIPTION:
@@ -53,7 +59,11 @@
if [[ -n ${DOC_CONTENTS} ]]; then
eshopts_push
set -f
- echo ${DOC_CONTENTS} | fmt ${T}/README.gentoo
+ if [[ -n ${DISABLE_AUTOFORMATTING} ]]; then
+ echo ${DOC_CONTENTS} ${T}/README.gentoo
+ else
+ echo ${DOC_CONTENTS} | fmt ${T}/README.gentoo
+ fi
eshopts_pop
dodoc ${T}/README.gentoo
else
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] The gx86 multilib project -- masterplan
El dom, 27-01-2013 a las 16:12 +0100, Michał Górny escribió: [...] 5. Solutions to specific problems - 1. x11-proto packages Those packages install headers to /usr/include and pkg-config files to /usr/lib64. This supposedly means that the headers could be ABI-specific; however, so far I haven't seen a single difference. Possible solutions: a) check the headers by hand, move pkg-config files to /usr/share, b) make the proto packages multilib. This will cause identical .pc files to be installed to lib32 lib64 but will also enable eclass checks for header consistency. Currently, emul packages can install /usr/lib32/pkgconfig files (when enabling development USE flag). This was added because, as emul sets tend to be obsolete in a few weeks, people compiling packages against its lib32 provided libs were getting build failures due native pkgconfig files (usually from newer libs) were being used. Regarding /usr/include, it looks harder to solve, current emul packages simply don't provide headers at all, but it caused issues like this in the past: https://bugs.gentoo.org/show_bug.cgi?id=299490 Maybe installing headers in other place would be interesting :/ signature.asc Description: This is a digitally signed message part
readme.gentoo.eclass: use echo -e instead of plain echo (Was: Re: [gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable=
El dom, 27-01-2013 a las 15:00 +0100, Pacho Ramos escribió:
Currently, when people uses DOC_CONTENTS variable to place their desired
messages, they are automatically reformatted by fmt to get proper
messages (for example, splitting long lines).
But, in some cases, may be useful to disable this behavior and respect
strictly how DOC_CONTENTS was formatted, for example in that kind of
messages telling people to run a command and, then, requiring a new line
to be used. This can also be useful to append extra information to
DOC_CONTENTS when, for example, additional info is needed when enabling
a USE flag.
Well, after reading man echo I see all this is not needed, I simply need
to use echo -e to get it understand \n to create new lines
New patch attached
--- /home/pacho/gentoo-x86/eclass/readme.gentoo.eclass 2013-01-24 22:38:41.0 +0100
+++ /usr/portage/eclass/./readme.gentoo.eclass 2013-01-27 18:41:40.0 +0100
@@ -53,7 +53,7 @@
if [[ -n ${DOC_CONTENTS} ]]; then
eshopts_push
set -f
- echo ${DOC_CONTENTS} | fmt ${T}/README.gentoo
+ echo -e ${DOC_CONTENTS} | fmt ${T}/README.gentoo
eshopts_pop
dodoc ${T}/README.gentoo
else
signature.asc
Description: This is a digitally signed message part
Re: readme.gentoo.eclass: use echo -e instead of plain echo (Was: Re: [gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable=
El dom, 27-01-2013 a las 13:05 -0500, Mike Frysinger escribió:
On Sunday 27 January 2013 12:47:28 Pacho Ramos wrote:
El dom, 27-01-2013 a las 15:00 +0100, Pacho Ramos escribió:
Currently, when people uses DOC_CONTENTS variable to place their desired
messages, they are automatically reformatted by fmt to get proper
messages (for example, splitting long lines).
But, in some cases, may be useful to disable this behavior and respect
strictly how DOC_CONTENTS was formatted, for example in that kind of
messages telling people to run a command and, then, requiring a new line
to be used. This can also be useful to append extra information to
DOC_CONTENTS when, for example, additional info is needed when enabling
a USE flag.
Well, after reading man echo I see all this is not needed, I simply need
to use echo -e to get it understand \n to create new lines
printf '%b' ${foo}
-mike
The problem is that it doesn't work so well. If I have the following at
src_prepare (for example):
src_prepare() {
DOC_CONTENTS=You must create a symlink rom /etc/splash/tuxonice
to the theme you want tuxonice to use, e.g.: \n
# ln -sfn /etc/splash/emergence /etc/splash/tuxonice \n
...
and I handle ${DOC_CONTENTS} with quotes, it will end writing that tabs
also in generated file as the contents of the variable will be put
as-is. On the other hand, if I don't put it between quotes and, later,
pass fmt, it will be formatted properly, without tabs and jumping to a
new line when \n is passed. In this way, echo will output a long line
with all the contents jumping to a new line when \n is found and, later,
fmt does the formatting.
But, if I use printf instead of echo:
1. If I put the variable with quotes it will be printed as-is (with
tabs).
2. If I drop the quotes, all spaces are dropped and end up with
something like:
Youmustcreateasymlinkfrom/etc/splash/tuxonicetothethemeyou
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] splashutils needs a maintainer
With spock retirement, splashutils became orphan. The problem is that it has a lot of unresolved bugs for a long time: https://bugs.gentoo.org/buglist.cgi?quicksearch=splashutilslist_id=1521218 that would need someone with more knowledge about it to maintain it (as I don't have splash on my systems for years). Also looks like splashutils is no more developed, but I don't know if we have a proper replacement for it in gentoo (most distributions are moving to plymouth, but I haven't tried if it works ok on Gentoo) Thanks for your help signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] splashutils needs a maintainer
El lun, 28-01-2013 a las 00:25 +0100, Alex Legler escribió: On 27.01.2013 23:06, Pacho Ramos wrote: With spock retirement, splashutils became orphan. The problem is that it has a lot of unresolved bugs for a long time: https://bugs.gentoo.org/buglist.cgi?quicksearch=splashutilslist_id=1521218 that would need someone with more knowledge about it to maintain it (as I don't have splash on my systems for years). Also looks like splashutils is no more developed, but I don't know if we have a proper replacement for it in gentoo (most distributions are moving to plymouth, but I haven't tried if it works ok on Gentoo) We have it, it works (or at least worked). Someone would need to implement it in genkernel initrds though as at the moment only dracut can handle it. In terms of package maintenance, I took the package from aidecoe when he dropped it to avoid it getting removed. People seem to have found issues in there now and it could use a bump. As I cannot boot my systems using dracut initrds right now, feel free to take the package (and the openrc plugin for it) and fix/bump/do whatever with it. Then, looks like no alternative is in good shape on Gentoo. What is Sabayon using? They look to have plymouth ebuilds in their overlay (but not in for-gentoo one, then, it probably has some incompatibility Gentoo :/) signature.asc Description: This is a digitally signed message part
Re: readme.gentoo.eclass: use echo -e instead of plain echo (Was: Re: [gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable=
El lun, 28-01-2013 a las 14:37 +0800, Ben de Groot escribió:
On 28 January 2013 12:37, Mike Frysinger vap...@gentoo.org wrote:
On Sunday 27 January 2013 13:21:27 Pacho Ramos wrote:
The problem is that it doesn't work so well. If I have the following at
src_prepare (for example):
src_prepare() {
DOC_CONTENTS=You must create a symlink rom /etc/splash/tuxonice
to the theme you want tuxonice to use, e.g.: \n
# ln -sfn /etc/splash/emergence /etc/splash/tuxonice
\n
...
and I handle ${DOC_CONTENTS} with quotes, it will end writing that tabs
also in generated file as the contents of the variable will be put
as-is. On the other hand, if I don't put it between quotes
forcibly normalizing whitespace for all callers is wrong imo (as is sending
it
through `fmt`). if the caller gave you content to write, it should write
it.
if the caller didn't want tabs, it shouldn't have used it in the first
place.
-mike
I've started using this eclass, but with README files, not the variable,
because this is currently the only way I can make sure it honours my
formatting.
Couldn't it be covered if echo -e was used (even with fmt) and you,
then, control formatting with some of the sequences it allows (they are
shown in its man page)?
signature.asc
Description: This is a digitally signed message part
Re: readme.gentoo.eclass: use echo -e instead of plain echo (Was: Re: [gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable=
El mar, 29-01-2013 a las 14:03 +0800, Ben de Groot escribió:
On 29 January 2013 03:30, Pacho Ramos pa...@gentoo.org wrote:
El lun, 28-01-2013 a las 14:37 +0800, Ben de Groot escribió:
I've started using this eclass, but with README files, not the variable,
because this is currently the only way I can make sure it honours my
formatting.
Couldn't it be covered if echo -e was used (even with fmt) and you,
then, control formatting with some of the sequences it allows (they are
shown in its man page)?
No. The eclass should assume that DOC_CONTENTS is already correctly
formatted. If you must, you can add a convenience function for people
who do want reformatting, but this should NOT be the default. Please
don't make this eclass harder to use than it needs to be.
I can add a variable (and probably will), but would prefer to keep it
formatting messages by default, otherwise, how will you set DOC_CONTENTS
variable inside a pkg phase (instead of global scope) without adding
tabs to it? You can of course add it, but it will be read as something
like:
src_prepare() {
DOC_CONTENTS=blablabla
blablabla
# Rest of src_prepare stuff
}
Also, autoformatting will help to prevent every package setting messages
with different lines length (in some cases really long lines that I
finally reported some bugs in the past to get them fitting in standard
80 characters per line).
I would then switch to echo -e and also add a function (like my
original solution in this thread) to allow you to disable formatting if
you want
signature.asc
Description: This is a digitally signed message part
Re: readme.gentoo.eclass: use echo -e instead of plain echo (Was: Re: [gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable=
El mié, 30-01-2013 a las 21:24 +0800, Ben de Groot escribió:
On 30 January 2013 05:47, Pacho Ramos pa...@gentoo.org wrote:
El mar, 29-01-2013 a las 14:03 +0800, Ben de Groot escribió:
On 29 January 2013 03:30, Pacho Ramos pa...@gentoo.org wrote:
El lun, 28-01-2013 a las 14:37 +0800, Ben de Groot escribió:
I've started using this eclass, but with README files, not the variable,
because this is currently the only way I can make sure it honours my
formatting.
Couldn't it be covered if echo -e was used (even with fmt) and you,
then, control formatting with some of the sequences it allows (they are
shown in its man page)?
No. The eclass should assume that DOC_CONTENTS is already correctly
formatted. If you must, you can add a convenience function for people
who do want reformatting, but this should NOT be the default. Please
don't make this eclass harder to use than it needs to be.
I can add a variable (and probably will), but would prefer to keep it
formatting messages by default, otherwise, how will you set DOC_CONTENTS
variable inside a pkg phase (instead of global scope) without adding
tabs to it? You can of course add it, but it will be read as something
like:
src_prepare() {
DOC_CONTENTS=blablabla
blablabla
# Rest of src_prepare stuff
}
I still prefer the eclass not to mess with formatting by default. You
can do what you want by
src_prepare() {
DOC_CONTENTS=blabla
indented content
# other stuff
}
But it will be recorded with indent in README.gentoo, what is not
desired.
src_install() {
default
readme.gentoo_reformat
}
Also, autoformatting will help to prevent every package setting messages
with different lines length (in some cases really long lines that I
finally reported some bugs in the past to get them fitting in standard
80 characters per line).
Sometimes long lines are what is required. If not, then filing a bug
is the friendly solution.
In that case, you could set the variable to skip formatting as, the
preferred option is to keep them in standard length, and the exception
is to require longer lines (in that case they could be covered with the
variable)
signature.asc
Description: This is a digitally signed message part
Re: readme.gentoo.eclass: use echo -e instead of plain echo (Was: Re: [gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable=
El dom, 27-01-2013 a las 18:47 +0100, Pacho Ramos escribió:
El dom, 27-01-2013 a las 15:00 +0100, Pacho Ramos escribió:
Currently, when people uses DOC_CONTENTS variable to place their desired
messages, they are automatically reformatted by fmt to get proper
messages (for example, splitting long lines).
But, in some cases, may be useful to disable this behavior and respect
strictly how DOC_CONTENTS was formatted, for example in that kind of
messages telling people to run a command and, then, requiring a new line
to be used. This can also be useful to append extra information to
DOC_CONTENTS when, for example, additional info is needed when enabling
a USE flag.
Well, after reading man echo I see all this is not needed, I simply need
to use echo -e to get it understand \n to create new lines
New patch attached
This will add an option to disabling autoformatting to let people get
their doc_contents 100% respected if they want
--- readme.gentoo.eclass 2013-01-24 22:38:41.0 +0100
+++ /usr/portage/eclass/readme.gentoo.eclass 2013-01-31 19:55:40.0 +0100
@@ -36,6 +36,12 @@
EXPORT_FUNCTIONS src_install pkg_postinst
+# @ECLASS-VARIABLE: DISABLE_AUTOFORMATTING
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# If non-empty, DOC_CONTENTS information will be strictly respected,
+# not getting it automatically formatted by fmt.
+
# @ECLASS-VARIABLE: FORCE_PRINT_ELOG
# @DEFAULT_UNSET
# @DESCRIPTION:
@@ -53,7 +59,11 @@
if [[ -n ${DOC_CONTENTS} ]]; then
eshopts_push
set -f
- echo ${DOC_CONTENTS} | fmt ${T}/README.gentoo
+ if [[ -n ${DISABLE_AUTOFORMATTING} ]]; then
+ echo ${DOC_CONTENTS} ${T}/README.gentoo
+ else
+ echo -e ${DOC_CONTENTS} | fmt ${T}/README.gentoo
+ fi
eshopts_pop
dodoc ${T}/README.gentoo
else
signature.asc
Description: This is a digitally signed message part
Re: readme.gentoo.eclass: use echo -e instead of plain echo (Was: Re: [gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable=
El vie, 01-02-2013 a las 17:55 +0800, Ben de Groot escribió: On 1 February 2013 02:59, Pacho Ramos pa...@gentoo.org wrote: El dom, 27-01-2013 a las 18:47 +0100, Pacho Ramos escribió: El dom, 27-01-2013 a las 15:00 +0100, Pacho Ramos escribió: Currently, when people uses DOC_CONTENTS variable to place their desired messages, they are automatically reformatted by fmt to get proper messages (for example, splitting long lines). But, in some cases, may be useful to disable this behavior and respect strictly how DOC_CONTENTS was formatted, for example in that kind of messages telling people to run a command and, then, requiring a new line to be used. This can also be useful to append extra information to DOC_CONTENTS when, for example, additional info is needed when enabling a USE flag. Well, after reading man echo I see all this is not needed, I simply need to use echo -e to get it understand \n to create new lines New patch attached This will add an option to disabling autoformatting to let people get their doc_contents 100% respected if they want How about using an as-is argument to readme.gentoo_create_doc? That would be more concise. :-) I have no problem on either solution... but don't have time just now to work on a patch to achieve it, if you have a bit time, I would really appreciate :) signature.asc Description: This is a digitally signed message part
Re: readme.gentoo.eclass: use echo -e instead of plain echo (Was: Re: [gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable=
El vie, 01-02-2013 a las 21:34 +0100, Pacho Ramos escribió: El vie, 01-02-2013 a las 17:55 +0800, Ben de Groot escribió: On 1 February 2013 02:59, Pacho Ramos pa...@gentoo.org wrote: El dom, 27-01-2013 a las 18:47 +0100, Pacho Ramos escribió: El dom, 27-01-2013 a las 15:00 +0100, Pacho Ramos escribió: Currently, when people uses DOC_CONTENTS variable to place their desired messages, they are automatically reformatted by fmt to get proper messages (for example, splitting long lines). But, in some cases, may be useful to disable this behavior and respect strictly how DOC_CONTENTS was formatted, for example in that kind of messages telling people to run a command and, then, requiring a new line to be used. This can also be useful to append extra information to DOC_CONTENTS when, for example, additional info is needed when enabling a USE flag. Well, after reading man echo I see all this is not needed, I simply need to use echo -e to get it understand \n to create new lines New patch attached This will add an option to disabling autoformatting to let people get their doc_contents 100% respected if they want How about using an as-is argument to readme.gentoo_create_doc? That would be more concise. :-) But, how could people then active that as-is option without needing to write a src_install function calling readme.gentoo_create_doc with that option? signature.asc Description: This is a digitally signed message part
[gentoo-dev] rox herd looks inactive for a long time
Hello Reviewing last commits of lack (the only rox team member), looks like he hasn't committed anything rox related for some time. rox herd has some bugs assigned to them that looks unattended (even some easy to fix bugs). I have contacted the team but got no reply at all. Is anybody willing to join the team? If not, I will proceed in next week in moving their packages to maintainer-needed (as that is really its current status) and show the list of packages letting people to easily pick what they prefer Thanks signature.asc Description: This is a digitally signed message part
