On 8/12/10 11:29 AM, Eray Aslan wrote:
It is perfectly legal to clear /var/run across reboots. Below is a bug
from a user that ran into some trouble because an init script assumes that
/var/run/package/ exists for its PID file:
Can we add a repoman check for that?
signature.asc
On 8/10/10 11:09 PM, Christian Faulhammer wrote:
PaweA Hajdan (phajdan.jr) phajdan...@gentoo.org:
pkg_postinst() {
einfo Example usage (.emacs):
einfo (require 'google-c-style)
einfo (add-hook 'c-mode-common-hook 'google-set-c-style)
einfo (add-hook 'c-mode-common-hook
On 8/8/10 6:22 PM, Paweł Hajdan, Jr. wrote:
I'd like to suggest a cleanup of our Get Gentoo page. It is one of the
more important pages, because every new user has to visit it.
http://dev.gentoo.org/~phajdan.jr/where.xml
Okay, let's get some decisions on it.
Joshua Saddler raised some
If you are a Gentoo developer and are using www-client/chromium, please
consider joining the Chromium in Gentoo project:
http://www.gentoo.org/proj/en/desktop/chromium/index.xml
You don't need to modify or bump packages to join. In fact, I'm rather
looking for good testers. We have some bugs to
On 8/16/10 5:29 PM, David Abbott wrote:
I can but just want to make sure this is what everyone wants;
http://dev.gentoo.org/~dabbott/pr/where.xml
I got that from http://dev.gentoo.org/~phajdan.jr/where.xml
Looks fine to me I am ready to commit, just say so and its done.
Looks good to me.
On 9/8/10 12:03 PM, Michał Górny wrote:
We already have a variety of use_*() functions with their specific
uses. But what I miss is a single, simple and universal use_echo()
function, behaving similarly to ?: operator in C. In other words, a
simple function replacing monsters like:
On 9/10/10 4:18 AM, Markos Chandras wrote:
I plan to create a patch for this[1] page and poke devrel for that
[1]: http://www.gentoo.org/proj/en/devrel/staffing-needs/
Actually, you just need to add some tags to your project page and the
Staffing Needs page gets automatically updated after
On 9/11/10 11:03 AM, Jonathan Callen wrote:
Just as a proof-of-concept, here's one implementation of such a
function, allowing for an arbitrary number of arguments:
use_echo() {
while [[ $# -gt 1 ]]; do
if use $1; then
echo $2
On 9/11/10 11:51 AM, justin wrote:
is the following comment an adequate way to close bugs with
RESOLVED/INVALID? If so, I will change the way I handle bugs and use it too.
virtual/os-headers: 2.6.35 (sys-kernel/linux-headers)
ACCEPT_KEYWORDS=amd64
you mix stable unstable - your
On 9/19/10 9:14 PM, Matti Bickel wrote:
So, yeah, what do you think? Is it worth it?
I second this GLEP. It seems like it will cleanly replace our hacked
eblits implementations from packages like php, glibc, and possibly more.
Also, it will allow more code sharing between ebuilds, which is
On 9/20/10 7:30 PM, Alec Warner wrote:
How does it provide more code sharing than the existing system?
Previously I could put code I wanted shared:
1) In a global eclass, which means any ebuild in the tree can likely use it
A global eclass is quite heavyweight. It requires a review on
I was just looking at some random ebuilds recently, and noticed this
snippet in gcc-4.5* ebuilds:
SSP_STABLE=amd64 x86 ppc ppc64 arm
# uclibc need tls and nptl support for SSP support
SSP_UCLIBC_STABLE=
Please note how the #-starting comment is inside the SSP_STABLE variable
declaration. It
$ euse --info system-sqlite
global use flags (searching: system-sqlite)
no matching entries found
local use flags (searching: system-sqlite)
[-] system-sqlite
Today I got http://bugs.gentoo.org/340517 filed against chromium-bin.
The machine that compiled the package had only gcc-4.4.3 installed.
It'd probably be difficult to solve the problem using dependencies (the
bug reporter had gcc-4.4.3 installed, but active version was 4.3.4).
I was thinking
On 10/28/10 7:42 PM, Mike Frysinger wrote:
Il giorno lun, 25/10/2010 alle 18.50 -0300, Alexis Ballier ha scritto:
Am I missing something obvious or is it just hiding a bug in the
linux
headers? I see no usage of INT_MAX in the patched .c file...
the maintainer already has done his due
On 10/27/10 1:05 PM, Diego Elio Pettenò wrote:
Il giorno mer, 27/10/2010 alle 12.49 +0200, Paweł Hajdan, Jr. ha
scritto:
Some context first. Upstream does not promise any binary compatibility
between releases, so each version has a different SONAME, if any.
That's a good approach (although
On 10/27/10 8:59 PM, James Rowe wrote:
* Paweł Hajdan, Jr. (phajdan...@gentoo.org) wrote:
There is one issue that keeps dev-lang/v8 in hard mask and prevents its
broader usage (I think www-client/chromium could start using it).
Thanks for working on this. I use v8 quite a bit, and being
On 10/29/10 1:03 PM, Markos Chandras wrote:
1) I want to drop the warning message located on profile.bashrc files
e.g $PORTDIR/default/linux/amd64/10.0/server/profile.bashrc
It is more than obvious what this profile is for so I don't think this
message makes any sense.
ewarn This profile has
On 10/29/10 1:24 PM, Markos Chandras wrote:
On Fri, Oct 29, 2010 at 01:18:14PM +0200, Paweł Hajdan, Jr. wrote:
ewarn This profile has not been tested thoroughly and is not considered to
be
ewarn a supported server profile at this time. For a supported server
If the above is no longer true
On 10/29/10 6:29 PM, Markos Chandras wrote:
Furthermore the message about glibc-2.4 and gcc-4.1 looks rather obsolete.
At least this part has to be removed/changed
Fine for me.
signature.asc
Description: OpenPGP digital signature
On 11/2/10 4:24 AM, Rafael Goncalves Martins wrote:
I think that a first step should be create a new category, maybe
called dev-lua, for all the Lua related stuff.
Just checking: how many packages would be in the new category?
Generally sounds good.
signature.asc
Description: OpenPGP
On 11/4/10 6:40 PM, Mark Loeser wrote:
Please do remove the flag. The fact that there are some ebuilds in the
tree that use it does not make it alright to introduce more.
Yeah, the he's doing that too bad excuse...
But there is a right point in that: why QA doesn't just commit fixes to
the
On 11/7/10 8:51 PM, Jory A. Pratt wrote:
As some of you are aware libjpeg-turbo is in the tree, with v8 support.
We will not keyword for any archs until we officially add the 1.1
release that is not avaliable as of yet. If we all use virtual/jpeg we
can ensure that the user has the right to
On 11/10/10 4:10 PM, Markos Chandras wrote:
Ping. 130 bugs again
If there are no objections, I will update the staffing needs page with
info that we need more bug wranglers.
I think we have clear indication there are not enough people wrangling
bugs, and we should just recruit them.
Paweł
On 11/14/10 8:36 PM, Petteri Räty wrote:
The IA64 arch team does not have the resources to maintain Java support so we
agreed that support will be dropped unless more man power becomes available.
Could you also add the info to
http://www.gentoo.org/proj/en/devrel/staffing-needs/ ?
Moreover,
On 11/15/10 11:20 AM, Christian Faulhammer wrote:
* reducing your keyword set (stable-wise) to a relative small subset
and rethink your normal testing keywords.
I think there is a related point here: when you start with a minimal
stable set, it's easy to extend that set later.
However, if
On 11/15/10 8:19 AM, Paweł Hajdan, Jr. wrote:
On 11/10/10 4:16 PM, Markos Chandras wrote:
On Wed, Nov 10, 2010 at 04:14:28PM +0100, Paweł Hajdan, Jr. wrote:
If there are no objections, I will update the staffing needs page with
info that we need more bug wranglers.
Please do. Thanks
I have
On 10/29/10 11:33 AM, James Rowe wrote:
* Paweł Hajdan, Jr. (phajdan...@gentoo.org) wrote:
I'm curious: do you have some more ebuilds using v8? It'd be great to
add them to the portage tree at some point, if possible. Or maybe
sunrise overlay...
We took the easy way out and chose Debian
On 11/25/10 2:59 PM, Alexis Ballier wrote:
I fail to understand why you claim that live ebuilds are a QA nightmare, you
may want to have a look at how I play with, eg, ffmpeg or vlc and their live
ebuilds: they make version bumps much easier and far less error prone.
I'm just curious. Could
On 11/25/10 4:07 PM, Alexis Ballier wrote:
By following closely upstream development you are able to adapt the live
ebuild to the current status, eg, for new deps. Usually with vlc, when a new
major version comes out, there are a couple of new features and a couple of
outdated features
On 11/29/10 12:45 PM, Sebastian Pipping wrote:
Sorry to hear. Please put a line like
USE_PYTHON=2.6 2.7 3.1
into /etc/make.conf. It sounded like that's the versions you want.
Is that documented anywhere? I couldn't find it easily on gentoo.org in
the docs.
Paweł
signature.asc
On 11/29/10 1:42 PM, Markos Chandras wrote:
*sigh*, Planet is not a place to inform users about these things. How
about a -dev-announce or even better a news item.
IMHO a news item is not much better. All users who install later than
some date will not see the news item (by design).
USE_PYTHON
On 12/1/10 9:13 PM, Alec Warner wrote:
How does a developer know when the stage generation is broken? Is
there a dashboard? At work we have a guy who is basically a build cop
and checks our build dashboard once a day or so and if it is broken he
goes and finds the guy who broke it and
On 12/1/10 9:34 PM, Joshua Saddler wrote:
Catalyst sends automated emails to rel...@gentoo.org from the
various build boxes: dolphin, poseidon, other dev.g.o machines.
So we have some automatic reporting. Can we have a webpage for that, or
a mailing list that people can subscribe to?
Idea:
On 12/12/10 9:19 PM, Markos Chandras wrote:
However, I do not have the hardware to perform any kind of build
testing to this package because it requires a significant amount of
resources during compilation phase.
Note that Gentoo has some machines for development purposes, see
On 12/12/10 9:57 PM, Markos Chandras wrote:
Can you please tell me which box ( I'd prefer an amd64 one ) are you
using for chromium? If it is in a working state I will ask for access
again!
I'm using miranda.
signature.asc
Description: OpenPGP digital signature
On 12/15/10 2:54 AM, Jeroen Roovers wrote:
I am starting to wonder if this is helping. It looks like everyone now
attempts to keep it 100 on a daily basis, but not to far 100, which
means a lot of old, difficult, nasty bug reports are left unattended.
Still, I got it down to about two dozen
On 12/17/10 4:25 PM, Ciaran McCreesh wrote:
As a result of things like this, Portage has had various different sets
of heuristics over time, and Paludis has had a different set.
Generally it seems fine to have different heuristics (I'll comment on
the specific problem below).
Paludis
deprecate EAPI-2 in favor of EAPI-3, hmmm
I think a repoman non-fatal warning would be fine. If we have a warning
about forcing -j1, we can surely have one about ancient EAPIs.
Paweł Hajdan, Jr.
P.S. I'm excited to see the progress with PMS and new EAPIs being more
and more convenient
I've noticed at least two forums threads that suggest there might be a
bug resulting in automatic flip of system python to python3:
http://forums.gentoo.org/viewtopic-t-859654-highlight-.html
http://forums.gentoo.org/viewtopic-p-6541077.html
Do you think it may be a bug, and if so, how can we
On 1/16/11 2:49 PM, Ciaran McCreesh wrote:
Second, when performing updates, Paludis also rewrites dependencies of
installed packages to use the names.
This seems to imply that portage behaves differently. Should we update
PMS when we determine what's the correct behavior?
signature.asc
I've noticed we have a SECURITY keyword on bugs.gentoo.org, but only 79
bugs have it, and doesn't seem to be actively used, so it seems to only
add confusion.
What do you think about removing it?
signature.asc
Description: OpenPGP digital signature
On 1/17/11 6:00 PM, Christian Ruppert wrote:
All 79 bugs would need a fix then. We can't remove used keywords/groups
and so on.
Only two bugs with SECURITY keywords are still open:
On 1/18/11 2:45 PM, Torsten Veller wrote:
What sort of confusion does SECURITY add?
I started thinking about it when https://bugs.gentoo.org/351922 was
filed (this is only an example).
The SECURITY keyword is not applied consistently (~80 bugs total), but
the description says Add this on all
There was a discussion on irc about a package that called enewuser and
enewgroup from pkg_preinst. That made it fail on fresh install, because
the new user was needed at the src_install time (for ownership of the
installed files). However, if the user was already present on the
system, it was just
On 1/20/11 1:50 AM, Diego Elio Pettenò wrote:
If you produced the file yourself, and it doesn't matter if the file is
reproducible (unless it is reproducible to sha512 identity), please use
the public_html directory in your dev.gentoo.org home to host these.
This makes sure that the file won't
On 1/25/11 12:20 PM, Tomáš Chvátal wrote:
I would like to upgrade tree-wide policy for EAPI usage in main tree.
I have a great idea for you.
How about creating a project (possibly a subproject of QA or something
else) that would help people do that? In case of no response from
maintainers just
On 1/25/11 12:38 PM, Tomáš Chvátal wrote:
Every arch teams should stabilise OR write out reason why they can't do
so to stable bug in 90 days. If any arch team fails to do so the
maintainer can decide to drop their keywords to testing. Given depgraph
breakages the maintainer can coordinate
On 1/25/11 1:29 PM, Tomáš Chvátal wrote:
Why would we need subproject for this.
The idea was that if you want to introduce a new policy, you should also
provide resources to make it possible. The below satisfies most of that.
QA team itself is done to help developers with this tasks. So if
On 1/26/11 3:14 AM, Ryan Hill wrote:
On Tue, 25 Jan 2011 12:38:03 +0100 Tomáš Chvátal
scarab...@gentoo.org wrote:
Won't this just pile on more work on already stressed to the max arch
teams? As in, now they have to stabilize more packages to get back to
where they were in the first place?
On 1/28/11 10:11 PM, Tomáš Chvátal wrote:
So draft we would like to have implemented as Glep update is this diff:
http://dev.gentoo.org/~scarabeus/glep-0048.diff
I'd suggest to split the diff, discussion and voting to make it more
focused:
1) QA team lead, deputy, and accepting new members of
On 1/25/11 1:30 PM, Markos Chandras wrote:
QA is not a solution to everything. The problem Tomas is trying to
counter here is the idle/slacking arches. If the arch is active but have some
concerns regarding the stabilization then let the maintainer deal with
it. This is the way we do it now
From time to time there are stabilization bugs where the current stable
is broken. For example, https://bugs.gentoo.org/show_bug.cgi?id=353487
However, in theory that should not happen, because presumably the
current stable has been tested in the past and considered not broken.
Of course that
On 2/7/11 9:50 PM, Markos Chandras wrote:
My suggestion, as I said to fosdem, is to freeze, or take a
snapshot if you like, of the current tree, stabilize what you need to
stabilize, test the whole tree ( at least compile wise ) for a couple of
weeks and then replace the existing stable tree.
On 2/8/11 9:24 AM, Markos Chandras wrote:
On Mon, Feb 07, 2011 at 10:02:36PM +0100, Paweł Hajdan, Jr. wrote:
There are machines available for various arches at
http://www.gentoo.org/proj/en/infrastructure/dev-machines.xml. I have
at least a few chromium-related chroots on miranda, and I've
It seems that with glibc-2.13 there are some serious compatibility
issues. There are good warnings on the planet
(http://psykil.livejournal.com/340806.html), but not every ~arch user
reads the planet, so how about creating news item with detailed
instructions how to ensure smooth glibc-2.13 update
tl;dr - can we add more automated tests to auto-generated stages?
On 2/8/11 1:22 PM, Fabian Groffen wrote:
Hmmm, odd. I experience amd64 (stable) as being pretty stable on my
servers. Last breakage which really got me upset was php, but
that's already some time ago.
Makes sense. Most of
On 2/9/11 2:57 PM, Rich Freeman wrote:
Perhaps we should target having glsas published within a certain
amount of time after a vulnerability is disclosed, whether corrected
or not. We could re-publish a final notice once all is well. We
really shouldn't consider users safe from a security
On 2/9/11 10:33 PM, Fabio Erculiani wrote:
What would be the main goals of this installer?
Could you elaborate a high level description of it?
As I said in the past, beside some annoying deps, anaconda already
works for Sabayon and working on a pure Gentoo module would be quite
easy. In
not a maintainer of base-system, but it seems to me that such a
change in behavior would only add to the confusion. glibc behaving
differently on Gentoo than other distros... no, that doesn't sound good.
Paweł Hajdan, Jr.
signature.asc
Description: OpenPGP digital signature
On 2/11/11 1:06 PM, Sebastian Pipping wrote:
I was abe to downgrade glibc to 2.12.2 and my sound problem [1] is now
gone again!
Just curious, what downgrade method did you use? Just untaring an older
glibc package?
signature.asc
Description: OpenPGP digital signature
have we learned from libpng 1.2 - 1.4 upgrade? I'd just like to
be better informed.
Finally, it seems that hard work on --as-needed and automatic fixing of
.la files is going to make the upgrade experience better now, right?
Paweł Hajdan, Jr.
P.S. The 1.2 - 1.4 upgrade wasn't really bad for me
Sometimes there are very simple things we can do to make arch
developers' life easier. For example, when stabilizing multiple packages
it's very helpful to post a snippet that can be copy-pasted to
package.keywords, like in those bugs:
http://bugs.gentoo.org/show_bug.cgi?id=322791
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
On 2/14/11 9:13 PM, Samuli Suominen wrote:
And http://bugs.gentoo.org/show_bug.cgi?id=349053#c1 ? I tried to
provide a clue howto get usable p.keywords list easy.
IMHO it's in the middle. I still have to do a manual step, but at least
it's pretty straightforward. Anyway, I think a list that
On 2/15/11 9:10 AM, Gilles Dartiguelongue wrote:
I don't think making a list for each arch is going to make anything any
easier for maintainers requesting stabilization, which means those list
we need more time to generate before being released. You just move the
problem to another place.
I
There is a bug about www-client/chromium icon theme dependencies
(https://bugs.gentoo.org/show_bug.cgi?id=352263), and I'm not quite sure
what's the best way to solve it.
The main issue is that in KDE only oxygen-icons work, and in XFCE
oxygen-icons *don't* work and one needs other icon themes
for
creating fully versioned tarballs on Gentoo side.
As the package seems rather unmaintained, I'm going to wait for a while
and check in the ebuild if nobody is against that.
Any feedback is welcome, please let me know what you think.
Paweł Hajdan, Jr.
signature.asc
Description: OpenPGP digital
www-client/chromium-9.0.597.98
www-client/chromium-
www-client/chromium-bin-9.0.597.84
Latest ebuilds visible in ~arch should be fixed now. Older ebuilds
should get removed soon. If there's anything more to be done there,
please let me know.
Paweł Hajdan, Jr
Does anyone else want to comment on this?
On 2/25/11 5:43 PM, Mike Gilbert wrote:
On Fri, Feb 25, 2011 at 9:42 AM, Paweł Hajdan, Jr.
phajdan...@gentoo.org wrote:
Portage obviously doesn't know which DE the user is running (multiple
DE's may be installed on the system), so I don't see a way
# Pawel Hajdan jr phajdan...@gentoo.org (04 Mar 2011)
# Masked for removal in 90 days.
# Multiple hard to fix and time consuming maintenance problems:
# - history of bugs (bug #304527, bug #335101, bug #347175,
#bug #349249, bug #356609)
# - upstream's binary builds cannot be used on Gentoo
is interested in doing that, I second that effort.
Paweł Hajdan, Jr.
signature.asc
Description: OpenPGP digital signature
is the CONFIRMED status
vs. UNCONFIRMED. Still, I'm not sure whether we use UNCONFIRMED so much.
Anyway, it should be possible to add UNCONFIRMED on top of the new
workflow, right?
Paweł Hajdan, Jr.
signature.asc
Description: OpenPGP digital signature
, and UNCONFIRMED would still be there:
http://bugzillaupdate.wordpress.com/2010/07/06/bugzilla-4-0-has-a-new-default-status-workflow/
I'm in favor of the new workflow.
Paweł Hajdan, Jr.
signature.asc
Description: OpenPGP digital signature
On 3/7/11 1:05 PM, Hanno Böck wrote:
Am Sun, 27 Feb 2011 15:44:13 +0100
schrieb Paweł Hajdan, Jr. phajdan...@gentoo.org:
As the package seems rather unmaintained, I'm going to wait for a
while and check in the ebuild if nobody is against that.
Any feedback is welcome, please let me know
On 3/7/11 11:13 AM, Brian Harring wrote:
Re-read what he stated- it'll convert all existing NEW bugs to
CONFIRMED upon migration. There's a fair number of bugs that are in a
NEW state, decent number that have sat for a long while too. Those
bugs aren't 'confirmed'- just like with the new
or not.
Yeah, I can understand how it could work technically. The only issue is
to make the version bump one automated step.
Paweł Hajdan, Jr.
signature.asc
Description: OpenPGP digital signature
/tools/export_tarball/export_tarball.py
in the Chromium source tree. I can review patches. :-D
Paweł Hajdan, Jr.
signature.asc
Description: OpenPGP digital signature
One of my ebuilds is using virtualx eclass, and I noticed the following
code inside the eclass:
retval=$?
# Now kill Xvfb
kill $(cat /tmp/.X${XDISPLAY}-lock)
else
debug-print ${FUNCNAME}: attaching to running X display
# Normal make if we can connect
bits from your message when reading earlier. Could
you please send me the ebuild you are using? If some printers can be
supported with no additional firmware/files, creating a non-live,
versioned-tarball based packages should be possible, and I can do it.
Paweł Hajdan, Jr.
signature.asc
I wonder why pax-utils.eclass uses elog instead of just einfo. An
example message looks like this:
* Fallback PaX marking -m
* out/Release/chrome
IMHO it's not very useful in the elog messages, but maybe there are
scenarios in which it is useful.
My idea is to just replace all elogs with
sys-devel/gcc runs tests, but the results are ignored and I remember the
tests fail most of the time.
Because the tests take long time to run and fail anyway (I understand
it's non-trivial to fix those on Gentoo side), I wonder whether it makes
sense to run them at all:
toolchain.eclass:
to scan all installed files in pkg_postinst for
pax-mark-ed files, and then elog something?
Paweł Hajdan, Jr.
signature.asc
Description: OpenPGP digital signature
I remember there was an effort to make python.eclass support EAPI 4 even
before it has been officially approved.
Now that we have EAPI 4 support even in stable portage, it would be
awesome to make python.eclass support that EAPI.
What do you think?
signature.asc
Description: OpenPGP digital
On 3/21/11 11:02 PM, Ryan Hill wrote:
It does to me, I use them all the time. ;) The important part is that we
install the test results, which can then be used for regression testing when
rolling patchsets.
I see, it makes sense. I guess you're comparing the test results before
and after
-l
6032
If I'm interpreting the data correctly, about 43% of Manifest files are
signed. That's not too bad, I was expecting something more like 5%.
By the way, is it acceptable to use the same GPG key for e-mail and
signing packages?
Paweł Hajdan, Jr.
signature.asc
Description: OpenPGP digital
On 3/25/11 3:43 PM, Michał Górny wrote:
How about Gentoo Foundation funding devs a full blown X509 client
certs?
Let's get signing and verifying working first, and then consider
anything that requires funding.
signature.asc
Description: OpenPGP digital signature
On 3/25/11 8:00 PM, Mike Frysinger wrote:
i wasnt aware you could extend the expiration date of a key. that
sort of defeats the purpose of having an expiration date doesnt it ?
then someone could steal your expired key, extend the date, and keep
using it.
I think that's one more reason for
-strict sign splitdebug stricter test test-fail-continue
userpriv usersandbox
I'd like to suggest removing digest from the line above. I've been
running with the developer profile and -digest in /etc/make.conf, and
everything is working fine.
Paweł Hajdan, Jr.
signature.asc
Description: OpenPGP
On 3/28/11 2:05 AM, Robin H. Johnson wrote:
I see so many bad ideas mentioned in this thread. The suggestions to
keep a gpg-agent with a very long passphrase TTL just provides a massive
new security hole:
===
Attacker breaks into developer's system, has access to SSH agent and GPG
agent
On 3/29/11 9:52 PM, Eray Aslan wrote:
# Eray Aslan e...@gentoo.org (29 Mar 2011)
# Abandoned project. Last release in 2005. Bugs #158003, #97589,
# #359411.
# Removal in 90 days
net-mail/mailwrapper
net-mail/mailer-config
That's cool. All I remember about it are file collisions. Thanks!
On 3/31/11 9:37 AM, Tomáš Chvátal wrote:
Ok two versioned virtuals (0.5 0.6) are now in the tree if people need
to specify the version.
Thank you, but it's still not enough for chromium. The virtual uses
=ffmpeg-0.6, and chromium is known to be broken with ffmpeg-0.6_p25767.
We need to require
On 3/27/11 1:13 PM, Paweł Hajdan, Jr. wrote:
I'd like to suggest removing digest from the line above. I've been
running with the developer profile and -digest in /etc/make.conf, and
everything is working fine.
Are there any objections against doing the above?
Christos (angelos), Mike (vapier
On 4/2/11 7:08 PM, Mike Frysinger wrote:
On Sat, Apr 2, 2011 at 12:22 PM, Paweł Hajdan, Jr. wrote:
On 3/27/11 1:13 PM, Paweł Hajdan, Jr. wrote:
I'd like to suggest removing digest from the line above. I've been
running with the developer profile and -digest in /etc/make.conf, and
everything
There is a bug about www-client/chromium and asian fonts:
http://bugs.gentoo.org/show_bug.cgi?id=359153
First, I'm just wondering whether making the browser RDEPEND on some
fonts would be a correct solution. Maybe, similarly to the icon themes,
we should just suggest some fonts in pkg_postinst.
On 4/5/11 6:37 PM, Ulrich Mueller wrote:
Already chromium's dependency on virtual/ttf-fonts is wrong, IMHO.
Oh, I added it to RDEPEND after Raúl Porcel (armin76) asked me on IRC to
do that - I think the issue was that the browser failed to launch
without the fonts installed.
I don't remember
On 4/9/11 10:50 AM, Samuli Suominen wrote:
On 04/09/2011 11:35 AM, Samuli Suominen wrote:
The 2 profiles in $subject will go away in 30 days wrt bug #361133.
And some early warning:
If you still use Linux 2.4, you should really look into migrating away
from it. For now the 2.4 profiles
On 4/13/11 8:15 PM, William Hubbs wrote:
The baselayout package provides files which all systems must have in
order to function properly. You are currently using version 1.x, which
has several issues. The most significant of these is that the included
init system is written entirely in bash,
On 4/30/11 3:05 PM, Panagiotis Christopoulos wrote:
On 14:28 Sat 30 Apr , Diego Elio Pettenò wrote:
If you read the last paragraph in my suggestion was to cycle the logs...
Maybe this would be better together with a mechanism (automatic?) to keep the
complete ChangeLogs (as they are now)
On 5/3/11 5:27 PM, Kfir Lavi wrote:
In the ebuild there is no mention of runtime dependency like gcc or glibc.
See
http://devmanual.gentoo.org/general-concepts/dependencies/index.html#implicit-system-dependency
Why sys-devel/gcc don't have a library version without the actual compiler?
This
201 - 300 of 505 matches
Mail list logo
