to
inform users about the change is certainly a good idea.
Best regards,
Chí-Thanh Christopher Nguyễn
has passed.
Best regards,
Chí-Thanh Christopher Nguyễn
rg/general-concepts/mirrors/index.html claims
that dev.gentoo.org is not acceptable for hosting main-tree items, and
they must be moved to mirror://gentoo before release.
Maybe putting a clarification there too would help in avoiding confusion
regarding this issue.
Best regards,
Chí-Thanh C
Samuli Suominen schrieb:
Also, both udisks and upower now have blockers for sys-apps/hal to
prevent overlapping features.
The result of this is that KDE and Gnome are now not installable at the
same time on a stable system.
Best regards,
Chí-Thanh Christopher Nguyễn
tomatically non-cruft, or that orphaned packages are
not at all cared about.
Best regards,
Chí-Thanh Christopher Nguyễn
Chí-Thanh Christopher Nguyễn schrieb:
Samuli Suominen schrieb:
Also, both udisks and upower now have blockers for sys-apps/hal to
prevent overlapping features.
The result of this is that KDE and Gnome are now not installable at the
same time on a stable system.
Ah sorry, I was wrong. KDE
Branko Badrljica schrieb:
> 2. Is there any info on gcc version that will support -march=Bulldozer ?
> I have googled a couple of gcc-related posts about optimizing for this
> CPU architecture intricacies and I have hoped to see support for it in
> 4.6... Is this stuff still in early development or
al/ttf-fonts with a new cjk USE-flag,
which would make it depend on one of the suggested fonts from bug 359153.
Best regards,
Chí-Thanh Christopher Nguyễn
nly
with a C or English locale if a different one is detected.
Regards,
Chí-Thanh Christopher Nguyễn
Eray Aslan schrieb:
> https://bugs.gentoo.org/show_bug.cgi?id=364445
> https://bugs.gentoo.org/show_bug.cgi?id=364401
>
> Basically, there are requests to add packages to RDEPEND in virtual/mda
> and virtual/mta that are not in the official tree but in sunrise.
>
> On one side, *DEPENDing on a pack
William Hubbs schrieb:
> I'm not an overlay user, but I'm thinking that an overlay user might be
> able to get around this by putting the virtual in package.provided.
>
Why must the user do it? Can't the package manager do it?
Regards,
Chi-Thanh Christopher Nguyen
Zac Medico schrieb:
>> Would it make sense to do the following:
>> (1) make all new-style virtuals additionally depend on an old-style
>> virtual (a new category might be appropriate)
>> (2) ebuilds in overlays can PROVIDE the old-style virtual
>>
> It seems like new-style virtual would be int
Ciaran McCreesh schrieb:
> On Sat, 23 Apr 2011 12:28:29 +0200
> Chí-Thanh Christopher Nguyễn wrote:
>
>> Would it make sense to do the following:
>> (1) make all new-style virtuals additionally depend on an old-style
>> virtual (a new category might be appropriate)
Ciaran McCreesh schrieb:
> On Sat, 23 Apr 2011 15:28:04 +0200
> Chí-Thanh Christopher Nguyễn wrote:
>
>> Because there is a reason for not doing so, or because you think that
>> multi-repository support is a superior solution which will come
>> sooner?
>>
Ciaran McCreesh schrieb:
> On Sat, 23 Apr 2011 16:47:37 +0200
> Chí-Thanh Christopher Nguyễn wrote:
>
>> What I propose solves the problems that old-style virtuals introduce
>> in dependency resolution.
>>
> Not really, because it means we'd hav
Jeroen Roovers schrieb:
> Look here, I am even willing to argue on your side just to possibly
> extract a meaningful objection to fixing LC_MESSAGES in
> sys-apps/portage.
I now tend to agree that LC_MESSAGES should be set to C by default.
However I suggest to put it in the default make.conf, toge
of the (now defunct) live ebuild of chromium-bin
Best regards,
Chí-Thanh Christopher Nguyễn
Patrick Lauer schrieb:
> On 06/03/11 16:09, Chí-Thanh Christopher Nguyễn wrote:
>
>> Michał Górny schrieb:
>>
>>> You could have a 'versioned' ebuild linked to the actual SRC_URI,
>>> and bump it whenever you notice the upstream tarball c
l-linux${arch_path}/${LV}/chrome-linux.zip";
-O "${T}"/${PN}-${LV}.zip
76
So essentially a live ebuild which downloads changing stuff from a http URI.
Best regards,
Chí-Thanh Christopher Nguyễn
esn't say the file can't be
> distributed. What part of it is causing that problem?
>
To my knowledge, the firmware files for HP printers are not
redistributable.
Best regards,
Chí-Thanh Christopher Nguyễn
Maxim Koltsov schrieb:
> Also i'd want to ask: is it woth to add new category (e.g.
> leechcraft-plugins) to simplify managing leechcraft ebuilds. And the
> last question: is it good to add versions for all ebuilds too?
>
I don't think there is a need for a new category. But I do think it
e ebuild and change the EAPI things may break, but
then the ebuild has your attention anyway.
And there is no real disadvantage over a python.eclass that dies on EAPI
4 and a python-2.eclass that dies on EAPI <=3
Best regards,
Chí-Thanh Christopher Nguyễn
e same filesystem as /, then there is
no real reason to not just make a symlink /usr -> .
Best regards,
Chí-Thanh Christopher Nguyễn
filesystem as /, then there
>> is no real reason to not just make a symlink /usr -> .
>
> That's a joke, right?
There are folks who seriously take this into consideration. I don't
necessarily agree with them, though.
Best regards,
Chí-Thanh Christopher Nguyễn
Samuli Suominen schrieb:
> 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)
Maybe I have to e
rs, it might make sense to keep /var separate depending on which
services write there.
Best regards,
Chí-Thanh Christopher Nguyễn
[foo-icons], while the virtual depends on
foo-icons? ( || ( list of packages known to contain foo-icons ) )
Of course, this makes sense only if it is known or easy to find out
which icon-themes contain which icons.
Best regards,
Chí-Thanh Christopher Nguyễn
Nirbheek Chauhan schrieb:
>>> A side-note that we've wanted to get out to all devs is that everyone
>>> should *always* use IUSE="+introspection".
>> Then why is it a flag?
>>
> So that people who use, say, json-glib in embedded environments don't
> need to pull in a package that is quite unnecessa
tool stack
> pulls in pango with the +introspection default. Useless to me, and my
> host. No problems since June 24 2011. (I thought it was already unmasked
> since I discovered it enabled back then)
Sounds to me like profile defaults are more appropriate than IUSE
defaults in this c
heir home
directories full of some stuff.
Regarding the problem of the developer neglecting (happened to me too,
ahem) to upload distfiles, maybe repoman could check for this?
Best regards,
Chí-Thanh Christopher Nguyễn
first, and removes me from metadata.xml.
If you plan to maintain the driver, you may also want to look at the
out-of-tree rtlwifi driver in bug 379953.
Best regards,
Chí-Thanh Christopher Nguyễn
f an EAPI is approved for use in the portage tree, its USE syntax
can also be used for news items.
2. Council must approve EAPIs for news items
3. A new GLEP or new version of the News-Item-Format is necessary
Your thoughts? Am I missing something?
Best regards,
Chí-Thanh Christopher Nguyễn
change in eselect is only
reflecting that.
Best regards,
Chí-Thanh Christopher Nguyễn
Ciaran McCreesh schrieb:
> On Sun, 21 Aug 2011 14:48:53 +0200
> Chí-Thanh Christopher Nguyễn wrote:
>> Question is, can I put the EAPI 2 USE conditional
>> "media-libs/mesa[video_cards_radeon]" in Display-If-Installed: or
>> not?
>
> No.
>
> L
Hello,
Please see the attached news item for review. The news item should be
published before mesa-7.11 goes stable.
Corresponding bug report: https://bugs.gentoo.org/show_bug.cgi?id=377349
Best regards,
Chí-Thanh Christopher Nguyễn
Title: Mesa r600 driver now defaults to gallium
Author: Chí
Francisco Blas Izquierdo Riera (klondike) schrieb:
> You can point the reader to
> http://www.x.org/wiki/RadeonFeature#Decoderringforengineeringvsmarketingnames
> in order to know wether his ATI card is or not an r600 ATI card.
> Specially since the reference to HD2000 includes some r500 cards.
Y
tch
both mesa and emul-linux-x86-opengl to gallium.
Best regards,
Chí-Thanh Christopher Nguyễn
Donnie Berkholz schrieb:
> On 23:12 Thu 25 Aug , Chí-Thanh Christopher Nguyễn wrote:
>> Existing users will not be switched automatically.
>
> Why not? If it's considered the supported route going forward, we should
> just do it automatically.
Some users might be u
away. Even bypassing the usual 30 days and no last rite
announcement was sent to -dev.
Bug 361181 is certainly on my TODO list, just not very high up to now.
If you think that there is some urgency in getting rid of the package,
please do explain so in advance.
Best regards,
Chí-Thanh Christopher Nguyễn
inux-headers reverse deps to be tracked stable.
>
> I've removed qutecom for you again.
Please put it back in tree. You have my consent to remove it on 13
October (when the 30 days are over) and I have not fixed it yet.
Best regards,
Chí-Thanh Christopher Nguyễn
Mike Frysinger schrieb:
> On Sunday, October 02, 2011 08:58:19 Chí-Thanh Christopher Nguyễn wrote:
>> Samuli Suominen schrieb:
>>>> Please point to existing authoritative documentation which says that
>>>> downgrades are unacceptable.
>>>>
>>
hangeLog files. but if this is going to be
> a
> sticking point for you, i can simply clean the tree as soon as we get newer
> stable versions.
If the old versions and reverse dependencies are dropped in accordance
with
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=5#doc_chap7
then I won't complain.
Best regards,
Chí-Thanh Christopher Nguyễn
also applies to
> setting dependencies just as well.
The downgrade is necessary to avoid user-visible breakage.
And the wording clearly does only apply to package removals.
Best regards,
Chí-Thanh Christopher Nguyễn
to you, but it certainly is not obvious to me why
linux-headers downgrade is so bad. If vapier's unsupported out-of-tree
software fails to build against old linux-headers, then he has to make
sure to have the correct version installed before proceeding. Blaming
that on qutecom is far-fetched IMO.
Best regards,
Chí-Thanh Christopher Nguyễn
headers version then?). And something about
out of tree compiles.
ssuominen himself mentioned
https://bugs.gentoo.org/show_bug.cgi?id=311241#c2 but that talks about
libraries not headers. And a bug comment can hardly be called
authoritative documentation.
Best regards,
Chí-Thanh Christopher Nguyễn
rship. Never commit on
things with unclear ownership until you've tried to clear it up.
Best regards,
Chí-Thanh Christopher Nguyễn
I've put into this porting effort, but not this
>> "attack" either.
> Then stop trying to remove packages that have an active maintainer. I could
> have sworn that was written down somewhere.
I found two instances of it
1. http://www.gentoo.org/proj/en/devrel/recrui
is not ok.
Packages have bugs. If it is a bug that affects a small number of users
in a minor way and there is no easy fix, then the bug will get less
attention than one that affects many users in a serious way. Live with it.
Best regards,
Chí-Thanh Christopher Nguyễn
Mike Frysinger schrieb:
> otherwise, Rich summed up things nicely in his later post.
If you mean that common sense thing: if there is disagreement about it,
then it is obviously not common.
>> The second time the package was removed was even without mask or
>> announcement.
> well, it shouldn't
ons are removed, not before.
Best regards,
Chí-Thanh Christopher Nguyễn
Mike Frysinger schrieb:
>>> by splitting my reply, you changed the meaning. having qutecom in the
>>> tree with a depend on versions that i'm now removing breaks the
>>> depgraph.
>> The depgraph is broken after the old versions are removed, not before.
> which is what i said
So qutecom is not br
Ciaran McCreesh schrieb:
> On Thu, 13 Oct 2011 12:23:07 +0200
> Chí-Thanh Christopher Nguyễn wrote:
>> So qutecom is not broken and needs not be removed as long as
>> Dependencies using <, <=, =, ~ or =* are broken, except in certain
> special situations inside ||.
I
mething that I have been asking for all the time. If you think
that what qutecom did should be illegal in Gentoo, then disallow it in
policy or code.
Best regards,
Chí-Thanh Christopher Nguyễn
Samuli Suominen schrieb:
>> This is something that I have been asking for all the time. If you think
>> that what qutecom did should be illegal in Gentoo, then disallow it in
>> policy or code.
>
> Drop that "should be" act, please. It looks as if you were still
> suggesting it was fine to do wh
agree with "typically".
Best regards,
Chí-Thanh Christopher Nguyễn
ryone think?
+1
Do you need iproute2 at all? I think you could fall back to busybox if
iproute2 is not installed.
While you are at it, please also switch from wireless-tools to iw :)
https://bugs.gentoo.org/show_bug.cgi?id=261655
Best regards,
Chí-Thanh Christopher Nguyễn
not visible to the user.
Removing/replacing references to the old tools from Gentoo documentation
would be something worth considering though.
Best regards,
Chí-Thanh Christopher Nguyễn
of not installing net-tools by default as
soon as openrc switches to iproute. However I think this would make many
users unhappy so has to be carefully prepared and users educated first.
Debian has set this goal in 2007[1] and they have not reached it yet.
Best regards,
Chí-Thanh Christop
meant as a fallback, if the user needs to uninstall
iproute2. Having some potential instability may be preferable to not
working at all.
openrc can already use busybox udhcpc instead of dhcpcd, so there is a
precedent.
Best regards,
Chí-Thanh Christopher Nguyễn
question "should openrc contain support for ifconfig/route".
Having the openrc ifconfig code around in case someone still wants/needs
it is something I fully agree with.
Best regards,
Chí-Thanh Christopher Nguyễn
Mike Frysinger schrieb:
> On Sunday 13 November 2011 13:04:57 Chí-Thanh Christopher Nguyễn wrote:
>> Mike Frysinger schrieb:
>>> until we have replacement for all of its tools, it's always going to be
>>> there.
>>
>> After net-tools is no longer needed
an remain enabled by default if -v is not passed to emerge.
Best regards,
Chí-Thanh Christopher Nguyễn
er --quiet-build=n to be a mode
> that most people would prefer to avoid.
No, in my proposal --quiet-build would override -v, not the other way round.
Best regards,
Chí-Thanh Christopher Nguyễn
Zac Medico schrieb:
> On 11/13/2011 04:36 PM, Chí-Thanh Christopher Nguyễn wrote:
>> Zac Medico schrieb:
>>>> Per discussion on IRC, I propose to make -v turn off quiet-build by
>>>> default.
>>>> It can remain enabled by default if -v is not passed to
but as you say, that isn't
> exactly preferable, and brings its own set of troubles.
> -mike
Ok, and do you see any other parts of net-tools that are needed for
basic setups?
Best regards,
Chí-Thanh Christopher Nguyễn
ution which most of the critics of quiet-build could
live with and users still won't see build output by default.
If a user passes -v and as a result sees build output, I think he won't
be confused or angry about it.[1]
Best regards,
Chí-Thanh Christopher Nguyễn
[1] http://xkcd.com/242/
est regards,
Chí-Thanh Christopher Nguyễn
he data which was collected so far suggests
otherwise.
The vocal minority argument is just made up. A vocal minority can push
or oppose changes.
If you think that the change is better for users, and they just need
time to adjust, then be a man and stand to your opinion. Don't hide it
behind such phony claims.
Best regards,
Chí-Thanh Christopher Nguyễn
untuone and unity ebuilds, if
you don't mind I will commit them to portage with ayatana herd and join
it myself.
Best regards,
Chí-Thanh Christopher Nguyễn
ave it like this for build.log when
reporting bugs.
Best regards,
Chí-Thanh Christopher Nguyễn
impractical. Still,
probably not worth the effort.
Best regards,
Chí-Thanh Christopher Nguyễn
ckage.mask and
>>> use.local.desc queries by crawlers. Like crawling the entire 13000 rev
>>> history for package.mask (or similar.)
Would it be feasible to use mod_rewrite to direct the most expensive
requests to a static copy, which is re-generated every
${REASONABLE_TIMEFRAME}?
Best regards,
Chí-Thanh Christopher Nguyễn
emory split to avoid HIGHMEM on 32
bit systems. If you do that, you might run out of address space.
Best regards,
Chí-Thanh Christopher Nguyễn
Alexandre Rostovtsev schrieb:
> Answers to anticipated questions:
Q8: SLOT can change after the package was installed. How to handle this
case?
Best regards,
Chí-Thanh Christopher Nguyễn
t; flag in font packages, enabled by default and masked in
profiles that don't support building from source.
Best regards,
Chí-Thanh Christopher Nguyễn
ocking
into memory have become less important.
The cdrom group will give access to /dev/sr* but not the associated /dev/sg*
Best regards,
Chí-Thanh Christopher Nguyễn
-wm/compiz-fusion
x11-wm/emerald
Best regards,
Chí-Thanh Christopher Nguyễn
[1] http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Frysinger schrieb:
> On Thursday 02 February 2012 17:56:16 Chí-Thanh Christopher Nguyễn
> wrote:
>> there have been a number of packages masked lately due to lack
>> of maintainer. However, their metadata.xml does not list
&g
ove the charset restriction on the C
locale, and added C.UTF-8. It has the "advantage" of not messing with
transliteration as LC_CTYPE=en_US.UTF-8 would.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609306
Best regards,
Chí-Thanh Christopher Nguyễn
-BEGIN PGP SIGNATURE-
Ve
;dr
Syslinux/extlinux can replace grub in many if not most cases. But for
a number of setups it is not well-suited. So a documented and stable
grub2 will still be needed.
Best regards,
Chí-Thanh Christopher Nguyễn
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux
simply explains that it's
>> masked for testing purposes :-/
>
> Grub is the only blocker. I don't want to unmask something that
> makes people's systems unbootable.
>
> I'm also out of ideas and open to suggestions.
Does gcc-4.7 have the same problem with
then be
a file that is meant to be accessed by users in /var/lib if your proposal is
realized.
Best regards,
Chí-Thanh Christopher Nguyễn
. Exceptions are
meta-packages.
If someone wants to have a lean system not just concerning disk space, that
would include disabling such code.
Best regards,
Chí-Thanh Christopher Nguyễn
# Chí-Thanh Christopher Nguyễn (29 Aug 2015)
# Masked for removal in 30 days. Multiple build failures. Upstream inactive.
# (bugs #321017, #581284, #588692, #602786, #649006, #654140)
www-plugins/gnash
Andrew Savchenko schrieb:
# Chí-Thanh Christopher Nguyễn (29 Aug 2015)
# Masked for removal in 30 days. Multiple build failures. Upstream inactive.
# (bugs #321017, #581284, #588692, #602786, #649006, #654140)
www-plugins/gnash
Is there any replacement available? AFAIK no, at least among
think it is a valid concern that removal of packages may sometimes be
overzealous, and to better keep packages in the tree as long as they are
useful and workarounds exist for build/runtime problems. Just in case of
gnash there is really no benefit in keeping it.
Best regards,
Chí-Thanh Christ
.
But putting them as code is not always possible, as it may require changes in
other packages or similar.
And sometimes, there were building and working packages masked for removal
just because they lacked a maintainer.
Best regards,
Chí-Thanh Christopher Nguyễn
upstream here. Of course giving users the ability to override.
Best regards,
Chí-Thanh Christopher Nguyễn
very much like to see -Werror allowed, this is just not
going to happen.
Best regards,
Chí-Thanh Christopher Nguyễn
-fatal. Or report upstream, so they can do
the Right Thing™ and don't redefine.
$ gcc -O1 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 foo.c
That is all what is desired.
Best regards,
Chí-Thanh Christopher Nguyễn
bogus, it could have been the code relying on
undefined behavior, and the compiler changing the semantics of such behavior,
and introducing an accompanying warning at the same time.
Best regards,
Chí-Thanh Christopher Nguyễn
amining the situation and taking appropriate action,
and then applying a change to no longer cause that particular warning (or
make it non-fatal if the warning is bogus/harmless).
Best regards,
Chí-Thanh Christopher Nguyễn
warnings" QA notice which
could be extended for this purpose.
Best regards,
Chí-Thanh Christopher Nguyễn
Kristian Fiskerstrand schrieb:
On 9/10/18 11:19 PM, Chí-Thanh Christopher Nguyễn wrote:
It is indeed an insurmountable task to write code that is warning-free
from the beginning across architectures, compiler versions, etc. But
that is not the goal anyway. It is examining the situation and
insufficient.
One should only be thankful for any tool
to detect issues hidden within code, stop and re-evaluate when new
issues are found.
+1
Best regards,
Chí-Thanh Christopher Nguyễn
or similar, which
will cause the build to fail if warnings are encountered in a warningfree
ebuild. I need to think more how this could work with binpkgs though.
Best regards,
Chí-Thanh Christopher Nguyễn
y had it.
From x11 packages (they used to be one of the major remaining -Werror
packages, cf. bug #416069) I recall a few cases where broken stuff on user
systems triggered -Werror build failures. But this was mostly people who
installed something to /usr/local and forgot about it.
Best regards,
Chí-Thanh Christopher Nguyễn
ore deciding on whether to use the package as is, attempt to
downgrade, or wait until a fix is released.
Best regards,
Chí-Thanh Christopher Nguyễn
you want to install this [y/N]?".
Best regards,
Chí-Thanh Christopher Nguyễn
levels, due to -Werror.
One is dev-libs/libcss: https://bugs.gentoo.org/626752
Best regards,
Chí-Thanh Christopher Nguyễn
201 - 300 of 340 matches
Mail list logo
