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

2018-01-10 Thread 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

2017-11-13 Thread 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?

2017-07-31 Thread 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

2017-05-31 Thread 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

2013-10-23 Thread 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

2013-10-14 Thread 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

2013-10-13 Thread Peter Volkov
В Вс, 13/10/2013 в 14:13 -0700, Matt Turner пишет:
 On Sun, Oct 13, 2013 at 12:32 PM, William Hubbs willi...@gentoo.org 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

2013-09-30 Thread 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?

2013-09-25 Thread 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

2013-07-24 Thread 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

2011-12-13 Thread 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

2011-12-12 Thread 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

2011-10-13 Thread 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

2011-10-12 Thread 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

2011-10-11 Thread 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: 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

2011-10-10 Thread 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.




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

2011-10-10 Thread 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.




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

2011-10-01 Thread Peter Volkov
+# Peter Volkov p...@gentoo.org (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

2011-08-06 Thread Peter Volkov
Has no maintainer. Has runtime problems. Dead upstream.
Removal in 30 days. Bug #377979
gnome-extra/gget

--
Peter.




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

2011-07-01 Thread 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] Re: [gentoo-commits] gentoo-x86 commit in net-misc/aria2: aria2-1.12.0.ebuild ChangeLog

2011-07-01 Thread Peter Volkov
В Птн, 01/07/2011 в 09:09 +0100, Ciaran McCreesh пишет:
 On Fri, 01 Jul 2011 12:03:41 +0400
 Peter Volkov p...@gentoo.org 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.




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

2011-06-29 Thread Peter Volkov
В Срд, 29/06/2011 в 07:53 +0100, Ciaran McCreesh пишет: 
 On Wed, 29 Jun 2011 02:47:36 -0400
 Mike Frysinger vap...@gentoo.org 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. 




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

2011-06-28 Thread 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 p...@gentoo.org
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!
 }
 /codesample
 
 note
-When using csed/c with cCFLAGS/c or cLDFLAGS/c, it is not safe to use
-a comma or a slash as a delimiter. The recommended character is a colon.
+When using csed/c with cCFLAGS/c or cLDFLAGS/c, it is not safe to
+use a comma, a colon or a slash as a delimiter. cgcc/c options may contain
+this characters so csed/c will fail after bash expansion. The recommended
+character is a vertical bar: '|' (the pipe).
 /note
 
 p
-- 
1.7.3.4



[gentoo-dev] RFC: optinal run time dependencies

2011-06-28 Thread 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.




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

2011-06-28 Thread 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.





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

2011-06-28 Thread 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:
 
 tags
  atom val=dev-util/diffballtag1 tag2 tag2 tag3/atom
  atom val==dev-util/diffball-1.0awesomeness/atom
 /tags

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] SHA256 and indention in metadata.xml

2011-06-28 Thread 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] SHA256 and indention in metadata.xml

2011-06-28 Thread 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] demanual update (was: Don't use / when applying sed with CFLAGS)

2011-06-28 Thread 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 p...@gentoo.org
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 enot/e correct to use the c${CC}/c variable for this purpose.
 /note
 
 p
-Sometimes a package will not use the user's c${CFLAGS}/c or c${LDFLAGS}/c.
-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 csed/c) to use c${CFLAGS}/c or c${LDFLAGS}/c correctly.
+Sometimes a package will not use the user's c${CFLAGS}/c or
+c${LDFLAGS}/c. 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 cemake/c (check Makefile to see if this is
+possible):
+/p
+
+codesample lang=ebuild
+EAPI=4
+
+src_compile() {
+	emake CC=$(tc-getCC) CFLAGS=${CFLAGS}
+}
+/codesample
+
+p
+In other cases, the build scripts should be modified (for example, with
+csed/c) to use c${CFLAGS}/c or c${LDFLAGS}/c correctly.
 /p
 
 codesample lang=ebuild
@@ -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!
 }
 /codesample
 
 note
-When using csed/c with cCFLAGS/c or cLDFLAGS/c, it is not safe to use
-a comma or a slash as a delimiter. The recommended character is a colon.
+When using csed/c with cCFLAGS/c or cLDFLAGS/c, it is not safe to
+use a comma, a colon or a slash as a delimiter. cgcc/c, cld/c,
+car/c, etc... options may contain this characters so csed/c will fail
+after bash expansion. The recommended character is a vertical bar: '|' (the
+pipe).
 /note
 
 p
-- 
1.7.3.4



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

2011-06-28 Thread 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.





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

2011-06-24 Thread 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.1content-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] Re: [gentoo-commits] gentoo-x86 commit in app-misc/linux-logo: linux-logo-5.11.ebuild ChangeLog

