Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
> On Fri, 24 May 2013, J Roeleveld wrote:
> This reminded me of my experience with info-files. Don't know how
> long ago it was that I used them as I find google to be a much more
> useful resource.
> But you might be interested in the following:
> * app-text/info2html
> Available versions: (2.0) *2.0
> {{vhosts}}
> Homepage:http://info2html.sourceforge.net/
> Description: Converts GNU .info files to HTML
> I haven't tried it myself yet.
Usually the result is much better if you start from the Texinfo source
and use texi2any --html (included with sys-apps/texinfo itself) for
conversion.
Ulrich
Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
On Tue, May 21, 2013 09:03, Alan McKinnon wrote:
> I don't like gnu info files. Neither me nor anyone I know can figure out
> how to drive info.
This reminded me of my experience with info-files. Don't know how long ago
it was that I used them as I find google to be a much more useful
resource.
But you might be interested in the following:
* app-text/info2html
Available versions: (2.0) *2.0
{{vhosts}}
Homepage:http://info2html.sourceforge.net/
Description: Converts GNU .info files to HTML
I haven't tried it myself yet. (Ignore the "hardmask" part in the output,
that's because the portage-filesystem is not automatically mounted)
--
Joost
Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
(Late reply due to busy week, just want to clarify a small detail) On Sun, May 19, 2013 16:34, Peter Stuge wrote: > J. Roeleveld wrote: >> I don't see how this will avoid the issue of a limited amount of >> inodes. >> That is what I usually run out of before the disk is full when >> storing lots of smaller files. > > I guess the number of unit files is on the order of hundreds, as long > as you haven't configured an INSTALL_MASK to avoid installing them. > (Why haven't you?) > > Are you saying that a few hundred inodes more will break many systems? > > It doesn't seem very likely to me. Peter, I agree, it is not likely, but this was in relation to embedded devices where diskspace is often at a premium. I will probably start a new thread on gentoo-user about inodes and filesystems configuration later this year. -- Joost ps. no need to reply to this :)
Re: [gentoo-dev] Re: robo-stable bugs
On Thu, 23 May 2013 23:40:42 -0600 Ryan Hill wrote: > Okay, so what are you using the STABLEREQ keyword for that you want > to set it when the bug is filed but before archs are added? The people that decided to change their way of using this keyword, did so because setting it as early as possible helps maintainers that forget to set it; I'm just following along this new approach. > If you want to see only stabilization bugs you can search in the > Keywording and Stabilization component. Yet, they brought this keyword to live for a reason; a reason unclear to me. Why is it unclear? Because nowadays people don't use it consistently; some apply it early, some apply it when they CC. > Can you suggest another way to search for stabilization bugs that > don't yet have archs CC'd (which is something I find rather useful)? Setting the keyword early helps here too, if everyone does so. Otherwise you can do ... 1) a search in Keywording and Stabilization and exclude all bugs where an arch is CC-ed, possible in the advanced search; or ... 2) obsessive summary grepping, for bugs with a wrong component set. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
[gentoo-dev] Re: robo-stable bugs
On Wed, 22 May 2013 10:58:26 +0200 Tom Wijsman wrote: > On Tue, 21 May 2013 18:57:20 -0600 > Ryan Hill wrote: > > > Also, your script does not set the STABLEREQ keyword. People are > > > having to hunt down your robo-stabilisation requests and add it > > > themselves. You should just do it yourself or turn your script off. > > > > Did you read the message? The point is you're supposed to add that > > yourself. It's not a STABLEREQ until you add arches. > > Yet the base system lead went and apply it to any stabilization bug; as > both him and Jer (the bug wrangling lead) do it this way, I'll be doing > it as well. Let's not be inconsistent with our leads unless there is > a wide decision to do so Okay, so what are you using the STABLEREQ keyword for that you want to set it when the bug is filed but before archs are added? If you want to see only stabilization bugs you can search in the Keywording and Stabilization component. Can you suggest another way to search for stabilization bugs that don't yet have archs CC'd (which is something I find rather useful)? -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: robo-stable bugs
On Thu, 23 May 2013 23:20:00 -0600 Ryan Hill wrote: > > Is a version bump an enhancement per se? > > Yes. Nothing is broken. There is no "bug" to fix. No. Things can be broken. There are almost always bugs to fix. New versions come with "bug" fixes too, users need these fixes. > > If all version bumps are > > enhancements, then why isn't Severity set to Normal instead? (What > > is an enhanced version bump to begin with, Mozilla?) > > It's not an "enhanced" bug, the bug is a request for an improvement > (aka enhance_ment_). Bug fixes are improvements too, so this definition is ambiguous. > Severity is meant to give you a way of categorizing open bugs by how > important they are, as you may want to fix actual bugs before > worrying about adding features. Version bumps do not necessarily add features; just because they have the potential to add features doesn't mean they don't fix actual bugs. > Maybe you don't use bugzilla like that but some people do and > lumping these bugs in with the "normal" ones prevents them from doing > so. Using "enhancement" prevents them from importing upstream bug fixes. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
[gentoo-dev] Re: robo-stable bugs
On Wed, 22 May 2013 13:00:46 +0200 Tom Wijsman wrote: > On Wed, 22 May 2013 11:07:26 +0200 > Ulrich Mueller wrote: > > > > > Is a stabilisation an enhancement per se? If all stabilisations > > > > are enhancements, then why isn't Severity set to Normal instead? > > > > (What is an enhanced severity to begin with, Mozilla?) > > > > > Why are they enhancements? Them having been this way is not a reason > > > not to change the priority and severity fields to make more sense. > > > > Do you agree that a version bump, i.e. an ebuild entering ~arch is > > an enhancement? Then why would it be different if the same ebuild gets > > promoted from ~arch to arch? > > Is a version bump an enhancement per se? Yes. Nothing is broken. There is no "bug" to fix. > If all version bumps are > enhancements, then why isn't Severity set to Normal instead? (What is > an enhanced version bump to begin with, Mozilla?) It's not an "enhanced" bug, the bug is a request for an improvement (aka enhance_ment_). Severity is meant to give you a way of categorizing open bugs by how important they are, as you may want to fix actual bugs before worrying about adding features. Maybe you don't use bugzilla like that but some people do and lumping these bugs in with the "normal" ones prevents them from doing so. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] gnome2.eclass does not respect ECONF_SOURCE
On Thu, May 23, 2013 at 2:31 PM, Mike Frysinger wrote:
> On Thursday 09 May 2013 12:59:11 Pacho Ramos wrote:
> > El mié, 08-05-2013 a las 20:59 -0400, Mike Frysinger escribió:
> > > On Wednesday 05 December 2012 18:02:51 Doug Goldstein wrote:
> > > > - if grep -q "disable-scrollkeeper" configure; then
> > > > + if grep -q "disable-scrollkeeper" ${ECONF_SOURCE:-.}/configure;
> then
> > >
> > > ECONF_SOURCE should be quoted
> > > -mike
> >
> > If it doesn't cause any problem (it shouldn't, I think), feel free to
> > commit adding the quotes. Thanks for noticing! (will CC gnome team to
> > keep them aware)
>
> Index: gnome2.eclass
> ===
> RCS file: /var/cvsroot/gentoo-x86/eclass/gnome2.eclass,v
> retrieving revision 1.120
> diff -u -p -r1.120 gnome2.eclass
> --- gnome2.eclass 16 Jan 2013 23:01:02 - 1.120
> +++ gnome2.eclass 23 May 2013 19:31:00 -
> @@ -122,7 +122,7 @@ gnome2_src_configure() {
> # Remember to drop 'doc' USE flag from your package if it was only
> used to
> # rebuild docs.
> # Preserve old behavior for older EAPI.
> - if grep -q "enable-gtk-doc" ${ECONF_SOURCE:-.}/configure ; then
> + if grep -q "enable-gtk-doc" "${ECONF_SOURCE:-.}"/configure ; then
> if has ${EAPI:-0} 0 1 2 3 4 && in_iuse doc ; then
> G2CONF="$(use_enable doc gtk-doc) ${G2CONF}"
> else
> @@ -132,29 +132,29 @@ gnome2_src_configure() {
>
> # Pass --disable-maintainer-mode when needed
> if grep -q "^[[:space:]]*AM_MAINTAINER_MODE(\[enable\])" \
> - ${ECONF_SOURCE:-.}/configure.*; then
> + "${ECONF_SOURCE:-.}"/configure.*; then
> G2CONF="--disable-maintainer-mode ${G2CONF}"
> fi
>
> # Pass --disable-scrollkeeper when possible
> - if grep -q "disable-scrollkeeper" ${ECONF_SOURCE:-.}/configure;
> then
> + if grep -q "disable-scrollkeeper" "${ECONF_SOURCE:-.}"/configure;
> then
> G2CONF="--disable-scrollkeeper ${G2CONF}"
> fi
>
> # Pass --disable-silent-rules when possible (not needed for
> eapi5), bug
> #429308
> if has ${EAPI:-0} 0 1 2 3 4; then
> - if grep -q "disable-silent-rules"
> ${ECONF_SOURCE:-.}/configure; then
> + if grep -q "disable-silent-rules"
> "${ECONF_SOURCE:-.}"/configure; then
> G2CONF="--disable-silent-rules ${G2CONF}"
> fi
> fi
>
> # Pass --disable-schemas-install when possible
> - if grep -q "disable-schemas-install" ${ECONF_SOURCE:-.}/configure;
> then
> + if grep -q "disable-schemas-install"
> "${ECONF_SOURCE:-.}"/configure; then
> G2CONF="--disable-schemas-install ${G2CONF}"
> fi
>
> # Pass --disable-schemas-compile when possible
> - if grep -q "disable-schemas-compile" ${ECONF_SOURCE:-.}/configure;
> then
> + if grep -q "disable-schemas-compile"
> "${ECONF_SOURCE:-.}"/configure; then
> G2CONF="--disable-schemas-compile ${G2CONF}"
> fi
>
> -mike
>
I guess I forgot to commit that to the tree when I posted it a few days
ago/week, w/e. Yeah commit that. My original commit was wrong.
--
Doug Goldstein
Re: [gentoo-dev] [PATCH multibuild.eclass] Use portable locking code from Fabian Groffen.
On 05/23/2013 12:29 PM, Mike Frysinger wrote: On Wednesday 15 May 2013 15:22:21 Michał Górny wrote: The 'userland_*' flags have proven not good enough to determine the availability of lock helpers. Fabian provided a nice portable locking code instead. Fixes: https://bugs.gentoo.org/show_bug.cgi?id=466554 --- gx86/eclass/multibuild.eclass | 29 +++-- this seems more appropriate for portability.eclass than other random places. there you can keep flock when it's available, or fall back to manual hacks like this. It can be tricky find out whether or not the underlying filesystem will behave well with flock. For example, maybe it will just fail temporarily due to lock exhaustion (ENOLCK), or maybe the filesystem doesn't support locking at all (ENOSYS). Given all of the variables, it may be safest to use hardlink locks in any case, since they work reliably on practically any relevant filesystem. So if we do end up putting something in portability.eclass, maybe hardlink locks are the way to go. Alternatively, we could add some locking functions in the next EAPI, and let the package manager handle the implementation details. -- Thanks, Zac
[gentoo-dev] Re: [gentoo-dev-announce] Bugzilla maintenance
On Thursday 23 of May 2013 23:51:33 Christian Ruppert wrote: > and getsatisfaction.com. far from what I expected :( signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] robo-stable bugs, the flipside
On 23 May 2013 19:49, Ian Stakenvicius wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 23/05/13 02:40 PM, Markos Chandras wrote: >> On 23 May 2013 19:11, Ian Stakenvicius wrote: >> Here's a new question on the robo-stable front -- I want to file a >> bug (by hand, probably) on the next stable candidate for my package >> and have the robo-stable script CC arches and STABLEREQ after 30 >> days (assuming no other bugs pop up) >> >> Is that doable? >> >> (for those of us too lazy to put an entry in our calendars :) >>> >> >> I guess you could use pybugz + cron to do what you want. >> > > homebrew, but it'd work. > > Are the sources for the auto-stable etc. script posted somewhere? I > don't think i've actually seen a URL at all in this thread (or the one > from a couple of months ago).. > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.19 (GNU/Linux) > > iF4EAREIAAYFAlGeZMgACgkQ2ugaI38ACPDeyQEAkgSoq/dJtCQjUBTJHSwTIk13 > 0odYcxYgcias45vE2vkA/j0UZRNFZbPtRhmyg9L5CO6LvfbAz92OY88wy0dcYYB5 > =Nh5F > -END PGP SIGNATURE- > I believe the sources are hosted here http://git.overlays.gentoo.org/gitweb/?p=proj/arch-tools.git;a=summary -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] [PATCH] gnome2.eclass does not respect ECONF_SOURCE
On Thursday 09 May 2013 12:59:11 Pacho Ramos wrote:
> El mié, 08-05-2013 a las 20:59 -0400, Mike Frysinger escribió:
> > On Wednesday 05 December 2012 18:02:51 Doug Goldstein wrote:
> > > - if grep -q "disable-scrollkeeper" configure; then
> > > + if grep -q "disable-scrollkeeper" ${ECONF_SOURCE:-.}/configure; then
> >
> > ECONF_SOURCE should be quoted
> > -mike
>
> If it doesn't cause any problem (it shouldn't, I think), feel free to
> commit adding the quotes. Thanks for noticing! (will CC gnome team to
> keep them aware)
Index: gnome2.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/gnome2.eclass,v
retrieving revision 1.120
diff -u -p -r1.120 gnome2.eclass
--- gnome2.eclass 16 Jan 2013 23:01:02 - 1.120
+++ gnome2.eclass 23 May 2013 19:31:00 -
@@ -122,7 +122,7 @@ gnome2_src_configure() {
# Remember to drop 'doc' USE flag from your package if it was only used
to
# rebuild docs.
# Preserve old behavior for older EAPI.
- if grep -q "enable-gtk-doc" ${ECONF_SOURCE:-.}/configure ; then
+ if grep -q "enable-gtk-doc" "${ECONF_SOURCE:-.}"/configure ; then
if has ${EAPI:-0} 0 1 2 3 4 && in_iuse doc ; then
G2CONF="$(use_enable doc gtk-doc) ${G2CONF}"
else
@@ -132,29 +132,29 @@ gnome2_src_configure() {
# Pass --disable-maintainer-mode when needed
if grep -q "^[[:space:]]*AM_MAINTAINER_MODE(\[enable\])" \
- ${ECONF_SOURCE:-.}/configure.*; then
+ "${ECONF_SOURCE:-.}"/configure.*; then
G2CONF="--disable-maintainer-mode ${G2CONF}"
fi
# Pass --disable-scrollkeeper when possible
- if grep -q "disable-scrollkeeper" ${ECONF_SOURCE:-.}/configure; then
+ if grep -q "disable-scrollkeeper" "${ECONF_SOURCE:-.}"/configure; then
G2CONF="--disable-scrollkeeper ${G2CONF}"
fi
# Pass --disable-silent-rules when possible (not needed for eapi5), bug
#429308
if has ${EAPI:-0} 0 1 2 3 4; then
- if grep -q "disable-silent-rules" ${ECONF_SOURCE:-.}/configure;
then
+ if grep -q "disable-silent-rules"
"${ECONF_SOURCE:-.}"/configure; then
G2CONF="--disable-silent-rules ${G2CONF}"
fi
fi
# Pass --disable-schemas-install when possible
- if grep -q "disable-schemas-install" ${ECONF_SOURCE:-.}/configure; then
+ if grep -q "disable-schemas-install" "${ECONF_SOURCE:-.}"/configure;
then
G2CONF="--disable-schemas-install ${G2CONF}"
fi
# Pass --disable-schemas-compile when possible
- if grep -q "disable-schemas-compile" ${ECONF_SOURCE:-.}/configure; then
+ if grep -q "disable-schemas-compile" "${ECONF_SOURCE:-.}"/configure;
then
G2CONF="--disable-schemas-compile ${G2CONF}"
fi
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] robo-stable bugs, the flipside
On Thu, May 23, 2013 at 2:49 PM, Ian Stakenvicius wrote: > > Are the sources for the auto-stable etc. script posted somewhere? I > don't think i've actually seen a URL at all in this thread (or the one > from a couple of months ago).. By all means publish your script when done. That seems like it would be useful for many, and certainly there would be no objections when used by package maintainers. It is just automating a repetitive task. Rich
Re: [gentoo-dev] [PATCH multibuild.eclass] Use portable locking code from Fabian Groffen.
On Wednesday 15 May 2013 15:22:21 Michał Górny wrote: > The 'userland_*' flags have proven not good enough to determine > the availability of lock helpers. Fabian provided a nice portable > locking code instead. > > Fixes: https://bugs.gentoo.org/show_bug.cgi?id=466554 > --- > gx86/eclass/multibuild.eclass | 29 +++-- this seems more appropriate for portability.eclass than other random places. there you can keep flock when it's available, or fall back to manual hacks like this. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/23/2013 04:02 AM, Daniel Campbell wrote: > > > I can't speak for others who wish to rid their systems of systemd, > but personally I look for any excessive use of space on my HDD, > despite it being rather large. Since you brought it up, which > packages can you think of that most or all Gentoo boxes will have > that take up more considerable amounts of files or disk space? I'm > honestly interested in *anything* that lowers the disk usage of my > OSes; to a point, anyway. Supporting X or Y codec or feature in the > kernel would be more important than saving 50kB in the kernel > binary, for instance. > It's not even that we don't agree with you, it's that you're asking package and/or PM maintainers to do a bunch of work to save you a few kilobytes of disk space. Their time is better spent elsewhere, I promise. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRnmuyAAoJEBxJck0inpOizroP/340iUw1ftiVKPh7I1cHFF19 9zBV7nW4hrQ25l0uViwLWtt9GMQ+TJK28cT3ru5/L5cQYIJpAmCpaB8bWGuLx1V3 O1XAtFJ16pu7gU72B7/0lGHIbxpl6qcMt+vKvuSnSQme6NANWadf0i3P3UvddGFS zB4QSbyyePtnjEGEL1mbN3+nZM58u9c3m0vkYfbY7TahclhH0HX48nc+IJTxReVF 22Z/KC7UaGzsXfJR+BDC0RPH42WTaVGkdytE6yotR5JchnLUxujhShYbfumbJs4g lRlP46bTlUzPEyriqRhdePsyEELDusACrIPzBK82BNEJP47WuO00kIi78CZ7dgyQ ix82I2d1UQG7+UFEui+eBroDnAmTIPxOgxsIBYMNTc2pUJmnSqHva7iY8QMkBEvo LddGMLFpjHj3D2LfM4L+RwZxpz0XRZCtZeDeYRnkXqEuPj7Df9/t+3LV5zljyho7 ppRJtBQvHGpB6G7z3HALyc8XIMXQmDtTBoE+CJms8Ifzd2Hs05Muo05he2C+dr8c b0zDg/5LqG2XloszqB+1MxZNvL9O8vUpAZS9ZIu/Q8+4UpGXO5yPav42aHIWx+Zi t4KYd8m9i4Wlusi+o4PCBvW4R0a0aOPJyfExg2eqKNFxMcZ2W+pUFgM2tFiZZC10 Am4B9ySQtlgiYa5Agwg2 =gYkv -END PGP SIGNATURE-
Re: [gentoo-dev] robo-stable bugs, the flipside
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23/05/13 02:40 PM, Markos Chandras wrote: > On 23 May 2013 19:11, Ian Stakenvicius wrote: > Here's a new question on the robo-stable front -- I want to file a > bug (by hand, probably) on the next stable candidate for my package > and have the robo-stable script CC arches and STABLEREQ after 30 > days (assuming no other bugs pop up) > > Is that doable? > > (for those of us too lazy to put an entry in our calendars :) >> > > I guess you could use pybugz + cron to do what you want. > homebrew, but it'd work. Are the sources for the auto-stable etc. script posted somewhere? I don't think i've actually seen a URL at all in this thread (or the one from a couple of months ago).. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGeZMgACgkQ2ugaI38ACPDeyQEAkgSoq/dJtCQjUBTJHSwTIk13 0odYcxYgcias45vE2vkA/j0UZRNFZbPtRhmyg9L5CO6LvfbAz92OY88wy0dcYYB5 =Nh5F -END PGP SIGNATURE-
Re: [gentoo-dev] robo-stable bugs, the flipside
On 23 May 2013 19:11, Ian Stakenvicius wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Here's a new question on the robo-stable front -- I want to file a bug > (by hand, probably) on the next stable candidate for my package and > have the robo-stable script CC arches and STABLEREQ after 30 days > (assuming no other bugs pop up) > > Is that doable? > > (for those of us too lazy to put an entry in our calendars :) > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.19 (GNU/Linux) > > iF4EAREIAAYFAlGeW8wACgkQ2ugaI38ACPA9HgEAqofd3JKguCgiaDCS65kD23U1 > rqc6POpLzA9oW/qmYqoA/0fmOLcgxxQnIQ79wzBWfF+RjNhcx3rt/wJBvFdiDkSm > =Ftge > -END PGP SIGNATURE- > I guess you could use pybugz + cron to do what you want. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
[gentoo-dev] robo-stable bugs, the flipside
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Here's a new question on the robo-stable front -- I want to file a bug (by hand, probably) on the next stable candidate for my package and have the robo-stable script CC arches and STABLEREQ after 30 days (assuming no other bugs pop up) Is that doable? (for those of us too lazy to put an entry in our calendars :) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGeW8wACgkQ2ugaI38ACPA9HgEAqofd3JKguCgiaDCS65kD23U1 rqc6POpLzA9oW/qmYqoA/0fmOLcgxxQnIQ79wzBWfF+RjNhcx3rt/wJBvFdiDkSm =Ftge -END PGP SIGNATURE-
Re: [gentoo-dev] robo-stable bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22/05/13 07:03 PM, Rick "Zero_Chaos" Farina wrote: > On 05/22/2013 09:11 AM, Ian Stakenvicius wrote: >> On 21/05/13 11:46 PM, Rick "Zero_Chaos" Farina wrote: > >>> I do, however, completely agree that there should be some way >>> to leave the bug open and state that it will be stabled later. >>> Would a comment trigger this in the script? That seems >>> semi-sane. If the maintainer wanted to stabilize things they >>> would cc arches, any other comment could likely be understood >>> to mean "don't auto-stable this". > >> Maybe we can do something with bug status? Something along the >> lines maybe of filing as 'unconfirmed' and a dev setting it to >> 'confirmed' (or anything else) would make it be ignored by the >> auto-stabilizer ? Or maybe 'confirmed' is the initial status and >> a dev can set it to 'unconfirmed' or w/e... ? > > > Changing Confirmed->Unconfirmed seems like a good policy. Also if > we are going to start establishing such policies they should be > posted somewhere and linked to from the autostabilization script's > comment. > I expect the script can probably work on the basis that any status other than what the bug was filed with is an exclusion for the auto-stable pass (confirmed->unconfirmed in this case). However, yes I agree it would be very useful to have a link to some page, describing the the whole autostabilization process (what the script does, how devs can interact with it). -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGeEiUACgkQ2ugaI38ACPAeNAD/QcSQL7yufe2YpKTb2cV2VP0r WJoHs4uozZIsRDrYXjcA/1icODLSi/sjCl6+zRLjdiUKvRJbKiz2FZRzAtZ3IjFN =B9Pd -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 23 May 2013 03:02:30 -0500 Daniel Campbell wrote: > I can't speak for others who wish to rid their systems of systemd, but > personally I look for any excessive use of space on my HDD, despite it > being rather large. Since you brought it up, which packages can you > think of that most or all Gentoo boxes will have that take up more > considerable amounts of files or disk space? I'm honestly interested > in *anything* that lowers the disk usage of my OSes; to a point, > anyway. Supporting X or Y codec or feature in the kernel would be more > important than saving 50kB in the kernel binary, for instance. These things are likely documented on websites on the internet, on wikis related to Gentoo and on our forums; if not, you can always start a new thread on the Gentoo Forums, a new discussion on social media (Google+, #gentoo-chat on FreeNode, the gentoo-user ML, ...) or so. Feel free to ping me by mail if you do so, I'll be happy to help... If you are an user that wishes to contribute to gentoo-dev, please stay on topic in the thread you are discussing in as well as with the goal of the ML; if you think we should implement or document space cleaning better, then you're always welcome to start a new thread about that. Thank you in advance. - -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBAgAGBQJRneV4AAoJEJWyH81tNOV9i8kIAJ8ukPzgwMCFcNVc9u/4PFPh r3T2bHUNZDK7tZoOtjgdQsiEhwtZGThDaIbNbJ3xvAzqh0gd/mY2qUDBKSZRX8oS JzFK86ZhjKqwm8TBZH/kXTRx98IgV6XxGmsDaGO0c9Zy0lQOzjhdhcCIpzVQwCa9 tZ51n0YlZQcCmL7ZU66/7Nd9Wrx6M6in9Jik6TSk7DH9ACs6IxTKG2WF1kVShI2m rd50w//F2ACHHZ0pXWjX9XJmNMOkD+jjHI/yV23GvObXJ8ZqXiicAIAT7G89YtBi G1ew93E2p9WQ06qIFSMfl/+4yQYTfHFRkSpetTAIkpXfAPruoXNhGmaDmadY+is= =V7zd -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/23/2013 01:41 AM, Michał Górny wrote: > On Wed, 22 May 2013 16:39:25 -0500 Daniel Campbell > wrote: > >> I'm curious as to why you consider users who want to save disk >> space (openrc or systemd, or other packages, it doesn't matter) >> as fundamentalists. > > I'd call them using other words but I didn't want to be that > inpolite. Seriously, there are bigger problems in the world than a > few text files. And much bigger useless space consumers which you > don't even notice because they don't have the 'systemd' name on > them. > > If you care about disk space, then find the biggest consumers and > try to work on them. Otherwise, you're just picking. And that's > close to fundamentalism. > I can't speak for others who wish to rid their systems of systemd, but personally I look for any excessive use of space on my HDD, despite it being rather large. Since you brought it up, which packages can you think of that most or all Gentoo boxes will have that take up more considerable amounts of files or disk space? I'm honestly interested in *anything* that lowers the disk usage of my OSes; to a point, anyway. Supporting X or Y codec or feature in the kernel would be more important than saving 50kB in the kernel binary, for instance. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRnc0WAAoJEJUrb08JgYgH8I0H/RqmDrgkexeLCaBB2RDXKyjv EAZeVQvjNuxzTJz5Qr+CNHgpAk58YCZVcH+IBspD3Ks1DatKzyoSxuwwG70lfDmX k/Rp9T+YL/gZnC3Ey6x/ScAwZIDlDbbZO3xwOt+3fHZEhiCE4IFEsCiaWCwEGHV1 NrROzDRBICYc9KePAtksqvYEovu8ex2JCAbthHhDb7fKvr3TqWCBzWtbSMVr0x9k ZWliahhmEx7IjZ65/yvv/AM2JYzLwaM1hwQxYUX+myTK5YFjMAaMLMZrEgiWp6KZ a8R0sW7SqbBlbP2z7nJjCrlggDYqMMF4Mv1x7uT0QPiiRxq32+FHcJinwecTHS8= =sOIU -END PGP SIGNATURE-
[gentoo-dev] Re: Making systemd more accessible to "normal" users
Tom Wijsman posted on Thu, 23 May 2013 08:57:02 +0200 as excerpted:
> If you really think[1] you need INSTALL_MASK for a few small files when
> there are much larger consumers around, you should carefully consider
> whether what you are doing is the right thing. ("OMG systemd units!")
>
>> [1] Think: Or for that matter, demonstrate to yourself and others.
Definitely agreed, there. IMO that whole issue's a tempest in a teapot,
as the saying goes, not only because it's a trivial use of space, but
because the solution for any gentooer that actually cares is equally
trivial.
That's part of what gentoo is all about, having the tools available to
simply do things like this for those who care to (see the whole Larry the
Cow thing), which we do... as a major bullet point of what makes us
gentoo. =:^)
--
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
