[gentoo-dev] Last rites: gnustep-libs/cddb
# Dead original upstream (last release in 2003) # Now its only consumer gnustep-apps/cdplayer bundles it directly # Removal in 30 days (bug #501160) gnustep-libs/cddb
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-plugins/wmbattery: ChangeLog wmbattery-2.42.ebuild wmbattery-2.19-r1.ebuild
Le 12/02/2014 15:13, Samuli Suominen a écrit :
On 12/02/14 10:57, Bernard Cafarelli wrote:
Le 12/02/2014 1:02, Samuli Suominen a écrit :
On 12/02/14 01:20, Bernard Cafarelli wrote:
Le Tue, 11 Feb 2014 12:09:14 +0200
Samuli Suominen ssuomi...@gentoo.org a écrit:
On 11/02/14 11:42, Bernard Cafarelli (voyageur) wrote:
voyageur14/02/11 09:42:47
Modified: ChangeLog
Added:wmbattery-2.42.ebuild
Removed: wmbattery-2.19-r1.ebuild
Log:
Version bump, adds upower support
(Portage version: 2.2.8-r1/cvs/Linux x86_64, signed Manifest
commit with key C74525F2)
Revision ChangesPath
1.24 x11-plugins/wmbattery/ChangeLog
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/ChangeLog?rev=1.24view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/ChangeLog?rev=1.24content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/ChangeLog?r1=1.23r2=1.24
Index: ChangeLog
===
RCS file:
/var/cvsroot/gentoo-x86/x11-plugins/wmbattery/ChangeLog,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- ChangeLog25 Sep 2012 14:08:40 -1.23
+++ ChangeLog11 Feb 2014 09:42:47 -1.24
@@ -1,6 +1,12 @@
# ChangeLog for x11-plugins/wmbattery
-# Copyright 1999-2012 Gentoo Foundation; Distributed under the
GPL v2
-# $Header:
/var/cvsroot/gentoo-x86/x11-plugins/wmbattery/ChangeLog,v 1.23
2012/09/25 14:08:40 voyageur Exp $
+# Copyright 1999-2014 Gentoo Foundation; Distributed under the
GPL v2
+# $Header:
/var/cvsroot/gentoo-x86/x11-plugins/wmbattery/ChangeLog,v 1.24
2014/02/11 09:42:47 voyageur Exp $
+
+*wmbattery-2.42 (11 Feb 2014)
+
+ 11 Feb 2014; Bernard Cafarelli voyag...@gentoo.org
+ -wmbattery-2.19-r1.ebuild, +wmbattery-2.42.ebuild:
+ Version bump, adds upower support
*wmbattery-2.41 (25 Sep 2012)
1.1 x11-plugins/wmbattery/wmbattery-2.42.ebuild
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/wmbattery-2.42.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/wmbattery-2.42.ebuild?rev=1.1content-type=text/plain
Index: wmbattery-2.42.ebuild
===
# Copyright 1999-2014 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header:
/var/cvsroot/gentoo-x86/x11-plugins/wmbattery/wmbattery-2.42.ebuild,v
1.1 2014/02/11 09:42:47 voyageur Exp $
EAPI=5
inherit autotools
DESCRIPTION=A dockable app to report APM, ACPI, or SPIC battery
status
HOMEPAGE=http://joeyh.name/code/wmbattery/;
SRC_URI=mirror://debian/pool/main/w/${PN}/${PN}_${PV}.tar.gz
LICENSE=GPL-2
SLOT=0
KEYWORDS=~amd64 ~ppc -sparc ~x86
IUSE=
DEPEND=sys-apps/apmd
sys-power/upower
x11-libs/libX11
x11-libs/libXext
x11-libs/libXpm
Are you sure there are no runtime dependencies at all?
Futhermore, does it really link against the upower libraries or
just
call it only at RDEPEND through dbus?
In any case, the deps are wrong.
Nice catch, also present in the previous bump! 2.40 used EAPI 3 so
it
had the implicit RDEPEND=${DEPEND}... Fixed in both 2.41 and 2.42
ebuilds
For upower this new version directly uses upower-glib, so it's a
build
dependency
I don't think it's legit to use the upower-glib library without
pkg-config. So I'm pretty sure you are missing build-time-only
dependency of virtual/pkgconfig then too.
Indeed:
% grep 'pkg-config.*upower'
/var/tmp/portage/x11-plugins/wmbattery-2.42/work/wmbattery/Makefile
LIBS+=$(shell pkg-config --libs upower-glib)
$(CC) $(CPPFLAGS) $(CFLAGS) $(shell pkg-config --cflags
upower-glib) -c upower.c -o upower.o
Dependency added, thanks!
One more thing, why does it depend on sys-apps/apmd (which is part of
the old hotplug base that got replaced by acpi in 1995'ish) ?
It is really a hardcoded dependency after gained upower support? Seems
crazy, I don't think APM is used in any modern machines.
I don't think Linux kernel even supports APM since version 3.3.0
anymore
fully...
The original codebase was APM-only (it's a fork from wmapm), with
support for
optional additional sources (sonypi/HAL/ACPI/...). But the base is still
APM.
Making it optional would be a nice new upstream feature indeed :)
[gentoo-dev] Re: mbox -- looks sort of interesting
On 02/13/2014 06:36 PM, Александр Берсенев wrote: Hi, It was my project. The portage changed a lot since that time, I can try to renew it, if it's still used. I used to use it a lot until it stopped working because of not understanding EAPI 5. I think others would find it useful, but I don't think many people are aware of it.
Re: [gentoo-dev] dev-lang/go
I think it would be good idea to start a separate gentoo-golang repository (github?) and treat it more (to keep it aligned with the way gentoo works) or less (to speed up the development) as if it were gx86. In the organization part, I think we could inspire ourself in the way gentoo-haskell works. Jan Matějka| Gentoo Developer https://gentoo.org | Gentoo Linux GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B Thanks the comments, I'm not familar with what portage does with haskel so I'll take a look. I'll collect the notes that have been made here and start a project on github or gitorious in the next few days and post the details here. Emery
[gentoo-dev] Should we allow picture files in the Portage tree?
When rewriting the script scanning for binary files in the Portage tree [1], I noticed that there are some 25 XPM and SVG image files, with sizes up to 13 kB. For the time being, I've added exceptions for MIME types image/svg+xml and image/x-xpmi [2], but I think it would be better to clarify our policy on this. The devmanual currently says: | Things that do not belong in the tree: | * Large patches | * Non-text files | * Photos of teletubbies | * Files whose name starts with a dot Should we allow pictures if the image file format is a text file? Ulrich [1] http://qa-reports.gentoo.org/output/find-binary-files.txt [2] http://git.overlays.gentoo.org/gitweb/?p=proj/qa-scripts.git;a=blob;f=find-binary-files.sh;hb=HEAD pgpmYDWzFmC_R.pgp Description: PGP signature
Re: [gentoo-dev] Should we allow picture files in the Portage tree?
On 02/13/2014 10:12 AM, Ulrich Mueller wrote: When rewriting the script scanning for binary files in the Portage tree [1], I noticed that there are some 25 XPM and SVG image files, with sizes up to 13 kB. For the time being, I've added exceptions for MIME types image/svg+xml and image/x-xpmi [2], but I think it would be better to clarify our policy on this. The devmanual currently says: | Things that do not belong in the tree: | * Large patches | * Non-text files | * Photos of teletubbies | * Files whose name starts with a dot Should we allow pictures if the image file format is a text file? Yes, provided it fits all the other criteria, ie small and does not contain teletubbies. The problem as I understand it, is with version control systems work with text files only, irrespect of what those text files encode. Ulrich [1] http://qa-reports.gentoo.org/output/find-binary-files.txt [2] http://git.overlays.gentoo.org/gitweb/?p=proj/qa-scripts.git;a=blob;f=find-binary-files.sh;hb=HEAD -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] Should we allow picture files in the Portage tree?
On Thu, Feb 13, 2014 at 4:12 PM, Ulrich Mueller u...@gentoo.org wrote: Should we allow pictures if the image file format is a text file? I think we should not. Even if you can open it in a text editor, you can't read it or interact with it in the same way that you can a text-based patch. For that reason, big size or small size, it still in essence falls under the 'binary file' criteria and thus should not be permitted.
Re: [gentoo-dev] Should we allow picture files in the Portage tree?
On 02/13/2014 10:24 AM, Jason A. Donenfeld wrote: On Thu, Feb 13, 2014 at 4:12 PM, Ulrich Mueller u...@gentoo.org wrote: Should we allow pictures if the image file format is a text file? I think we should not. Even if you can open it in a text editor, you can't read it or interact with it in the same way that you can a text-based patch. For that reason, big size or small size, it still in essence falls under the 'binary file' criteria and thus should not be permitted. 1) You can interact with svg files with a text editor if you know what you are doing. 2) You want your vcs to show the diff in that file and you can make sense of that diff. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] Should we allow picture files in the Portage tree?
On 14 February 2014 04:28, Anthony G. Basile bluen...@gentoo.org wrote: 2) You want your vcs to show the diff in that file and you can make sense of that diff. Though how many of them are well formatted SVGs, and how many of them are single-line SVG files without whitespace, such as linefeeds and appropriate indentation? Because diffs are usually not very useful if lots of changes occur on a single line. -- Kent
Re: [gentoo-dev] Should we allow picture files in the Portage tree?
On Thu, Feb 13, 2014 at 10:30 AM, Kent Fredric kentfred...@gmail.com wrote: On 14 February 2014 04:28, Anthony G. Basile bluen...@gentoo.org wrote: 2) You want your vcs to show the diff in that file and you can make sense of that diff. Though how many of them are well formatted SVGs, and how many of them are single-line SVG files without whitespace, such as linefeeds and appropriate indentation? Because diffs are usually not very useful if lots of changes occur on a single line. If these were really hand-maintained SVG files I could see how it might fit into an scm model. However, these are text files in the same sense that an assembly language listing generated from a C++ file would be. Sure, you could manipulate it by hand, but the reality is that upstream is going to change 47 lines in the source and you're going to upgrade your gcc and as a result 90% of the 3M line listing will change on a small upgrade. Likewise, when upsteam changes their desktop icon it isn't going to result in a 3-line change to the SVG file. I guess the question though is whether they cause harm. If the files are small and don't cause issues with the scm they're stored in, then I don't really see the issue with storing them. It doesn't really matter if they're SVG files or uuencoded whatever (though if our tree is GPL we need to make source available for anything that has it - probably not an issue for SVG unless it is derived from some kind of composite). Rich
Re: [gentoo-dev] Re: mbox -- looks sort of interesting
On Thu, 13 Feb 2014 21:11:36 +1100 Michael Palimaka kensing...@gentoo.org wrote: On 02/13/2014 06:36 PM, Александр Берсенев wrote: Hi, It was my project. The portage changed a lot since that time, I can try to renew it, if it's still used. I used to use it a lot until it stopped working because of not understanding EAPI 5. I think others would find it useful, but I don't think many people are aware of it. Yes, if you can please work on updating it. Please contact us on the gentoo-portage-dev mail list or irc #gentoo-portage for changes to portage that will help keep it working in the future. I started development of a public_api branch long ago just for having a stable API for apps to use. Perhaps some of what you need can be integrated there. -- Brian Dolbec dolsen
Re: [gentoo-dev] Re: mbox -- looks sort of interesting
On Thu, Feb 13, 2014 at 11:07 AM, Brian Dolbec dol...@gentoo.org wrote: Yes, if you can please work on updating it. Please contact us on the gentoo-portage-dev mail list or irc #gentoo-portage for changes to portage that will help keep it working in the future. I started development of a public_api branch long ago just for having a stable API for apps to use. Perhaps some of what you need can be integrated there. Seems like a valuable tool. It would be best if it could either use portage APIs where available, or if effort could be directed at incorporating the necessary features into portage or its APIs so that you're not stuck maintaining a fork. I'm sure the portage team will help where they can. Rich
Re: [gentoo-dev] Bug #494552: libnotify
Hi there On 2014-02-09, Tom Wijsman wrote: The expiration time variable is made in https://git.gnome.org/browse/libnotify/tree/tools/notify-send.c?id=0.7.5#n135 and it is set in https://git.gnome.org/browse/libnotify/tree/tools/notify-send.c?id=0.7.5#n146 after which 'notify_notification_set_timeout' is called on an 'notify' object in https://git.gnome.org/browse/libnotify/tree/tools/notify-send.c?id=0.7.5#n231 which all seems fine. But: In the comment for 'notify_notification_set_timeout' there's this note that the timeout may be ignored by the server. -- Elias
Re: [gentoo-dev] dev-lang/go
Hi all,
I responded to this a while back, but I guess my email didn't go out for
some reason.
As the primary go maintainer, I do want to be involved in this. :-)
On Tue, Feb 11, 2014 at 01:38:44AM +0100, yac wrote:
On Mon, 30 Dec 2013 15:48:17 -0500
Emery Hemingway em...@vfemail.net wrote:
I really like working with Go, and would like to see a means of
merging Go packages with Portage. In short I am asking if anyone else
is interested in a Go project.
I might be. I have packaged something for private use but it just a
bunch of hacks. Anyway, I have some production go code.
For those who aren't familiar with Go, I will sumarise why Portage and
Go do not play well together.
Go is static linked by default.
The Go compiler creates static libraries and binaries. Libraries
compilied with different versions of Go (1.1/1.2) may not be linked
into the same binary.
Haskell is staticaly linked as well (by default) and you can see the
gentoo haskell project. I don't see this as a problem, we just will have
all dependencies in DEPEND and will have to scope on the go compiler
version under something like /usr/lib/go-1.{1,2}/...
That could be done easily enough, but what about the tools in /usr/bin
(there aren't many, but there are a couple), and these do not change
name with each version of go.
Go libraries are usually unversioned.
Libraries outside the system library are resolved with an import
statement that specifies a source code repository, such as a git or
mecurial repository. Most often Go libraries are installed using the
'go get' tool that clones a repository, and simply assumes HEAD/tip is
the best revision to build against. There is some support for using
git tags but it is not well documented. Often these libraries are very
small for the sake of reuse and to keep APIs simple.
My understanding is that a library repo will have branches based on the
version of go, so for example, it might have a branch called go-1 which
will be where go get will look to find the latest version of the code
that works with go-1.x.
In this case we just have to require upstream to make releases or
publish either live ebuilds, or ebuilds versioned something like
0_pre-MM-DD.ebuild [1]
I don't think we are going to be able to require upstream to make
releases, so that leaves us with:
1) using live ebuilds, which will never be allowed to have keywords by
gentoo policy, or
2) publishing snapshots, which also means we have to create tarballs to
match them. This will be a lot of work for us as maintainers. Also, the
only way we will know when a new version of the library is released is
to closely monitor the upstream git repository.
The other concern, which I believe zero was talking about is, once a
library is installed in GOPATH, I don't think the go build system
rebuilds it. In other words, go get will see that it is already there
and I don't think it goes back out to the net to check for any changes.
William
signature.asc
Description: Digital signature
[gentoo-dev] Re: Re: Re: dropping redundant stable keywords
On Wed, Feb 05, 2014 at 01:08:33AM +0100, Tom Wijsman wrote: On Tue, 4 Feb 2014 21:03:20 + Steven J. Long wrote: Tom Wijsman wrote: They are less work; since it lets the slower arches move their work to bugs of important packages that need their attention, instead of bugs of non-important packages were the stabilization isn't really necessary. Huh? The slower arch is not keeping up with stabilisation. How can the stabilisation suddenly be unnecessary? If it is not needed, there is no problem, and we wouldn't be having this discussion. It is still necessary, as clear from the difference in importance. Much better for the arch in question to field the bug, than tell the user there is no problem, and we don't care. That way you can get the user involved in stabilisation and AT via that bug, instead of turning them away with priggishness. Problems should be visible instead of hidden, as well as resolved. A move in work means a move in work, further implications are yours... Very gnomic: nothing's being hidden in the above approach. I can't make sense of the rest so I'll move on, noting only that it's up to the arch team, as to what _they_ decide to kick back to unstable. And that can work without a problem if we have a mechanism in place to relieve maintainers of those bugs. Personally I'd do it after 45 days to speed things up, and let the ATs concerned, take the bug as and when (eg turn the stabilisation into a tracker for the slow archs concerned, if there are multiple.) The arguments and headaches at the user, bug and AT sides are causing more work (or detracting from real work) too. Yes, the less work that we can do, the more work the user has to do as a natural consequence; discussions like these are there to prevent those headaches way in advance, as we can proper adapt and/or respond to the situation. And if needed, bring out news such that the user is well informed. Not sure which argumentation this is about though. Perfectly simple: instead of having this row repeatedly, or borking archs, let's use the solution proposed by the ARM AT: provide a technical reason why it won't work, rather than a conceptual problem with the hack. Searching for such technical reasoning is a leeway for hacking hoping. Er what? Solutions were provided, a policy has been made; we are exactly avoiding to row repeatedly, and this is yet another solution I propose: Provide a technical reason why it will work? You have colons after a solution I propose: with nothing after it. Kinda sums up your discussion for me. And your answer to tell us what it breaks is tell us why it works? Pfft. You further demonstrate this solution that I propose we should use: The history of computing is littered with hacks that turned out to shed new light on a problem: it's called exploring the problem domain. It's only when you have idiomatic knowledge of the language/tools *and* the specific domain, that you can envision oddball solutions and more importantly _know_ that they will work (perhaps with a bit of tweaking.) It is called prototyping. That's just another word: exploring the problem domain is much more useful to keep in mind. Similar to how Keep it Simple (and) Stupid is much more useful while coding, than: It is more important to make the purpose of the code unmistakable than to display virtuosity. The problem with obscure code is that debugging and modification become much more difficult, and these are already the hardest aspects of computer programming. (Kernighan and Plauger, 1976) ..although the latter is still worth reading/knowing about. Further, the solution steev brought up is much much better than simply dropping the ebuild. snip The -* keyword is special. It is used to indicate package versions which are not worth trying to test on unlisted archs. [1] Finally: some actual content. You can keep rehashing about winning, but all it does is break policy. *sigh* The wonderful thing about policy is that it reflects (or is supposed to) consensus opinion with light to contemporaneous circumstance. Since circumstances change, so too must policy be open to change or adaptation, in line with basic principles. So let's look at extending it, since there is *no* technical problem: 'The redundant -* keyword is a metadata marker. It is used to indicate, in line with the semantic of strip all, that the ebuild in question can only be used for the specific archs noted for one of two reasons: 1) The package-maintainer has stabilised a newer version on at least one arch personally, the ATs for the archs listed have taken longer than XX days to test and stabilise, and the maintainer would otherwise drop the ebuild altogether. 2) The package version is not worth trying to test on unlisted archs.' The policy which flows from that is: 'In the first case, it is QA policy that a comment of the form: #
[gentoo-dev] Last rites: app-emacs/nxml-mode
# Ulrich Müller u...@gentoo.org (13 Feb 2014) # Included with Emacs since version 23. # Last stand-alone release in 2004. # Masked for removal in 30 days, bug 501234. app-emacs/nxml-mode pgpb9060mgC3n.pgp Description: PGP signature
Re: [gentoo-dev] dev-lang/go
I made an overlay for Go eclasses and packages: https://github.com/gentoo-golang/overlay If anyone is interested ping 'emery' in #gentoo-dev-help and I'll add you to the github organization. There is an overlay skeleton at master, and a first draft eclass and ebuilds for btcd on another branch. I'll start adding what was discussed here as issues on the repo. Emery
Re: [gentoo-dev] Re: mbox -- looks sort of interesting
Ok, I'll work on it. 2014-02-13 23:00 GMT+06:00 Rich Freeman ri...@gentoo.org: On Thu, Feb 13, 2014 at 11:07 AM, Brian Dolbec dol...@gentoo.org wrote: Yes, if you can please work on updating it. Please contact us on the gentoo-portage-dev mail list or irc #gentoo-portage for changes to portage that will help keep it working in the future. I started development of a public_api branch long ago just for having a stable API for apps to use. Perhaps some of what you need can be integrated there. Seems like a valuable tool. It would be best if it could either use portage APIs where available, or if effort could be directed at incorporating the necessary features into portage or its APIs so that you're not stuck maintaining a fork. I'm sure the portage team will help where they can. Rich
Re: [gentoo-dev] Thank you
06.02.2014 10:30, Canek Peláez Valdés пишет: Hi. TL;DR, this is basically just a THANK YOU to the Gentoo devs Thanks for your feedback - much appreciated! -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-emacs/erc
# Ulrich Müller u...@gentoo.org (14 Feb 2014) # Included with Emacs since version 22.3. # Last stand-alone release in 2008, last commit to repo in 2009. # Masked for removal in 30 days, bug 501274. app-emacs/erc pgp4CYqhDQAEA.pgp Description: PGP signature
Re: [gentoo-dev] Re: mbox -- looks sort of interesting
Holy crap, that looks awesome! How does one pronounce your name, Александр? On Thu, Feb 13, 2014 at 11:28 PM, Александр Берсенев b...@hackerdom.ru wrote: Ok, I'll work on it. 2014-02-13 23:00 GMT+06:00 Rich Freeman ri...@gentoo.org: On Thu, Feb 13, 2014 at 11:07 AM, Brian Dolbec dol...@gentoo.org wrote: Yes, if you can please work on updating it. Please contact us on the gentoo-portage-dev mail list or irc #gentoo-portage for changes to portage that will help keep it working in the future. I started development of a public_api branch long ago just for having a stable API for apps to use. Perhaps some of what you need can be integrated there. Seems like a valuable tool. It would be best if it could either use portage APIs where available, or if effort could be directed at incorporating the necessary features into portage or its APIs so that you're not stuck maintaining a fork. I'm sure the portage team will help where they can. Rich
Re: [gentoo-portage-dev] [PATCH v2] Add --output-style option to repoman
On Thu, 13 Feb 2014 03:19:35 -0500
Mike Frysinger vap...@gentoo.org wrote:
On Monday, February 10, 2014 20:22:36 Chris Reffett wrote:
This patch adds a --output-style option to repoman, which gives the
user a choice of output formats for the repoman checks. Choices are
default (current style) and column (a greppable format), but it
should be easy to add more. Fixes bug 481584.
i'd expect a proper structured output would make sense to include in
the default set. like JSON. just create a dict and send it to
json.dump().
He is working on more changes to repoman and the output. So, if you
can, Chris, then do it, add a json option.
v2: Fix docstring to be complete and in the standard format, make
use of default choices in --output-style wrt comments by antarus
and dol-sen
erm, i thought the previous docstring was correct. it followed
PEP257 while this new one is like javadoc or something.
It is the existing format that has been around in portage for years.
There is even a page for it:
http://www.gentoo.org/proj/en/portage/doc/policies/docstring-spec.xml
It is also the style that epydoc recognizes.
-utilities.format_qa_output(f, stats, fails, dofull, dofail,
options, qawarnings)
+if options.output_style == 'column':
+ utilities.format_qa_output_column(f, stats, fails, dofull,
dofail, options, qawarnings)
+else:
+ utilities.format_qa_output(f, stats, fails, dofull,
dofail, options, qawarnings)
use a func pointer instead.
format_outputs = {
'column': utilities.format_qa_output_column,
'default': utilities.format_qa_output,
}
format_output = format_outputs.get(options.output_style,
format_outputs['default'])
format_output(f, stats, fails, dofull, dofail, options, qawarnings)
yeah, make it so. Good spot, Mike
Since Mike was too slow in replying, make another commit to change
it.
+ formatter.add_literal_data(NumberOf + category
+ )
prefer to use % rather than + like so:
'NumberOf %s ' % category
+ formatter.add_literal_data(%s % number)
well actually, for simple additions like that, string1 + string2, it is
actually faster.
But for multiple additions, %s is much better, faster. Also if the
string is translated, then use %s regardless. That way the %s can be
moved around for the translation.
str(number)
-mike
--
Brian Dolbec dolsen
signature.asc
Description: PGP signature
Re: [gentoo-portage-dev] [PATCH v2] Add --output-style option to repoman
On Thu, Feb 13, 2014 at 7:42 AM, Brian Dolbec dol...@gentoo.org wrote:
On Thu, 13 Feb 2014 03:19:35 -0500
Mike Frysinger vap...@gentoo.org wrote:
On Monday, February 10, 2014 20:22:36 Chris Reffett wrote:
This patch adds a --output-style option to repoman, which gives the
user a choice of output formats for the repoman checks. Choices are
default (current style) and column (a greppable format), but it
should be easy to add more. Fixes bug 481584.
i'd expect a proper structured output would make sense to include in
the default set. like JSON. just create a dict and send it to
json.dump().
He is working on more changes to repoman and the output. So, if you
can, Chris, then do it, add a json option.
v2: Fix docstring to be complete and in the standard format, make
use of default choices in --output-style wrt comments by antarus
and dol-sen
erm, i thought the previous docstring was correct. it followed
PEP257 while this new one is like javadoc or something.
It is the existing format that has been around in portage for years.
There is even a page for it:
http://www.gentoo.org/proj/en/portage/doc/policies/docstring-spec.xml
It is also the style that epydoc recognizes.
-utilities.format_qa_output(f, stats, fails, dofull, dofail,
options, qawarnings)
+if options.output_style == 'column':
+ utilities.format_qa_output_column(f, stats, fails, dofull,
dofail, options, qawarnings)
+else:
+ utilities.format_qa_output(f, stats, fails, dofull,
dofail, options, qawarnings)
use a func pointer instead.
format_outputs = {
'column': utilities.format_qa_output_column,
'default': utilities.format_qa_output,
}
format_output = format_outputs.get(options.output_style,
format_outputs['default'])
format_output(f, stats, fails, dofull, dofail, options, qawarnings)
yeah, make it so. Good spot, Mike
Since Mike was too slow in replying, make another commit to change
it.
+ formatter.add_literal_data(NumberOf + category
+ )
prefer to use % rather than + like so:
'NumberOf %s ' % category
+ formatter.add_literal_data(%s % number)
well actually, for simple additions like that, string1 + string2, it is
actually faster.
But for multiple additions, %s is much better, faster. Also if the
string is translated, then use %s regardless. That way the %s can be
moved around for the translation.
In general we prefer % for readability purposes, not because it is faster.
foo = Bar + foo + + baz + , + goat
foo = Bar %s %s, %s % (foo, baz, goat)
I think this case could go either way, because even with %, NumberOf%s is
not much of an improvement.
The code is littered with the former though, and it makes it really
annoying to read ;)
-A
str(number)
-mike
--
Brian Dolbec dolsen
Re: [gentoo-portage-dev] [PATCH v2] Add --output-style option to repoman
On Thu, 13 Feb 2014 10:03:50 -0800 Alec Warner anta...@gentoo.org wrote: On Thu, Feb 13, 2014 at 7:42 AM, Brian Dolbec dol...@gentoo.org wrote: well actually, for simple additions like that, string1 + string2, it is actually faster. But for multiple additions, %s is much better, faster. Also if the string is translated, then use %s regardless. That way the %s can be moved around for the translation. In general we prefer % for readability purposes, not because it is faster. foo = Bar + foo + + baz + , + goat foo = Bar %s %s, %s % (foo, baz, goat) I think this case could go either way, because even with %, NumberOf%s is not much of an improvement. The code is littered with the former though, and it makes it really annoying to read ;) -A Do I have to sick Brian Harring on you ;) I said for simple string addition... string1 + string2 is faster and equally readable Your example goes into the string %s %s, %s example where the string substitution is actually faster. Plus it is a lot more readable. -- Brian Dolbec dolsen
