Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: toolchain.eclass
On 02/09/2015 07:19 PM, Anthony G. Basile wrote: On 02/09/15 06:40, Michał Górny wrote: This breaks a few packages [1,2]. Please fix the breakage and run repoman next time. [1]:https://travis-ci.org/gentoo/gentoo-portage-rsync-mirror/jobs/50118225#L4304 [2]:https://travis-ci.org/gentoo/gentoo-portage-rsync-mirror/jobs/50118228#L923 Someone has a shiny new toy :) Seriously this is great, but asking someone to run repoman when making a change to an eclass is extreme. You'd have to run it against the whole tree and while I haven't timed it, that's going to be a heavy task. Travis times it: 18m 10s ;-) @mgorny could you steal AutoRepomanWarning parser from Patrick and apply it to your travis job? Cheers, Kacper BTW, when I saw this I went out and added travis-ci to all my github repos. What a wonderful service. If only I can figure out how to make it work with clang static analysis. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs
Hi All! There's a bunch packages that I'm officially maintaining but due to the lack of time I'm unable to do that properly. I'd be grateful if you could step in for me. I'll remove myself from metadata in the following packages within 7 days: # OpenCL app-admin/eselect-opencl dev-util/intel-ocl-sdk virtual/opencl dev-vcs/svnmailer sys-block/megacli sys-cluster/polysh x11-themes/pidgin-penguins-smileys As of now, I've also dropped maintainership in some of the packages that belong to following herds: app-doc/doxygen dev-tools dev-python/autopep8 python / sping dev-python/d2to1 python dev-python/figleafpython dev-lang/ekopath sci dev-lang/path64 sci sci-astronomy/galaxy sci-astronomy sys-apps/hwloccluster sys-process/glances python www-apps/bitten python and packages I've co-maintained with: app-editors/gobby dev-zero net-libs/libinfinity dev-zero net-libs/net6 dev-zero net-libs/obby dev-zero net-misc/sobbydev-zero net-misc/l7-filter-userspace bicorph x11-drivers/nvidia-driversjer Sorry guys that I haven't been much of a help lately. I'll also cease to watch over dev-tools herd. Hwoarang is all alone there so I guess he'll appreciate all help that he can get. Cheers, Kacper signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Response to a friendly note about changing bug reports
On 08/07/2013 01:57 AM, Andreas K. Huettel wrote:
Am Dienstag, 6. August 2013, 23:46:08 schrieb Jeroen Roovers:
23:37:25 willikins rej, you have notes! [21:13] mrueg Let me
rephrase this: Just a friendly notice to please refrain from rephrasing
bug summaries from Stabilize ${P} to ${P} stable req. This just
adds unneeded noise to the bug. I don't want this on bugs I've reported
or am assigned to.
This is my equally short and friendly note: It's not going to happen.
Forget about it. They are not your bug reports and anyone is
actually /welcome/ to improve them. Get used to it.
To get technical on the improvement bit, we have agreed time on time
that stating the atom and then the action is the way to go. The main
reasons is that it helps people who need to regularly read /lists/ of
bug summaries sort them better. Until we get a specific [Atoms] field
implemented, it will need to stay this way.
Jer,
please stop making whitespace noise on bugs that you have absolutely no
relation to. It just causes unnecessary bugmail. If maintainers care they
will
change it themselves.
Cheers,
Andreas
Hi,
with all due respect Andreas but I think you missed the point of Jer's
mail. There's absolutely nothing like relation to bug or bug
maintainership.
Your bug can only mean that you're responsible for fixing the issue
that was reported, not that you *own* that particular bit of bugzilla's
database...
Not so hypothetical situation: someone files a bug: Fancy KDE mail
program fails with my gcc, you fix it and live happily ever after.
How on earth am I supposed to find it when porting/stabilizing newer
version of gcc?
I expect (as many others) something similar to =kde-base/kmail-4.8.10
fails to build with gcc-4.8
I deeply respect the work of people who fix bugzilla subjects to conform
to atom: issue format. It saves me a great deal of time.
Cheers,
Kacper
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Response to a friendly note about changing bug reports
On 08/07/2013 11:04 AM, Andreas K. Huettel wrote:
Am Mittwoch, 7. August 2013, 10:46:04 schrieb Kacper Kowalik:
On 08/07/2013 01:57 AM, Andreas K. Huettel wrote:
Am Dienstag, 6. August 2013, 23:46:08 schrieb Jeroen Roovers:
23:37:25 willikins rej, you have notes! [21:13] mrueg Let me
rephrase this: Just a friendly notice to please refrain from rephrasing
bug summaries from Stabilize ${P} to ${P} stable req. This just
adds unneeded noise to the bug. I don't want this on bugs I've reported
or am assigned to.
Jer,
please stop making whitespace noise on bugs that you have absolutely no
relation to. It just causes unnecessary bugmail. If maintainers care they
will change it themselves.
Cheers,
Andreas
[...]
Not so hypothetical situation: someone files a bug: Fancy KDE mail
program fails with my gcc, you fix it and live happily ever after.
How on earth am I supposed to find it when porting/stabilizing newer
version of gcc?
I expect (as many others) something similar to =kde-base/kmail-4.8.10
fails to build with gcc-4.8
I deeply respect the work of people who fix bugzilla subjects to conform
to atom: issue format. It saves me a great deal of time.
That's fine, bug wranglers are doing a great job there.
However, I'm also sick of getting bugmail because $RANDOM_DEV thinks
* TRACKER is better than Tracker,
This is pointless, indeed
* every atom needs a = in front, and
* Please stabilize XXX should always be replaced by XXX stabilization.
Those two are actually useful. There are many scripts used by ATs that
parse title field. One could argue: Fix your damn scripts but in the
end it's your bugspam vs predicting all possible ways someone could
express an atom.
I seriously doubt that people are changing bug reports cause they break
their sense of aesthetics (/me waves to all OCDs out there). Most of the
changes have some underlying technical reason. Even if it's whitespace,
'=' or ordering.
Cheers,
Kacper
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs
On 06/16/2013 11:31 AM, Pacho Ramos wrote: Due ramereth lack of time: sys-block/megacli As a very unhappy owner of hardware that uses it, I'll take it. Cheers, Kacper signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages using -Werror
On 03.05.2013 10:06, Ben de Groot wrote: On 3 May 2013 12:09, Ryan Hill dirtye...@gentoo.org wrote: Most of the bugs filed on the gcc 4.8 tracker so far have been caused by packages being built with -Werror. I just noticed one package where the Makefile was being patched to remove -g from CXXFLAGS but -Werror on the same line was left in. Just in case people weren't aware, building with -Werror is a bad idea and against policy*. If you're fixing one of these bugs by silencing the warning be sure to remove the flag also. Thanks! https://bugs.gentoo.org/show_bug.cgi?id=werror http://blog.flameeyes.eu/2009/02/future-proof-your-code-dont-use-werror * said policy might not actually exist in writing outside of the mailing list. still a bad idea though. -- gcc-porting toolchain, wxwidgets @ gentoo.org If this is a policy, it should be documented in our devmanual. It is [1] Cheers, Kacper [1] http://devmanual.gentoo.org/ebuild-writing/common-mistakes/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Establishing Gentoo patch policy to keep our patches consistent and clean
On 06.04.2013 20:08, Michał Górny wrote: Hello, As far as I'm aware, we don't really have much of a patch maintenance policy in Gentoo. There a few loose rules like «don't put awfully big files into FILESDIR» or the common sense «use unified diff», but no complete and clear policy. Especially considering the late discussion related to the needless and semi-broken functionality in epatch, I'd like to propose setting the following rules for patches in tree and in Gentoo-sourced patchsets: 1. Patches have to be either in unified or context diff format. Unified diff is preferred. 2. Patches have to apply to the top directory of the source tree with 'patch -p1'. If patches are applied to sub-directories, necessary '-p' argument shall be passed to 'epatch' explicitly. Developers are encouraged to create patches which are compatible with 'git am'. 3. Patches have to end with either '.patch' or '.diff' suffix. 4. If possible, patches shall be named in a way allowing them to be applied in lexical order. However, this one isn't necessary if patches from an older ebuild are applied to a newer one. 5. The patch name shall shortly summarize the changes done by it. 6. Patch files shall start with a brief description of what the patch does. Developers are encouraged to use git-style tags like 'Fixes:' to point to the relevant bug URIs. 7. Patch combining is discouraged. Developers shall prefer multiple patches following either the upstream commits or a logical commit sequence (if changes are not committed upstream). The above-listed policy will apply to the patches kept in the gx86 tree (in FILESDIRs) and patch archives created by Gentoo developers. They will not apply to the patch archives created upstream. Hi, there's at least one guideline written by the Ancient Ones that I know [1] It roughly follows the ideas that you've described. I think it'd be enough if people read it and used as a suggestion not a strict ruling. Imposing things like lexical order or git-style heading is a bit too much for me. Do we really need rules for everything? Cheers, Kacper [1] http://dev.gentoo.org/~vapier/clean-patches signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree
On 27.01.2013 18:26, Mike Frysinger wrote: On Friday 25 January 2013 18:51:44 Mike Frysinger wrote: i've taken Constanze' work and rewritten it a bit to be easier to use (imo) as most settings are now defaults merged. i'll move iputils over to it first and if there aren't any problems, i'll move more over to it. -mike Could you also add 'filecaps' to use.desc, please? Kacper signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Defaulting for debug information in profiles
On 12/17/2012 11:11 AM, Tomáš Chvátal wrote: Hi lads, lately I am having bit of problems from getting relevant debug info from users. All trouble can be saved by asking user to recompile package with relevant flags on bug report, resolving the bug as NEEDINFO. Instead of forcing everybody out there using Gentoo to have additional XGb for debug, patching troublesome packages like webkit-gtk etc. Bug without valid data is by definition... invalid? I'm pretty amused by this thread, cause *you* taught me that ^^. I had once the very same idea :) Cheers, Kacper Since we already have splitdebug for quite time (and I suppose quite few of us are using it) how about making it to default profiles default enabled and add -g to default cflags. Currently it is only enabled in the developer profile. This results in 2 gb data in /usr/lib/debug for my system which is not that bad with current disk sizes and it saves users quite some time when i have to request them to recompile half of their system with debug info just to get idea how to fix their issue. I would go even for compressdebug feature but that one needs more time as some packages like glibc fails to merge with it and you need newer gdb to work with it. Cheers Tom signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)
On 16.12.2012 18:20, Michael Orlitzky wrote: On 12/16/2012 12:02 PM, Fabian Groffen wrote: On 16-12-2012 11:57:35 -0500, Michael Orlitzky wrote: 3. Get off CVS for Christ's sake. Nobody wants to work with that. I don't know how this fits into my bullet list, but it's important. It doesn't, and it's not. I'm not going to put together a powerpoint presentation for you, but think about it this way. Many new developers who want to contribute to to some project will learn git, because a large number of important projects use git. No (new) developers are going to learn CVS. Ever. But there's nothing to learn... You only need to c'n'p code listings 1.1 - 1.3 [1] once in a lifetime of your dev box. Then you only type 'cvs up' for the rest of your developer life. If you ever encounter anything unusual and you don't want to waste precious time to even read the warning/error message you rm -rf offending directory and you do... 'cvs up'. How hard is that? Cheers, Kacper [1] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1chap=4 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Packages up for grab
Hi Folks! There are a few packages that I'm no longer interested in maintaining: media-gfx/mandelbulber (co maintained-by media-gfx, needs bump and some opencl love) net-irc/irssi-xmpp (stablereq pending #440864) net-misc/identicurse (no bugs, no stable) I'll drop myself in a week and assign to m-n@g.o or leave just the herd. Of course unless you grab them first ;-) Thanks! Kacper signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 18.11.2012 08:57, Greg KH wrote: On Sat, Nov 17, 2012 at 11:02:19PM -0800, Alec Warner wrote: 1) systemd-udev will require systemd. Stated by the systemd maintainers themselves as a thing they want to do in the future. Some users don't want to use systemd. We could go into detail as to why; but I think that is not as important as one may think. The point is that the desire is there, and thusly there are users who want to make other systems (namely openrc) work. People like openrc. My VMs for instance, boot reasonably quickly. Booting 5 seconds faster may be super duper, but not at the cost of an existing reliable solution. So is this the goal? Great, someone say that then, that's all I'm asking for here. That's wonderful, seriously. But why is this suddenly an official Gentoo project? When did that happen, and why? Why not just do a normal project and if it matures and is good enough, then add it to the distro like all other packages are added. My main point here is the fact that this is now being seen as an act by Gentoo, the distro / foundation. And that happened in private, without any anouncement. Which is not good on many levels. I'm unsure on what grounds you disapprove. People start (and abandon) projects often in Gentoo. Suddenly you dislike one such project and object to this practice? Certainly if we had to get some sort of Foundation consensus (for anything) nothing would happen. We can't even get more than 40% of foundation members to vote. I object if this is seen as a Gentoo blessed fork of a community project that is worked on by all other major Linux distros. That is the type of decision that can be made by the Gentoo Council, which is fine, but it sure would be nice if it were publicly stated, instead of having to see it on the Gentoo github site instead. Hi, I've seen this argument being repeated all over this thread and I'd like to clarify: http://github.com/gentoo (nor it's bitbucket.org counterpart) was never meant to host Gentoo blessed forks/projects and it *doesn't*. Sole purpose of it, was to encourage more contribution from users using web goodies like click a button to fork, since most of the people are very comfortable with github's workflow. We (gentoo-science team) have seen significant increase of interest since we've started using github. Cheers, Kacper P.s. Just to emphasise it even more: There's a pornview fork there too. I don't recall Gentoo Council acknowledging it as default imageviewer. We should definitely put it into agenda. /reductio ad absurdum And if that is the decision of the council, I would expect the ability to have some type of discussion about it, wouldn't you? Also, the whole issue with the copyrights is very serious, for the reasons I've stated before. Don't mess with copyrights, developers, and companies, take them very serious, as they are the basis for our licenses. thanks, greg k-h signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] PORTAGE_GPG_KEY strictness
On 17.10.2012 03:30, Patrick Lauer wrote: On 10/17/12 06:54, Robin H. Johnson wrote: Hi all, One of the items that has come up in the Git conversion, and needs some attention. [snip] As such, we've decided to make the PORTAGE_GPG_KEY strictly enforce what was originally intended. - You must specify a key or subkey exactly. - The leading 0x is optional. - If you want to use a subkey, per the PGP specifications, you must suffix your keyid with !. - Your keyid is exactly: 8, 16, 24, 32 xor 40 hexdigits long. That's nice. Can we also add some basic policies on key format (key length, validity) and get a centrally-hosted keyring? Then it'd even make sense for us to start using the whole signing thing now :) Additionally, can any consensus achieved here be documented right away? e.g. here [1] or @devmanual.g.o Cheers, Kacper [1] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=6 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Lastrites: sys-cluster/lam-mpi
# Kacper Kowalik xarthis...@gentoo.org (24 May 2012)
# Masked for removal in 30 days (#324415), Doesn't build with
# libtool-2.2 (#276194), bundles vulnerable copy of libtool (#297648),
# fails to install with new coreutils and automake-1.11 (#328549),
# last release 2007-02-14, doesn't provide MPI-2
# Superseeded by sys-cluster/{openmpi,mpich2}
sys-cluster/lam-mpi
Took long enough to kill that one...
Cheers,
Kacper
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!
On 05/23/2012 01:00 PM, Pacho Ramos wrote:
El mié, 23-05-2012 a las 10:31 +0100, Markos Chandras escribió:
On Wed, May 23, 2012 at 9:04 AM, Pacho Ramos pa...@gentoo.org wrote:
El mié, 23-05-2012 a las 06:39 +1000, Michael escribió:
On 2012-05-22 03:46, Alexandre Rostovtsev wrote:
On May 20, autools.eclass was changed to no longer inherit eutils, see
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?r1=1.133r2=1.134
Relying on autotools.eclass for your eutils needs was always a terrible
idea, but a few ebuilds did it anyway. Those ebuilds are now *broken*
since they can no longer use epatch. See bug #416847 for an example.
Check your ebuilds to make sure you inherit eutils in anything that uses
epatch!
-Alexandre Rostovtsev.
Since eutils inherits multilib and user, the breakage extends beyond
epatch.
For example, I just saw bug #417153, where a user reported failed calls
to enew{user,group}.
The autotools.eclass change should probably be reverted until things are
properly checked I think (and I will do it tomorrow if nobody disagrees)
It is far too late to do that. What is done is done. Let try and fix
what is still broken
Regards,
Markos
But we still have no idea what kind of commands provided by eutils and
eclasses inheritted by it are now missing, epatch usage was fixes,
enewgroup/user will probably be done but... other missing commands could
still appear in the tree :|
I wrote a simple, stupid script just a moment ago. Please don't show it
to anybody who knows how to write in Python :D
It shows all missing inherits, not just the ones causing failures, but
it could prolly be adjusted to do that instead.
Cheers,
Kacper
#!/usr/bin/env python
import re
import os
import argparse
class DirectoryWalker:
# a forward iterator that traverses a directory tree
def __init__(self, directory):
self.stack = [directory]
self.files = []
self.index = 0
def __getitem__(self, index):
while 1:
try:
file = self.files[self.index]
self.index = self.index + 1
except IndexError:
# pop next directory from stack
self.directory = self.stack.pop()
self.files = os.listdir(self.directory)
self.index = 0
else:
# got a filename
fullname = os.path.join(self.directory, file)
if os.path.isdir(fullname) and not os.path.islink(fullname):
self.stack.append(fullname)
return fullname
usage = usage: %prog [options] DIRECTORY
parser = argparse.ArgumentParser()
parser.add_argument(-e, nargs=1, default=[user],
help=Name of the eclass to test, e.g. 'user')
parser.add_argument(-p, nargs=1, default=[/usr/portage],
help=Directory where eclass resides, e.g. PORTDIR)
parser.add_argument(directory, nargs=1,
help=Directory with ebuilds to run tests )
args = parser.parse_args()
is_ebuild = re.compile('\.ebuild$')
ebuilds = filter(is_ebuild.search, DirectoryWalker(args.directory[0]))
re_func = re.compile(FUNCTION).search # TODO: improve me
fname = open('%s/eclass/%s.eclass'% (args.p[0], args.e[0]))
funcs = [func.split()[-1].strip()
for func in filter(re_func, fname.readlines())]
fname.close()
# Listen carefully, I shall speak it only once
regexps = {func: re.compile(func).search for func in funcs}
re_inher = re.compile(^inherit.*%s% args.e[0]).match
for ebuild in ebuilds:
fname = open(ebuild,'r')
lines = fname.readlines()
fname.close()
uses_function = any([len(filter(regexps[key], lines))
for key in regexps.keys()])
uses_eclass = len(filter(re_inher, lines))
if uses_function and not uses_eclass:
print(%s should inherit %s.eclass % (ebuild, args.e[0]))
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] -Werror unwanted?
On 15.05.2012 13:29, Tony Chainsaw Vroon wrote: On 14/05/12 16:44, hasufell wrote: However, I don't see references to ebuild policy (in devmanual or howtos) how to handle Werror. As can be judged by the title of my patches on the subject, I consider -Werror to be short-sighted at best and idiotic at worst. The next GCC version, which will add *loads* of warnings to anything that compiled cleanly before, is going to kill you. Remove it from the build system. It is one of those patches that will probably live downstream until the end of time, but that is acceptable. That's why IMHO the best way to fix those bugs is to make -Werror optional. It the hardest path, but both upstream and downstream should be satisfied. Cheers, Kacper signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: remove ldap from desktop profiles use flags
On 05/08/2012 02:01 AM, Rich Freeman wrote: On Mon, May 7, 2012 at 7:17 PM, Walter Dnes waltd...@waltdnes.org wrote: There's a server profile which could be the answer. I've never seen that as being a terribly useful profile. Servers tend to be very minimal configurations. Maybe if we ever ripped sshd out of the default profile we might put it there, but beyond that what would you run on EVERY server? If I were to build a server I'd just stick with the default profile, and then add to it. Hi, read what Walter written till the very end ;) Problem is not what to *add* to the default profile, but rather that you have to *remove* tons of flags from it to have something compact. As he already mentioned usually USE=-* is the way to start. There were plans once among the cluster herd's members to write minimalistic profile for hpc server/node and ha cluster that would inherit from a barebone server profile. We just never got to it as demand wasn't that high. Maybe it's time to revisit the problem. Cheers, Kacper signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] cmake-utils.eclass: set default of CMAKE_VERBOSE=1
On 04.05.2012 18:30, hasufell wrote: # @ECLASS-VARIABLE: CMAKE_VERBOSE # @DESCRIPTION: # Set to enable verbose messages during compilation. By default this is deactivated which is inconvenient imo and results in pastes having minimum information. I have to tell users every time to recompile with CMAKE_VERBOSE=1 so that I have proper information on what is going on. Are there any arguments against this being default? Hi, It's been discussed previously here [1] with nack from cmake-utils.eclass maintainers and general conclusion that's too expensive to write to stdout :/ If you're gonna make it happen this time, I'll owe you a beer... Cheers, Kacper [1] http://archives.gentoo.org/gentoo-dev/msg_1b58b577fde07f7735ae6b9eb34885be.xml signature.asc Description: OpenPGP digital signature
[gentoo-dev] Bug trackers for gcc porting bugs
Hi all, this is just a friendly reminder: please *always* block bug reports related to packages failing with gcc against proper tracker bugs[1][2]. They are aliased as 'gcc-4.x' to make your life easier. This greatly decreases amount of work required for later stabilization/keywording. TIA! Cheers, Kacper [1] https://bugs.gentoo.org/show_bug.cgi?id=346809 [2] https://bugs.gentoo.org/show_bug.cgi?id=390247 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Bug trackers for gcc porting bugs
On 04/30/2012 11:50 AM, Kacper Kowalik wrote: Hi all, this is just a friendly reminder: please *always* block bug reports related to packages failing with gcc against proper tracker bugs[1][2]. They are aliased as 'gcc-4.x' to make your life easier. This greatly decreases amount of work required for later stabilization/keywording. TIA! Cheers, Kacper [1] https://bugs.gentoo.org/show_bug.cgi?id=346809 [2] https://bugs.gentoo.org/show_bug.cgi?id=390247 One additional remark. It would be superb if you could resolve those bug by indicating the version of package with fixes. Extract from ChangeLog would suffice, e.g. +28 Apr 2012; Davide Pesavento p...@gentoo.org + +files/qt-webkit-4.8.1-no-use-ld-gold.patch, qt-webkit-4.8.1.ebuild: + Fix build with gcc-4.7 (bug 411849 by Andrew John Hughes and Nicolas + Schlumberger). instead of: Fixed in CVS Cheers, Kacper signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-python/xsv
# Kacper Kowalik xarthis...@gentoo.org (28 Apr 2012) # No longer maintained upstream, superseeded by # dev-python/lxml, bug 396497 # Masked for removal in 30 days. dev-python/xsv signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: global USE tcmalloc
Hi, seems more and more software starts to use this: dev-db/drizzle:tcmalloc dev-db/haildb:tcmalloc dev-db/redis:tcmalloc dev-lang/ruby-enterprise:tcmalloc dev-libs/libmemcached:tcmalloc sys-cluster/gearmand:tcmalloc - Use the dev-util/google-perftools libraries to replace the malloc() implementation with a possibly faster one. I'm about to add sys-cluster/ceph to that list Cheers, Kacper signature.asc Description: OpenPGP digital signature
[gentoo-dev] [RFC] enable verbose build whenever it's possible
Hi, I'd like to ask that we enable verbose building by default. I have cmake-utils.eclass in mind, because it's dead easy there, but there's a lot of packages that support things like make V=1 or make VERBOSE=1 too. I've seen too many bugs reports today that gave me cute, colorful build.logs and almost no information about underlaying bug... Cheers, Kacper signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] enable verbose build whenever it's possible
W dniu 05.11.2011 18:04, Michał Górny pisze: On Sat, 5 Nov 2011 12:05:15 +0100 Ulrich Mueller u...@gentoo.org wrote: On Sat, 05 Nov 2011, Kacper Kowalik wrote: I'd like to ask that we enable verbose building by default. I have cmake-utils.eclass in mind, because it's dead easy there, but there's a lot of packages that support things like make V=1 or make VERBOSE=1 too. I've seen too many bugs reports today that gave me cute, colorful build.logs and almost no information about underlaying bug... In fact, there's already bug 379497 [1] open for this. Some build systems might use the variable V for something else, so adding --disable-silent-rules may be the safer solution. Of course --disable-silent-rules is the way to go for autotools based packages. Yeah, please use the correct configure opt rather than throwing in random makevars. I don't want to throw any vars blindly to emake. V=1 was just an example that I've seen in some packages' build systems. It was more like a proposal to use whatever build system of given package provides. Cheers, Kacper signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] enable verbose build whenever it's possible
On 11/05/11 21:00, Maciej Mrozowski wrote: On Saturday 05 of November 2011 09:58:00 Kacper Kowalik wrote: Hi, I'd like to ask that we enable verbose building by default. I have cmake-utils.eclass in mind, because it's dead easy there, but there's a lot of packages that support things like make V=1 or make VERBOSE=1 too. I've seen too many bugs reports today that gave me cute, colorful build.logs and almost no information about underlaying bug... That's usually because users sometimes attach only relevant parts of build log (well, relevant according to their taste = last lines, even when they use parallel compilation). Any particular example of bug report with entire build log from cmake-utils in fancy mode, and still being unable to locate the problem? I ask, because we're appending summary just after configure phase to make vorbose logging of whole build process unecessary. Yeah take bug 297699 as an example and relavant snippet: [0m[31m[1mLinking CXX executable eqsl [0m[ 22%] CMakeFiles/eqsl.dir/eqsl.cxx.o: In function `callback(char const*)': eqsl.cxx:(.text+0x192a): undefined reference to `Fl::lock()' eqsl.cxx:(.text+0x1ef1): undefined reference to `Fl::unlock()' As we don't see actual linking we cannot immediately tell what libraries were linked and rule out/diagnose as-needed issue. As I cannot even reproduce the bug right now I can only rely on clairvoyance to figure what happened there... Cheers, Kacper signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Shutdown of berlios
W dniu 29.10.2011 11:39, Tomáš Chvátal pisze: Hi guys, as you probably know berlios is going to be shut down at the end of the year so we should probably find/create alternative download locations for the packages in the main tree. The attached list provide all those with mirror://berlios so if you are interested in some of those packages, or know upstream try to convince them to use sourceforge or other hosting that should suit their needs. If the upstream is dead I have no clear idea what to do, but maybe infra could set-up something download.gentoo.org where we could keep all the files with their sums and gpg sign from us gentoo devs to ensure their validity. I am sending this mail now because from now on we should have 60 days to prepare - just ~2 packages day should solve the issue :) Would be easier if you told us who should fix what you lazy bum. Fixed in attached list. Prolly I should have opened a bug instead, but I'm lazy too :P Cheers, Kacper sign...@gentoo.org app-emulation/x48 nim...@gentoo.org app-portage/conf-update darks...@gentoo.org app-portage/eix dertobi...@gentoo.org app-portage/etc-proposals flamee...@gentoo.org app-text/unpaper hwoar...@gentoo.org app-text/u2ps sp...@gentoo.org media-gfx/splashutils bil...@gentoo.org sys-fs/fatsort hd_bru...@gentoo.org www-misc/xxv BY HERD: accessibility app-accessibility/festival-ru base-system sys-apps/gscanbus sys-apps/rename cjk app-i18n/xsim cpp dev-cpp/libebt crypto app-crypt/tpm-emulator desktop-misc app-office/rubrica x11-misc/slim x11-misc/suxpanel x11-misc/treeline x11-themes/gtk-engines-candido x11-themes/slim-themes dev-embedded dev-embedded/openocd dev-embedded/usbprog embedded dev-embedded/bitbake x11-libs/tslib games games-arcade/supertux games-emulation/dboxfe games-emulation/gngeo games-emulation/gnomeboyadvance games-emulation/hatari games-puzzle/enigma games-server/pvpgn games-simulation/lincity-ng games-strategy/netpanzer gnome app-crypt/gringotts graphics media-gfx/gimmage media-gfx/mirage media-libs/lensfun gstreamer media-sound/soundconverter kde kde-misc/kio-ftps lcd app-misc/lcd-stuff maintainer-n...@gentoo.org app-dicts/qvortaro dev-libs/libsmtp media-optical app-cdr/b5i2iso app-cdr/cuecue app-cdr/cuetools app-cdr/iat app-cdr/serpentine media-tv media-plugins/vdr-softdevice x11-themes/xxv-skins mobile net-wireless/bcm43xx-fwcutter net-wireless/wifi-radar net-dialup net-dialup/radiusclient-ng net-mail net-mail/fetchmail netmon net-analyzer/nast net-news net-news/rsstool net-p2p net-p2p/gift-ares net-p2p/gift-fasttrack nx net-misc/nxcl net-misc/nxsadmin net-misc/qtnx ppc sys-apps/lsadb python dev-python/iconvcodec dev-python/utidylib dev-util/spe net-wireless/python-wifi qt dev-tex/qtexengine ruby dev-ruby/ncurses-ruby sci media-libs/emfengine sci-libs/liborigin sci-misc/vitables sci-visualization/qtiplot sci-chemistry sci-libs/pycifrw sci-geosciences sci-geosciences/gpsd sci-geosciences/mapnik sci-mathematics sci-mathematics/snns sound app-accessibility/festival-ru media-libs/phat media-sound/canorus media-sound/gbsplay media-sound/gimmix media-sound/gpodder media-sound/horgand media-sound/sonata tex app-text/winefish video media-video/griffith media-video/guvcview media-video/lxdvdrip media-video/transcode media-video/ttcut media-video/vdr2jpeg voip net-misc/sipsak wxwidgets dev-util/codeblocks xen app-emulation/xen-tools signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Moving more hardening features to default?
W dniu 20.10.2011 10:47, Paweł Hajdan, Jr. pisze: I've noticed http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags, i.e. Debian is starting to make more and more hardening features default, at least for most packages. Should we start doing that too? What are possible problems with that? It seems like it's mostly about USE=hardened, right? Hi, just a bunch of quick questions from a hardened newbie: 1) Is there are reason to do it beside Debian is going to do it? 2) What's wrong with current approach i.e. having seperate hardened profile? 3) What are the benefits for an average desktop user or high-performance cluster? While answering that, please skip things obvious like having more secure box. Cheers, Kacper signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-lang/open64
Masked since 25.05.2011, current version is not working. Pending removal in 30 days # Michael Sterrett mr_bon...@gentoo.org (25 May 2011) # Needs an old version of bison that isn't in the tree anymore. dev-lang/open64 Cheers, Kacper signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rite: sys-block/iscsi-initiator-core-tools
# Kacper Kowalik xarthis...@gentoo.org (19 Aug 2011) # Ancient, obsolete, last release in 2006, practically unmaintained # Bugs: 198621 # Pending removal in 30 days sys-block/iscsi-initiator-core-tools signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rite: sys-fs/unionfs
# Kacper Kowalik xarthis...@gentoo.org (08 Aug 2011) # Ancient, doesn't work with modern kernels, never stable # and practically unmaintained # Bugs: 165559, 165749, 171967 # Pending removal in 30 days sys-fs/unionfs signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?
W dniu 01.08.2011 13:12, Marc Schiffbauer pisze: * Samuli Suominen schrieb am 01.08.11 um 09:23 Uhr: On 07/31/2011 05:23 PM, Michał Górny wrote: On Sat, 30 Jul 2011 16:55:23 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: I dislike the IUSE=+static some packages are currently doing to workaround this, instead of moving the needed shared libs to / I dislike the idea of pciutils and usbutils database(s) in non-standard location in / to keep udev working I dislike the idea of moving libglib-2.0, libdbus-1, libdbus-glib-1, and couple of dozen more libs to / I dislike the idea of maintaining and keeping track of the files in / using files from /usr. Does any of the PMs have check for this, like NEEDED entries? I can imagine this getting past the maintainers easily otherwise Most likely still not seeing the full picture here, and just scratching the surface... Despite that, I don't have any strong opinion on any of this, just need to know if I should start moving the files over Honestly, I'd rather see system libs and apps being moved to /usr rather than the opposite. IMO the benefit of getting a clear tree is greater than benefits of having separate fs for 'system' and 'non-system' packages which actually tend to randomly depend one on another. that's my impression now too since nobody has managed to provide useful case for separate /usr, or they have been very vague like adding 1+1 on / and /usr filesystem sizes and counting the risk of corrupted filesystem from that (one word: backup) and even then they can go with dracut and have the initramfs mount the /usr before init dracut with it's externsive modules covers the other mentioned cases too I'm responding to this particular mail cause it's last in queue and because it replicates things already mentioned before. I am a zeleous follower of having seperate /usr partition, thus seeing moot arguments that goes in favour of my case is pretty annoying. * For example if a filesystem fills 100%. Imagine your /usr is 100% full by accident. Thats bs, cause / can fill out even when you have /usr seperate. Even faster cause usually you've got very small / like 1Gb. You miss one thing that accidentally writes to / and you're as much toasted. * IMO its a good idea to seperate mostly static filesystems from those with many writes How mering / and /usr increase that? What prevents you having separate partition for heavy write areas inside /usr ? * Some people want a read-only /usr Yes, that's only reasonable argument here. * /usr/portage can get very huge and is often written to. With / and /usr being on the same FS you really want to have /usr/portage on a seperate FS then Even with separate /usr it's good to have separate partition for /usr/portage. You can have partition with small blocks and large no. of inodes this way. How does that prevents merging / and /usr ? Cheers, Kacper signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?
W dniu 30.07.2011 15:55, Samuli Suominen pisze: On 07/30/2011 01:46 PM, Ciaran McCreesh wrote: On Sat, 30 Jul 2011 10:27:27 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: Since running separate /usr without mounting it from initramfs on top of / before init is and has been broken with udev for a long time now[1][2][3] [1] http://bugs.gentoo.org/show_bug.cgi?id=364235 [2] http://fedoraproject.org/wiki/Features/UsrMove#Move_all_to_.2Fusr [3] http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken Can we warn users about not doing the separate /usr mistake in the handbook? It's important to consider the timeline here. Separate /usr was accidentally broken by a sudden increase in dependencies from base system packages to desktopy things. It was only later that certain people decided that oh, separate /usr is a bad idea anyway, and they did so because they couldn't figure out how to fix the mess they'd caused. This is very much a case of carelessly letting the horse escape and then trying to convince everyone that no-one needs a horse anyway... Someone mentioned NFS mount on /usr. Do we have other reasons? How many users that might be? That covers headless/diskless clusters and I suspect many people still do that. Cheers, Kacper signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] net-misc/pimd RFC for new ebuild
W dniu 19.07.2011 19:31, Donnie Berkholz pisze:
On 11:43 Sun 17 Jul , Kacper Kowalik wrote:
W dniu 17.07.2011 10:45, Kfir Lavi pisze:
src_compile() {
emake CC=$(tc-getCC) || die
}
Some systems export CC as gcc -m64.
I guess I'm a little confused here. What exactly is the problem and fix
you're proposing? You stopped halfway through, there should've been a
part at the end that said:
, so you need to do XX to avoid YY from happening.
Use quotes: CC=$(tc-getCC). Without it you could get emake CC=gcc -m64
and that would of course fail.
Apologies for mental leap...
Cheers,
Kacper
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] net-misc/pimd RFC for new ebuild
W dniu 19.07.2011 20:40, Mike Frysinger pisze:
On Tue, Jul 19, 2011 at 14:32, Kacper Kowalik wrote:
W dniu 19.07.2011 19:31, Donnie Berkholz pisze:
On 11:43 Sun 17 Jul , Kacper Kowalik wrote:
W dniu 17.07.2011 10:45, Kfir Lavi pisze:
src_compile() {
emake CC=$(tc-getCC) || die
}
Some systems export CC as gcc -m64.
I guess I'm a little confused here. What exactly is the problem and fix
you're proposing? You stopped halfway through, there should've been a
part at the end that said:
, so you need to do XX to avoid YY from happening.
Use quotes: CC=$(tc-getCC). Without it you could get emake CC=gcc -m64
and that would of course fail.
CC=gcc -m64 is a fairly questionable setting in the first place
(you're most likely doing something wrong/stupid already),
I've encountered it only once - during prefix bootstrap [1], but it did
bite me in the ass back then. Exactly because somebody forgot to quote
CC during emake invocation :)
Cheers,
Kacper
[1]
http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/scripts/bootstrap-prefix.sh
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] net-misc/pimd RFC for new ebuild
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
W dniu 17.07.2011 10:45, Kfir Lavi pisze:
Hi,
I have created a new ebuild for net-misc/pimd [1].
From the webpage:
pimd is a lightweight stand-alone PIM-SM v2 multicast routing daemon.
I would like you guys to review the ebuild and the rc-file.
This ebuild is based on net-misc/mrouted.
EAPI=2
Please use latest eapi when introducing new ebuilds
inherit eutils toolchain-funcs
where do you use 'eutils.eclass'?
DESCRIPTION=Lightweight stand-alone PIM-SM v2 multicast routing daemon
HOMEPAGE=http://vmlinux.org/jocke/pimd.shtml;
SRC_URI=ftp://ftp.vmlinux.org/pub/People/jocke/${PN}/${P}.tar.bz2;
LICENSE=Stanford
Is that a correct license? Compare LICENSE.mrouted with
${PORTDIR}/licenses/Stanford and then with BSD.
SLOT=0
KEYWORDS=~amd64 ~x86
IUSE=+doc
Where do you use doc flag?
DEPEND=|| ( dev-util/yacc sys-devel/bison )
RDEPEND=
Is yacc or bison really invoked during build? (Check either Makefile or
TODO ;) ) Assuming it isn't those two lines are unnecessary.
CONFIG_CHECK=~IP_PIMSM_V2:
WARNING_BRIDGE=CONFIG_IP_PIMSM_V2 is required for pimd
these are not used.
src_prepare() {
# Respect user CFLAGS, remove upstream optimisation and -Werror
sed -i Makefile \
-e '/^CFLAGS/{s|[[:space:]]=| +=|g;s|-O2||g;s|-Werror||g}' \
|| die
}
It would be more legible if you convert it to patch.
src_compile() {
emake CC=$(tc-getCC) || die
}
Some systems export CC as gcc -m64.
src_install() {
dobin pimd || die
...
All those helpers could be easily avoided.
src_install() {
emake DESTDIR=${D} prefix=/usr \
datadir=/usr/share/doc/${PN} install || die
newinitd ${FILESDIR}/pimd.rc pimd
}
Only don't install unnecessary docs:
sed -i -e s/INSTALL LICENSE LICENSE.mrouted// Makefile
Please note that there's already bug for that pkg[1] it would be good if
further development would be done there.
Cheers,
Kacper
[1] https://bugs.gentoo.org/show_bug.cgi?id=352848
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iJwEAQECAAYFAk4irrgACgkQIiMqcbOVdxTfXAP/VAZi6HwGPRQrCzYTJ840brkb
+KVBHUunzd+dML0m24oiq5CmR31SuYIpj4qXvsXuYYL2A2kK1N8R/A7KOcZ4MaGw
BkltP/crrLJU6qHnTVrEXLE2SEYUxAGbTw2D4Lx0DE3jkLtikNDp/I2D0bS3aK9l
/kuMMZp89zx293OeTBo=
=QQI+
-END PGP SIGNATURE-
Re: [gentoo-dev] More signing problems
W dniu 14.07.2011 12:31, Thomas Kahle pisze: Hi, When doing automatted committing during stabilization, I recently started seeing manifest signing fail like this: gpg: pkglue.c:41: mpi_from_sexp: Assertion `data' failed. !!! !!! gpg exited with '6' status !!! Disabled FEATURES='sign' The curious thing: It works most of the time, but fails sometimes. I don't know how to trigger the behaviour. Any ideas? Cheers Thomas Problem reported here: http://www.gossamer-threads.com/lists/gnupg/gcrypt/55063 and fixed upstream +10pts for Arfrever :) Cheers, Kacper signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Please review fortran-2.eclass next round
W dniu 17.06.2011 05:03, Mike Frysinger pisze:
DEPEND=virtual/fortran
RDEPEND=${DEPEND}
i'm not sure that RDEPEND is correct. do all fortran compilers additionally
require the fortran compiler to be available at runtime ?
They require fortran runtime library if they don't link it statically.
Cheers,
Kacper
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 W dniu 16.05.2011 15:41, Mark Loeser pisze: Mike Frysinger (vapier) vap...@gentoo.org said: vapier 11/05/16 03:30:02 Removed: bzip2-1.0.5-r1.ebuild Log: old Please document removal of ebuilds in ChangeLogs. http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/ It'd also be better to do this all as one commit and run repoman with each commit. Thanks, I don't understand the purpose of such mails (it's 2nd within the period of few days). Council have already voted that those changes should be added to changelog so there's nothing technical to discuss. As for the conflict resolution the policy states: 1) try to resolve the issue among yourselves 2) consult with the project lead (QA?) 3) if all fails go to devrel Neither of those points include sending mail to gentoo-dev, which tend to quickly convert into the witch hunt and seldom lead to anything conclusive. Cheers, Kacper -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iJwEAQECAAYFAk3RZMwACgkQIiMqcbOVdxRGuAP+JHinAeoeYqSxAqfjqcP5Q922 Jr8E4IPPpazlVUeWrtg2uHOIShkHQI8l5djiJ7mnsVGkRooPibX4ndX9rHLkwErH XahKTnHiUPSl1qoMr6f5fyqjQQ7O6dvpVXpT9O6g1/lyRmbnTB2dj6ts5trO88XL n7ehyPhupEewFjGAjbU= =Lvvm -END PGP SIGNATURE-
[gentoo-dev] Last rites: dev-python/cgal-python
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 # Kacper Kowalik xarthis...@gentoo.org (29 Apr 2011) # Fails to build with gcc 4.5. It doesn't work with latest cgal # Bugs 320543, 344723 # Removal in 30 days dev-python/cgal-python Cheers, Kacper -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iJwEAQECAAYFAk27A5QACgkQIiMqcbOVdxQMXAP9EnW19LazCoudkk20BQIxDtQ7 8e4y9LrFld2KYHNG3MKNOxVwLXtelOnTAk37WYaTTsjOu7Cl5QNZsPLA6SbPWEnp LWQwckRuo2K+89jN9ihJ1GzPQ8Jjf11KkiXyjmpfAE9uZWOmTGnYx6bbwRylVhhO +lsZEVQ6m4EJVIebx3o= =Co3+ -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: package.keywords-compatible snippets when stabilizing multiple packages
W dniu 14.02.2011 18:52, Paweł Hajdan, Jr. pisze:
On 2/14/11 3:07 PM, Tomáš Chvátal wrote:
Same does x11 team...
Example:
http://bugs.gentoo.org/show_bug.cgi?id=354237
I think this does not need any policy, most teams can use brains and
fill the bugs quite conveniently :)
Well, that's the entire point. For the bug you cited, and - for another
example - http://bugs.gentoo.org/show_bug.cgi?id=353434 I can't just
copy-paste something to my package.keywords file.
The table is indeed pretty, and it has value, but I'm just asking for a
bit more convenience.
bugz attachment 262031 -v | grep ' ppc ' | awk '{print =$1}' -
/mnt/ppc32/etc/portage/package.keywords
bugz attachment 262031 -v | grep ' ppc64 ' | awk '{print =$1}' -
/mnt/ppc64/etc/portage/package.keywords
Erhm, how more convinient it can be?
Cheers,
Kacper
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Touching profiles
W dniu 03.02.2011 08:39, Torsten Veller pisze: * Theo Chatzimichos tampak...@gentoo.org: For the record, Kacper told me today that every developer is allowed to touch ppc/ppc64 profiles. Archies that don't want others to touch their profiles should mention it in the devmanual. I was not aware of that, I thought that !arch member is not allowed to touch arch-specific profiles. Just to be clear I was talking about package.mask file. Kitten-forbid you tweak e.g. make.defaults. Honestly, I don't see the reasons why dev should be forbid to *add* pkgs to package.mask file for other profiles that inherit base. *Removing* is quite different, but again common sense advise you shouldn't lift it until reason for masking is gone. That you cannot verify if you're not an arch member. The situation is complicated: snip - Some arch teams don't want other devs to touch their profiles: DON'T TOUCH THIS FILE. Instead, file a bug and assign it to... But this arch is neiter mentioned in the handbook nor in the manual: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=5#doc_chap4 http://devmanual.gentoo.org/archs/index.html Clearly if something is written in bold and at the very top of the file you should respect. I'm sure there are reasons for it and I've never seen that particular arch being unresponsive. - The devhandbook[2] is also kind of unmaintained. Devmanual and -handbook are waiting for a merge AFAIR. - And there is already a stalled bug[3] about Developer Handbook should document how/when to touch arch profiles' files Summary: You do it wrong either way. The problem actually boils down to asking... Arch team members are out there on irc, have mail aliases, etc. This very thread was started due to lack of communication. It could have looked like that: KDE: I would like to unmask KDE-4.6.0 in base, but that requires mask in ppc64/package.mask. Can I do it? PPC64: Sure, go ahead. and it would have taken approx. 30s Cheers, Kacper signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion: Portage should not mask packages globally, but only for some arches
W dniu 02.02.2011 08:59, Nikos Chantziaras pisze:
It seems that KDE 4.6 is still hard-masked for x86 and amd64 because
it's waiting for ppc and ppc64 keywords. I believe it would be
beneficial for people if they wouldn't have to wait for arches that
don't affect them at all.
It seems better if the packages can be unmasked for x86 and amd64 and
only kept hard-masked for ppc/ppc64 while they wait for keywords.
Otherwise, all arches will feel the effect of the slowest one without
there being a need for this.
I don't know what gave you the idea that ppc* has anything to do with
masking/unmasking of KDE-4.6. Just 2 facts:
1) you can unmask anything by using /etc/portage/package.unmask,
therefore nothing can ever hold *you* back
2) arches already have independent package.mask files, see
${PORTDIR}/profiles/arch/powerpc/package.mask for an example.
Best regards,
Kacper Kowalik
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Rating STABLEREQ bugs
Hi, I would like to discuss proposal that is loosely connected to Slacker arches thread. Could we please start using Priority field in b.g.o? Rationale: 1) I've started to receive mails in which Dev. E. Loper is delighted that I've just stabled pkg A, but it would be really cool if stabled B instead, which is gravely important, whereas A not so much. 2) Increasing P on unattended bugs, could increase ATs attention. 3) I would very much like to see user requested STABLEREQ 30 days and 1sec have passed, no problems kind of bugs. Cheers, Kacper signature.asc Description: OpenPGP digital signature
[gentoo-dev] Lastrite: media-libs/gle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 # Kacper Kowalik xarthis...@gentoo.org (06 Jun 2011) # Masked for removal in 30 days by QA request, abandoned by upstream 7 yrs ago, # bug #350635, no reverse dependencies in tree. Ebuild will be kept after # removal in xarthisius' overlay media-libs/gle -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iJwEAQECAAYFAk0lkLIACgkQIiMqcbOVdxTpNAP/VADaPSpCPoqB0v8NsjyGONgr Os5GaY+DJ/3GGkFaT0jCTA9WQT5y67YsmqZJF027A64RMbjbSuOsef18nunpXV1b nVlB+QLrLwn7O6HmQwC9g/JFbgYJM41+yEGXDA9RIlMeR1jxIuEFZ4rxjWp3mSSd Bvzpu0I2s5tjnyTp0ss= =ToSo -END PGP SIGNATURE-
[gentoo-dev] Lastrite: sys-cluster/tentakel
# Kacper Kowalik xarthis...@gentoo.org (28 Dec 2010) # Masked for removal in 30 days, abandoned by # upstream, bugs #238796, #241344, #316941 # Use sys-cluster/gsh as an replacement sys-cluster/tentakel signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Please move your packages to virtual/jpeg
W dniu 08.11.2010 13:25, Daniel Pielmeier pisze: Easy would be if you had added the maintainers to that list :) Updated list: app-admin/analog herds=no-herd maintainers=maintainer-nee...@gentoo.org (This package lacks a primary herd or maintainer.) app-admin/reportmagic herds=no-herd maintainers=Default assignee for orphaned packages maintainer-nee...@gentoo.org app-admin/testdisk herds=forensics maintainers=Robin H. Johnson robb...@gentoo.org (Primary maintainer) forens...@gentoo.org app-crypt/steghide herds=no-herd maintainers=maintainer-nee...@gentoo.org app-editors/emacs herds=emacs maintainers= app-editors/ted herds=no-herd maintainers=Harald van D?k true...@gentoo.org app-editors/xemacs herds=xemacs maintainers=xem...@gentoo.org (Primary Maintainer) app-emulation/crossover-office-pro-bin herds=wine maintainers= app-emulation/qemu-kvm herds=qemu maintainers= app-emulation/spice herds=no-herd maintainers=Tiziano M?ller dev-z...@gentoo.org app-emulation/vice herds=games maintainers= app-misc/tracker herds=freedesktop maintainers= app-office/abiword herds=gnome-office maintainers= app-office/abiword-plugins herds=gnome-office maintainers= app-text/mupdf herds=no-herd maintainers=Michael Weber x...@gentoo.org dev-games/clanlib herds=games maintainers= dev-games/crystalspace herds=games maintainers= dev-games/irrlicht herds=games maintainers= dev-games/neoengine herds=games maintainers= dev-games/openscenegraph herds=games maintainers= dev-java/icedtea herds=java maintainers=Andrew John Hughes gnu_and...@member.fsf.org (Proxy Maintainer) Vlastimil Babka cas...@gentoo.org (Commiter (CC me)) dev-java/icedtea6-bin herds=java maintainers= dev-lang/php herds=php maintainers= dev-lang/pike herds=no-herd maintainers=Luis F. Araujo ara...@gentoo.org dev-lang/R herds=sci-mathematics maintainers= dev-lang/swi-prolog herds=prolog maintainers= dev-libs/DirectFB herds=games maintainers= dev-libs/pslib herds=printing tex maintainers= dev-ml/camlimages herds=ml maintainers= dev-ml/gd4o herds=ml maintainers= dev-perl/GD herds=perl maintainers= dev-perl/Tk-JPEG-Lite herds=perl maintainers= dev-python/pyds herds=python maintainers= dev-python/wxpython herds=python wxwidgets maintainers= dev-ruby/ruby-gd herds=ruby maintainers= dev-scheme/plt-scheme herds=scheme maintainers= dev-tcltk/blt herds=tcltk maintainers= dev-tcltk/tkimg herds=tcltk maintainers=S?bastien Fabbro bicat...@gentoo.org (Feel free to take over) dev-util/dialogblocks herds=no-herd maintainers=Alin Nastac mrn...@gentoo.org dev-util/gource herds=no-herd maintainers=Enrico Tagliavini enrico.tagliav...@gmail.com (Proxied co-maintainer) flamee...@gentoo.org dev-util/helpblocks herds=no-herd maintainers=Alin Nastac mrn...@gentoo.org dev-vcs/cvsgraph herds=cvs-utils maintainers=Lance Albertson ramer...@gentoo.org games-action/armagetronad herds=games maintainers= games-action/openastromenace herds=games maintainers= games-arcade/bumprace herds=games maintainers= games-arcade/mtp-target-bin herds=games maintainers= games-arcade/stepmania herds=games maintainers= games-arcade/tuxpuck herds=games maintainers= games-emulation/gcube herds=games maintainers= games-emulation/generator herds=games maintainers= games-engines/gargoyle herds=games maintainers=Michele Noberasco s4...@gentoo.org games-fps/alienarena herds=games maintainers= games-fps/darkplaces herds=games maintainers= games-fps/nexuiz herds=games maintainers= games-fps/openarena herds=games maintainers= games-fps/qudos herds=games maintainers= games-fps/tremulous herds=games maintainers= games-fps/warsow herds=games maintainers= games-puzzle/neverball herds=games maintainers= games-rpg/freedroid herds=games maintainers= games-rpg/freedroidrpg herds=games maintainers= games-simulation/secondlife-bin herds=games maintainers= games-sports/gracer herds=games maintainers= games-sports/xmoto herds=games maintainers= games-strategy/asc herds=games maintainers= games-strategy/savage2-bin herds=games maintainers= games-strategy/savage-bin herds=games maintainers= games-strategy/scorched3d herds=games maintainers= games-strategy/ufo-ai herds=games maintainers= games-util/atlas herds=games maintainers= gnome-extra/gnome-web-photo herds=gnome maintainers=Markos Chandras hwoar...@gentoo.org kde-base/gwenview herds=kde maintainers= kde-base/krdc herds=kde maintainers= kde-base/libkdcraw herds=kde maintainers= kde-base/libkexiv2 herds=kde maintainers= kde-base/okular herds=kde maintainers= mail-filter/spamprobe herds=net-mail maintainers= media-gfx/argyllcms herds=no-herd maintainers=Andreas K. Huettel dilfri...@gentoo.org media-gfx/autopano-sift-C herds=graphics maintainers= media-gfx/blender herds=graphics maintainers=Luca Barbato lu_z...@gentoo.org media-gfx/dcraw herds=no-herd maintainers=Peter Volkov p...@gentoo.org Wolfram Schlich wschl...@gentoo.org (Primary maintainer) media-gfx/digikam herds=kde maintainers=dilfri...@gentoo.org media-gfx/enblend herds=graphics maintainers= media-gfx/eog herds=gnome maintainers=
Re: [gentoo-dev] Re: [Bug 142517] sys-fs/unionfs-1.3 fails on error: invalid operands to binary
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 W dniu 11.09.2010 15:38, Jeroen Roovers pisze: 1) OK, we have someone anonymously using bugs.gentoo.org in an official capacity? I don't think this is a good idea. 2) This bug was RESOLVED/FIXED 4 years ago. There is absolutely no reason to reassign it now. However did this, consider signing in with a personal address and stop making those changes to closed bugs. For the record it was me. I admit it (mass reassignment) was stupid thing to do. Once again I am terribly sorry for that spam/load I introduced. Won't happen again. Best regards, Kacper Kowalik -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iJwEAQECAAYFAkyLibAACgkQIiMqcbOVdxSkgwP+NeId8T1lQfgW20h70Cynwskk Ia3yaQTBYGuxTjrkg83yzn8yP40tKHz7bTN/kmR1YeSNROQXwVmYf/B5LgRFSEdo 2CBJ5Pfw5ZCyNNt6kensZSEc0456AbnlqnJD0l9hblFR/XRVDMpaKI8O4NimqkfM u+hC1+WAlojuZbhZwQQ= =WG7+ -END PGP SIGNATURE-
Re: [gentoo-dev] USE=doc for .pdf's ? (WAS: Re: [gentoo-commits] gentoo-x86 commit in sci-astronomy/kapteyn: metadata.xml ChangeLog kapteyn-1.9.2.ebuild)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 W dniu 13.07.2010 22:04, Jeremy Olexa pisze: global:doc: Adds extra documentation (API, Javadoc, PDFs at maintainer's discretion, etc) I think you missed API here. I don't really see the difference between bunch of html files and one 8Mb pdf file. In most cases the former are not build either, yet they are doc flag dependent. Cheers, Kacper Kowalik -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iJwEAQECAAYFAkw8zPYACgkQIiMqcbOVdxTQogP+Ki4Ik61GfT0zsRJ/bKN86pnR PGQehSEapEoyG0qcUUbc4kXKqYxsO6oyVpTMNTZq3vCLPyALjM3/oOlcP9/Rh3Lh t6iw7jgA29iz+pF204WZ4ACPG+74libf0hZf6Gw2npgMA6MWPRSpRmAv8rBIoOrZ nS4FZFtmOxyaOhmnyAI= =ro1B -END PGP SIGNATURE-
[gentoo-dev] Last rites: sci-geosciences/vis5d+
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 # Kacper Kowalik xarthis...@gentoo.org (24 Jun 2010) # Last release in 2002. fails with --as-needed Bug 248356 # Build system beyond repair, automagic dependency on Tcl # Fails to build with fortran # # masked for removal in 30 days sci-geosciences/vis5d+ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iJwEAQECAAYFAkwjRxQACgkQIiMqcbOVdxTzfAP6AjsoUyG1bmWCz1wpWy+3VYC/ uMYRvkbxuQZVfllQH0QgxKsZo81O6DDaL3UYxFRnS2DlsIGU35oUyyX1VvSo2Ao9 noBMsPaOTfc5OxLhtbPBtAA6Xlelst6oFFfAV1Og7hOJPVFZhMa/0gPQcLr6x1GP awhOnijLNSTTAJx1ehM= =7JDL -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs -- xmerlin, yoswink, chtekk, omp, tantive, mueli, bluebird, hncaldwell, caleb
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 W dniu 11.06.2010 21:12, Ben de Groot pisze: app-text/wgetpaste -- this is now maintainer-needed! I would like to grab it Also, my proxy-maintainers will need new contacts: x11-wm/echinus - anyone from desktop-wm still active? Alive kicking, we'll gladly proxy it for Nico Best regards, Kacper Kowalik -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iJwEAQECAAYFAkwSjfIACgkQIiMqcbOVdxSR+AP7Bo5GPnHwjBKjnmbZVRp0BM6t 1cIT5YwvRQ9CmJjf9Zd5wNLNAOgPSgTRcbL4jJcWDvo9zk3KizCzh36wVg2LVlw1 y59oJcbR1x2WOmHbHhBHk5eQH1Dq/WW+nOs7JMF6bAL58SKXQwDaDW+jbLQM4u51 tQ/AbrwY+fqx4acnx9o= =t2Ne -END PGP SIGNATURE-