2011-06-24 Thread Peter Volkov
В Птн, 24/06/2011 в 18:22 +0200, Jeroen Roovers пишет:
 On Fri, 24 Jun 2011 10:29:51 +0400
 Peter Volkov p...@gentoo.org 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 EOF
 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.




Re: [gentoo-dev] Packages up for grabs

2011-06-19 Thread 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.




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

2011-06-01 Thread 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 @@
 
 body
 p
-The cChangeLog/c must be updated with each commit. The
-echangelog tool should be used to create cChangeLog/c entries;
-the format of a cChangeLog/c is now defined as whatever
-cechangelog/c creates.
+The cChangeLog/c must be updated with each commit. The only possible
+relaxations for this rule are:
+/p
+
+ul
+  lib1./b Nonfunctional whitespace changes/li
+  lib2./b Changes in comments (lines starting with # in ebuild, or leading text in patches)/li
+  lib3./b Manifest updates/li
+  lib4./b Changes in cChageLog/c itself ;)/li
+/ul
+
+p
+The echangelog tool should be used to create cChangeLog/c entries; the
+format of a cChangeLog/c is now defined as whatever cechangelog/c
+creates.
 /p
 
 p


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

2011-06-01 Thread Peter Volkov
В Срд, 01/06/2011 в 19:37 -0400, Matt Turner пишет:
 On Wed, Jun 1, 2011 at 7:29 PM, Jorge Manuel B. S. Vicetto
 jmbsvice...@gentoo.org 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.





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

2011-05-30 Thread 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?

2011-05-24 Thread 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] Should server be a global use flag?

2011-05-24 Thread 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 u...@gentoo.org wrote:
  From http://devmanual.gentoo.org/general-concepts/use-flags/:
  | 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] arch teams and better tools

2011-05-22 Thread 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:
  http://git.overlays.gentoo.org/gitweb/?p=proj/arch-tools.git;a=summary

 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

2011-05-17 Thread 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.




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

2011-05-17 Thread 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.




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

2011-05-16 Thread 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.161content-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.




Re: [gentoo-dev] Devmanual text on ChangeLogs

2011-05-01 Thread 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:
 snip
 Though not mandatory, it is highly recommended that file removals are
 also recorded the same way.
 /snip 

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.




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

2011-05-01 Thread 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] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/transmission: transmission-2.12.ebuild

2011-04-30 Thread 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] Bugzilla - New Default Status Workflow

2011-04-30 Thread 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] Devmanual text on ChangeLogs

2011-04-30 Thread 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] rfc: openrc use flag

2011-04-22 Thread 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

2011-04-20 Thread 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

2011-04-10 Thread Peter Volkov
В Чтв, 31/03/2011 в 11:18 +0300, Samuli Suominen пишет:
 # Samuli Suominen ssuomi...@gentoo.org (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

2011-03-25 Thread 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

2011-03-22 Thread 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

2011-01-25 Thread 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] On hosting self-produced distfiles

2011-01-20 Thread 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] Last rites: net-analyzer/ipcad

2011-01-20 Thread 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] IPv6 herd

2010-12-29 Thread 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

2010-12-06 Thread Peter Volkov
В Сбт, 04/12/2010 в 11:42 +, Markos Chandras пишет:
 # Markos Chandras hwoar...@gentoo.org (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: Maintainer notes in metadata.xml?

2010-12-03 Thread 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] Re: Re: Maintainer notes in metadata.xml?

2010-12-03 Thread 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 pre 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] Maintainer notes in metadata.xml?

2010-12-01 Thread 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

2010-11-21 Thread Peter Volkov
В Вск, 21/11/2010 в 01:47 -0600, Ryan Hill пишет:
 On Sun, 21 Nov 2010 17:35:18 +1300
 Alistair Bush ali_b...@gentoo.org 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

2010-11-16 Thread Peter Volkov
eiВ Втр, 16/11/2010 в 07:53 +0100, Hans de Graaff пишет:
 On Tue, 2010-11-16 at 06:40 +, Peter Volkov (pva) wrote:
   
  +# Peter Volkov p...@gentoo.org (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.

2010-11-10 Thread 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

2010-11-01 Thread 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

2010-10-30 Thread Peter Volkov
В Птн, 29/10/2010 в 09:11 -0700, Alec Warner пишет:
 On Fri, Oct 29, 2010 at 5:21 AM, Markos Chandras hwoar...@gentoo.org 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.




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

2010-10-29 Thread 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] Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/tcpreplay: ChangeLog tcpreplay-3.4.5_beta2.ebuild

