Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

[Peter Volkov]

On Wed, Jan 10, 2018 at 9:31 PM, Aaron W. Swenson 
wrote:

> Title: GnuCash 2.7+ Breaking Change
>

Aaron, but why do we need this news item? 2.7 version is a development
version that is not supposed to be used by end users. As far as I
understand this backup is a temporary measure until stable release will be
out. It's much better to have this version package masked. Then in package
mask comment we could note the need for backup.

--
Peter.

Re: [gentoo-dev] Open Build Service

[Peter Volkov]

On Tue, Nov 14, 2017 at 4:47 AM, Samuel Bernardo <
samuelbernardo.m...@gmail.com> wrote:
The only feature that would be useful for now is emerge obtaining the

> precompiled binary packages to install in containers/VMs from http
> rather than nfs[1].
>

Samuel, probably I miss something but this should work out of box:
https://wiki.gentoo.org/wiki/Binary_package_guide#Web_based_binary_package_host

Or do you mean something else?

--
Peter.

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Peter Volkov]

On Mon, Jul 31, 2017 at 6:11 PM, Rich Freeman  wrote:

> On Mon, Jul 31, 2017 at 10:52 AM, Alec Warner  wrote:
> > Sorry, to be clear the conclusion I was hoping to draw is that one has 2
> > repos instead of 1.
> >
> > 1) Rolling.
> > 2) Stable.
> >
> > Rolling is typical ~arch Gentoo. People in rolling can do whatever they
> > want; they can't affect stable at all.
> >
> > Stable is an entirely separate repo, a fork, where CPVs are pulled from
> > Rolling into Stable. If Stable wants to keep a gnarly old version of some
> > package around; great! But the rolling people don't have to care.
> >
>
> This seems like it would be fairly painful to maintain.  You'd need to
> constantly pull in new packages, and prune out old ones.  It would
> duplicate many of the functions maintainers already do.  I doubt
> anybody would go to the trouble to make this happen.
>

Long time ago releng team did something similar. We defined stable as
tested distribution that has all security updates merged back. From my
experience what made that efforts very tedious was that there were packages
that do not specify minimum required versions for dependencies. Thus we had
to duplicate maintainer's work and check lot's of dependencies again.

Also when we speak about stable tree we first should define what stability
are we talking about? What do we guarantee? ABI/API compatibility or that
it is expected "just work" (whatever this means)?

--
Peter.

Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

[Peter Volkov]

Hi.

On Wed, May 31, 2017 at 10:32 PM, Vadim A. Misbakh-Soloviov 
wrote:
> Currently, we have a situation, that there are two Vim's: "old" one
(vim8) and
> NeoVim... Unfortunately, both of them have different runtimedirs...
>
> ... NeoVim supports Vim's plugins/scripts very well (although I
> didn't find any evidence of the opposite), so it is possible to fix that
> situation by many of "kludge" ways, including:
>
> - patching NeoVim source to include Vim's runtimedirs (incl. "after" dir),
> // NeoVim upstream highly disagree with such way, if any

But what is the reasoning for upstream from this way? If NeoVim supports
vim plugins but not vice versa this looks as a very logical step.

--
Peter.

Re: [gentoo-dev] Packages up for grabs

[Peter Volkov]

В Сб, 19/10/2013 в 18:12 +0200, Pacho Ramos пишет:
> sys-fs/vzquota

This is part of openvz. Took this.

--
Peter.

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Peter Volkov]

В Вс, 13/10/2013 в 14:32 -0500, William Hubbs пишет:
> from what I'm seeing, we should look into converting /etc/mtab to a
> symlink to /proc/self/mounts [1].
> 
> Are there any remaining concerns about doing this?

The only concern I have how this change affects *BSD or prefix? But yet
I failed to find a package that is affected and that is not Linux
specific.

--
Peter.

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Peter Volkov]

В Вс, 13/10/2013 в 14:13 -0700, Matt Turner пишет:
> On Sun, Oct 13, 2013 at 12:32 PM, William Hubbs  wrote:
> > from what I'm seeing, we should look into converting /etc/mtab to a
> > symlink to /proc/self/mounts [1].

> Is the issue with NFS user mounts resolved? (Mentioned
> https://wiki.gentoo.org/wiki/Systemd#.2Fetc.2Fmtab and elsewhere)

Looks like Gentoo's nfs-utils package does not support this. nfs-utils
have --enable-libmount-mount so we just need to start using it.
https://bugs.gentoo.org/show_bug.cgi?id=487962

BTW, most distributions did all this changes two years ago, so all
packages have support for mtab. For exampled, I've checked two packages
that had this problem two years ago and one package unconditionally
depends on libmount (pam_mount) while another just avoids touch mtab if
it's not writable and works anyway (cifs-utils). Both packages with
required changes are in Gentoo's stable tree :)

--
Peter.

Re: [gentoo-dev] stabilizing libraries without testing reverse deps

[Peter Volkov]

В Пн, 30/09/2013 в 00:54 +0200, Andreas K. Huettel пишет:
> Am Sonntag, 29. September 2013, 23:41:03 schrieb hasufell:
> > It seems this happens more frequently these days, so I'd like to
> > remind people to check stable reverse deps before stabilizing a
> > library, especially when this is a non-maintainer stablereq.
> > 
> > Arch teams do not test them, so this is the business of the maintainer
> > or the dev who requested stabilization.
> 
> Arch testing includes testing of reverse deps. 
> If that's not the case, arch teams are not doing their job.

I think it's good idea if maintainers and arch team developers will work
in tandem and help each other by both checking reverse deps. That said
the question here is who is in charge for stable tree stability? Stable
tree is the arch team's primary responsibility. That is why only they
are allowed to touch stable keywords after all. So arch team developer
should never commit anything if at least few reverse deps were checked.
Last but not least, I guess that average developer has lot's of things
in package.keywords, so it's not sane to expect developer to do stable
tree checks.

--
Peter.

Re: [gentoo-dev] does v8 shared library make sense with current upstream approach?

[Peter Volkov]

В Вт, 24/09/2013 в 11:46 -0700, "Paweł Hajdan, Jr." пишет:
> On 9/22/13 5:24 PM, Peter Stuge wrote:
> > "Paweł Hajdan, Jr." wrote:
> >> "compiling with versions of v8 other than what is included is not
> >> currently supported."
> > ..
> >> For now V8 upstream gives no guarantees about API/ABI stability and
> >> actually breaks it very often
> > 
> > I agree that it isn't worth the effort to try to offer V8 as a
> > library then.
> 
> Perfect.

But could you comment on how hard it'll be to slot v8 shared library?
Keeping libraries bundled is a security nightmare.

--
Peter.

Re: [gentoo-dev] vserver herd is empty

[Peter Volkov]

В Вс, 21/07/2013 в 10:23 +0200, Pacho Ramos пишет:
> Will remove the herd if nobody joins in a week.

I talked to hollow and we think it's worth to remove this herd.

Actually only openvz and vserver packages are in this herd and they are
maintained completely independently for a long time... I'll drop this
herd from metadata.xml in few days.

--
Peter.

[gentoo-dev] Last rites: net-libs/wt

[Peter Volkov]

net-libs/wt library was added to the tree for net-p2p/eiskaltdcpp. Later
upstream decided not to use it and net-libs/wt left unmaintained. Now it
is broken and requires version bump. If anybody is interested in this
library, please, take it. If nobody steps in next month I'll drop it
from the tree.

--
Peter.

Re: [gentoo-dev] News Item - MythTV

[Peter Volkov]

В Птн, 09/12/2011 в 20:38 -0500, Rich Freeman пишет:
> I'm considering sending out this news item in a few days - comments
> are welcome.  It is a bit different in tone from a typical news item
> but MythTV has been in not-so-great shape for a while and my goal is
> to reel things in a bit and commit to something we can continue to
> maintain, while soliciting help from the community.

This does not look like a news item, but more like a project status
update or blog post. Probably it's much better to create webpage (or
news item) on www.gentoo.org and add elog/ewarn to point there. Once
mythtv team changes this information may change, but all users will see
it anyway.

--
Peter.

Re: [gentoo-dev] rfc: news item for png15

[Peter Volkov]

В Птн, 14/10/2011 в 01:01 +0300, Samuli Suominen пишет:
> small news item for stable users. lets keep it simple...

I think it's better to put all knowledge from forum post inside:
1.  --keep-going option for revdep-rebuild.
2. better find:
find /usr -name "*.la" -o -name "*.pc" -o -name "*-config" -exec grep -H
png14 {} \;
or even better to provide one-liner for user's convenience.

--
Peter.

Re: [gentoo-dev] Re: Lastrite: media-gfx/pngcrush

[Peter Volkov]

В Втр, 11/10/2011 в 19:10 +0300, Samuli Suominen пишет:
> > Samuli pretends here to act as a part of QA team (although he is not).
> > Actually even whiteboard of stabilization bug tells #at _earliest_ 17
> > Oct" and thus there is really no sign for rush. This is the case where
> > QA should voice and either explain why fast stabilization of libpng is
> > so important or stop policy breakage. That said it became really common
> > to break our own policies (with no attempts to amend policy).
> 
> full stop.

[snip history]

> what does this has to with qa@ team?

The only bodies that are allowed to avoid policies in Gentoo are QA and
security teams. Since this issue has nothing to do with security the
only option left is QA.

> so no, you don't get to use this as anykind of weapon against me or
> anyone else involved.

Sorry, I never wanted to touch any weapons and I really appreciate your
efforts. You really do tremendous job for Gentoo. But this is not the
first thread where I ask you same question: what is the problem to
follow policy? If it was a mistake what's the problem to sorry and
update mask interval. If not... What will happen if you keep hard masked
package for 30 days instead of 14? How this will affect libpng
stabilization? The only thing that changes - we will have 56
non-development related mails less in our mailboxes.

--
Peter.

Re: [gentoo-dev] Re: Lastrite: media-gfx/pngcrush

[Peter Volkov]

В Втр, 11/10/2011 в 08:09 +0100, Markos Chandras пишет:
> Isn't this the same situation with gcc stabilizations?

No. As was pointed many times, there was (and still is) no clear
stabilization path announced. But there is some work behind scene and
pressing dates with absolutely no need. If you want developers to
cooperate make checkpoints clear and make this information available in
advance.

--
Peter.

Re: [gentoo-dev] Re: Lastrite: media-gfx/pngcrush

[Peter Volkov]

В Вск, 09/10/2011 в 22:28 +, Duncan пишет:
> Chí-Thanh Christopher Nguyễn posted on Sun, 09 Oct 2011 18:37:59 +0200 as
> excerpted:
> 
> > Duncan schrieb:
> >> Libpng isn't held up that way, while the package still gets its 30 day
> >> masking last-rites.  No policy broken; no maintainer toes stepped on as
> >> a result of the broken policy.  No more nasty threads about (this)
> >> broken policy and unhappy maintainers as a result! =:^)
> > 
> > Actually removing a package that doesn't violate any (written) rules
> > without maintainer consensus could be considered a violation of policy
> > too.
> > 
> > http://www.gentoo.org/proj/en/devrel/recruiters/mentor.xml Respect
> > existing maintainers:
> > Never commit when someone else has clear ownership. Never commit on
> > things with unclear ownership until you've tried to clear it up.

Samuli pretends here to act as a part of QA team (although he is not).
Actually even whiteboard of stabilization bug tells #at _earliest_ 17
Oct" and thus there is really no sign for rush. This is the case where
QA should voice and either explain why fast stabilization of libpng is
so important or stop policy breakage. That said it became really common
to break our own policies (with no attempts to amend policy).

> You are correct, but AFAIK, that's one function of tree-cleaners (whether 
> or not the remover is actually on the tree-cleaner team), when packages 
> are broken due to going stale against current, and the bugs reporting the 
> problem remain open for months without (visible) movement (there's some 
> movement here, yes, but was it visible?).

No treecleaners are supposed to be working on maintainer-needed packages
only:
http://www.gentoo.org/proj/en/qa/treecleaners/index.xml

> So, please, at LEAST honor the 30-day-in-mask bit.  

This must be honored.

--
Peter.

Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/wireshark: wireshark-1.6.2.ebuild ChangeLog wireshark-1.4.9.ebuild wireshark-1.4.7.ebuild wireshark-1.6.0_rc1.ebuild wiresha

