Re: [gentoo-dev] Re: How a proper server profile should look like
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 While I tend towards the cleaner design, not the don't fix what isn't *broken* approach -- I'm fine either way. But I think the handbook or some tool should obnoxiously spit the flags (and a minor justification for each flag and/or the set of flags) of each profile in your face when you are at the set a profile step of the installation. This way it can clarify that the user might want to disable some of the profile-enabled flags. - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlD+R9cACgkQRtClrXBQc7WCUgD+MyFwwjQ9BQ8lakIIyAoTNxye Z+6HQ3BYvJEZjlRJYwYA/2Y5EEX3gjq2KzhS1q8+nSa7CEycd2jJo6QtUZxjFk88 =+/+5 -END PGP SIGNATURE-
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] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On 22 January 2013 03:56, Zac Medico zmed...@gentoo.org wrote:
On 01/21/2013 07:45 PM, Mike Gilbert wrote:
My suspicion is that portage's environment save/restore process will
overwrite any setting I attempt to make on the destination host.
If necessary, you can use /etc/portage/bashrc to override
CONFIG_CHECK_FATAL for binary packages. Something like this would work:
[[ ${EMERGE_FROM} == binary ]] CONFIG_CHECK_FATAL=0
--
Thanks,
Zac
I guess the problem is when you create a binpkg and not when you
install it on the target. wild idea Would it be possible to make
this nonfatal if FEATURES contains binpkg or -B was passed to
emerge?/wild idea
--
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] readme.gentoo.eclass: Add a readme.gentoo_force_print_elog function to force elog printing
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
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
Il 22/01/2013 04:38, Robin H. Johnson ha scritto:
I'm raising this patch because of the recent spate of bugs with the
latest udev that now fails to boot your system if CONFIG_DEVTMPFS is
not available in your kernel.
Bugs: 408947, 409393, 437320, 453074
CONFIG_CHECK has not been fatal for some years now, because there turned
out to be some cases where it cannot detect what the system really has
[1], or what is returned is wrong [2].
However, while this is has been superb in helping those corner-cases,
the fallout is that users frequently ignore the non-fatal warnings that
a configuration option is needed to run a binary later, and end up with
weird breakage.
This patch introduces a new option, CONFIG_CHECK_FATAL, defaulting to
enabled, that explicitly causes a die if:
- CONFIG_CHECK cannot be performed successfully.
- Any CONFIG_CHECK options fail.
For the aforementioned corner cases, those environments are used to
customizing their make.conf heavily, and they should add:
CONFIG_CHECK_FATAL=0
This patch does NOT change the handling of ~/tilde in CONFIG_CHECK
- options that are required at compile-time MUST NOT use ~/tilde.
- options that are only required at run-time MUST include the ~/tilde.
Footnotes:
1. If you are using a VM environment, where the kernel is provided
outside of your VM, and you don't have kernel sources, or
/proc/config.gz, you CANNOT detect what options the kernel is
configured with.
2. Building stages for example. You may have /proc bind-mounted from the
host system, but it does not reflect the environment you are building
for.
IMHO the number of cases where CONFIG_CHECK is reliable is so small that
making it fatal will only bloat make.conf and env with a new var for
most users.
However this move could make sense if (and only if) CONFIG_CHECK could
reliabily know where it's used.
It could be made fatal for example if all the following conditions are met:
- buildpkg is disabled
- /proc/config.gz (decompressed) is the same as
${KERNEL_BUILD_DIR}/.config and both exists
- /boot is mounted and the bootloader will load the currently running kernel
AIMHO it's very difficult (would say impossible) to implement this in a
cross package manager and reliable way.
So please don't
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On Tue, Jan 22, 2013 at 6:11 AM, viv...@gmail.com viv...@gmail.com wrote: IMHO the number of cases where CONFIG_CHECK is reliable is so small that making it fatal will only bloat make.conf and env with a new var for most users. Tend to agree. I just got an elog out of udisks complaining about USB_SUSPEND not being set, and I have no idea why I'd need that on a system that is powered 24x7. Even the kernel docs suggest that it should be disabled if users aren't sure if they need it. Maybe we need some way to distinguish between must-have and nice-to-have situations? Clearly failure to boot is in a different category than not-able-to-suspend. Rich
Re: [gentoo-dev] Re: How a proper server profile should look like
On Tue, Jan 22, 2013 at 2:22 AM, Ben de Groot yng...@gentoo.org wrote: On 22 January 2013 03:28, Rich Freeman ri...@gentoo.org wrote: On Mon, Jan 21, 2013 at 12:51 PM, Dustin C. Hatch admiraln...@gmail.com wrote: The package defaults have gotten out of hand, in my opinion. I use default/linux/amd64/10.0 on all my machines and my /etc/portage/package.use directories have dozens of -flag entries for packages with ridiculous defaults, and almost none that come from the profile. I'm considering removing pkginternal from USE_ORDER. And this is the problem with having the default profile be really minimal. It just moves the problem into per-package defaults that are much more painful to override. No offense, but that's nonsense. You override it the exact same way. Indeed, you're correct. It is not necessary to do what Dustin suggested to disable package use-defaults - if you set -foo in make.conf it will apply to all packages even if it is a use-default. Rich
Re: [gentoo-dev] Re: How a proper server profile should look like
On Tue, Jan 22, 2013 at 3:03 AM, Alexander Berntsen alexan...@plaimi.net wrote: While I tend towards the cleaner design, not the don't fix what isn't *broken* approach -- I'm fine either way. But I think the handbook or some tool should obnoxiously spit the flags (and a minor justification for each flag and/or the set of flags) of each profile in your face when you are at the set a profile step of the installation. This way it can clarify that the user might want to disable some of the profile-enabled flags. Not really sure that adds much value. A few users might want to disable everything, but just as many if not more are likely to want to enable stuff that is disabled. Should we therefore list all the flags on the system and which ones are enabled and disabled? I guess we could, but it is a REALLY long list. In practice I find that the way I tend to use USE flags is that I just ignore them until something unexpected happens, and then change them. Rich
Re: [gentoo-dev] January stabilization candidates
On Wednesday, January 16, 2013 07:14:12 PM Tomáš Chvátal wrote: Dne So 12. ledna 2013 14:49:52, Paweł Hajdan, Jr. napsal(a): Please review attached automatically generated stabilization candidates for January. I don't want to annoy people with automatically filed bugs, and at the same time I also received lots of positive feedback about the effort to keep the stable tree more up-to-date. I think the best way to proceed is to listen to that feedback and continue the effort, while also keeping an updated list of exclusions for packagers/herds that are actively stabilized by maintainers. Paweł Hmm, nice idea but how about expanding metadata.xml with something like info for stabilisations so they can be automatically grabbed for it. Quite few software is just nice enough that it can go automatically for stable in 30 days, and someone could just go then and open new bugs (with assigned arches) based on it (of course it expects brain from the guy reporting it that he checks if there are no open bugs). Because mails to -dev are frankly annoying. :-) Tom Tom, This is a better idea. I also believe this one can be auto stablized after 30 days. It's just kernel documentation. -- Mike Pagano Gentoo Developer - Kernel Project Team Lead - Gentoo Sources E-Mail : mpag...@gentoo.org GnuPG FP : EEE2 601D 0763 B60F 848C 9E14 3C33 C650 B576 E4E3 Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index
Re: [gentoo-dev] Re: How a proper server profile should look like
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22/01/13 13:12, Rich Freeman wrote: As a long-time user, I can't put myself in a first-time user's frame of reference. But it would be useful for me whenever I'm installing Gentoo on a new device, if I were able to have the profile's USE-flags listed. (I know I can find them elsewhere, but it would still be convenient for me.) - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlD+jtUACgkQRtClrXBQc7XKvAD+L3kf/+txOUTGGTwcPDnZTDsb v630SlBCE9uyoEx0SzgA/3rHGYYkGQ7w9srZ8LjFc3S3iZ0WV3OLOPw9QyRePr3P =OcXI -END PGP SIGNATURE-
Re: [gentoo-dev] January stabilization candidates
On 13.1.2013 0.49, Paweł Hajdan, Jr. wrote: Please review attached automatically generated stabilization candidates for January. I don't want to annoy people with automatically filed bugs, and at the same time I also received lots of positive feedback about the effort to keep the stable tree more up-to-date. I think the best way to proceed is to listen to that feedback and continue the effort, while also keeping an updated list of exclusions for packagers/herds that are actively stabilized by maintainers. I have an RSS feed for this purpose at: http://gentoo.petteriraty.eu/stable.rss Sources are available here: https://github.com/betelgeuse/scripts/blob/master/rss-changelog Maybe this is something that should be pushed to official Gentoo infrastructure so more people know about it and use it? Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-01-20 23h59 UTC
On Mon, Jan 21, 2013 at 12:10:12PM +0100, Theo Chatzimichos wrote: On Mon, Jan 21, 2013 at 1:25 AM, Robin H. Johnson robb...@gentoo.org wrote: The attached list notes all of the packages that were added or removed from the tree, for the week ending 2013-01-20 23h59 UTC. How about sending those mails to gentoo-dev-announce only? Theo +1 from me. -- Mr. Aaron W. Swenson Gentoo Linux Developer Email : titanof...@gentoo.org GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0 GnuPG ID : D1BBFDA0 pgpZsK2vDnZ_5.pgp Description: PGP signature
Re: [gentoo-dev] January stabilization candidates
2013/1/22 Petteri Räty betelge...@gentoo.org: I have an RSS feed for this purpose at: http://gentoo.petteriraty.eu/stable.rss Sources are available here: https://github.com/betelgeuse/scripts/blob/master/rss-changelog Maybe this is something that should be pushed to official Gentoo infrastructure so more people know about it and use it? Yup that would be nice. Also we could really finegrain it based on metadata.xml settings if someone really wants to exclude his packages, and also we could think if it should be opt-out or opt-in. Cheers Tom
Re: [gentoo-dev] January stabilization candidates
On Tue, Jan 22, 2013 at 2:25 PM, Petteri Räty betelge...@gentoo.org wrote: On 13.1.2013 0.49, Paweł Hajdan, Jr. wrote: Please review attached automatically generated stabilization candidates for January. I don't want to annoy people with automatically filed bugs, and at the same time I also received lots of positive feedback about the effort to keep the stable tree more up-to-date. I think the best way to proceed is to listen to that feedback and continue the effort, while also keeping an updated list of exclusions for packagers/herds that are actively stabilized by maintainers. I have an RSS feed for this purpose at: http://gentoo.petteriraty.eu/stable.rss Sources are available here: https://github.com/betelgeuse/scripts/blob/master/rss-changelog Maybe this is something that should be pushed to official Gentoo infrastructure so more people know about it and use it? File a bug against us then, with all the information needed for the deployment Theo
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On 01/22/2013 01:22 AM, Markos Chandras wrote:
On 22 January 2013 03:56, Zac Medico zmed...@gentoo.org wrote:
On 01/21/2013 07:45 PM, Mike Gilbert wrote:
My suspicion is that portage's environment save/restore process will
overwrite any setting I attempt to make on the destination host.
If necessary, you can use /etc/portage/bashrc to override
CONFIG_CHECK_FATAL for binary packages. Something like this would work:
[[ ${EMERGE_FROM} == binary ]] CONFIG_CHECK_FATAL=0
--
Thanks,
Zac
I guess the problem is when you create a binpkg and not when you
install it on the target. wild idea Would it be possible to make
this nonfatal if FEATURES contains binpkg or -B was passed to
emerge?/wild idea
The closest thing that PMS has defined is the MERGE_TYPE variable, which
is supported since EAPI 4. This variable has 3 possible values: source,
buildonly, or binary. Ebuilds can detect emerge --buildpkgonly by
checking for [[ ${MERGE_TYPE} == buildonly ]]. However, for normal
--buildpkg or FEATURES=buildpkg, the MERGE_TYPE is source.
--
Thanks,
Zac
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On 01/21/2013 10:22 PM, Sergey Popov wrote: 22.01.2013 08:23, Mike Gilbert wrote: I guess this change is ok, given that I can opt-out fairly easily. Zac's workaround for binary packages makes me feel better too. I am curious, can not this check be added to eclass? Or eclass does not know about type of merged package? Since EAPI 4 we have the MERGE_TYPE variable which has 3 possible values: source, buildonly, or binary. -- Thanks, Zac
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] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On Tue, Jan 22, 2013 at 06:51:54AM -0800, Zac Medico wrote:
On 01/21/2013 10:22 PM, Sergey Popov wrote:
22.01.2013 08:23, Mike Gilbert wrote:
I guess this change is ok, given that I can opt-out fairly easily. Zac's
workaround for binary packages makes me feel better too.
I am curious, can not this check be added to eclass? Or eclass does not
know about type of merged package?
Since EAPI 4 we have the MERGE_TYPE variable which has 3 possible
values: source, buildonly, or binary.
# MERGE_TYPE = EAPI 4+
# EMERGE_FROM = EAPI 0-3
_frombin=${MERGE_TYPE}${EMERGE_FROM}
[[ ${_frombin//binary} == ${_frombin} ]] [[ ${CONFIG_CHECK_FATAL+set} == set
]] || CONFIG_CHECK_FATAL=1
But probably easier to just set it in bashrc/catalystrc/make.conf
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
[gentoo-dev] Re: How a proper server profile should look like
Rich Freeman posted on Tue, 22 Jan 2013 07:12:06 -0500 as excerpted: Should we therefore list all the flags on the system and which ones are enabled and disabled? I guess we could, but it is a REALLY long list. In practice I find that the way I tend to use USE flags is that I just ignore them until something unexpected happens, and then change them. The one thing I wish the handbook had taught, way back when I started (and I read the handbook well enough that even before I had a system up and running on gentoo... 2004.0/amd64 wasn't quite ready for NPTL and I blocked on it, but 2004.1 worked... I was helping others who apparently had /not/ read it so well! this wasn't there and AFAIK still isn't), was... If in doubt, leave it out. Remember, because gentoo is build-from- source, every package installed has a much higher cost in terms of continuing upgrades over time, than on a binary distro. If you aren't sure you're going to use it, or will only use it maybe a couple times a year, strongly consider omitting it, thus avoiding the upgrade cost. You can always install it later if you find you REALLY need it. That applies to both packages and USE flags (which often bring in extra packages) on your system. One of the first things I realized out of the gate was that keeping both gnome and kde installed wasn't going to be practical for me, and I preferred the better configurability of kde so I quickly dropped gnome. But over the years my system has gotten progressively leaner as I trimmed this and that, one thing at a time, because there really IS a continuing maintenance cost to every single package installed, ESPECIALLY on the ~arch systems I run where the package churn is much higher, even MORE so for those (like me) that like to run stuff like kde prereleases from the overlays. KDE for example has two feature releases a year and updates every month, basically 12 releases a year. For those running the pre- releases, it's 16, as for the couple months before a feature release they're on a two-week update cycle. For those running its pre-releases, KDE *BY* *ITSELF* is thus several hundred package upgrade builds 16 times a year (plus -rX bumps if any). I've trimmed my kde to ~170 packages at last upgrade (and just trimmed a couple more after that, deciding with dolphin as my GUI fileman and firefox as my default browser I no longer needed konqueror or its addons, so I think I'm down to 168 per kde upgrade here, now). With my six-core bulldozer and PORTAGE_TMPDIR in tmpfs, that's actually reasonable. I wouldn't expect ordinary gentooers to go to the lengths I have to reduce system bloat while keeping functionality I actually use, as the system set I've negated is there fore a reason and USE=-* is discouraged for a reason -- it TAKES someone with quite some experience and knowledge to properly navigate those sorts of things. But if anything, that's all the MORE reason there should be a minimal profile available, for those who want as lean an installation as possible. The more stuff turned on the worse it gets, especially for USE flags on system set packages and the packages they in turn drag in, multiple levels down. That's actually why I eventually killed my system set, too much (including xorg-server and kdelibs) was being pulled into it by the USE flags, and for safety reasons, portage puts much stronger parallel-emerge- jobs limitations on @system and its deps, many packages of which are piddly little things that kept portage running alone at 1.00 load average on a six-core! So the smaller the set of profile-enabled USE flags and the smaller the @system set, the better, and a minimal profile that people can add what they need to, would ideally be the recommended profile for most users. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: How a proper server profile should look like
On Tue, Jan 22, 2013 at 02:06:29PM +0100, Alexander Berntsen wrote As a long-time user, I can't put myself in a first-time user's frame of reference. But it would be useful for me whenever I'm installing Gentoo on a new device, if I were able to have the profile's USE-flags listed. (I know I can find them elsewhere, but it would still be convenient for me.) Maybe a note in the install docs to run... emerge --info | grep ^USE -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
[gentoo-dev] stabilization candidates rss feed html pages
On Tue, 2013-01-22 at 14:44 +0100, Theo Chatzimichos wrote: On Tue, Jan 22, 2013 at 2:25 PM, Petteri Räty betelge...@gentoo.org wrote: On 13.1.2013 0.49, Paweł Hajdan, Jr. wrote: Please review attached automatically generated stabilization candidates for January. I don't want to annoy people with automatically filed bugs, and at the same time I also received lots of positive feedback about the effort to keep the stable tree more up-to-date. I think the best way to proceed is to listen to that feedback and continue the effort, while also keeping an updated list of exclusions for packagers/herds that are actively stabilized by maintainers. I have an RSS feed for this purpose at: http://gentoo.petteriraty.eu/stable.rss Sources are available here: https://github.com/betelgeuse/scripts/blob/master/rss-changelog Maybe this is something that should be pushed to official Gentoo infrastructure so more people know about it and use it? File a bug against us then, with all the information needed for the deployment Theo I had a look at the script, unfortunately (for me), it's both a ruby script and deps on paludis to get the information. Personally I think this would work well, but re-written in python and use portage for info. As euscan is all about scanning for upgradeable pkgs, it is already getting updated pkg info, scanning metadata.xml, etc. using portage, gentoolkit, and custom code. So this would fit well with it. It is python, django based. It could also offer the rss feed in a web page with a search box, and/or integrate the candidates into the pkgs status reports it does. Second reason, I believe it is getting or already has deployment on gentoo infra servers. I pinged `fox` in #-www about it, Corentin iksaif wasn't online there at the time. cc'ing them here. -- Brian Dolbec dol...@gentoo.org signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] stabilization candidates rss feed html pages
On Tue, Jan 22, 2013 at 10:57 PM, Brian Dolbec dol...@gentoo.org wrote: On Tue, 2013-01-22 at 14:44 +0100, Theo Chatzimichos wrote: On Tue, Jan 22, 2013 at 2:25 PM, Petteri Räty betelge...@gentoo.org wrote: On 13.1.2013 0.49, Paweł Hajdan, Jr. wrote: Please review attached automatically generated stabilization candidates for January. I don't want to annoy people with automatically filed bugs, and at the same time I also received lots of positive feedback about the effort to keep the stable tree more up-to-date. I think the best way to proceed is to listen to that feedback and continue the effort, while also keeping an updated list of exclusions for packagers/herds that are actively stabilized by maintainers. I have an RSS feed for this purpose at: http://gentoo.petteriraty.eu/stable.rss Sources are available here: https://github.com/betelgeuse/scripts/blob/master/rss-changelog Maybe this is something that should be pushed to official Gentoo infrastructure so more people know about it and use it? File a bug against us then, with all the information needed for the deployment Theo I had a look at the script, unfortunately (for me), it's both a ruby script and deps on paludis to get the information. Personally I think this would work well, but re-written in python and use portage for info. As euscan is all about scanning for upgradeable pkgs, it is already getting updated pkg info, scanning metadata.xml, etc. using portage, gentoolkit, and custom code. So this would fit well with it. It is python, django based. It could also offer the rss feed in a web page with a search box, and/or integrate the candidates into the pkgs status reports it does. Second reason, I believe it is getting or already has deployment on gentoo infra servers. I pinged `fox` in #-www about it, Corentin iksaif wasn't online there at the time. cc'ing them here. I think that euscan would benefit of this feature, but the your arguments against ruby/paludis aren't valid IMO. If the euscan guys want to integrate the feature, nice. If not, lets just stick with this script. It is simple enough that even ruby n00bs like me can understand what it does :P BR. -- Rafael Goncalves Martins Gentoo Linux developer http://rafaelmartins.eng.br/
Re: [gentoo-dev] stabilization candidates rss feed html pages
On Wed, 2013-01-23 at 01:15 -0200, Rafael Goncalves Martins wrote: On Tue, Jan 22, 2013 at 10:57 PM, Brian Dolbec dol...@gentoo.org wrote: On Tue, 2013-01-22 at 14:44 +0100, Theo Chatzimichos wrote: On Tue, Jan 22, 2013 at 2:25 PM, Petteri Räty betelge...@gentoo.org wrote: On 13.1.2013 0.49, Paweł Hajdan, Jr. wrote: Please review attached automatically generated stabilization candidates for January. I don't want to annoy people with automatically filed bugs, and at the same time I also received lots of positive feedback about the effort to keep the stable tree more up-to-date. I think the best way to proceed is to listen to that feedback and continue the effort, while also keeping an updated list of exclusions for packagers/herds that are actively stabilized by maintainers. I have an RSS feed for this purpose at: http://gentoo.petteriraty.eu/stable.rss Sources are available here: https://github.com/betelgeuse/scripts/blob/master/rss-changelog Maybe this is something that should be pushed to official Gentoo infrastructure so more people know about it and use it? File a bug against us then, with all the information needed for the deployment Theo I had a look at the script, unfortunately (for me), it's both a ruby script and deps on paludis to get the information. Personally I think this would work well, but re-written in python and use portage for info. As euscan is all about scanning for upgradeable pkgs, it is already getting updated pkg info, scanning metadata.xml, etc. using portage, gentoolkit, and custom code. So this would fit well with it. It is python, django based. It could also offer the rss feed in a web page with a search box, and/or integrate the candidates into the pkgs status reports it does. Second reason, I believe it is getting or already has deployment on gentoo infra servers. I pinged `fox` in #-www about it, Corentin iksaif wasn't online there at the time. cc'ing them here. I think that euscan would benefit of this feature, but the your arguments against ruby/paludis aren't valid IMO. That's exactly why I put in the (for me) in that statement. If the euscan guys want to integrate the feature, nice. Since Euscan is python, django based and already using python interfaces to portage, gentoolkit. It would be logical to redo it in python. But I believe it is set up to be able to run pretty much any script/binary as well. If this script gets run on gentoo infra, then euscan can just use that feed for display and add code to parse it for it's other reports. It is likely simpler for euscan to add picking up the additional data to produce the stabilization reports/feeds while it is scanning the newly sync'd tree and updating it's db. Producing the rss feed is simple at that point. Plus the data for other report formats would already be in it's db, making the rest of the displays simpler. If not, lets just stick with this script. Let's wait to hear from Corentin and Federico on it... It is simple enough that even ruby n00bs like me can understand what it does :P BR. It is for me too. -- Rafael Goncalves Martins Gentoo Linux developer http://rafaelmartins.eng.br/ -- Brian Dolbec dol...@gentoo.org 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
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 signature.asc Description: This is a digitally signed message part.