2010-10-29 Thread Peter Volkov
В Птн, 29/10/2010 в 19:29 +0200, Michał Górny пишет:
 On Fri, 29 Oct 2010 12:12:38 +0400
 Peter Volkov p...@gentoo.org 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.




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

2010-10-29 Thread 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] New eshowkw

2010-10-26 Thread 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] Support for Python 3

2010-10-25 Thread 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

2010-10-25 Thread 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] Re: [gentoo-commits] gentoo-x86 commit in app-cdr/cdemu: metadata.xml ChangeLog cdemu-1.3.0.ebuild

2010-10-21 Thread 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

2010-10-20 Thread Peter Volkov
В Втр, 19/10/2010 в 17:39 +0200, Christian Faulhammer пишет:
 Peter Volkov (pva) p...@gentoo.org:
  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

2010-10-09 Thread 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)

2010-10-02 Thread 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)

2010-10-02 Thread 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] Help on f-spot-0.8 problem

2010-10-02 Thread 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)

2010-10-02 Thread 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.




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

2010-10-01 Thread 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.




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

2010-10-01 Thread 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.1view=markup
 plain: 
 http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-python/sympy/files/sympy-0.6.7-python-2.7.patch?rev=1.1content-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.
 +rPut 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 net-libs/libproxy: ChangeLog libproxy-0.4.6.ebuild

2010-10-01 Thread 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.




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

2010-10-01 Thread 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.




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

2010-09-20 Thread 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] Re: Patch for python.eclass

2010-09-20 Thread 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] RFC: Repoman to autogenerate ChangeLog entries

2010-09-20 Thread Peter Volkov
В Пнд, 20/09/2010 в 09:16 +0200, Michał Górny пишет:
 On Mon, 20 Sep 2010 09:44:38 +0400
 Peter Volkov p...@gentoo.org 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] RFC: Repoman to autogenerate ChangeLog entries

2010-09-19 Thread 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

2010-09-16 Thread 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

2010-09-16 Thread 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

2010-09-16 Thread 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.




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

2010-09-14 Thread 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] Re: [gentoo-commits] gentoo-x86 commit in dev-python/hachoir-parser: ChangeLog hachoir-parser-1.3.4.ebuild

2010-09-13 Thread 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 betelge...@gentoo.org wrote:
   
   +
   +*hachoir-parser-1.3.4 (10 Sep 2010)
   +
   +  10 Sep 2010; Arfrever Frehtes Taifersar Arahesis 
   arfre...@gentoo.org
   +  -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

2010-08-19 Thread 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.