[Peter Volkov]

В Втр, 13/09/2011 в 11:53 +0200, Diego Elio Pettenò пишет:
> Il giorno mar, 13/09/2011 alle 10.28 +0100, Ciaran McCreesh ha scritto:
> > In that case blocking just old versions is wrong, since if your
> > installed version is broken and you try to reinstall, you'll need to
> > uninstall first too.

wireshark relinks against system wsutil library during 'make DESTDIR=
${D} install', so once wireshark-1.6 is installed we have
libwsutil.so.1.0.0. There is nothing bad linking with correct library
version (even though binary came from previous version).

> It doesn't matter as much when it's the same version because then it
> would have the same soversion and thus it wouldn't cause _visible_
> trouble.
> 
> It might be interesting to note that it seems like rc4->final also
> causes the same problem.

Well, I can just drop _rc part in blocker. _rc versions were hardmasked
anyway.

> Just for completeness sake, this can usually be fixed/worked around by
> making sure to list just-built .la files _before_ the /usr libraries. I
> had to work that around on opensc before. PAM also suffers from the same
> issue _if_ the .la files are kept around.

Hm interesting. Actually I've tried to strace libtool and it have not
touched system .la files but since we drop .la anyway I'll recheck.

--
Peter.

[gentoo-dev] Last rites: net-wireless/madwifi-old{,-tools}

[Peter Volkov]

+# Peter Volkov  (02 Oct 2011)
+# Old package for very old kernel, unmaintained, fails to build, bug
#362827
+net-wireless/madwifi-old
+net-wireless/madwifi-old-tools

Pending removal on 02 Nov 2011.

-- 
Peter.

[gentoo-dev] Last rites: gnome-extra/gget

[Peter Volkov]

Has no maintainer. Has runtime problems. Dead upstream.
Removal in 30 days. Bug #377979
gnome-extra/gget

--
Peter.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/aria2: aria2-1.12.0.ebuild ChangeLog

[Peter Volkov]

