Hey people, what are we going to do with bugs like:
https://bugs.gentoo.org/show_bug.cgi?id=421839
https://bugs.gentoo.org/show_bug.cgi?id=445848
I'd like to help with things. Is the process of building livecd .isos
and stages documented somewhere? I'd like to reproduce problems locally,
work on
# Tomáš Chvátal scarabeus@ (04 Nov 2012)
# Masked for testing with gcc-4.7 and to verify reverse deps
dev-libs/icu-49.9.1
I think with icu-50.1-r2 the problems are solved. It should get more
testing in ~arch. I'd like to unmask it.
WDYT?
signature.asc
Description: OpenPGP digital signature
On 12/9/12 1:17 PM, Brian Dolbec wrote:
Starting from a question by Markos in #gentoo-portage about whether to
remove entries in profiles/updates for tree-cleaned packages...
What's the advantage of doing that?
I propose that we say, once a year, schedule a tree-cleaning of old
updates
On 12/7/12 11:51 PM, Diego Elio Pettenò wrote:
Sounds good to me. Tinderbox was fine with the latest changes to icu.
Just for reference, next time it would be nice to unmask this when chromium
and libreoffice are both bumped (i.e., two days ago), so that people don't
have to rebuild them
On 12/17/12 2:11 AM, Tomáš Chvátal wrote:
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.
Fully seconded.
On 12/17/12 2:19 AM, Tomáš Chvátal wrote:
With respect to reality how stuff is done in the linux land all the
variable data should be in /var so we should adjust and move it in
there too.
What would you think?
Fully seconded.
+1 to /var/cache/portage and having distfiles outside of the
On 12/17/12 7:32 AM, Anthony G. Basile wrote:
So what should I teach? Here's what I've got off the top of my head:
Please comment. If it gets systematized enough, it can be a guide to
future devs too. Everything will be creative commons.
I think it's worth to mention somewhere that although
On 12/20/12 7:21 PM, Doug Goldstein wrote:
I'm curious who had the brain dead idea to retire Gentoo developers
that are still interested in the distro, that maintain low activity
packages for herds that are stretched way too thin, and are still
contributing to the distro in many ways other
On 12/29/12 5:24 PM, Mike Frysinger wrote:
rough poll: how many people actually care about nscd ? i'm making it into a
USE flag for glibc-2.17 and it's easiest for me to do IUSE=nscd which means
it'd default to off.
If you want, you can still enable the nscd USE flag in the profile so it
is
On 1/1/13 2:51 AM, Dirkjan Ochtman wrote:
IMO it would probably be good to limit our CA roots to Mozilla's
libnss selection by default and perhaps add a packaged selection of
secondary CA's (like CACert) for those who are so inclined.
I think that's a good idea: make it easy to only use the
It came up again with https://bugs.gentoo.org/show_bug.cgi?id=449918,
and I think it's worth to think about a better fix. I still keep hitting
mysterious collisions with orphaned files from time to time.
How about switching the developer profile from collision-protect to
protect-owned, and
On 1/6/13 8:30 AM, Diego Elio Pettenò wrote:
I just gave a quick look at the init scripts installed on the tinderbox,
and the amount of them that use mkdir to create the directories in /run
and similar is astounding.
Please check `man runscript` and use the checkpath helper instead.
Should
On 1/4/13 9:47 PM, Donnie Berkholz wrote:
I did much of the design work nearly 2 years ago:
http://dev.gentoo.org/~dberkholz/gentoo_website/gentoo_landing_black.png
http://dev.gentoo.org/~dberkholz/gentoo_website/gentoo_landing_install.png
On 1/6/13 5:31 PM, Robin H. Johnson wrote:
Just a heads up,
DNSSEC is now live on *.dev.gentoo.org hosts.
Wow, that sounds pretty cool to me!
This could be a nice news: Gentoo one of the first to deploy DNSSEC -
what do you think? :)
Paweł
signature.asc
Description: OpenPGP digital
Please review attached automatically generated stabilization candidates
for January.
I don't want to annoy people with automatically filed bugs, and at the
same time I also received lots of positive feedback about the effort to
keep the stable tree more up-to-date.
I think the best way to
I'm trying to make Chromium be more compatible with more versions of
ffmpeg:
https://groups.google.com/a/chromium.org/d/topic/chromium-dev/fm5Oe_AC3Sc/discussion
(although not stated there, that includes libav).
Now the initial response there is not enthusiastic (which doesn't
surprise me), but
On 1/15/13 3:36 PM, Andreas K. Huettel wrote:
several people have pointed out to me that the 10.0 - 13.0 transition would
be a good moment to finally remove the (also in my opinion rather useless)
server profiles.
The easiest way to do this would be to
* just not copy the server
On 1/15/13 4:55 AM, Alexis Ballier wrote:
On Mon, 14 Jan 2013 20:34:42 -0800
Paweł Hajdan, Jr. phajdan...@gentoo.org wrote:
I'm trying to make Chromium be more compatible with more versions of
ffmpeg:
https://groups.google.com/a/chromium.org/d/topic/chromium-dev/fm5Oe_AC3Sc/discussion
On 1/16/13 8:40 AM, Alec Warner wrote:
Google generally prefers agility. Particularly when machines have gobs
of memory (so bundling is not as big of a deal as it was previously)
and they can staff security fixes for all their bundled libs. This is
quite a pervasive attitude there. Coming from
On 1/15/13 4:55 AM, Alexis Ballier wrote:
On Mon, 14 Jan 2013 20:34:42 -0800
Paweł Hajdan, Jr. phajdan...@gentoo.org wrote:
I'm trying to make Chromium be more compatible with more versions of
ffmpeg:
https://groups.google.com/a/chromium.org/d/topic/chromium-dev/fm5Oe_AC3Sc/discussion
On 1/20/13 1:46 AM, Luca Barbato wrote:
On 19/01/13 20:10, Paweł Hajdan, Jr. wrote:
have a way to more simply exclude code that requires CODEC_ID_OPUS.
Exclude in chrome or in libavcodec?
The latter is a matter of adding --disable-decoder=opus and/or not
--enable-libopus in the configure
On 1/12/13 11:49 PM, Paweł Hajdan, Jr. wrote:
Please review attached automatically generated stabilization candidates
for January.
Oops, today I've tried my _separate_ script to file stabilization bugs
based on a generated list of packages to support that workflow.
Now the bug is that the list
On 2/11/13 11:14 PM, Michał Górny wrote:
My patches introduce a single wrapper with argv-as-parameter syntax.
That is, the fore-mentioned example would look like:
virtualx run_tests --foo
Maybe we can just adapt Ubuntu's (I think) xvfb-run? More
standardization == profit.
Thank you
On 2/13/13 12:28 AM, Robin H. Johnson wrote:
On Wed, Feb 13, 2013 at 12:12:35AM +0100, Michael Weber wrote:
What is the rotation strategy for (near) outdated keys?
Alter the key or create a new one? Sign the new with the old one?
If your keysize is still good, you should ideally update the
On 2/26/13 4:39 PM, Pavlos Ratis wrote:
I would like to announce you a new try to 'revive' the Bugday event.
This is excellent! Thank you for your work on this.
I have listed some maintainer-wanted and maintainer-need bugs and
Bugzilla admins also re-enabled the bugday flag. I would like to
On 4/6/13 11:08 AM, Michał Górny wrote:
1. Patches have to be either in unified or context diff format. Unified
diff is preferred.
Are there any other formats than unified and context diff? If not, it'd
be like another for indoor or outdoor use only or home or office use
- i.e. no need to
On 4/6/13 12:41 PM, Michał Górny wrote:
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.
That could be helpful - could this be made more precise though? Is there
any
On 4/9/13 10:15 PM, Mike Frysinger wrote:
i plan on updating the latest glibc to add USE=suid. in pkg_preinst and
ROOT==/, the ebuild will read /proc/mounts for a devpts line with gid=5. if
it doesn't find one, i'll have it call `die`. if the bsd pty scenario wasn't
long dead, and the
On 4/30/13 8:25 PM, Ryan Hill wrote:
I'm also going to rename the test flag to regression-test or something
similar to get it out of FEATURES=test control. The testsuite is a huge
time-suck and only useful to developers IMO (always expected to fail and
primarily meant to be used to check for
On 5/1/13 3:04 AM, Fabio Erculiani wrote:
It is sad to say that the territoriality in base-system (and
toolchain) is not allowing any kind of progress [3] [4]. This is
nothing new, by the way.
[4] useless crap: https://bugs.gentoo.org/show_bug.cgi?id=399615
As far as I read the bug, Mike
On 5/5/13 6:20 AM, Jeroen Roovers wrote:
On Sat, 04 May 2013 19:49:03 +0200
viv...@gmail.com viv...@gmail.com wrote:
(Also, why do a revision bump and leave
the stable revision unfixed?)
but this:
because automake-1.13 is _not_ stable an because there are enough
changes to risk to break
On 5/8/13 2:56 AM, Andreas K. Huettel wrote:
the deptree of kde-base has been broken for over two months now (most likely
more, it was already bad for a while when I filed bug 460532), and we cannot
really commit new KDE releases without repoman --force option.
A package is missing keyword
On 5/19/13 6:40 AM, Jeroen Roovers wrote:
Private messages and public comments through bugzilla are so far
ignored, it seems, so let's try a venue where it's sure to cause a
flamewar instead. My apologies for the inconvenience.
Hey Jeroen, apologies if I have ignored any of your feedback.
On 5/20/13 5:10 AM, Gilles Dartiguelongue wrote:
That would explain why you're still filling gnome stabilization bugs
while we replied many times we don't want them in their current form ?
If you're still getting bugs from my script it's a bug in my script,
sorry about that. Could you post the
On 5/21/13 6:38 AM, Thomas Sachau wrote:
And if a maintainer is not responding within 30 days, you can ping him
or, without a response, try to get a different maintainer. Just assuming
that a stable request is ok without a maintainer response is really not
a good idea.
Thomas, this effort is
On 5/21/13 1:17 PM, Alexis Ballier wrote:
On Tue, 21 May 2013 20:51:52 +0100 Markos Chandras
hwoar...@gentoo.org wrote:
I'd rather not see this process changes, because it has helped
bringing the stable tree up2date. However, given that *a few*
people don't like it, I suggest you don't file
On 5/25/13 12:45 PM, Mike Gilbert wrote:
You may see small (~60 seconds) difference when compiling Chromium due
to faster target dependency resolution.
You may also see faster builds in general because ninja is designed for
very high degree of parallelization as compared to make.
From a
On 6/9/13 7:22 AM, Alex Legler wrote:
I'd appreciate some input on below plan to move project pages to the Wiki:
Alex, thanks for working on this! Some feedback:
1. How will the project pages be protected against unwanted edits? I
think it's valuable to have some official pages where you know
On 6/12/13 11:51 PM, Dirkjan Ochtman wrote:
Still seems like working in gentoo-x86 without doing stabilization
would cover most of those bases. Working in the unstable main tree is
still a lot better than keeping stuff out there in an overlay, IMO.
+1
This works really well for the Gentoo
On 6/16/13 12:36 AM, Alexander V Vershilov wrote:
In this is a continuation of a 'gentoo-haskell' sub-thread I have to say that
Chromium and co. it not a development library this is a end user application.
End user applications should be in tree (except for some testing reasons), if
not just
Today an interesting thing happened to my repoman, as I was committing a
change:
Creating Manifest for /home/ph/gentoo-x86/dev-lang/v8
gpg: no default secret key: Unusable secret key
gpg: /home/ph/gentoo-x86/dev-lang/v8/Manifest: clearsign failed:
Unusable secret key
!!! !!! gpg exited with '2'
On 6/20/13 2:16 AM, Michał Górny wrote:
Doing test signatures won't cover all failures.
Do you know an example? The only one I'm aware of is when a test
signature is made very close to the expiration date, and then the real
signature would be done after it.
IMHO the best thing to do would be
On 6/30/13 3:03 PM, Thomas Kahle wrote:
dev-cpp/gtest is Google's testing framework. According to upstream it
is supposed to be shipped as source code and then compiled by the build
system of the software that should be tested. In particular it should
be compiled with exactly the same flags.
On 7/24/13 8:31 AM, Alex Alexander wrote:
On Wed, Jul 24, 2013 at 10:15:51AM -0400, Mike Gilbert wrote:
Actually, Portage normally handles this situation gracefully by using
the dependencies from the portage tree instead of vdb. However, in the
case of a slot-operator dep, it always uses vdb.
On 7/24/13 5:53 PM, Rick Zero_Chaos Farina wrote:
On 07/24/2013 03:18 PM, Ciaran McCreesh wrote:
On Wed, 24 Jul 2013 21:17:26 +0200
Michał Górny mgo...@gentoo.org wrote:
Other thing is that Portage explicitly ignores PMS in this matter
and uses dependencies from ebuilds rather than recorded
About one month ago I've filed
https://bugs.gentoo.org/show_bug.cgi?id=474358 about modernizing
toolchain.eclass by creating new toolchain-r1.eclass and migrating
ebuilds using it to the new eclass.
Please see attachments and review the code.
One issue has already been raised, and it's
Currently USE=system-ffmpeg is masked for stable www-client/chromium
ebuilds. However, recently a new enough media-libs/ffmpeg has been
stabilized, making it possible to use system ffmpeg in stable.
I'd like to make the change close to a new version of chromium being
stabilized so that less
On 7/26/13 9:50 AM, Diego Elio Pettenò wrote:
Does this still allow me to use libav? If not I'd like to veto it.
You can still use libav - either unmask it or USE=-system-ffmpeg.
Paweł
signature.asc
Description: OpenPGP digital signature
On 7/26/13 9:13 PM, Rick Zero_Chaos Farina wrote:
On 07/27/2013 12:08 AM, Matt Turner wrote:
Can we make autobuilds go to /experimental and then only move them to
/releases when someone actually tests them?
Very interesting. :) I had a similar idea. I think it's great.
Looking at bugzilla
On 5/20/13 9:58 AM, Paweł Hajdan, Jr. wrote:
On 5/20/13 5:10 AM, Gilles Dartiguelongue wrote:
This generally needs to go first so sorting by summary shows your
packages in order and you have a chance to see this part of the summary
in bugzilla (with version optionally), the rest of the summary
On 8/12/13 10:21 PM, heroxbd wrote:
As a natual consequence of the on-going Google Summer of Code project,
Gentoo on Android[3], we can run native Gentoo on *all* the Android
devices. Compiling out an Xorg and output to HDMI has no theoretical
difficulty. Furthermore, sharing of graphic output
On 8/13/13 8:39 AM, Alexis Ballier wrote:
Your arguments make sense but you should also consider it the other
way: When you are maintaining a package properly by forwarding patches
upstream, having $randomdev jumping in, adding a patch, and letting you
clean up the mess is kind of annoying.
On 8/20/13 3:26 AM, Michał Górny wrote:
I've added a few new fancy features for Gentoo developers to portage
git. Sadly, since Zac isn't planning another release until 2.2.0 goes
stable, you need to switch to - to use them. But I say to you, it's
worth the hassle.
I'd really appreciate
On 8/20/13 11:19 AM, William Hubbs wrote:
During the last release of OpenRC, I learned that people *do* run
production servers on ~arch. I asked about it and was told that the
reason for this is bitrot in the stable tree.
People frequently point to lack of manpower as reason for this, but I
On 8/27/13 3:01 AM, Michał Górny wrote:
b) assume that early src_fetch() is allowed to fail and retry before
build. This is much like what portage does anyway. If VCS is not
installed yet during parallel fetch or --fetchonly, the particular
fetch fails like it can fail due to 404. When the
Just small, very small comments. To avoid being accused of bikeshedding,
I'm totally fine if you don't apply any of them. It's entirely up to you. :)
https://bugs.gentoo.org/show_bug.cgi?id=480826 :
if use directfb ; then
# since DirectFB can link against SDL and trigger a
On 9/20/13 9:27 AM, Michał Górny wrote:
Putting another includedir is even worse kind of band-aid. If we're to
put them in a directory, I'd rather require 'more complete' includes,
like:
#include openrc/rc.h
Otherwise, you're just fighting conflicts in the scope of a single
On 9/15/13 10:01 AM, William Hubbs wrote:
All,
here is another question wrt OpenRC's api.
Currently we store two header files (rc.h and einfo.h) in /usr/include.
Since we have more than one include file, wouldn't it be standard
practice to store them in a sub directory of /usr/include?
On 9/20/13 12:24 PM, Diego Elio Pettenò wrote:
As Michał said.
Please consider updating the documentation - ebuild(5):
RESTRICT = [strip,mirror,fetch,userpriv]
This should be a space delimited list of portage features to
restrict. You may use conditional syntax to vary
On 9/21/13 8:42 AM, Mike Gilbert wrote:
GRUB2 will be stabilized soon (bug 455544). Here's a draft of a news
item to hopefully prevent any confusion. Please review.
Great news! Thanks for working on this, and it basically works
(chainloaded for now, see below) on my x86 system.
Some general
I'd like to get your feedback and opinion about removing shared v8
library package from Gentoo. It's currently used by www-client/chromium,
dev-db/drizzle, dev-db/mongodb, dev-lang/v8cgi and sci-geosciences/osgearth.
net-libs/nodejs switched back to bundled v8 a long time ago:
25 Feb 2013;
On 9/21/13 1:19 PM, Mike Gilbert wrote:
I wasn't able to reproduce this in qemu. It is possible that GRUB's
graphical terminal driver has some issues with VMWare.
However, have a Gentoo box at work that runs GRUB2 on VMWare ESX, and
I don't recall having any display issues on the console.
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
On 9/25/13 2:44 AM, Diego Elio Pettenò wrote:
On Tue, Sep 24, 2013 at 7:46 PM, Paweł Hajdan, Jr.
phajdan...@gentoo.orgwrote:
Perfect.
Seriously? Perfect because one person agrees with you?
Sigh.
Look at the API breaks and talk to v8 upstream - if you have a better
solution to actual bugs
On 9/25/13 1:16 AM, Peter Volkov wrote:
But could you comment on how hard it'll be to slot v8 shared library?
Keeping libraries bundled is a security nightmare.
Slotting v8 would be hugely impractical and rather a misuse of SLOTs.
Slotting makes sense when there are at most 2-3 major versions,
On 9/25/13 9:01 AM, Ian Stakenvicius wrote:
However, if it's possible to keep the rest of the tree using one
system package of v8 (or very small subset), and just maintain
that(those) via security backports, would that be viable?
In the current state of v8, no.
Latest security-supported v8 is
On 1/14/10 1:49 PM, Nirbheek Chauhan wrote:
Besides this, there is the problem of accommodating people who use a
subtree of gentoo-x86, and those who don't want the entire CVS history
on their hard drives. In summation, robbat2 needs *our* help in the
following:
a) Push functionality in
On 1/17/10 6:57 PM, Vaeth wrote:
On Sun, 17 Jan 2010, Paweł Hajdan, Jr. wrote:
I wonder why the affected package (eselect-opengl) couldn't run
lafilefixer itself. It's mandatory for all users, and would save a lot
of frustration.
It is not mandatory: You could as well re-emerge the affected
On 1/17/10 7:28 PM, Krzysiek Pawlik wrote:
On 01/17/10 18:20, Paweł Hajdan, Jr. wrote:
Please: When you run tools which break checksums/dates of the database,
give the user the possibility to decide whether he really wants this.
Good point, I didn't realize that. However, I'd rather fix
On 1/24/10 5:51 PM, Petteri Räty wrote:
There should be no legitimate reason for the number to go up so please
whenever bumping ebuilds, remove the usage of built_with_use.
How about adding a repoman check for that?
Paweł
signature.asc
Description: OpenPGP digital signature
papering over the real problem, but
the good side is that it'd make running with FEATURES=test much easier.
By the way, for packages that fail the test suite and refuse to disable
it, I change the env locally so that FEATURES=-test (via /etc/portage/env).
Paweł Hajdan jr
signature.asc
Description
On 2/21/10 10:40 AM, Thilo Bangert wrote:
Paweł Hajdan, Jr. phajdan...@gentoo.org said:
The concern here may be that it's papering over the real problem, but
the good side is that it'd make running with FEATURES=test much easier.
which is a good thing, since more tests will be run. RESTRICT
On 2/21/10 10:11 AM, Paweł Hajdan, Jr. wrote:
On 2/21/10 5:08 AM, Ryan Hill wrote:
I have one simple request. When you make a non-trivial change to an ebuild -
a patch, a version bump, anything that can effect the behaviour of the
package - please run the test suite.
Yeah, on my dev box I
On 2/22/10 2:01 PM, Gilles Dartiguelongue wrote:
Le dimanche 21 février 2010 à 10:53 +0100, Paweł Hajdan, Jr. a écrit :
$ tree /etc/portage/env
/etc/portage/env
|-- app-portage
| `-- portage-utils.env
|-- dev-libs
| |-- boost.env
| `-- libevent.env
|-- dev-python
| `-- pygtk.env
run chmod 755 ${base}
eerror and try again.
die unable to read ${base}
fi
Thanks,
Paweł Hajdan jr
signature.asc
Description: OpenPGP digital signature
.
occuring only with non-UTF-8 locales should be reported directly to upstream
nit: occuring - occurring
Paweł Hajdan jr
signature.asc
Description: OpenPGP digital signature
and possible co-maintaining herds are CC-ed.
Anyway, I don't have a strong opinion about any of these, just prefer a
simplicity of the rules.
Paweł Hajdan jr
signature.asc
Description: OpenPGP digital signature
?
The elected Gentoo Council decides on global issues and policies that
affect multiple projects in Gentoo.
Paweł Hajdan jr
signature.asc
Description: OpenPGP digital signature
to
be the most common use case.
Anyway, the earlier the user can react to USE flags conflict, the better.
Paweł Hajdan jr
signature.asc
Description: OpenPGP digital signature
-sources some love.
Of course that would mean getting included in
hardened-ker...@gentoo.org, but I guess it's the easiest part.
Paweł Hajdan jr
signature.asc
Description: OpenPGP digital signature
On 4/3/10 11:16 AM, Tobias Scherbaum wrote:
Hell no, but ...
We have lots of quite understaffed areas, to sum up in a positive way.
Summing it up the negative way one might say, we have lots of areas were
users might get the idea Gentoo already is dead.
For example:
- hardened-sources
On 4/3/10 12:03 PM, Krzysztof Pawlik wrote:
On 04/03/10 10:50, Petteri Räty wrote:
I don't think later is valid resolution. If there's a valid bug it just
means it's never looked at again. If the bug is not valid then a
different resolution should be used. So what do you think about
disabling
I'd like to add a package for spin to the tree (it's used at several
universities, including mine and Caltech).
However, it's not straightforward. The basic license is for educational
purposes only.
Here are my suggestions how to implement that.
/usr/portage/licenses/spin-educational with the
, but was
confused why they are separate. I think I've seen similar comments from
other developers.
I think I'd rather prefer merging the quizzes.
Paweł Hajdan jr
signature.asc
Description: OpenPGP digital signature
icon theme packages in the tree could be added to that.
The suggested description would be Virtual for desktop environments'
icon themes.
Suggested herd would be freedesktop.
What do you think?
Paweł Hajdan jr
signature.asc
Description: OpenPGP digital signature
On 4/11/10 9:54 PM, Petteri Räty wrote:
On 04/11/2010 10:38 PM, Paweł Hajdan, Jr. wrote:
What do you think about creating a new virtual package, icon-theme?
This would for example simplify the dependencies for
www-client/chromium, which currently uses this:
What other packages would make
To make it easier to find stabilization bugs with arch-testers'
comments, I'd like to add new flags to Gentoo bugzilla.
This is only an initial idea, and maybe a different implementation would
be better (like the status whiteboard, if it's easily searchable).
Initially, I'd like a new flag
On 4/26/10 12:34 PM, Matti Bickel wrote:
On 04/26/2010 11:40 AM, Paweł Hajdan, Jr. wrote:
To make it easier to find stabilization bugs with arch-testers'
comments, I'd like to add new flags to Gentoo bugzilla.
Can you explain how the TESTED Keyword is not sufficient for your
goal
get enough data from the above to produce a
good bug report for ccache.
What actions would you suggest?
Paweł Hajdan jr
signature.asc
Description: OpenPGP digital signature
On 4/29/10 9:41 AM, Robin H. Johnson wrote:
On Thu, Apr 29, 2010 at 09:06:51AM +0200, Paweł Hajdan, Jr. wrote:
What actions would you suggest?
Have your user do a binary search of the ccache dir to find which cache
file is causing the problem, by restoring from his backup then renaming
half
On 5/10/10 7:27 PM, Samuli Suominen wrote:
Should we advise users to do something like:
find /usr/lib -name '*.la' | xargs sed -i -e '/^dep/s:-lpng12:-lpng14:'
lafilefixer --justfixit is easier to remember. Does it work equally well?
Paweł
signature.asc
Description: OpenPGP digital
On 5/10/10 7:42 PM, Samuli Suominen wrote:
On 05/10/2010 08:34 PM, Paweł Hajdan, Jr. wrote:
On 5/10/10 7:27 PM, Samuli Suominen wrote:
Should we advise users to do something like:
find /usr/lib -name '*.la' | xargs sed -i -e '/^dep/s:-lpng12:-lpng14:'
lafilefixer --justfixit is easier
On 5/14/10 3:54 PM, Matti Bickel wrote:
From my work on b.g.o: I use a simplified version of this, shown at:
http://dev.gentoo.org/~mabi/gentooBzLifecycle.png
Yeah, I think the linked diagram really reflects the reality, much
better than the official one. I'm in favor of removing the Verified
On 6/3/10 3:32 PM, Markos Chandras wrote:
And maybe it would be a wise move to merge/remove some herds because ,as I
see, the number of herds is equal ( or even higher ) to the number of
developers.
Here are some more empty herds:
1) kerberos herd is empty :(
2) secure-tunnelling is empty
3)
What do you think about doing the following change in
/usr/portage/profiles/targets/developer/make.defaults:
replace test with test-fail-continue to make it just less
frustrating (we still have a lot of test failures)
Hopefully that will also make more of us use the developer profile, and
detect
On 6/4/10 5:35 PM, Jesus Rivero (Neurogeek) wrote:
I've been thinking about this for a while. Some packages have tests
that are meant only for upstream in certain conditions
and are not meant to be ran during installing.
I think that in extreme cases src_test should not call such tests.
As
On 6/7/10 12:10 PM, Thilo Bangert wrote:
as it seems, there is disagreement about the issue among developers.
Perhaps the council would like to settle this, so that we can go on with
our lives.
i do agree, that all packages should build successfully including the test
phase. RESTRICTing
On 6/4/10 5:11 PM, Paweł Hajdan, Jr. wrote:
What do you think about doing the following change in
/usr/portage/profiles/targets/developer/make.defaults:
The following change has now landed in CVS:
Index: targets/developer/make.defaults
On 6/11/10 5:27 AM, Robin H. Johnson wrote:
- Ability to split woodpecker/dev.g.o up, and have an EU dev machine,
and a US dev machine. (If mail isn't being forwarded outside of our
systems, you would put in ${userna...@eu.dev.gentoo.org.
Sounds good to me. Looks like it would have lower
On 6/13/10 6:35 PM, Michał Górny wrote:
But who's talking here about moving abandoned ebuilds just to keep
them? I'd wanted just to make it simpler to switch the 'maintainership'
from Gentoo devs to Sunrise users, when the second are ready to
maintain the ebuild well.
Can you suggest a
1 - 100 of 505 matches
Mail list logo