[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

2010-08-17 Thread 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: [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

2010-08-17 Thread 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.




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

2010-08-16 Thread 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=3chap=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.




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

2010-08-16 Thread 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] Package version in case of upstream patches from stable branch of development

2010-08-04 Thread Peter Volkov
В Втр, 03/08/2010 в 22:17 +0300, Petteri Räty пишет:
 On 08/03/2010 03:03 PM, Peter Volkov wrote:
  Bug 330667 requests _p or
  _pre. I feel that _p|_pre versions should be left for VCS (read
  development) versions of the package, while during backports we have the
  best version with all important upstream+gentoo fixes available to the
  moment and I'd better avoid to call it development.
 
 If you read the bug you will see that our python has essentially been
 development versions so _p is in line with what you say above.

Quotation from the bug:

gentoo's 3.1.2 is _not_ 3.1.2, it's a pre of 3.1.3.

Not taking into consideration that it is possible to name _p 3.1.2 I
would like to point that patches are from _stable_ branch as thus all
users want them. This is not development version.

  If we decide to go with _p or _pre could we agree on answers for the
  following questions:
   - Does single patch from upstream's VCS justify _p$(date|rev) version?
  What if this is _the only_ patch in the upstream's VCS?
 
 No if the patch is small and can be reasonably understood. If the patch
 for example switches the used build system and I would think _p is
 called for.

   - Now what about two patches? Three? N? When does few patches became
  pile?
 
 You should ask upstream to make a release when they start to pile up.

Yup, but since patchset being pile is a clause to change version, we
should formally define what is a pile. 20kb unpacked? 10 patches? Until
this is done such decision is on maintainer's discretion, like
maintainer told in comment #1.

   - What if I drop single patch from the upstream's patchset for stable
  branch, should we drop _pre _p version and add -rN?
 
 _p reflects upstream situation so dropping a patch from that is a Gentoo
 modification there so it would be _p12323-r1.

Rigorously speaking even dropping one patch makes it not to be _p12323
any more and we should version it somehow differently. How? Since ebuild
is based on upstream's stable tarbal obvious solution is to use the
tarbal's version.

   - What if there are two dependent patches, and first one fixes
  indentation? Should we spend time on backporting second patch (time
  consuming and error prone process) or use both and live closer to
  upstream?
 
 I would leave this up to the maintainer. Depends on how much time
 backporting takes.

After reading your answers I don't understand why the bug is still
opened and what it is about. Arfrever told that he fells that it's up to
him how to version packages. And I agree with him in this exact case.

-- 
Peter.




Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-zope/datetime: ChangeLog datetime-2.12.5.ebuild

2010-08-04 Thread Peter Volkov
В Втр, 03/08/2010 в 17:12 -0500, Jeremy Olexa пишет:
 On Thu, 29 Jul 2010 20:22:47 + (UTC), Arfrever Frehtes Taifersar
 Arahesis (arfrever) arfre...@gentoo.org wrote:
  snip
  SRC_URI=http://pypi.python.org/packages/source/${MY_PN:0:1}/${MY_PN}/${MY_P}.tar.gz;
  snip
 
 This is a perfect example of over-complexification - Why didn't you
 just use D instead of ${MY_PN:0:1} ?

Just take a look at pypi.python.org repository structure. This URL can
be copypasted from one package into another package from the same
repository without any changes... 

-- 
Peter.




Re: [gentoo-dev] Package version in case of upstream patches from stable branch of development

2010-08-04 Thread Peter Volkov
В Срд, 04/08/2010 в 09:42 +, Jorge Manuel B. S. Vicetto пишет:
 If you take KDE's team example, we provide ebuilds to track the stable
 branch from upstream in our overlay. They're called version..
 It's true that our ebuild does use the live vcs, but in this case the
 difference is that instead of the users using a live ebuild, they get
 a snapshot of the tree done by our maintainer from time to time.
 Trying to pretend these snapshot ebuilds are the release version is
 very wrong and no one should assume they'll build fine.

Even for official upstream releases build tests are not enough. So there
is not difference with _p here.

 There are already a few bugs that can be attributed to this.

Ok, let's say that this depends on upstream. And for Gentoo this means
that the decision how to set version for the package depends on
maintainer. Lot's of packages do not have dedicated release tests
upstream (even build tests) and for this packages I don't see difference
between stable branch and release. In such case our version just
indicates that our package is base on tarbal of that version and nothing
more.

 The point here is that one thing is for a maintainer to pick specific
 commits from the stable branch and back port them to fix some bugs,
 another thing is to blindly fetch a snapshot of the stable branch.

In reality it's hard to see difference if commit was done blindly or it
was well tested until obvious crash happens.

 It would be based on a release if it only applied specific patches to
 fix known issues. The minute you start tracking a stable branch you
 should stop calling it a release and 300kloc is not a small patch.

Actually I think this limit depends on size of project. In any case
until we have something documented that's up to maintainer...

 This is unfortunately the main issue here. You may work on a specific
 package on Gentoo, but when that package is essential for the system
 use / stability, it stops being just your package. This latest
 example has lead users to a point where their PM stopped working.
 Breaking the PM is not a small oops 

That's completely different topic... I'm not talking about stability at
all. Of course, python is special package and should be treated/tested
by maintainers as such! Probably for such core packages ~arch is not
enough and we need different process... But that a different topic.

Bug I mentioned pretends that we have policy how to set version for
packages that use backported upstream patches. My point is that there is
no such policy and line between _p or -rN is very fuzzy to set such
policy. Thus bug itself is INVALID...

-- 
Peter.




[gentoo-dev] Package version in case of upstream patches from stable branch of development

2010-08-03 Thread Peter Volkov
Hi.

How should we version our packages in case we've backported upstream
patches from stable branch of development? Bug 330667 requests _p or
_pre. I feel that _p|_pre versions should be left for VCS (read
development) versions of the package, while during backports we have the
best version with all important upstream+gentoo fixes available to the
moment and I'd better avoid to call it development.

If we decide to go with _p or _pre could we agree on answers for the
following questions:
 - Does single patch from upstream's VCS justify _p$(date|rev) version?
What if this is _the only_ patch in the upstream's VCS? 
 - Now what about two patches? Three? N? When does few patches became
pile? 
 - What if I drop single patch from the upstream's patchset for stable
branch, should we drop _pre _p version and add -rN?
 - What if there are two dependent patches, and first one fixes
indentation? Should we spend time on backporting second patch (time
consuming and error prone process) or use both and live closer to
upstream?

I think without exact answers on this questions I don't think this bug
330667 may request anything, only suggest... But what do you think?

-- 
Peter.




  1   2   3   >