В Птн, 01/07/2011 в 09:09 +0100, Ciaran McCreesh пишет:
> On Fri, 01 Jul 2011 12:03:41 +0400
> Peter Volkov  wrote:
> > > pkg_setup() {
> > >   if use scripts && use !xmlrpc && use !metalink; then
> > 
> > This really calls for REQUIRED_USE from EAPI="4".
> > 
> > REQUIRED_USE="scripts? ( ^^ ( xmlrpc metalink ) )"
> 
> That's not the same condition as the one in the pkg_setup.

Ah, yea. I guess any of xmlrpc or metalink are required for scripts. So,
correct one should be:

REQUIRED_USE="scripts? ( || ( xmlrpc metalink ) )"

--
Peter.

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/aria2: aria2-1.12.0.ebuild ChangeLog

[Peter Volkov]

В Чтв, 30/06/2011 в 19:27 +, Sebastian Pipping (sping) пишет: 
> Log:
>   net-misc/aria2: Bump to 1.12.0, looks trivial
>  
> EAPI="2"
> 
> inherit bash-completion
...
> pkg_setup() {
>   if use scripts && use !xmlrpc && use !metalink; then
>   ewarn "Please also enable the 'xmlrpc' USE flag to actually use 
> the additional scripts"
>   fi
> }

This really calls for REQUIRED_USE from EAPI="4".

REQUIRED_USE="scripts? ( ^^ ( xmlrpc metalink ) )"

> src_install() {
>   emake DESTDIR="${D}" install || die "emake install failed"
> 
>   rm -rf "${D}/usr/share/doc/aria2"

|| die

--
Peter. 

Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?

[Peter Volkov]

В Срд, 29/06/2011 в 07:53 +0100, Ciaran McCreesh пишет: 
> On Wed, 29 Jun 2011 02:47:36 -0400
> Mike Frysinger  wrote:
> > > Both. There's code in Paludis that duplicates a bunch of that stuff
> > > simply because I wasn't sure what I could and couldn't rely upon.
> > 
> > the file should provide the classic e* output funcs that we've all
> > grown to love, and are now enshrined in PMS.  it has had other
> > functions come and go over the years, but i think things have settled
> > on just the output helpers.  was there anything other than the output
> > helpers you were interested in ?
> 
> I seem to recall duplicating the colours stuff for Eselect too. But the
> variable names seem to be different there, and the 'portageq' call
> screws around with things, so perhaps by now things have diverged to the
> extent that it's easier to just keep similar but different code around.

Having single location for this functions allows system wide
customization of colors...

Personally I'd like to have this functions in separate package. What if
we'll provide two tarballs from the single openrc sources, e.g.
efunctions.tar.bz2 and openrc.tar.bz2, and correspodingly two packages?
openrc tarbal will have code for efunctions included but its
installation will be disabled in ebuild. This way we'll have full openrc
sources for those who need it and in Gentoo we'll have separate package
with efunctions for other packages to depend on.

--
Peter. 

Re: [gentoo-dev] demanual update (was: Don't use / when applying sed with CFLAGS)

[Peter Volkov]

В Втр, 28/06/2011 в 12:23 -0400, Mike Frysinger пишет:
> On Tuesday, June 28, 2011 02:54:03 Michał Górny wrote:
> > emake CC="$(tc-getCC)" CFLAGS="${CFLAGS}"...
> 
> this is easily dangerous when it comes to packages (and many do) that append 
> in the Makefile.  specifying on the command line blocks those while passing 
> via env works fine.  i'm not sure it's appropriate to provide as an example.

Hm, I'm not sure I understand what you are talking about here. Could you
provide example?

--
Peter.

Re: [gentoo-dev] demanual update (was: Don't use / when applying sed with CFLAGS)

[Peter Volkov]

Thank you Fabian, Michał. Added note on Makefile and mentioned other
tools as well. Updated patch is in attachment.

--
Peter.
>From 9d24f4bab09be481e70ab04c85f20a246162dc0a Mon Sep 17 00:00:00 2001
From: Peter Volkov 
Date: Tue, 28 Jun 2011 10:05:17 +0400
Subject: [PATCH] Use | as a separator for sed'ing CFLAGS

/, : is a bad idea per thread on gentoo-dev:

http://archives.gentoo.org/gentoo-dev/msg_654cd9daf2548a524c8a09a82b80916f.xml
---
 .../functions/src_compile/building/text.xml|   31 +++
 1 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/ebuild-writing/functions/src_compile/building/text.xml b/ebuild-writing/functions/src_compile/building/text.xml
index 700f0f1..1bc3ec2 100644
--- a/ebuild-writing/functions/src_compile/building/text.xml
+++ b/ebuild-writing/functions/src_compile/building/text.xml
@@ -43,10 +43,24 @@ It is not correct to use the ${CC} variable for this purpose.
 
 
 
-Sometimes a package will not use the user's ${CFLAGS} or ${LDFLAGS}.
-This must be worked around, as sometimes these variables are used for specifying
-critical ABI options. In these cases, the build scripts should be modified (for
-example, with sed) to use ${CFLAGS} or ${LDFLAGS} correctly.
+Sometimes a package will not use the user's ${CFLAGS} or
+${LDFLAGS}. This must be worked around, as sometimes these variables are
+used for specifying critical ABI options. In some cases it's enough to pass
+correct parameters for the emake (check Makefile to see if this is
+possible):
+
+
+
+EAPI="4"
+
+src_compile() {
+	emake CC="$(tc-getCC)" CFLAGS="${CFLAGS}"
+}
+
+
+
+In other cases, the build scripts should be modified (for example, with
+sed) to use ${CFLAGS} or ${LDFLAGS} correctly.
 
 
 
@@ -58,15 +72,18 @@ src_compile() {
 
 # We have a weird build.sh to work with which ignores our
 # compiler preferences. yay!
-sed -i -e "s:cc -O2:$(tc-getCC) ${CFLAGS} ${LDFLAGS}:" build.sh \
+sed -i -e "s|cc -O2|$(tc-getCC) ${CFLAGS} ${LDFLAGS}|" build.sh \
 || die "sed fix failed. Uh-oh..."
 ./build.sh || die "Build failed!"
 }
 
 
 
-When using sed with CFLAGS or LDFLAGS, it is not safe to use
-a comma or a slash as a delimiter. The recommended character is a colon.
+When using sed with CFLAGS or LDFLAGS, it is not safe to
+use a comma, a colon or a slash as a delimiter. gcc, ld,
+ar, etc... options may contain this characters so sed will fail
+after bash expansion. The recommended character is a vertical bar: '|' (the
+pipe).
 
 
 
-- 
1.7.3.4

Re: [gentoo-dev] SHA256 and indention in metadata.xml

[Peter Volkov]

В Сбт, 25/06/2011 в 13:24 -0400, Mike Frysinger пишет:
> On Sat, Jun 25, 2011 at 10:23, Nirbheek Chauhan wrote:
> > On Sat, Jun 25, 2011 at 6:16 PM, justin wrote:
> >> Another question, do we have a rule, how the metadata.xml has to be
> >> indented? Tabs or n spaces?
> >
> > There's no rule, but we should follow the same rule as ebuilds —
> > indentation should be with a tab that's displayed as 4 spaces in
> > editors (no expansion of tabs to spaces).
> 
> meh ... let devs do whatever they want

Why? This looks like perfect case to use standard indentation.
Personally I'd like indentation to be fixed (and I don't really care
how).

--
Peter.

Re: [gentoo-dev] SHA256 and indention in metadata.xml

[Peter Volkov]

В Вск, 26/06/2011 в 17:20 +0200, Maciej Mrozowski пишет:
> I never understood the reason after keeping deps not sorted alphabetically 
> where order doesn't matter - it's like someone purposely made ebuild harder 
> to 
> read - it's counter productive.

Like with perl modules with well written configure.ac I like them to be
sorted in the order there. This way makes easier for me to see if there
is anything redundant in deps or not.

--
Peter.

Re: [gentoo-dev] Are tags just sets?

[Peter Volkov]

В Пнд, 27/06/2011 в 20:26 -0700, Brian Harring пишет:
> > Second, make a bunch of sets named kde-tag, editors-tag, xml-tag,
> > monkeys-tag etc.

I'd like avoid editing multiple files. Much better will be keep tags
with package.

> Counter proposal; use what you're proposing as a cache.  metadata.xml 
> is the proper place for this

++

> Roughly, and this is definitely a rough sketch:
> 
> 
>  tag1 tag2 tag2 tag3
>  awesomeness
> 

Since use dependencies eapi should be provided somewhere.

Also I like metadata.xml proposal since it'll be easy to use
per-category metadata.xml for all ebuilds to inherit.

--
Peter.

Re: [gentoo-dev] Re: Thoughts about broken package handling

[Peter Volkov]

В Втр, 28/06/2011 в 07:17 +0100, Ciaran McCreesh пишет:
> There was going to be a really simple, elegant, ebuild-controllable and
> provably working fix for that in EAPI 4 in the form of := deps, but
> they got dropped because Portage couldn't implement it.
> 
> Which is strange, because it should have been a ten minute job...

There is a good opportunity to  resubmit this for EAPI=5 ;)

--
Peter.

[gentoo-dev] RFC: optinal run time dependencies

[Peter Volkov]

Hi guys. We've had discussion on optional runtime dependencies in bug
361255, but I think it's worth to have broader discussion of this issue.

=
Abstract

Optional runtime dependencies are dependent packages that are not
required to run program but when installed enhance program run-time
features. Below new use flag prefix is suggested to handle such rdeps.

Motivation

Optional run time dependencies are packages that are not required at
runtime
but when installed provide additional features for program. For example,
app-text/asciidoc works fine without media-gfx/graphviz, but to generate
diagrams from a textual specification media-gfx/graphviz have to be
installed.

Currently there are two common approaches for this problem:

1. add a use flag to control runtime dependency
2. add elog message into pkg_postinst to notify users that some features
depend
on installing package A, B, etc.

Both of this approaches are suboptimal.

Use-flags (1) will require user to rebuild package just to install
optional runtime
dependency.

elog messages do not present possible features during emerge --preted.
So 
after reading elog message this requires user to run another emerge just
to
have all asciidoc features installed.

elog-message approach complicates developement. Let's consider case
where
package foo depends on asciidoc with graph support. Without use flags 
foo-ver.ebuild have to contain something like:

RDEPEND="
app-text/asciidoc
media-gfx/graphviz"

Now it is possible that graph provider for app-text/asciidoc changes
(e.g. on
graphviz-ng). In such case all this packages that require asciidoc with
graph support
will have to be updated (controrary to use-flag approach where
asciidoc[graphviz]
dependency is sufficient).

Also sometimes more then one package is required to provide feature.
net-im/psi it requires both net-im/psimedia and app-crypt/qca-ossl:2 for
voice calls (jingle) support:

PDEPEND="
jingle? ( net-im/psimedia
app-crypt/qca-ossl:2 )"

net-im/psimedia builds fine without app-crypt/qca-ossl:2 but it is still
required
to have working jingle in psi. Such dependencies are not very evident
for
non-maintainer and may cause problems during upgrade if, say, another
bar
dependency will became required for jingle support, but user/developer
will be
not very attentive rereading yet another time ewarn messages.

Also elog approach adds text into anyway overloaded elog output.

Specification

Starting with EAPI=X new prefix ~ is allowed in IUSE use flag
definition. Use
flags prefixed with ~ are not allowed to be used anywhere but only
inside
PDEPEND dependency specification. This USE flags are used during
dependency
resolution as normal. Package manager is allowed to skip re-installation
of the
package due to this USE flag change but still it should record such USE
change
into package database.

Rationale

Since use-flag approach has only one drawback it's good idea to fix it.

Backwards Compatibility

This should be inside some future EAPI thus is backward compatible.
Already existing prefixes (+ and -) are allowed to be in any part of
prefix, i.e. IUSE="~foo ~+bar +~baz" should work.
=

Comments?

May be instead of ~ introduce three additional prefixes (~ and another
two for +~ and -~ cases)?

--
Peter.

[gentoo-dev] demanual update (was: Don't use / when applying sed with CFLAGS)

[Peter Volkov]

В Пнд, 27/06/2011 в 17:01 +0200, Fabian Groffen пишет:
> On 27-06-2011 14:08:52 +, Justin Lecher wrote:
> > Please do not use / as seperater when using sed with CFLAGS. I came
> across a bug today where it failed for crossdev. Here the toolchain
> header paths in the cflags and consowuently the seds fail.

This is already documented (see link below).

> Please also don't use ':' as separator, as some platforms have options
> for their toolchain that includes colons.

But still our documentation explicitly suggests ':' for CFLAGS cases and
example allows bash substitution.

http://devmanual.gentoo.org/ebuild-writing/functions/src_compile/building/index.html
see example in "Fixing Compiler Usage" section and text below:
sed -i -e "s:cc -O2:$(tc-getCC) ${CFLAGS} ${LDFLAGS}:" build.sh

Are there any objections to suggest '|' for CFLAGS, LDFLAGS (see
attachment)?

--
Peter.

>From 989cd3700ec0f3aa13cfca08b97c4c461b738883 Mon Sep 17 00:00:00 2001
From: Peter Volkov 
Date: Tue, 28 Jun 2011 10:05:17 +0400
Subject: [PATCH] Use | as a separator for sed'ing CFLAGS

/, : is a bad idea per thread on gentoo-dev:

http://archives.gentoo.org/gentoo-dev/msg_654cd9daf2548a524c8a09a82b80916f.xml
---
 .../functions/src_compile/building/text.xml|8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/ebuild-writing/functions/src_compile/building/text.xml b/ebuild-writing/functions/src_compile/building/text.xml
index 700f0f1..550ef5c 100644
--- a/ebuild-writing/functions/src_compile/building/text.xml
+++ b/ebuild-writing/functions/src_compile/building/text.xml
@@ -58,15 +58,17 @@ src_compile() {
 
 # We have a weird build.sh to work with which ignores our
 # compiler preferences. yay!
-sed -i -e "s:cc -O2:$(tc-getCC) ${CFLAGS} ${LDFLAGS}:" build.sh \
+sed -i -e "s|cc -O2|$(tc-getCC) ${CFLAGS} ${LDFLAGS}|" build.sh \
 || die "sed fix failed. Uh-oh..."
 ./build.sh || die "Build failed!"
 }
 
 
 
-When using sed with CFLAGS or LDFLAGS, it is not safe to use
-a comma or a slash as a delimiter. The recommended character is a colon.
+When using sed with CFLAGS or LDFLAGS, it is not safe to
+use a comma, a colon or a slash as a delimiter. gcc options may contain
+this characters so sed will fail after bash expansion. The recommended
+character is a vertical bar: '|' (the pipe).
 
 
 
-- 
1.7.3.4

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-misc/linux-logo: linux-logo-5.11.ebuild ChangeLog

[Peter Volkov]

В Птн, 24/06/2011 в 18:22 +0200, Jeroen Roovers пишет:
> On Fri, 24 Jun 2011 10:29:51 +0400
> Peter Volkov  wrote:
> 
> > > src_prepare() {
> > >   echo "./logos/gentoo.logo" >> logo_config
> > >   echo "./logos/gentoo2.logo" >> logo_config
> > >   echo "./logos/banner-simplified.logo" >> logo_config
> > >   echo "./logos/banner.logo" >> logo_config
> > >   echo "./logos/classic-no_periods.logo" >> logo_config
> > >   echo "./logos/classic-no_periods_or_chars.logo" >>
> > > logo_config echo "./logos/classic.logo" >> logo_config
> > 
> > cat >> logo_config <<-EOF will look much better here.
> 
> src_prepare() {
> cat >> logo_config < line0
> line1
> line2
> line3
> EOF
> }
> 
> Since I like indenting, I don't think so. Using FILESDIR is probably
> better, as mgorny suggested.

Note '-' before EOF. With it indenting works fine. See `info bash`:

   If the redirection operator is `<<-', then all leading tab
characters are stripped from input lines and the line containing
DELIMITER.  This allows here-documents within shell scripts to be
indented in a natural fashion.

But ${FILESDIR} works too, although additional file IMO redundant.

--
Peter.

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-misc/linux-logo: linux-logo-5.11.ebuild ChangeLog

[Peter Volkov]

В Птн, 24/06/2011 в 06:20 +, Jeroen Roovers (jer) пишет:
> jer 11/06/24 06:20:28
> 
>   Modified: ChangeLog
>   Added:linux-logo-5.11.ebuild
>   Log:
>   Version bump.

> plain: 
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-misc/linux-logo/linux-logo-5.11.ebuild?rev=1.1&content-type=text/plain
> 
> Index: linux-logo-5.11.ebuild
> ===
> # Copyright 1999-2011 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> # $Header: 
> /var/cvsroot/gentoo-x86/app-misc/linux-logo/linux-logo-5.11.ebuild,v 1.1 
> 2011/06/24 06:20:27 jer Exp $
> 
> EAPI="4"
> 
> inherit eutils toolchain-funcs
> 
> MY_P=${PN/-/_}-${PV}
> S=${WORKDIR}/${MY_P}
> DESCRIPTION="A utility that displays an ANSI/ASCII logo and some system 
> information"
> HOMEPAGE="http://www.deater.net/weave/vmwprod/linux_logo/";
> SRC_URI="http://www.deater.net/weave/vmwprod/linux_logo/${MY_P}.tar.gz";
> 
> LICENSE="GPL-2"
> SLOT="0"
> KEYWORDS="~amd64 ~hppa ~ia64 ~mips ~ppc ~sparc ~x86"
> IUSE="nls"
> 
> RDEPEND="nls? ( virtual/libintl )"
> DEPEND="${RDEPEND}
>   nls? ( sys-devel/gettext )"
> 
> src_prepare() {
>   echo "./logos/gentoo.logo" >> logo_config
>   echo "./logos/gentoo2.logo" >> logo_config
>   echo "./logos/banner-simplified.logo" >> logo_config
>   echo "./logos/banner.logo" >> logo_config
>   echo "./logos/classic-no_periods.logo" >> logo_config
>   echo "./logos/classic-no_periods_or_chars.logo" >> logo_config
>   echo "./logos/classic.logo" >> logo_config

cat >> logo_config <<-EOF will look much better here.

>   cp "${FILESDIR}"/gentoo{,2}.logo "${S}"/logos/

|| die

>   echo "NAME gentoo" >> "${S}"/logos/gentoo.logo
> }
> 
> src_compile() {
>   ARCH="" ./configure --prefix="${D}"/usr || die

Why not src_configure()?
Also use econf or add # some comment here, please.

>   emake CFLAGS="${CFLAGS}" LDFLAGS="${LDFLAGS}" CC="$(tc-getCC)"
> }
> 
> src_install() {
>   emake DESTDIR="${D}" install
> 
>   dodoc BUGS README README.CUSTOM_LOGOS TODO USAGE LINUX_LOGO.FAQ
> 
>   cp "${FILESDIR}"/${PN}.conf "${WORKDIR}"
>   sed -i -e 's/-L 4 -f -u/-f -u/' "${WORKDIR}"/${PN}.conf

|| die

With best regards,
--
Peter.

Re: [gentoo-dev] Packages up for grabs

[Peter Volkov]

В Вск, 12/06/2011 в 15:21 +0200, Michal Januszewski пишет:
> I have a number of packages in which I have lost interest and which I
> no longer want to maintain:

> dev-util/oprofile

Taken.

--
Peter.

Re: [gentoo-dev] Re: RFC: better policy for ChageLogs

[Peter Volkov]

В Срд, 01/06/2011 в 19:37 -0400, Matt Turner пишет:
> On Wed, Jun 1, 2011 at 7:29 PM, Jorge Manuel B. S. Vicetto
>  wrote:
> > To be clear I support the goal to move our tree to git.
> > However, I'd like to point out that simply moving to git will leave us
> > in the same state.

++
ChangeLog files are text to be distributed to our users so they are
completely independent of vcs we use.

> > Assuming everyone agrees that git is far more useful
> > than cvs to check for changes in the tree, a simple but important issue
> > remains: the plan is to move the "development tree" to git, but to keep
> > the rsync mirrors for users. So the "move to git" doesn't fix the issue
> > for users or developers using an rsync tree.
> 
> Temporarily or permanently?
> 
> One of the huge benefits in using git would be really fast emerge
> --syncs. Not having some kind of system for migrating users to git
> seems like a lot of the benefits are lost.

Is git faster then rsync? I've never done any checks but it'll be
surprising if it will. Another useful feature of rsync is --exclude that
allows some categories to be excluded (for size and speed efficiency),
e.g. my servers don't need kde-* and games-*. Also taking into account
that we use portage tree on embedded devices where again both size and
speed really matters it looks like the answer on your question is
"permanently".

--
Peter.

RFC: better policy for ChageLogs (was: Re: [gentoo-dev] Council May Summary: Changes to ChangeLog handling)

[Peter Volkov]

В Пнд, 30/05/2011 в 14:55 -0700, Brian Harring пишет:
> The problem is, that's a *fuzzy* definition. 

Ok, let's start with something and then we'll add more items if
required. Currently I'd like to propose following text:

The ChangeLog must be updated with each commit. The only possible
relaxations for this rule are:

1. Nonfunctional whitespace changes
2. Changes in comments (lines starting with # in ebuild, or leading text
in patches)
3. Manifest updates
4. Changes in ChageLog itself ;)

Something unclear? Anything else?

--
Peter.
diff --git a/ebuild-writing/misc-files/changelog/text.xml b/ebuild-writing/misc-files/changelog/text.xml
index d92bbf4..eea927e 100644
--- a/ebuild-writing/misc-files/changelog/text.xml
+++ b/ebuild-writing/misc-files/changelog/text.xml
@@ -5,10 +5,21 @@
 
 
 
-The ChangeLog must be updated with each commit. The
-echangelog tool should be used to create ChangeLog entries;
-the format of a ChangeLog is now defined as "whatever
-echangelog creates".
+The ChangeLog must be updated with each commit. The only possible
+relaxations for this rule are:
+
+
+
+  1. Nonfunctional whitespace changes
+  2. Changes in comments (lines starting with # in ebuild, or leading text in patches)
+  3. Manifest updates
+  4. Changes in ChageLog itself ;)
+
+
+
+The echangelog tool should be used to create ChangeLog entries; the
+format of a ChangeLog is now defined as "whatever echangelog
+creates".
 
 
 

Re: [gentoo-dev] Council May Summary: Changes to ChangeLog handling

[Peter Volkov]

В Птн, 20/05/2011 в 13:19 +0300, Mart Raudsepp пишет:
> On T, 2011-05-17 at 13:32 +0300, Petteri Räty wrote:
> > http://www.gentoo.org/proj/en/council/meeting-logs/20110510-summary.txt
> > 
> > Please note that you must now update ChangeLog with each commit. For
> > more information please see the meeting log and the preceding mailing
> > list thread:
> > 
> > http://www.gentoo.org/proj/en/council/meeting-logs/20110510.txt
> > http://archives.gentoo.org/gentoo-dev/msg_eaefa325b31360324d0fe53d0b9071e6.xml

So, I just realized that we have to update Changelogs for everything,
whitespaces and comments included. Even after reading meeting logs I
still wonder, why council have decided to vote policy change that was
not supported even by minority of developers? The whole idea after human
editable ChangeLogs was to avoid whitespace changes and changes in
comments. In the current state it is possible to generate them on rsync
servers and avoid this burden.

I would like council to update policy to allow exclude whitespace
changes and changes in comments.

--
Peter.

Re: [gentoo-dev] Should "server" be a global use flag?

[Peter Volkov]

В Пнд, 23/05/2011 в 13:32 -0400, Anthony G. Basile пишет:
> On 05/23/2011 12:37 PM, Michał Górny wrote:
> > On Mon, 23 May 2011 16:48:15 +0200
> > Ulrich Mueller  wrote:
> >> From :
> >> | If the effect of the USE flag upon pkg-one is substantially
> >> | different from the effect it has upon pkg-two, then the flag is not
> >> | a suitable candidate for being made a global flag. In particular,
> >> | note that if client and server USE flags are ever introduced, they
> >> | can not be global USE flags for this reason.

We need to update this. As with USE ssl - it just enables ssl support
with no knowledge in advance how it'll be implemented. Since we are
allowed to have both global and local USE flag descriptions, global USE
flag now better defines overal sense of USE flag while local may adjust
it to make better sense for current package...

> > With that definition, USE=crypt should definitely not be global.
> >
> Yep.  Eg. USE="crypt" for evolution means dependence on app-crypt/gnupg
> and is local while USE="crypt" for thunderbird means dependency on
> x11-plugins/enigmail and is global.  Both are substantially different
> from what USE="crypt" means for util-linux which enables crypto-loop and
> is a global.

It's good idea to open bug and suggest better local USE flag
descriptions.

--
Peter.

Re: [gentoo-dev] Should "server" be a global use flag?

[Peter Volkov]

В Пнд, 23/05/2011 в 17:19 +0200, Jeroen Roovers пишет:
> I find myself wondering why so much information is being jammed into
> USE flag descriptions that /should/ be available in HOWTOs from
> upstream, or else should be written down in HOWTOs we maintain
> ourselves - we (Gentoo) used to be good at providing HOWTOs as needed
> and it's a good tradition to keep up. It helps the entire open source
> community and not just our users, too.

I don't see how moving USE flag descriptions from portage tree in HOWTOs
will help community. This will just take more time to check what USE
flag does. Also it's clear that maintaining another 10 guides will just
slow things down with no real benefit.

> Anyway, count the YESs above. Maybe some people want to
> comment/explain/defend how they wrote their descriptions, so don't
> touch them just yet. :) 

We can add global 'server' USE flag and still keep local USE flag
descriptions where they make global description a bit more clear. And if
I understood your last message correctly, in case you want to update USE
flag descriptions yourself, please, don't touch USE flag descriptions
but open bugs for maintainers to decide.

--
Peter.

Re: [gentoo-dev] arch teams and better tools

[Peter Volkov]

Hi!

В Вск, 22/05/2011 в 10:13 +0200, Thomas Kahle пишет:
> On 18:44 Sat 21 May , "Paweł Hajdan, Jr." wrote:

> > Here's my answer to that, still in very early development:
> > 

> Have you seen app-portage/tatt ? 
> https://github.com/tom111/tatt

It looks that quite similar functionality is required to open
stabilization bugs. It's really takes time to check that there is no
bugs opened in the package and all dependent libraries, then to copy all
maintainers and create list of packages with archs like:

cate-gory/library-ver  amd64 ppc ppc64 x86 
cate-gory/pkg-ver amd64 x86

Have anybody thought/programmed such tool? :)

--
Peter.

Re: [gentoo-dev] rfc: use of the /run directory

[Peter Volkov]

В Втр, 17/05/2011 в 20:43 +0200, Ângelo Arrifano пишет:
> On Tuesday 17 May 2011 20:28:56 Nirbheek Chauhan wrote:
> > I'd add that if we want /run to be on tmpfs, /var/run and /tmp should
> > both be on tmpfs by default. I've been doing this manually for a year,
> > and so have other distributions.
> 
> The lwn article is definitely interesting to read, I welcome the new /run. I 
> wouldn't make /tmp as tmpfs though, there are some packages (wireshask I'm 
> looking at you) that can fill the directory fairly easy.

Hm, may be I miss something... but how wireshark fills /run? As far as I
see dumps go into /tmp.

--
Peter.

Re: [gentoo-dev] rfc: use of the /run directory

[Peter Volkov]

В Втр, 17/05/2011 в 11:57 -0500, William Hubbs пишет:
> I think we should support the /run directory [1] [2].

> I, as well as several others, believe we should proactively create this
> directory ... What does everyone else think?

I've read https://lwn.net/Articles/436012/ and that convinced me. Until
there is better solution, please, do it. Also I think it's good idea if
it'll be on tmpfs, as it should, from the very beginning.

--
Peter.

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/nspr: nspr-4.8.8.ebuild ChangeLog

[Peter Volkov]

В Птн, 13/05/2011 в 21:13 +, Jory Pratt (anarchy) пишет:
> plain: 
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-libs/nspr/ChangeLog?rev=1.161&content-type=text/plain

> src_configure() {
>   cd "${S}"/build
> 
>   echo > "${T}"/test.c
>   $(tc-getCC) -c "${T}"/test.c -o "${T}"/test.o
>   case $(scanelf -BF'%M' "${T}"/test.o)$(scanmacho -BF'%M' "${T}"/test.o) 
> in
>   ELFCLASS64*|POWERPC64*|X86_64*) myconf="${myconf} 
> --enable-64bit";;
>   ELFCLASS32*|POWERPC*|I386*|ARM*) ;;
>   *) die "Failed to detect whether your arch is 64bits or 32bits, 
> disable distcc if you're using it, please";;
>   esac

Why do you need such complex detection? Also in nss ebuild I see
different detection:

> Index: nss-3.12.10.ebuild
[snip]
> src_compile() {
>   strip-flags
> 
>   echo > "${T}"/test.c
>   $(tc-getCC) ${CFLAGS} -c "${T}"/test.c -o "${T}"/test.o
>   case $(file "${T}"/test.o) in
>   *64-bit*|*ppc64*|*x86_64*) export USE_64=1;;
>   *32-bit*|*ppc*|*i386*) ;;
>   *) die "Failed to detect whether your arch is 64bits or 32bits,
disable distcc if you're using it, please";;
>   esac

It looks like good idea to unify them.

--
Peter.

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-libs/libmnl: libmnl-1.0.1.ebuild ChangeLog

[Peter Volkov]

В Вск, 01/05/2011 в 12:25 +, Fabian Groffen (grobian) пишет:
> grobian 11/05/01 12:25:59

>   Fix econf call for Prefix: don't mix Prefix compatible and incompatible code

>  src_configure() {
>   econf \
> - --libdir=/$(get_libdir)
> + --libdir="${EPREFIX}"/$(get_libdir)
>  }

Could you clarify this bit, please? Should we use ED, EPREFIX, ... in
EAPI>=3 or we just ignore it and write ebuilds as always until prefix
team ports them and adds keywords?

-- 
Peter.

Re: [gentoo-dev] Devmanual text on ChangeLogs

[Peter Volkov]

В Вск, 01/05/2011 в 13:44 +0300, Panagiotis Christopoulos пишет:
> On 12:06 Sun 01 May , Samuli Suominen wrote:
> > So not only they are rather useless, and information you can easily
> get
> > from sources.gentoo.org, they take your time as well.
> 
> Then, let's change it to:
> 
> "Though not mandatory, it is highly recommended that file removals are
> also recorded the same way."
>  

Panagiotis, there is no use in ChangeLog if information there is not
reliable. With policy you suggest one will have to check ChangeLog first
and then in half cases go to sources.gentoo.org to find out when ebuild
was removed. Two actions instead of one: either look ChangeLog or go to
web for cvs history.

Also, repoman commit is even slower then echangelog and thus nobody
waits for it to finish: just call it in console and switch to other
deals then just return back to check. If there are very many commits it
possible to script them. The only thing Samuli needs to do is to use
ecommit() hook:

ecommit() {
echangelog "$@"
repoman commit -m "$@"
}

But Samuli knows this very well and Fabian's answer describes situation
best.

-- 
Peter.

Re: [gentoo-dev] Devmanual text on ChangeLogs

[Peter Volkov]

В Сбт, 30/04/2011 в 12:02 +0300, Samuli Suominen пишет:
> On 04/30/2011 11:46 AM, Petteri Räty wrote:
> > I propose a simple new text: "Every commit should have an entry in
> > ChangeLog."

Nonfunctional commits should not be recored in ChangeLog. Personally I
quite frequently add URLs of upstream bug reports in ChangeLog. I don't
think this addition should be recorded in ChangeLog.

> > If we eventually autogenerate them from git logs this would
> > happen any way (unless some kind of filtering system is in the middle)
> > so we could already start now.

Without filtering system ChangeLogs are useless. Also I need some way to
edit ChangeLogs manually.

> "Every new file, and modification to existing file should have an entry
> in ChangeLog." to skip the proper ChangeLog-less removals.

Removal is quite functional change so it should be recored.

-- 
Peter.

Re: [gentoo-dev] Bugzilla - New Default Status Workflow

[Peter Volkov]

В Чтв, 28/04/2011 в 18:06 +0300, Panagiotis Christopoulos пишет:
> On 16:07 Thu 28 Apr, Christian Ruppert wrote:
> > So once again:
> > 
> > https://bugs.gentoo.org/docs/en/html/lifecycle.html

I'm all for new lifecycle.

> > CLOSED gone. VERIFIED will be added.
> What is the meaning of VERIFIED? (I also never understood the meaning of
> the old CLOSED). 

The user who had bug checked (verified) that it does not exists any
more.

-- 
Peter.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/transmission: transmission-2.12.ebuild

[Peter Volkov]

В Сбт, 30/04/2011 в 07:39 +0300, Samuli Suominen пишет:
> On 04/30/2011 07:10 AM, Jeremy Olexa wrote:

> sources.gentoo.org is for that.

It's not convenient to use browser to read ChangeLog.

> So no, I won't start cluttering up ChangeLogs and I would prefer if
> others would stop it as well

I'm the user and this information is useful for me. Please, stop
thinking for me and start adding ChangeLog entries.

If you think this clutters ChangeLog it's possible to make format more
terse, but please, document all changes (but typos and comments).

-- 
Peter.

Re: [gentoo-dev] rfc: openrc use flag

[Peter Volkov]

В Чтв, 21/04/2011 в 14:30 -0500, William Hubbs пишет:
> On Wed, Apr 20, 2011 at 08:20:32PM +0200, Pacho Ramos wrote:
> > 1. Would need to rebuild some packages when switching between init
> > systems.
> 
> I don't think you can get away from this, no matter how you approach
> it. The other approach I thought of is to include the udev pieces
> directly in openrc and make it possible to build openrc with or without
> udev integration. That will still mean you have to rebuild openrc though
> if you want udev support.

Do we allow installation of two init systems side by side? If yes, then
eselect module can be used to change services that will be stated by
udev.

-- 
Peter.

Re: [gentoo-dev] rfc: openrc use flag

[Peter Volkov]

В Срд, 20/04/2011 в 12:24 -0500, William Hubbs пишет:
> The author of the bug feels that the way to fix this is for us to put a
> check in openrc that makes it refuse to run services if it was not used
> in the boot process.

This is good idea to have in any case since I remember my system went
crazy after I've tried to start some service inside chroot.

> This may work; however, I do not feel that it addresses the root cause
> of the bug. I feel that the root cause is packages unconditionally
> installing udev rules which assume everyone uses openrc.

I'd voted to have both implemented.

-- 
Peter.

Re: [gentoo-dev] Lastrite: gst-plugins-v4l and xfce4-icon-theme

[Peter Volkov]

В Чтв, 31/03/2011 в 11:18 +0300, Samuli Suominen пишет:
> # Samuli Suominen  (31 Mar 2011)
> # Deprecated and doesn't build since linux-headers-2.6.38. Use
> gst-plugins-v4l2
> # instead. Masked for removal in 30 days. See bug 359647.
> media-plugins/gst-plugins-v4l

Samuli when you add patches, please, do runtime tests or assign bugs on
maintainers. Build time test during addition of patches for psimedia to
fix this dependencies on media-plugins/gst-plugins-v4l (even although it
was taken from fedora distribution and I hope like it worked for them)
just started to crash psi application. Really such changes should not
break stable tree.

-- 
Peter.

Re: [gentoo-dev] rejecting unsigned commits

[Peter Volkov]

В Чтв, 24/03/2011 в 17:59 -0400, Mike Frysinger пишет:
> is there any reason we should allow people to commit unsigned
> Manifest's anymore ? 

Why? Without policy on how we do that and more importantly how we check
that signing makes no sense...

-- 
Peter.

Re: [gentoo-dev] Re: Re: RFC: Making largefile a global use

[Peter Volkov]

В Чтв, 10/03/2011 в 11:49 +0100, Diego Elio Pettenò пишет:
> Any configure with AC_SYS_LARGEFILE will get a
> --enable-largefile option, but if you grep through the tree, this is
> usually simply added unconditionally.

Is there any value adding --enable-largefile? autoconf macros have it
enabled by default.

-- 
Peter.

Re: [gentoo-dev] EAPI usage in main tree

[Peter Volkov]

В Втр, 25/01/2011 в 14:33 +0100, Thomas Sachau пишет:
> Do you have some more arguments for your request? Most new developers
> will have to know about all EAPi versions anyway since they join an
> existing team with existing ebuilds, which will mostly not use the
> newest EAPI.
> 
> As an argument againt this: Noone forces you to keep older EAPI
> versions of the ebuilds you maintain, you can always bump them to the
> latest EAPI. But why do you want to force this on all developers? 

I think your first paragraph is actually the argument to use latest EAPI
whenever possible. Such policy provides us with the path to avoid
situation you described while insisting on keeping old EAPI's obviously
will force new developer to learn ancient knowledge. IOW, such policy
provides path to simplify work in team.

-- 
Peter.

Re: [gentoo-dev] Last rites: net-analyzer/ipcad

[Peter Volkov]

В Срд, 19/01/2011 в 11:58 -0500, Dane Smith пишет:
> # Packages below fail to build with
> # >=sys-kernel/linux-headers-2.6.35 and block its
> # stabilization. Bugs untouched in over 3 months.
> # Masking for removal on 21 Mar 2011.
> # net-analyzer/ipcad (bug 335592)

This one is fixed and will stay in the tree. Thanks.

-- 
Peter.

Re: [gentoo-dev] On hosting self-produced distfiles

[Peter Volkov]

В Чтв, 20/01/2011 в 03:50 +0100, Diego Elio Pettenò пишет:
> Do you really think I should have "discussed" with "a team" about this?
> More than asking Robin as part of infra if it's okay (with his answer
> being "yeah, that's fine | i do it too", literally)?

This was already mentioned in this thread, but still. AFAIR (betelgeuse
knows better) average developer's age is less then three years and thus,
many files hosted in home directory became unavailable after developer
retires. Thus the solution you propose does not address the problem we
have and it's not a nice to enforce it in the policy (without some
additional policy to keep developer's home directory on server for three
years and anyway this needs discussion with infra first).

-- 
Peter.

Re: [gentoo-dev] IPv6 herd

[Peter Volkov]

Hi!

В Втр, 21/12/2010 в 18:45 +, Markos Chandras пишет:
> As someone may notices on this bug[1], the package is 
> maintained by the ipv6 herd. However, there is no such 
> herd listed on herd webpage[2]. 
> Furthermore, there is just one developer in this herd(?). 
> Maybe we should merge this "ghost" herd to netmon or
> something and reassign all the packages as well?

Actually it looks like net-misc/ipv6calc is the only package, thus I've
reassigned it on myself and I'm going to request ipv6 alias removal.
CC'ing them. Guys if you alive, please, respond to gentoo-dev.

> [1]:http://bugs.gentoo.org/show_bug.cgi?id=349264
> [2]:http://www.gentoo.org/proj/en/metastructure/herds/herds.xml

-- 
Peter.

Re: [gentoo-dev] Last rites: app-emulation/ies4linux

[Peter Volkov]

В Сбт, 04/12/2010 в 11:42 +, Markos Chandras пишет:
> # Markos Chandras  (04 Dec 2010)
> #  on behalf of QA team
> #
> # ies4linux does not work with recent versions of wine.
> # Last update back in 2008. Bug #344233
> # Masked for removal in 2011-01-04
> app-emulation/ies4linux

In case you wonder what to do now, it's possible to download and use
winetricks script: http://wiki.winehq.org/winetricks

-- 
Peter.

Re: [gentoo-dev] Re: Re: Maintainer notes in metadata.xml?

[Peter Volkov]

В Птн, 03/12/2010 в 13:12 +0100, Diego Elio Pettenò пишет:
> Il giorno ven, 03/12/2010 alle 14.50 +0300, Peter Volkov ha scritto:
> > Same logic applies for metadata.xml. Personally doing AT work I always
> > review ebuild. At the same time I never opened metadata.xml, so I
> > don't see your point. 
> 
> Have you read my post? I said to make _repoman_ spew the content during
> scan/full calls.

Sorry I wasn't clear enough. I think repoman full/scan is a tool for
maintainer. Doing AT work I run them just before commit - too late for
test instructions. It's possible to change workflow but since I never
experienced repoman warnings that may stop stabilization I don't see any
reasons to wait while repoman scan/full finishes (too long!) just to see
test instructions.

That said I think that it's good idea to have some better place for
maintainer notes and may be metadata.xml is the right place. If you are
going to add tags, please, make sure they'll behave like  to keep
formatting. Also besides test instructions we need some place (another
tag) to keep notes _for_ maintainer. And finally I think we need two new
repoman commands to see instructions, to avoid long delay before repoman
shows anything.

-- 
Peter.

Re: [gentoo-dev] Re: Maintainer notes in metadata.xml?

[Peter Volkov]

В Срд, 01/12/2010 в 17:35 +0100, Diego Elio Pettenò пишет:
> Il giorno mer, 01/12/2010 alle 17.02 +0300, Peter Volkov ha scritto:
> > Comments inside are better suited for this task - you see/update notes
> > as you edit ebuild.
> > 
> How many ATs/arch maintainers will look _within_ the ebuild when testing
> an ebuild for stable?

Same logic applies for metadata.xml. Personally doing AT work I always
review ebuild. At the same time I never opened metadata.xml, so I don't
see your point.

-- 
Peter.

Re: [gentoo-dev] Maintainer notes in metadata.xml?

[Peter Volkov]

В Срд, 01/12/2010 в 02:00 +0100, Diego Elio Pettenò пишет:
> I was wondering if we have space already, or if others would feel
> strongly about making space for, maintainer notes in packages'
> metadata.xml.

Comments inside are better suited for this task - you see/update notes
as you edit ebuild.

-- 
Peter.

Re: [gentoo-dev] Re: GCC 4.5 unmasking tomorrow

[Peter Volkov]

В Вск, 21/11/2010 в 01:47 -0600, Ryan Hill пишет:
> On Sun, 21 Nov 2010 17:35:18 +1300
> Alistair Bush  wrote:
> 
> > > > We don't do revbumps on masked toolchain packages.
> > > 
> > > Why not?
> > 
> > Yeah why not?  do you inform users of this?
> 
> Users unmasking toolchain packages need to be paying close attention to
> what's going on behind the scenes.  They're in the tree for people who
> know what they're doing to test.  Even unmasked, toolchain revbumps are
> expensive and we do them only when absolutely necessary.

I don't see any reasons not to revbump package even if it was
hardmasked...

-- 
Peter.

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Peter Volkov]

eiВ Втр, 16/11/2010 в 07:53 +0100, Hans de Graaff пишет:
> On Tue, 2010-11-16 at 06:40 +0000, Peter Volkov (pva) wrote:
> >  
> > +# Peter Volkov  (16 Nov 2010)
> > +# Last rites: dev-python/py-rrdtool #345701
> > +# Old python bindins that currently are included into net-analyzer/rrdtool
> > +# Removal on 16 Dec 2010
> > +dev-python/py-rrdtool
> 
> I have a similar todo item on my list for the standalone ruby bindings,
> but I have not masked them yet because rrdtool 1.0.50 doesn't include
> them and is still in the tree. I'm not sure when the python bindings got
> incorporated into rrdtool, but I'm guessing it might be similar.

> Any plans to remove rrdtool-1.0.50 from the tree? Or should I just go
> ahead and remove the ruby bindings anyway?

rrdtool-1.0 is used by SFlowtool and last time I've tried it worked so I
don't see any reason to drop rrdtool-1.0.50 from the tree. As for
bindings, py-rrdtool have known problems and thus I've decided to drop
it. Probably it's good idea to do the same for ruby bindings as rrdtool
ChangeLog suggests that some problems were fixed there too.

If users need bindings they better use recent rrdtool and bundled
bindings, rrdtool-1.0.x for sflowtool only.

-- 
Peter.

Re: [gentoo-dev] News item for restructuring of hardened profiles.

[Peter Volkov]

В Втр, 09/11/2010 в 18:20 -0500, Anthony G. Basile пишет:
> Title: Restructuring of Hardened profiles
[...]
> Display-If-Profile: hardened/linux

Is it possible to restrict this news item to be shown on affected
profiles only?

-- 
Peter.

Re: [gentoo-dev] Changes in server profiles

[Peter Volkov]

В Вск, 31/10/2010 в 16:38 +0200, Alex Alexander пишет:
> On Sun, Oct 31, 2010 at 11:50:02AM +, Markos Chandras wrote:
> > On Sat, Oct 30, 2010 at 10:59:08PM -0400, Richard Freeman wrote:
> > > Isn't this essentially what the default profile is?  Basically server is
> > > just default + USE="apache2 ldap mysql snmp truetype xml".
> > Well it shouldn't be like that. And if the default profile is pretty
> > much the same as the server one, then please consider removing the
> > server profile as it makes no sense then
> 
> Please don't. The fact that there are only a few changes doesn't make it
> useless. Also, you'd be forcing all users currently using the profile to
> migrate without any real reason.

But what is the target group of this profile? It sets only 6 USE flags
that are really useless on half of servers (e.g. VPN/mail server). I'd
better set only -perl -python there to make servers less dependent on
python/perl updaters and decrease rebuilds for servers. Also it's good
idea to make them hardened only as hardened works very well for
servers. 

-- 
Peter.

Re: [gentoo-dev] Changes in server profiles

[Peter Volkov]

В Птн, 29/10/2010 в 09:11 -0700, Alec Warner пишет:
> On Fri, Oct 29, 2010 at 5:21 AM, Markos Chandras  wrote:
> Can I install a machine with the server profile and USE=-ldap, but
> still get ldap + pam working?
> Can I install a machine with the server profile and USE=-apache, but
> still get apache + php working?  apache + rails?
> How many packages support each USE flag?
> How many of those packages have IUSE defaults for +ldap or +apache already?

Having lxc/openvz/vserver technologies at hand it's not rare to split
LAMP server into a number of virtual servers (containers): mysql /
backend with php / frontend / smtp - everything sits in its own
container. And USE=apache will be used only in _one_ container. Also not
all servers are web servers. So IMO server profile should be just
minimal profile that hints users that this profile will stay minimal and
usable for all kinds of servers. That said I think server profile is
useless and for servers I maintain my own profiles.

-- 
Peter.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/tcpreplay: ChangeLog tcpreplay-3.4.5_beta2.ebuild

[Peter Volkov]

В Птн, 29/10/2010 в 17:51 +0200, Diego Elio Pettenò пишет:
> Il giorno ven, 29/10/2010 alle 12.12 +0400, Peter Volkov ha scritto:
> > 
> > Please, hard mask beta versions. To fix this bug it's not hard to
> > backport patch (patch referenced in bug) and this will give us good
> > version to stabilize. Really don't abuse beta versions.
> > 
> It vastly depends how "beta" the beta version is, so it's up to the
> maintainer deciding that.

Yup. But then, please, tell what were the reasons for this decision (in
ChangeLog or inside ebuild). If there are no reasons - hard mask it.

Also speaking about this specific package: I've maintained this package
quite long time and I'm following upstream mailing list and I've never
heard from upstream it's safe to push betas on all users.

-- 
Peter.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/tcpreplay: ChangeLog tcpreplay-3.4.5_beta2.ebuild

[Peter Volkov]

В Птн, 29/10/2010 в 19:29 +0200, Michał Górny пишет:
> On Fri, 29 Oct 2010 12:12:38 +0400
> Peter Volkov  wrote:

> > Please, hard mask beta versions.
> 
> I personally don't see a reason why he needed to do that.
> If a particular package was a popular one and/or the beta version
> changed a lot which might imply a lot of users getting trouble due to
> it, then I would agree.

If the package is not popular there is even more reasons to rely on the
upstream's judgment and hard mask betas.

> Please notice that 'beta' is not the same for each upstream. There are
> indeed packages which are in 'beta' state for the time being -- would
> you like all of them to be hard masked? 

Until you have explicit "go for it" from upstream or there is no real
pressure to use betas, please, hard mask them.

> Or maybe you're fine with them because they don't put 'beta' in their PV?

I'm fine in case upstream released package for general usage and we use
them. I'm not fine in case package name suggests that package is for
testing but we push it on users. Beta is beta.

And for the sake of discussion I already had not so nice talks with
upstream about Gentoo and beta versions we push on users... So this
request is not out of the air.

-- 
Peter.

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/tcpreplay: ChangeLog tcpreplay-3.4.5_beta2.ebuild

[Peter Volkov]

В Птн, 29/10/2010 в 06:03 +, Jeroen Roovers (jer) пишет:
> jer 10/10/29 06:03:08
> 
>   Modified: ChangeLog
>   Added:tcpreplay-3.4.5_beta2.ebuild
>   Log:
>   Beta version bump, fixes buffer overflow (bug #336605).

Please, hard mask beta versions. To fix this bug it's not hard to
backport patch (patch referenced in bug) and this will give us good
version to stabilize. Really don't abuse beta versions.

-- 
Peter.

Re: [gentoo-dev] New eshowkw

[Peter Volkov]

В Втр, 26/10/2010 в 17:39 +0200, Tomáš Chvátal пишет:

> If the script lack some feature you really want to use also let me know,
> maybe it wont be too hard to implement.

Nice! What I always missed is an ability to print stable archs in format
ready to use in bugzilla's CC field, IOW output string like:

am...@gentoo.org,x...@gentoo.org

where amd64,x86 are archs where package has stable keywords :)

-- 
Peter.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-cdr/cdemu: metadata.xml ChangeLog cdemu-1.3.0.ebuild

[Peter Volkov]

В Пнд, 25/10/2010 в 09:07 -0500, Donnie Berkholz пишет:
> On 14:24 Sun 24 Oct , William Hubbs wrote:
> > I don't like no* use flags either, for the same reason that was given
> > above.  -no* is a double negative and it should be avoided.
> 
> Agreed. The argument that it's removing a feature is an implementation 
> detail that users don't and shouldn't have to care about at all.

Ok, renamed :)

-- 
Peter.

Re: [gentoo-dev] Support for Python 3

[Peter Volkov]

В Пнд, 25/10/2010 в 15:37 +0200, Arfrever Frehtes Taifersar Arahesis
пишет:
> I would like to suggest that setting Python 3.1 as main active version of 
> Python be officially
> supported and recommended for Gentoo developers since 2010-12-01. Majority of 
> packages supporting
> only Python 2.* have been prepared to work correctly in situation when Python 
> 3.* is set as main
> active version of Python.

How many packages left?

-- 
Peter.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-cdr/cdemu: metadata.xml ChangeLog cdemu-1.3.0.ebuild

[Peter Volkov]

В Чтв, 21/10/2010 в 09:08 +0300, Eray Aslan пишет:
> On 21.10.2010 07:57, Peter Volkov wrote:
> > Why unwanted? I remember there was never consensus... 
> 
> Well, in that case there is a discrepency with the devmanual:
> http://devmanual.gentoo.org/general-concepts/use-flags/index.html#noblah-use-flags

Nothing there applies here, since this USE flag has nothing to do with
archs/profiles...

-- 
Peter.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-cdr/cdemu: metadata.xml ChangeLog cdemu-1.3.0.ebuild

[Peter Volkov]

В Втр, 19/10/2010 в 17:39 +0200, Christian Faulhammer пишет:
> "Peter Volkov (pva)" :
> > pva 10/10/19 14:35:39
> > 
> >   Modified: metadata.xml ChangeLog
> >   Added:cdemu-1.3.0.ebuild
> >   Log:
> >   Version bump. Added nocdemud USE flag to avoid cdemud dependency
> > #315491 wrt Michał Górny. 
> >   (Portage version: 2.1.9.18/cvs/Linux x86_64)
> 
>  Is there a reason you don't use EAPI=1 syntax for default USE flags,
> instead of the unwanted no* USE flags?

Why unwanted? I remember there was never consensus... 

In general USE flags enable/disable feature. Here "feature" is
_disabling_ cdemud and thus USE=nocdemud better expresses what intended.

-- 
Peter.

Re: [gentoo-dev] Revbumped php-ext-* eclasses

[Peter Volkov]

Hi!

В Вск, 03/10/2010 в 13:41 +0200, Ole Markus With пишет: 
> for slot in `php_get_slots`; do

It's better use $() instead of backticks:
http://mywiki.wooledge.org/BashFAQ/082

> [[ -z "${PHP_EXT_ZENDEXT}" ]] && PHP_EXT_ZENDEXT="no"
> 
...
> [[ -z "$USE_PHP" ]] && USE_PHP="php5-2 php5-3"

In some places eclass uses ${var} syntax but here and later it uses
$var. I'm not sure which syntax is better but in Gentoo we use ${var}
and for readability it's better to stick to single style.

> php_get_slots() {
> local s
> local slot

single $(local s slot) is enough here.

> php_init_slot_env() {
...
> S="${WORKDIR}/$1"
> cd $S

S is unquoted, and ${}

> php-ext-source-r2_buildinilist() {
...
> for x in ${PHPSAPILIST} ; do

local x?

-- 
Peter.

Re: [gentoo-dev] Re: .la files removal news item (GLEP 42)

[Peter Volkov]

В Сбт, 02/10/2010 в 10:43 -0700, Zac Medico пишет:
> On 10/02/2010 05:21 AM, Peter Volkov wrote:
> > Is it possible for portage-2.1.8.x to depend on lafilefixer and add run
> > lafilefixer (if installed) from base profile bashrc?

> We can do a portage-2.1.8.4 version bump with support for running
> lafilefixer, but this is a questionable move given that this version
> bump will be eligible for stabilization at about the same time as
> portage-2.1.9.13.

This looks like the good case for fast stabilization so I'd better went
this way. Any objections?

-- 
Peter.

Re: [gentoo-dev] Help on f-spot-0.8 problem

[Peter Volkov]

Hi, Pacho.

В Птн, 01/10/2010 в 20:14 +0200, Pacho Ramos пишет:
> Since Calchan doesn't have much time for f-spot and dotnet team is 
> conformed basically by me, I would welcome any help for trying to
> bump f-spot to its 0.8 version. The problem is that eautoreconf doesn't
> run, even running "autoreconf" on unpacked upstream sources fails with
> the following error:
> $ autoreconf
> /usr/share/aclocal/sigc++.m4:8: warning: underquoted definition of
> AM_PATH_SIGC
> /usr/share/aclocal/sigc++.m4:8:   run info '(automake)Extending aclocal'
> /usr/share/aclocal/sigc++.m4:8:   or see
> http://sources.redhat.com/automake/automake.html#Extending-aclocal
> help/Makefile.am:1: HAVE_GNOME_DOC_UTILS does not appear in
> AM_CONDITIONAL

$ cd f-spot-0.8.0
$ grep -r HAVE_GNOME_DOC_UTILS . | grep m4

will help you to see that this conditional is defined
in  ./build/m4/shamrock/gnome-doc.m4.

> build/build.rules.mk:37: ENABLE_ATK does not appear in AM_CONDITIONAL

this on is defined in ./build/m4/f-spot/gtk-sharp.m4. This problem can
be fixed with correct include pathes:

autoreconf -f -I build/m4/shamrock/ -I build/m4/f-spot/

thus I think

AT_M4DIR="-I build/m4/shamrock/ -I build/m4/f-spot/" eautoreconf

should work.

> I have already installed app-text/gnome-doc-utils-0.20.1, I have also 
> verified /usr/share/gnome-doc-utils/gnome-doc-utils.make is the same as
> f-spot provided one, and that sources doesn't seem to be shipping any 
> gnome-doc-utils.m4 file
> 
> Thanks a lot for your help and ideas :-)

Thank you for taking care about this package! I really appreciate f-spot
version bump :)

-- 
Peter.

Re: [gentoo-dev] Re: .la files removal news item (GLEP 42)

[Peter Volkov]

В Птн, 01/10/2010 в 20:02 +0200, Diego Elio Pettenò пишет:
> I, sincerely, have poured enough effort in trying to solve the issue,
> discussing it, documenting it, showing how to deal with new packages,
> showing how to identify pointless .la files that only increase the
> number of them installed and cause false positives… and I'm still told
> that a) I haven't done _enough_, as I had to prepare a master plan of
> it and b) I'm too negative about stuff. 

Diego, I guess that you were "told that..." is due to the way you've
tried to reach developer's community. Actually I failed to find any
mails on '.la files removal' subject in gentoo-dev-announce or
gentoo-dev mailing lists. Now I assume that by efforts you mean blog
posts and bug reports. Both of this medias are targeted on small
subgroup of Gentoo developers: blogs contain only personal opinion and
no Gentoo developer supposed to read blogs (btw, I'm not reading all
blog entries); bug reports are really better but again only small
fraction of developers is informed (only 10 bugs is currently opened).
Yea, there were some discussions on -dev mailing list: first discussion
I found was "Removing .la files..." where we discussed _problems_ such
removal may cause with no clear resolution. After that 'la file'
substring matches thread about libpng (again problems) and some even
shorter threads. So every developer knew that we should remove .la files
but also we knew that inconsistent removal (like currently happened
again) causes problems for users and nobody ever announced any
distro-wide guidelines. It is obvious that to avoid useless rebuild we
should have been started from most popular leaf packages like
gnome/xfce/X11 and only then move on dependent libraries but nobody
told: please, start now from here and here. Currently it'll be great if
you could point on relevant information so we could continue to
remove .la files without mess (e.g. altering stable packages). But looks
like before such plan could be announced we really need to discuss how
we handle stable packages (heh, again). So I'll end with bottom line:
please, post really important distribution wide things to appropriate
media (gentoo-dev-announce mailing list)!

-- 
Peter.

Re: [gentoo-dev] Re: .la files removal news item (GLEP 42)

[Peter Volkov]

В Птн, 01/10/2010 в 12:38 -0700, Zac Medico пишет:
> Maybe advise them to use post_pkg_preinst instead of post_src_install,
> so it works even for binary packages.

Is it possible for portage-2.1.8.x to depend on lafilefixer and add run
lafilefixer (if installed) from base profile bashrc?

-- 
Peter.

Re: [gentoo-dev] .la files removal news item (GLEP 42)

[Peter Volkov]

В Птн, 01/10/2010 в 12:27 +0200, Tomáš Chvátal пишет:
> this can be done either by using the
> (currently testing) Portage 2.1.9 series, or by adding the following
> snippet to your /etc/portage/bashrc:
> 
> post_src_install() {
> lafilefixer "${D}"
> }

It's better to avoid suggesting this as such things tend to stay for a
very long time on user's systems and since this'll became redundant once
portage 2.1.9 will go stable soon it'll la files will be "fixed" twice
for no reason.

-- 
Peter.

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-libs/libproxy: ChangeLog libproxy-0.4.6.ebuild

[Peter Volkov]

В Срд, 29/09/2010 в 20:43 +, Pacho Ramos (pacho) пишет:
> pkg_setup() {
>   if use python; then
>   python_set_active_version 2
>   fi

It's much shorter and clearer to write

use python && python_set_active_version 2

-- 
Peter.

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/openvpn: ChangeLog openvpn-2.1.3.ebuild

[Peter Volkov]

В Пнд, 27/09/2010 в 11:37 +, Dirkjan Ochtman (djc) пишет:
> src_prepare() {
>   epatch "${FILESDIR}/${PN}-2.1_rc13-peercred.patch"
>   epatch "${FILESDIR}/${PN}-2.1_rc20-pkcs11.patch"
>   use ipv6 && epatch "${WORKDIR}/${PN}-2.1.1-ipv6-${IPV6_VERSION}.patch"
>   use eurephia && epatch "${DISTDIR}/${PN}-2.1.0_eurephia.patch"
>   sed -i \
>   -e "s/gcc \${CC_FLAGS}/\${CC} \${CFLAGS} -Wall/" \
>   -e "s/-shared/-shared \${LDFLAGS}/" \
>   plugin/*/Makefile || die "sed failed"
>   eautoreconf

Is autoreconf really necessary here? Looks like it is redundant in case
ipv6 or eurephia are disabled.

> src_configure() {

>   econf ${myconf} \
>   $(use_enable passwordsave password-save) \
>   $(use_enable ssl) \
>   $(use_enable ssl crypto) \
>   $(use_enable iproute2) \
>   || die "configure failed"

|| die is redundant here.


> src_compile() {
>   use static && sed -i -e '/^LIBS/s/LIBS = /LIBS = -static /' Makefile
> 
>   emake || die "make failed"
> 
>   if ! use minimal ; then
>   cd plugin
>   for i in $( ls 2>/dev/null ); do

This is bad construction:
http://mywiki.wooledge.org/BashPitfalls#for_i_in_.24.28ls_.2A.mp3.29

>   [[ ${i} == "README" || ${i} == "examples" || ${i} == 
> "defer" ]] && continue
>   [[ ${i} == "auth-pam" ]] && ! use pam && continue
>   einfo "Building ${i} plugin"
>   cd "${i}"
>   emake CC=$(tc-getCC) || die "make failed"
>   cd ..

I think pushd/popd are better suited for this then cd "${dir}" / cd ..

>   done
>   cd ..
>   fi
> }

>   # remove empty dir
>   rmdir "${D}/usr/share/doc/openvpn"

|| die is prudent here.

>   # Empty dir
>   dodir /etc/openvpn
>   keepdir /etc/openvpn

dodir is redundant: keepdir will create directory.

>   # Install some helper scripts
>   exeinto /etc/openvpn
>   doexe "${FILESDIR}/up.sh"
>   doexe "${FILESDIR}/down.sh"

|| die after doexe is really good idea.

>   # Install the init script and config file
>   newinitd "${FILESDIR}/${PN}-2.1.init" openvpn
>   newconfd "${FILESDIR}/${PN}-2.1.conf" openvpn

|| die absent

>   # install examples, controlled by the respective useflag
>   if use examples ; then
>   # dodoc does not supportly support directory traversal, #15193
>   insinto /usr/share/doc/${PF}/examples
>   doins -r sample-{config-files,keys,scripts} contrib
>   prepalldocs
>   fi

>   # Install plugins and easy-rsa
>   if ! use minimal ; then
>   cd easy-rsa/2.0
>   make install "DESTDIR=${D}/usr/share/${PN}/easy-rsa"
>   cd ../..
> 
>   exeinto "/usr/$(get_libdir)/${PN}"
>   doexe plugin/*/*.so
>   fi
> }
> 
> pkg_postinst() {
>   # Add openvpn user so openvpn servers can drop privs
>   # Clients should run as root so they can change ip addresses,
>   # dns information and other such things.
>   enewgroup openvpn
>   enewuser openvpn "" "" "" openvpn
> 
>   if [[ -n $(ls /etc/openvpn/*/local.conf 2>/dev/null) ]] ; then

I'd suggested [ -e /etc/openvpn/*/local.conf ] here, but probably there
are better alternatives. Also ${ROOT} is missed here.

>   ewarn "WARNING: The openvpn init script has changed"
>   ewarn ""
>   fi
> 
>   einfo "The openvpn init script expects to find the configuration file"
>   einfo "openvpn.conf in /etc/openvpn along with any extra files it may 
> need."

This information is for users, so, please, use elog here.

>   einfo ""
>   einfo "To create more VPNs, simply create a new .conf file for it and"
>   einfo "then create a symlink to the openvpn init script from a link 
> called"
>   einfo "openvpn.newconfname - like so"
>   einfo "   cd /etc/openvpn"
>   einfo "   ${EDITOR##*/} foo.conf"
>   einfo "   cd /etc/init.d"
>   einfo "   ln -s openvpn openvpn.foo"
>   einfo ""
>   einfo "You can then treat openvpn.foo as any other service, so you can"
>   einfo "stop one vpn and start another if you need to."
> 
>   if grep -Eq "^[ \t]*(up|down)[ \t].*" "${ROOT}/etc/openvpn"/*.conf 
> 2>/dev/null ; then
>   ewarn ""
>   ewarn "WARNING: If you use the remote keyword then you are 
> deemed to be"
>   ewarn "a client by our init script and as such we force up,down 
> scripts."
>   ewarn "These scripts call /etc/openvpn/\$SVCNAME-{up,down}.sh 
> where you"
>   ewarn "can move your scripts to."
>   fi
> 
>   if ! use minimal ; then
>   einfo ""
>   einfo "plugins have been installed into 
> /usr/$(get_libdir)/${PN}"
>   fi
> 
>   if use i

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/sympy/files: sympy-0.6.7-python-2.7.patch

[Peter Volkov]

В Птн, 01/10/2010 в 12:01 +0200, Diego Elio Pettenò пишет:
> Il giorno ven, 01/10/2010 alle 12.30 +0400, Peter Volkov ha scritto:
> > 
> > This patch fixes not test failure, but sympy's ability to work with
> > python-2.7. Although python-2.7 is currently masked it will be
> > unmasked
> > soon and some users may have it installed already. Looks like revision
> > bump to propagate this change in package on users is necessary in this
> > case. Please, bump revision. 
> 
> You still need to run python-updated (oh joy) so it probably isn't
> strictly required.

I was talking about case where python-2.7 it is already installed
(although it is hard masked it is already in the tree). In such case
python-updater will not be run.

-- 
Peter.

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/sympy/files: sympy-0.6.7-python-2.7.patch

[Peter Volkov]

В Птн, 24/09/2010 в 20:09 +, Arfrever Frehtes Taifersar Arahesis
(arfrever) пишет:
>   Added:sympy-0.6.7-python-2.7.patch
>   Log:
>   Fix majority of test failures with Python 2.7 (bug #330713).

This patch fixes not test failure, but sympy's ability to work with
python-2.7. Although python-2.7 is currently masked it will be unmasked
soon and some users may have it installed already. Looks like revision
bump to propagate this change in package on users is necessary in this
case. Please, bump revision.

> Revision  ChangesPath
> 1.1  dev-python/sympy/files/sympy-0.6.7-python-2.7.patch
> 
> file : 
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-python/sympy/files/sympy-0.6.7-python-2.7.patch?rev=1.1&view=markup
> plain: 
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-python/sympy/files/sympy-0.6.7-python-2.7.patch?rev=1.1&content-type=text/plain
> 
> Index: sympy-0.6.7-python-2.7.patch
> ===
> http://github.com/sympy/sympy/commit/717516b8ffae806cdfdea8141ceb839107d92431
> 
> --- sympy/printing/pretty/stringpict.py
> +++ sympy/printing/pretty/stringpict.py
> @@ -81,7 +81,7 @@
>  return '\n'.join(result), newBaseline
>  
>  def right(self, *args):
> -"""Put pictures next to this one.
> +r"""Put pictures next to this one.
>  Returns string, baseline arguments for stringPict.
>  (Multiline) strings are allowed, and are given a baseline of 0.
>  >>> from sympy.printing.pretty.stringpict import stringPict
> --- sympy/utilities/runtests.py
> +++ sympy/utilities/runtests.py
> @@ -778,7 +778,7 @@
>  def start(self):
>  self.write_center("test process starts")
>  executable = sys.executable
> -v = sys.version_info
> +v = tuple(sys.version_info)
>  python_version = "%s.%s.%s-%s-%s" % v
>  self.write("executable:   %s  (%s)\n\n" % (executable, 
> python_version))
>  self._t_start = clock()

-- 
Peter.

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-admin/supervisor: ChangeLog supervisor-3.0_alpha9.ebuild

[Peter Volkov]

В Чтв, 23/09/2010 в 20:18 +, Arfrever Frehtes Taifersar Arahesis
(arfrever) пишет:
> src_install() {
>   distutils_src_install
>   newinitd "${FILESDIR}/init.d" supervisord
>   newconfd "${FILESDIR}/conf.d" supervisord

|| die is necessary after newinitd/newconfd. This will prevent broken
package to be installed in case $FILESDIR/{init.d,conf.d} miss in users
portage tree.

-- 
Peter.

Re: [gentoo-dev] RFC: Repoman to autogenerate ChangeLog entries

[Peter Volkov]

В Пнд, 20/09/2010 в 09:16 +0200, Michał Górny пишет:
> On Mon, 20 Sep 2010 09:44:38 +0400
> Peter Volkov  wrote:
> 
> > Another problem that there is no way to alter ChangeLog. Since
> > ChangeLogs are intended for users it's good idea to be able fix
> > typos / add credits there and thus it's impossible to generate them
> > from git commit messages.
> 
> How about using git notes [1] to alter ChangeLogs? These could be added
> to any commit without altering the commit itself (i.e. the hash remains
> the same).
> 
> [1] http://www.kernel.org/pub/software/scm/git/docs/git-notes.html

It's ok if it works:
http://archives.gentoo.org/gentoo-dev/msg_2e115d6286018891e62bbacd2e8f8c7c.xml

But that said, text files are easier...

-- 
Peter.

Re: [gentoo-dev] Re: Patch for python.eclass

[Peter Volkov]

В Пнд, 20/09/2010 в 04:53 +0200, Arfrever Frehtes Taifersar Arahesis
пишет:
> > while you're in the process of cleaning things up, i know we dont have a 
> > rule 
> > anywhere in terms of line length, but python.eclass has always struck me as 
> > a 
> > file with incredibly excessive line length.  comparing to other eclasses, 
> > it 
> > has multiple lines in it longer than any single line in any other eclass.
> > 
> > i normally develop in a terminal with 170 cols (which i think is larger 
> > than 
> > average), so i'm pretty lenient, but even python.eclass exceeds that 
> > multiple 
> > times if not running close to it.
> 
> python.eclass has many nested checks, loops etc.

Although we don't write ebuilds in C there are useful bits in
/usr/src/linux/Documentation/CodingStyle:

1. Coding style is all about readability and maintainability using
commonly available tools.

2. Now, some people will claim that having 8-character indentations
makes the code move too far to the right, and makes it hard to read on a
80-character terminal screen. The answer to that is that if you need
more than 3 levels of indentation, you're screwed anyway, and should fix
your program.


In other words having many nested checks means that eclass needs
reorganization to avoid them.

-- 
Peter.

Re: [gentoo-dev] omitting redirecting man pages from compression

[Peter Volkov]

В Вск, 19/09/2010 в 19:43 -0400, Mike Frysinger пишет:
> many man pages exist merely as a redirect to another man page:
> $ xzcat /usr/share/man/man1/zcat.1.xz
> .so man1/gzip.1
> 
> compressing these tiny (always?) results in a larger file.  that means we
> arent saving space, and we're adding overhead at runtime.

Isn't it better to skip compression on all tiny files (not only man
pages)? In such case some other functions will need to be updated too
(e.g. ecompress --suffix)...

-- 
Peter.

Re: [gentoo-dev] RFC: Repoman to autogenerate ChangeLog entries

[Peter Volkov]

В Вск, 19/09/2010 в 16:17 +0100, Mike Auty пишет:
> It should be possible to still maintain this distinction, something like:
> 
> "Version bump.  Added feature foo.
> - --
> Feature foo required a complete rewrite of src_install."
> 
> And then the ChangeLog generation can happen separately.  The problem
> with this method [...]

Another problem that there is no way to alter ChangeLog. Since
ChangeLogs are intended for users it's good idea to be able fix typos /
add credits there and thus it's impossible to generate them from git
commit messages.

-- 
Peter.

Re: [gentoo-dev] RFC: fox.eclass update

[Peter Volkov]

В Чтв, 16/09/2010 в 18:34 -0400, Mike Frysinger пишет:
> On Thursday, September 16, 2010 15:41:27 Peter Volkov wrote:
> > В Чтв, 16/09/2010 в 15:29 -0400, Mike Frysinger пишет:
> > > > FOX_PV="${FOX_PV:-${PV}}"
> > > 
> > > while you're here, i'd change to:
> > > : ${FOX_PV:=${PV}}
> > 
> > Why? This looks less readable...
> 
> only because your eyes arent tuned to it

Instead of explicit variable assignment (what was intended) you suggest
to call `:` command and implicitly assign variable with bash parameter
expansion...

-- 
Peter.

Re: [gentoo-dev] RFC: fox.eclass update

[Peter Volkov]

В Чтв, 16/09/2010 в 15:29 -0400, Mike Frysinger пишет:
> 
> > FOX_PV="${FOX_PV:-${PV}}"
> 
> while you're here, i'd change to:
> : ${FOX_PV:=${PV}} 

Why? This looks less readable...

-- 
Peter.

Re: [gentoo-dev] RFC: fox.eclass update

[Peter Volkov]

В Чтв, 16/09/2010 в 16:24 +0200, Matti Bickel пишет:
> +FOXVER=`get_version_component_range 1-2 ${FOX_PV}`

It's better to prefer $() style over ``:
http://mywiki.wooledge.org/BashFAQ/082

>  if [ "${PN}" != fox ] ; then
> FOX_COMPONENT="${FOX_COMPONENT:-${PN}}"
>  fi
>  
> -if [ "${FOXVER}" != "1.0" ] && [ -z "${FOX_COMPONENT}" ] ; then
> +if [ -z "${FOX_COMPONENT}" ] ; then
> DOXYGEN_DEP="doc? ( app-doc/doxygen )"
>  fi

It's better to use [[ ]] and avoid quotes since ebuilds are bash
scripts.

> -   elibtoolize
> +   eautoreconf

Hm, is this change necessary?

> +   if ( ! use doc ) && [ -d "${D}/usr/share/doc/${PF}/html" ] ;
> then

Subshell looks redundant here.

> +   epause

It's better to avoid epause as it makes build slower at the same time
it's most probable that nobody is looking on the screen at the moment[1]
and portage will print all elog messages at the end of the build in any
case.
 
[1] while emerge output is one of those things one can observe for ages
(like water, fire and others working) still it's possible no one
thoughtfully staring at the screen...

-- 
Peter.

Re: [gentoo-dev] RFC: fox.eclass update

[Peter Volkov]

В Чтв, 16/09/2010 в 17:44 +0200, Jeroen Roovers пишет:
> On Thu, 16 Sep 2010 09:41:30 -0500
> Jeremy Olexa  wrote:
> 
> > * econf doesn't need to "|| die"
> 
> Is that a novelty change? Most of the tree still does econf || die ...

econf is function that dies on its own.

But still there is one case where || die after econf can be useful -
very-very long list of econf options you have to edit rather frequently.

econf \
parameter1 \
parameter2 \
... \
parameterN || die

In case || die is absent and developer forgot '\' at the end of line
portage will not abort build: econf with shortened list of options will
succeed and next most probably absent command `parameterk parameter$((k
+1)) ... parameterN` will have no || die at the end. In general case ||
die after econf is redundant and should be dropped.

-- 
Peter.

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/sqlalchemy: ChangeLog sqlalchemy-0.5.8.ebuild

[Peter Volkov]

В Пнд, 13/09/2010 в 16:44 +, Arfrever Frehtes Taifersar Arahesis
(arfrever) пишет:
> arfrever10/09/13 16:44:13
> 
>   Modified: ChangeLog
>   Added:sqlalchemy-0.5.8.ebuild
>   Log:
>   Restore for old versions of Gourmet.

Please, mention why the change was made.

-- 
Peter.

Re: [gentoo-dev] CUPS 1.4 and FFMpeg 0.6

[Peter Volkov]

В Чтв, 09/09/2010 в 10:20 +0200, Christian Faulhammer пишет:
> Does anybody here know an obstacle to the stabilisation?

Just found that I'm unable to print with cups-1.4:

https://bugs.gentoo.org/show_bug.cgi?id=337057

Since Samsung printers are rather popular I think this is a blocker. But
probably this is local problem only. Could anybody confirm that problem
and report to the bug report?

-- 
Peter.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/hachoir-parser: ChangeLog hachoir-parser-1.3.4.ebuild

[Peter Volkov]

В Вск, 12/09/2010 в 17:01 +0300, Mart Raudsepp пишет:
> On L, 2010-09-11 at 23:18 +0300, Petteri Räty wrote:
> > On 09/11/2010 11:14 PM, Ryan Hill wrote:
> > > On Sat, 11 Sep 2010 22:10:51 +0300
> > > Petteri Räty  wrote:
> > > 
> > >>> +
> > >>> +*hachoir-parser-1.3.4 (10 Sep 2010)
> > >>> +
> > >>> +  10 Sep 2010; Arfrever Frehtes Taifersar Arahesis 
> > >>> 
> > >>> +  -hachoir-parser-1.3.3.ebuild, +hachoir-parser-1.3.4.ebuild:
> > >>> +  Version bump.

> That's why I tend to spend the time to briefly summarize what the
> version bump actually improves for users by upstream (see my gstreamer
> bumps for example). I spend the time once, thousands of users get the
> information handily with emerge --changelog and the like, without
> digging into /usr/share/doc/*/NEWS* _after_ upgrading and already having
> had to do the work to decide if its important upgrade for them or not
> (in case of conservative upgrading).

This ether should became common practice or it'll stay useless and even
harmful. It's hard to anticipate upstream NEWS in our ChangeLogs since
very few packages do this and as I see logic behind our ChangeLogs they
are intended for changes in our package (ebuilds), not for upstream
changes. At the same time this additional information makes our
ChangeLogs harder to read and find out what was changed in ebuild and
why. That said I think it's really useful to have this information with
rsync but it's better come with different solution instead of utilizing
package's ChangeLogs...

-- 
Peter.

Re: [gentoo-dev] Re: app-editors/vim-7.3 and python[3] USE flags

[Peter Volkov]

В Чтв, 19/08/2010 в 19:58 +, Duncan пишет:
> Jim Ramsay posted on Thu, 19 Aug 2010 17:00:17 + as excerpted:
> 
> > Option 1: IUSE="python python3"
> > 
> > Where python -> --enable-pythoninterp And python3 ->
> > --enable-python3interp
> > 
> > This means if you want python3 support and not python2 support you would
> > need USE="-python +python3"  A bit confusing, perhaps? Or if I set the
> > local flag description properly, is it okay?
> 
> What about USE=python indicating "maintainer's choice" of version?

++ But not maintainer's choice, but _upstream's choice_.

> You could then have either python2 or python3 flags for the other one.

Yup. This allows people to have best python support if they don't care
about version and those who care have USE flag for additional feature.

-- 
Peter.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in www-apps/drupal: drupal-5.23.ebuild ChangeLog drupal-6.19.ebuild drupal-6.16.ebuild drupal-6.17.ebuild drupal-5.22.ebuild

[Peter Volkov]

В Втр, 17/08/2010 в 11:27 +0200, Alex Legler пишет:
> but as for removing the old versions, that's something we usually ask
> people to do after bumping packages with security issues to minimize
> the risk of people installing possibly vulnerable versions.

I agree with removal but not immediately. Personally I already had
issues with another web application: it worked in my installation, but
people were unable to use it after security fix. Since having vulnerable
but working installation is better then "fixed" but broken, I'd rather
always kept old versions for some time. Also it's not a big problem to
have old versions in the tree since you have to specify version number
explicitly to install them...

-- 
Peter.

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in www-apps/drupal: drupal-5.23.ebuild ChangeLog drupal-6.19.ebuild drupal-6.16.ebuild drupal-6.17.ebuild drupal-5.22.ebuild

[Peter Volkov]

В Пнд, 16/08/2010 в 18:04 +, Alexey Shvetsov (alexxy) пишет:
> alexxy  10/08/16 18:04:52
> 
>   Modified: ChangeLog
>   Added:drupal-5.23.ebuild drupal-6.19.ebuild
>   Removed:  drupal-6.16.ebuild drupal-6.17.ebuild
> drupal-5.22.ebuild
>   Log:
>   [www-apps/drupal] Version bump

Always reference bug number and mention people that spent time reporting
problems in our bugzilla. Please, add bug # and attribution into
ChangeLog. Also with version bump it's always good idea to keep previous
version to allow re-installation of previous versions in the case of
regressions.

https://bugs.gentoo.org/show_bug.cgi?id=323399

-- 
Peter.

Re: [gentoo-dev] Re: Why (i.e. USE="openssl" instead of USE="ssl")

[Peter Volkov]

В Сбт, 14/08/2010 в 18:29 +0200, Peter Hjalmarsson пишет:
> lör 2010-08-14 klockan 15:14 +0300 skrev Samuli Suominen:
> > > [1] Last time I did a bugreport about this, here is the answer:
> > > https://bugs.gentoo.org/show_bug.cgi?id=310681
> > 
> > Long story short:
> > 
> > If package has SSL support, and use "ssl" is ignored or not present in a
> > ebuild. it's plain broken.
> > 
> > Every ebuild in tree with USE="openssl" is a QA violation, and should be
> > fixed asap.

> Is there a policy I can point Doug to in the bug referenced as he asks
> for it?

This was discussed many times here and since every time we had same
consensus the policy is in place. It's just not written in devmanual or
gentoo.org/doc.

-- 
Peter.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Peter Volkov]

В Сбт, 14/08/2010 в 20:06 +0300, Markos Chandras пишет:
> On Sat, Aug 14, 2010 at 06:26:36PM +0200, Thilo Bangert wrote:
> > > So you want me to force everyone to update the package just to respect
> > > the LDFLAGS.
> > 
> > yes. IIRC it has been stated on this list before, that a change which 
> > changes the resulting binary always needs to be done in a revbump. 
> List? Really? I use devmanual for ebuild development not list archives.

Heh, devmanual is second source of information and first is good old
official documentation. Take a look at our "Ebuild policy":

http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1

Now let me read it:


"Versioning and revision bumps"

"Package revision numbers should be incremented by Gentoo Linux
developers when the ebuild has changed to the point where users would
want to upgrade."

This general and a unclear sentence. Below it is explained quite well:

"Typically, this is the case when fixes are made to an ebuild that
affect the resultant installed files, but the ebuild uses the same
source tarball as the previous release."

For this this clear: if installed files changed do bump revision. And to
make this more clear later text discusses cases when no revbump
required:

"If you make an internal, stylistic change to the ebuild that does not
change any of the installed files, then there is no need to bump the
revision number. Likewise, if you fix a compilation problem in the
ebuild that was affecting some users, there is no need to bump the
revision number, since those for whom it worked perfectly would see no
benefit in installing a new revision, and those who experienced the
problem do not have the package installed (since compilation failed) and
thus have no need for the new revision number to force an upgrade."

Clear, right? And some exceptions, people mentioned in this tread:

"A revision bump is also not necessary if a minority of users will be
affected and the package has a nontrivial average compilation time; use
your best judgement in these circumstances."


Yes, we need to merge two piecies of information. But at the moment
we'll have to use both and in case devmanual has something unclear try
to look at other documentation. So, please, do revbumps for all changes
that affect installed files. ~arch is _supposed_ to be fast moving
target and for ~arch it's ok to rebuild package just for small fix. In
case users want something more stable that should use stable...

-- 
Peter.