[gentoo-dev] Last rites: media-fonts/symbola

2020-03-29 Thread Chí-Thanh Christopher Nguyễn

# Chí-Thanh Christopher Nguyễn  (2020-03-29)
# Old releases gone from upstream, new releases use overly restrictive
# license. For ancient scripts and symbols, use media-fonts/quivira instead.
# For emojis and pictographs, use media-fonts/noto-emoji instead.
# Masked for removal in 30 days, bug #715226
media-fonts/symbola



Re: [gentoo-dev] Fwd: [gentoo-commits] repo/gentoo:master commit in: app-office/calcurse/

2020-03-12 Thread Chí-Thanh Christopher Nguyễn

Alec Warner schrieb:
On Thu, Mar 12, 2020 at 9:54 AM Andreas K. Huettel <mailto:dilfri...@gentoo.org>> wrote:


Someone needs to grow up here.


Meh, to me (someone who can't commit to ::gentoo) I have a few concerns here. 
First, I don't see a lot of QA reverts on the gentoo-dev list. Is it common 
practice to post reverts publicly? Second, I'm not aware that we would revert 
for things like this. Most of the items you mention look fairly minor (maybe 
the python comment looks impactful?) Why can't we fix these items in a future 
commit, rather than revert? What did Patrice's commit break?


If the issues are so serious that we have to prevent any breakage/regressions 
from reaching users, I guess an alternative response would have been to 
p.mask the offending new ebuild. Unless the commit caused some tree-wide 
breakage which I can't see here however.



Best regards,
Chí-Thanh Christopher Nguyễn



Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template

2019-12-05 Thread Chí-Thanh Christopher Nguyễn

Michał Górny schrieb:

+
+#
+# This file specifies packages that are considered deprecated


I think that is not an apt description in my understanding of your original 
post on the matter. The package.deprecated file is supposed to contain not 
just (qualified) package names, but some sort of package dependency 
specifications (PMS 8.2.6).


Perhaps the examples should also reflect this.


Best regards,
Chí-Thanh Christopher Nguyễn



Re: [gentoo-dev] New distfile mirror layout

2019-10-28 Thread Chí-Thanh Christopher Nguyễn

Hi!


Today you get chastised for using /space/distfiles-local and not
following policy changes.  The devmanual states that it's deprecated
since at least 2011, and talks of using d.g.o [1].
> [1] 
https://devmanual.gentoo.org/general-concepts/mirrors/index.html#suitable-download-hosts


Sorry I'm late to the party, but I would like to enquire about what happens 
if a file with existing filename but different b2sum gets uploaded to 
/space/distfiles-local now?


Doing so and updating the Manifest used to be another (not necessarily 
preferred) method to address upstream remaking release packages.



Best regards,
Chí-Thanh Christopher Nguyễn



Re: [gentoo-dev] [RFC] Using HTTPS mirrors only in thirdpartymirrors (when possible)

2019-09-30 Thread Chí-Thanh Christopher Nguyễn
Michał Górny schrieb:

> Many 'FTP' hosts belong to different tiers.  There's a major difference
> between knowing that a user is fetching *something* from big mirror of
> everything, and knowing the exact precise thing being fetched.  It may
> mean knowing that the user is fetching vulnerable package (for whatever
> reason).

As Portage uses one connection per file, which exact file was downloaded can
still be inferred from the amount of transferred data (to a degree).

I agree that it is a step forward though, however small it is.


Best regards,
Chí-Thanh Christopher Nguyễn



Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags

2019-07-17 Thread Chí-Thanh Christopher Nguyễn

Michał Górny schrieb:

Packages must not disable installing manpages via USE flags



a. USE flags that disable building both a program and its manpage


I think it seems an implicit goal that this policy should apply to programs 
and their manpages?


In that case, I would suggest to at least limit this policy to man section 1 
and 8. As mattst88 explained in another post, X.org developer documentation 
in man pages is not interesting for non-developers, and does usually not 
describe the functions of a program.



Best regards,
Chí-Thanh Christopher Nguyễn



Re: [gentoo-dev] Last rites: sys-boot/raspberrypi-firmware

2019-03-16 Thread Chí-Thanh Christopher Nguyễn

Matt Turner schrieb:

The most important one is support for the 256 MB RAM devices (original RPi
Model B), which works fine on raspberrypi-userland. vc4 still has issues if
less than 256 MB RAM are allocated to the GPU.


That sounds like an awful device to run Gentoo on.


Compiling on a 256 MB Raspberry Pi 1 Model B is of course no joy. Before mine 
broke, I plugged the SD card into another, faster ARM computer, chrooted in 
and emerged updates. That was ok.



I'd like to require libglvnd for all libGL providers and get rid of
app-eselect/eselect-opengl. What do you suggest we do about
raspberrypi-userland?


I suggest to drop eselect-opengl and its dependency in raspberrypi-userland. 
raspberrypi-userland installs into /opt anyway so should not conflict with 
anything else. And those people who really need acceleration on 256 MB 
devices will have to set the proper environment variables.



Best regards,
Chí-Thanh Christopher Nguyễn



Re: [gentoo-dev] Last rites: sys-boot/raspberrypi-firmware

2019-03-15 Thread Chí-Thanh Christopher Nguyễn

Matt Turner schrieb:

Do you know something about media-libs/raspberrypi-userland as well?
I'm hoping to enable libglvnd support in media-libs/mesa and
x11-drivers/nvidia-drivers soon, and this is the only other package in
Gentoo that uses app-eselect/eselect-opengl.

Do we care to keep this now that Mesa's vc4 driver is in good shape?


There are uses for raspberrypi-userland which the vc4 driver (last I checked 
at least) does not cover very well.


The most important one is support for the 256 MB RAM devices (original RPi 
Model B), which works fine on raspberrypi-userland. vc4 still has issues if 
less than 256 MB RAM are allocated to the GPU.



Best regards,
Chí-Thanh Christopher Nguyễn



Re: [gentoo-dev] [PATCH] eclass/linux-mod.eclass: add module signing support

2018-09-21 Thread Chí-Thanh Christopher Nguyễn

Alexander Tsoy schrieb:

+   sign_binary_path="${KV_OUT_DIR}/scripts/sign-file"


Yet another way to screw up modules building. It relies on some binary
in the kernel build dir that may break after openssl update (e.g.
soname change).


Maybe the sign-file application could be packaged, for example as part of 
sys-apps/linux-misc-apps.



Best regards,
Chí-Thanh Christopher Nguyễn



Re: [gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror

2018-09-21 Thread Chí-Thanh Christopher Nguyễn

Mike Auty schrieb:

Installation will proceed, but the user will get a big fat warning that
the sys-fs/zfs package is potentially broken.


This seems like a sure-fire way to make users paranoid and/or
desensitized?  People will learn to ignore warnings if we make them big
red and flashing but then say they're only potential breakages (and they
subsequently discover that most everything runs fine).  If they learn to
ignore big red flashing warnings it'll be more difficult when they're
not potential breakages but actual ones we've accurately identified...


Maybe "big fat warning" was a bit of an overstatement. I meant the same kind 
of notice that @preserved-rebuild set produces today. Or the "configuration 
files need updating" message.


Much like the aforementioned, the affected package might continue to work 
totally fine, or be broken in subtle ways. It might bother the user enough to 
report a bug, but hopefully not enough to turn them away from Gentoo.


Best regards,
Chí-Thanh Christopher Nguyễn



Re: [gentoo-dev] Changing policy about -Werror

2018-09-21 Thread Chí-Thanh Christopher Nguyễn

Richard Yao schrieb:


To make code behave differently it needs substantial amount of code
to provide you an example. You need to him O2<->O3 behaviour delta
after all. But I will try (for a different warning, it should not matter
much).

Thanks. I had been incorrect about -O3 giving not us some additional 
information for warnings. My apologies for the confusion.


Below is a reduced example of a larger C++ program.
Many thanks to Ulya for providing recent example!


Not that it matters now, but there are examples of packages building at -O2 
but failing to build at -O3 optimization levels, due to -Werror.


One is dev-libs/libcss: https://bugs.gentoo.org/626752


Best regards,
Chí-Thanh Christopher Nguyễn



Re: [gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror

2018-09-12 Thread Chí-Thanh Christopher Nguyễn

Rich Freeman schrieb:

If the user recognizes this as a critical package, then they can do the
research before deciding on whether to use the package as is, attempt to
downgrade, or wait until a fix is released.


But, you've ALREADY overwritten the previous version of the package
that presumably didn't have this problem.  What if downgrading doesn't
cause the problem to go away?  What if it is due to some dependency or
toolchain change?  Users would presumably want to roll back to the
binaries that were working just a few minutes ago, not build new ones
that might or might not have the same issue.


Users could weigh their options and then decide on how to best proceed. In 
case of zfs, they still have time until next reboot to fix this.


Or the maintainer can set PROPERTIES="interactive" in anticipation of such a 
situation and ask "Are you sure you want to install this [y/N]?".



Best regards,
Chí-Thanh Christopher Nguyễn



Re: [gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror

2018-09-12 Thread Chí-Thanh Christopher Nguyễn

Rich Freeman schrieb:

Requirements:

* Do not fail to build/install when a warning is encountered


On a particularly critical package like a filesystem, wouldn't we want
to still fail to install when a warning is encountered?


Installation will proceed, but the user will get a big fat warning that the 
sys-fs/zfs package is potentially broken.



I get that users might quit if packages don't install, but I'm not
sure that a filesystem corruption is going to make them any happier...


If the user recognizes this as a critical package, then they can do the 
research before 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



Re: [gentoo-dev] Changing policy about -Werror

2018-09-12 Thread Chí-Thanh Christopher Nguyễn

Thomas Deutschmann schrieb:

So let's turn this around: Please show us a *real* case within Gentoo
where "-Werror" prevented a real problem which wouldn't otherwise being
noticed. E.g. show us a package which was merged on user's system,
replacing a working previous version of that package causing *real*
problems which could have been prevented if package would have set
"-Werror".


I think your request will be difficult to meet, precisely due to the strict 
policy against -Werror which means that it is already long gone from most 
packages which originally 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



[gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror

2018-09-12 Thread Chí-Thanh Christopher Nguyễn

Hi!

So from the discussion I gather that -Werror has both desirable and 
undesirable effects. Question is, can we somehow mitigate the undesirable 
effects while still retaining the desirable effects as much as possible?


Requirements:
* Bother the user enough that they will report the problem, but not enough 
that they will leave Gentoo for another distro, which means:

* Do not fail to build/install when a warning is encountered
* Do not silently install the package anyway when a warning is encountered

Rough suggestion:

1. Introduce a new value in ebuilds for PROPERTIES, named "warningfree" (or 
something similar for RESTRICT if that is preferable).
2. Introduce a new package set, named @broken-warningfree. If a package is in 
this set, emerge will display a notification each time it runs (like with 
@preserved-rebuild).
3. Extend install-qa-check.d/90gcc-warnings so that optionally all compiler 
warnings will be caught
4. If PROPERTIES="warningfree" is set, 90gcc-warnings catches all compiler 
warnings
5. If PROPERTIES="warningfree" is set, and there is a warning caught, add the 
package to the @broken-warningfree set on install
6. If there is no warning caught, remove the package from the 
@broken-warningfree set (if it is currently in there)
7. When ebuild maintainers remove -Werror from a package, they can set 
PROPERTIES="warningfree" at their discretion


Also possible is to introduce FEATURES="strict-warnings" 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



Re: [gentoo-dev] Changing policy about -Werror

2018-09-12 Thread Chí-Thanh Christopher Nguyễn

Alon Bar-Lev schrieb:

We
are unique as permutations and architectures that are used by Gentoo
users are so diverse that we find issues that nobody else finds.


This needs to be highlighted more, as it is why suggestions that the 
maintainer can simply put -Werror back on their own system are 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



Re: [gentoo-dev] Changing policy about -Werror

2018-09-10 Thread 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 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).


sure, but for upstreams that make this an explicit goal, do we really
want to apply additional downstream pataches with the additional
complexity that carries for build system (autotools re-generation that
might make it unsupported upstream etc) ?


I fully understand why in the general case this is considered undesirable.

But in very specific cases it can make sense to err on the side of caution, 
and the rigid -Werror policy gets in the way. This is what the initial 
message by bircoph suggested.



Best regards,
Chí-Thanh Christopher Nguyễn



Re: [gentoo-dev] Changing policy about -Werror

2018-09-10 Thread Chí-Thanh Christopher Nguyễn

Mart Raudsepp schrieb:

one way to look at it though, is that it is a valuable upstream
contribution that this configuration produces the error, so Gentoo is
contributing to upstream development because of it.


And losing users and thus relevance in the process. Not everyone goes
to bugzilla always and then waits for a fix, or fixes it themselves.
Normal people wipe that stuff away and install an operating
system/distribution that doesn't cause them grief in its place.


This is indeed a problem with -Werror (I mentioned it in a previous message). 
Tinderboxing as k_f suggested could not possibly cover the vast number of 
configurations that users have either.


An alternative to -Werror could be maybe some kind of "package health" status 
that would alert users if warnings happened in supposedly warning-free code. 
Portage already has a "Package triggers severe warnings" QA notice which 
could be extended for this purpose.



Best regards,
Chí-Thanh Christopher Nguyễn



Re: [gentoo-dev] Changing policy about -Werror

2018-09-10 Thread Chí-Thanh Christopher Nguyễn

Matt Turner schrieb:

This sounds good in theory, but I think it's pretty well established
that in practice this isn't effective and instead is a large waste of
time.


I think even the thread starter stated that -Werror is unnecessary in the 
vast majority of cases.



In fact, the foundational premise that it's possible to build
without warnings everywhere is simply wrong.

Consider again the bug that started this. The maintainer had not built
this configuration. None of the arch teams had built this
configuration until I did for the last architecture Cc'd. The patch
committed doesn't change anything installed on the system, if not for
Werror preventing the code from building.


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 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



Re: [gentoo-dev] Changing policy about -Werror

2018-09-10 Thread Chí-Thanh Christopher Nguyễn

Fabian Groffen schrieb:

On 09-09-2018 11:22:41 -0400, Richard Yao wrote:

-Werror has caught bugs that could have resulted in data loss in ZFS in the 
past thanks to it being built in userspace as part of zdb. So it is useful for 
integrity too, not just security (although arguably, integrity is part of 
security).


This is a misconception, as jer already pointed out.  Instead:

-Werror has forced you to take notice of problems that could have
resulted in data loss in ZFS ...


But in general it doesn't say when or how the problems became acute. Assuming 
that the warning isn't 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



Re: [gentoo-dev] Changing policy about -Werror

2018-09-10 Thread Chí-Thanh Christopher Nguyễn

Jason Zaman schrieb:

No. With -Werror, upstream indicates that if a warning occurs, the build
should fail and the resulting code not be installed on user systems.

Instead, someone knowledgeable should look at the situation *first* and
determine whether it is a bogus warning, a trivial issue, or something which
warrants further attention.

I have long disagreed with QA policy on this, and think that ebuilds should
respect upstream here. Of course giving users the ability to override.


I disagree. -Werror means that upstream wants it to build without
warnings on their distro with their version of the compiler with their
versions of all the libraries.


It means, upstream wants it to build without warnings everywhere. And if a 
warning occurs (due to change in compiler, libraries, architecture, etc.), 
have a developer look at it first before installing the code on user systems.



There are things that upstream absolutely should be setting which make a
big difference for security like FORTIFY_SOURCE but hardened already has
that set so I get this and thus basically everything would fail to
compile.

$ gcc -O1 -D_FORTIFY_SOURCE=2 foo.c
:0:0: warning: "_FORTIFY_SOURCE" redefined
: note: this is the location of the previous definition

This all on amd64 too. If we start with other arches or cross compilers
or other things then -Werror is just not possible.


But you have looked at the issue, decided that it is harmless, and can now 
make this particular warning non-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



Re: [gentoo-dev] Changing policy about -Werror

2018-09-09 Thread Chí-Thanh Christopher Nguyễn

Andrew Savchenko schrieb:

So my proposal is:

1) Deprecate QA policy with unconditional demand of -Werror removal.
2) Add to devmanual's chapter on -Werror an exception clause about
security-oriented software and maintainer's right to make final
decision.


Likely this proposal will not fly. I understand that -Werror is a 
precautionary measure against installing broken code on user systems, and I 
am all for using it when upstream says so. But it is understandably unwelcome 
by many on Gentoo. If ebuilds started to use -Werror in greater numbers, 
perceived tree quality would go down as build failures increase.


"But it's for your own good!" you would tell users who are angry again that 
package XY didn't compile. -Werror gets in the way of users getting things 
done, and if that happens too often, you might drive those users out.


So while I would very much like to see -Werror allowed, this is just not 
going to happen.



Best regards,
Chí-Thanh Christopher Nguyễn



Re: [gentoo-dev] Changing policy about -Werror

2018-09-09 Thread Chí-Thanh Christopher Nguyễn

Michał Górny schrieb:

Are you suggesting that
upstream is going to detect all those situations and prevent them from
occurring, or are you going to WONTFIX the resulting bugs?


No. With -Werror, upstream indicates that if a warning occurs, the build 
should fail and the resulting code not be installed on user systems.


Instead, someone knowledgeable should look at the situation *first* and 
determine whether it is a bogus warning, a trivial issue, or something which 
warrants further attention.


I have long disagreed with QA policy on this, and think that ebuilds should 
respect upstream here. Of course giving users the ability to override.



Best regards,
Chí-Thanh Christopher Nguyễn



Re: [gentoo-dev] Last rites: www-plugins/gnash

2018-08-30 Thread Chí-Thanh Christopher Nguyễn

Michał Górny schrieb:

I 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.



It may make sense if there is some developer caring enough to actually
put those workarounds in the ebuild, rather than expecting every single
user trying to build it find them himself (and hope he's got all
of them, and the right set).


If you mean, putting these workarounds as elog message, maybe.
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



Re: [gentoo-dev] Last rites: www-plugins/gnash

2018-08-30 Thread Chí-Thanh Christopher Nguyễn

Michał Górny schrieb:

So maybe mask it, but not remove?



Maybe it's time you realize that if you want something to stay, then you
need to actually *take it* and *fix it*.  Keeping clearly broken stuff
so that every user could try jumping through a few hoops to build it has
no value.


I 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 Christopher Nguyễn



Re: [gentoo-dev] Last rites: www-plugins/gnash

2018-08-30 Thread Chí-Thanh Christopher Nguyễn

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 free

software. And there still many sites which require flash to work.


The following other free flash implementations exist:

* LightSpark: active development, ASv2 only
* swfdec: development stopped in 2009
* Shumway: abandoned by Mozilla in 2016, very low development activity still 
happens in github[0]


I think your best bet to replace gnash would be Shumway. Though it is not 
possible to use on current Firefox[1].



So maybe mask it, but not remove?


Current gnash snapshot in the tree can only build against a specific set of 
dependencies, which may disappear any time now (newer versions are stable).


I tried to build upstream git head, but it fails. This was reported a year 
ago, no reaction from upstream:

https://savannah.gnu.org/bugs/?51484

If it is impossible to build, then I think having it in the tree has no value.


Best regards,
Chí-Thanh Christopher Nguyễn


[0] https://github.com/ExE-Boss/mozilla-shumway
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1443253



[gentoo-dev] Last rites: www-plugins/gnash

2018-08-28 Thread 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



Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-22 Thread Chí-Thanh Christopher Nguyễn

Matt Turner schrieb:


As an example of how this works out, I have both sys-apps/hwids and
sys-apps/pciutils built with USE=udev, but media-gfx/gimp built without it.


If it adds no additional dependencies, why do you care?


USE flags are supposed to control features, not dependencies. 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



Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)

2018-07-19 Thread Chí-Thanh Christopher Nguyễn

Ulrich Mueller schrieb:

Users must never
need to modify files in /var/lib to configure a package's operation,
and _the_specific_file_hierarchy_ used to store the data _must_not_be_
_exposed_ to regular users."


One small note, while it is never needed to modify, skel.ebuild would 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



[gentoo-dev] Re: Monthly x11@ project status for June 2018

2018-06-03 Thread Chí-Thanh Christopher Nguyễn

Matt Turner schrieb:

Without eselect-mesa, the Gallium i915 and swrast drivers are installed
if USE=gallium; otherwise the classic versions are installed. I suspect
this is good enough.


To my knowledge, the i915g driver supports only 915/945 hardware.
The intel classic driver supports older chips (down to 810, though I believe 
that everything below 830 has been quite broken for years).


Of course it is questionable whether there are any such users left at all.


Best regards,
Chí-Thanh Christopher Nguyễn



Re: [gentoo-dev] Mailing list moderation and community openness

2018-03-21 Thread Chí-Thanh Christopher Nguyễn
Rich Freeman schrieb:

> Actually, I think it is more of a technical constraint.  It is
> basically impossible to blacklist somebody on a mailing list, since
> all they need to do is roll up a new email address.
> 
> I can think of various arguments for whitelisting or not whitelisting,
> but it seems silly to blacklist.

And how often did it actually happen that blacklisting was evaded on -dev
mailing list?


Best regards,
Chí-Thanh Christopher Nguyễn



Re: [gentoo-dev] Mailing list moderation and community openness

2018-03-21 Thread Chí-Thanh Christopher Nguyễn
Michael Palimaka schrieb:
> I see that in bug #650964[1] Council is pushing forward again with
> implementing user whitelisting on this mailing list (ie. anyone that is
> not "approved" will have their mail rejected).
> 
> Could someone please explain how this doesn't directly contradict the
> core tenets of an open and inclusive community?

(I do not intend to single out your post, just replying to the thread in
general here)

I would like to ask people to stay respectful in their disagreement towards
the Council and their decision here. You might not agree with the decision,
but the Council is an elected body and was given these powers by the
developer community which they represent. Also I have no doubt that Council
members who voted for -dev moderation are aware of the counter arguments and
honestly expect a net positive effect from this.

If you dislike mailing list moderation, campaign and/or vote in the next
period for candidates who want to reverse this decision.


Best regards,
Chí-Thanh Christopher Nguyễn



Re: [gentoo-dev] Mailing list moderation and community openness

2018-03-21 Thread Chí-Thanh Christopher Nguyễn
Kristian Fiskerstrand schrieb:

> Switching to mailman might have some good merits on its own, but as I
> understand it it isn't necessary for the proposal at hand, that can be
> solved using access control lists in mlmmj-process?

I would advise caution that Council better not try to micro-manage Infra here.


Best regards,
Chí-Thanh Christopher Nguyễn



[gentoo-dev] Re: [gentoo-project] rfc: council members and appeals

2018-02-13 Thread Chí-Thanh Christopher Nguyễn
Ulrich Mueller schrieb:

> Don't vote for that person then? Why would we need a general rule
> restricting voters from electing any specific candidate?

For the same reason why governing bodies sometimes restrict accumulation of
mandates (and have term limits etc.). Of course the electorate can just vote
for another person, but that is not the point.

In the case of Gentoo, if one body is supposed to supervise the other,
holding positions in both can lead to problems. While this may be ok if one
of them is small and limited in scope, the more powerful both are the more
problematic it gets.


Best regards,
Chí-Thanh Christopher Nguyễn



[gentoo-dev] Re: [gentoo-project] rfc: council members and appeals

2018-02-13 Thread Chí-Thanh Christopher Nguyễn
Dean Stephens schrieb:

>> Suppose that the council decides to accept an appeal from comrel. Is it
>> a conflict of interest for a member of the council who is also a member
>> of comrel to vote in the appeal? If it isn't, it is at least a pretty
>> strong perception that it is.
>>
> Why? How? Exactly what sort of conflicting interest is supposed to be
> present?

I think in Comrel vs. Council is not a conflict of interest, but rather
throwing the appeals process off balance. Can you expect someone to neutrally
review material and actions (question the authenticity of evidence, identify
potential misconduct, etc.) that they themselves used to build the case
against the reprimanded?

Best regards,
Chí-Thanh Christopher Nguyễn



[gentoo-dev] Re: [gentoo-project] rfc: council members and appeals

2018-02-13 Thread Chí-Thanh Christopher Nguyễn
Dean Stephens schrieb:
>> QA and Comrel are special in that they can take disciplinary action against
>> non-members, which there is no recourse against except appeal to the Council.
>>
> At the very least: QA, Comrel, IRC ops (in every project specific
> channel), planet/universe, forums, and wiki.

Council, QA and Comrel are effectively the governing bodies of Gentoo,
enacting and/or enforcing project-wide policy on their own accord. The others
that you mention have only direct power in a very limited area.


Best regards,
Chí-Thanh Christopher Nguyễn



[gentoo-dev] Package up for grabs: games-engines/love

2018-02-01 Thread Chí-Thanh Christopher Nguyễn

Hi all!

Due to lack of time, I have to drop maintainership of games-engines/love.
There is some user interest in this package, and a version bump is 
needed (bug 640802).



Best regards,
Chí-Thanh Christopher Nguyễn




Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

2018-01-11 Thread Chí-Thanh Christopher Nguyễn

Michał Górny schrieb:

I guess you should have voiced your opinion back when discussion was
taking place instead of being hostile *now* because the Council listened
to what the developers requested.


The arguments why these posting restrictions are a pretty bad idea have 
all been voiced back then already. So no point in posting them again 
each time.


But of course it is also true that Council is elected by and acts on 
behalf of the developers. So my suggestion for developers who heavily 
disagree with this decision is to look at who voted which way in the 
public logs. Then read carefully who in their next Council election 
manifesto plans to lift this restriction again.



Best regards,
Chí-Thanh Christopher Nguyễn





Re: [gentoo-dev] LINGUAS to be removed from USE_EXPAND

2017-12-30 Thread Chí-Thanh Christopher Nguyễn
gro...@gentoo.org schrieb:

> The package sci-mathematics/maxima for ages uses linguas_* flags for
> installing translated documentation, the possible values of * are
> 
> de es pt pt_BR
> 
> This usage is, I suppose, wrong. I tried simply to replace all linguas_ to
> l10n_ in the ebuild, but repoman complains about pt_BR.

It should be l10n_pt-BR.
LINGUAS used POSIX locales which define _ as separator between language and
territory, while L10N uses BCP 47 which defines - as separator.


Best regards,
Chí-Thanh Christopher Nguyễn



Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

2017-12-14 Thread Chí-Thanh Christopher Nguyễn

gro...@gentoo.org schrieb:
If the developers of liblinebreak had not decided to rename their 
library, I could safely bump it from 2.1 to 4.0, in spite of the fact 
that it is maintainer-needed, right?
Am I personally responsible for their decision to use the new name 
libunibreak?


I think you could alternatively have used a pkgmove from liblinebreak to 
libunibreak, then do the bump.



Best regards,
Chí-Thanh Christopher Nguyễn



Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

2017-12-14 Thread Chí-Thanh Christopher Nguyễn

Michał Górny schrieb:

Breaking the dependency tree was a *honest* mistake on the person who
reverted this commit.

Andrey pretty clearly stated that he did this *on purpose*.


The removal of the package in violation of Gentoo policy was fully 
intentional from what I can see. There was no 30-day prior notice + 
p.mask which is required before removing a package.


But even that it is not bad, just fix that mistake.


Best regards,
Chí-Thanh Christopher Nguyễn





Re: [gentoo-dev] Manifest2 hashes, take n+1-th: 3 hashes for the tie-breaker case

2017-10-24 Thread Chí-Thanh Christopher Nguyễn
Michał Górny schrieb:
> Oh, and most notably, the speed loss will be mostly visible to users.
> An attacker would have to compute the additional hashes only
> if the fastest hash already matched, i.e. rarely. Users will have to
> compute them all the time.

That is currently the case with portage, but not an inevitable consequence of
having 3 hash functions in the Manifest. Portage could be made to check only
one or two of them (even by default), giving the tie-breaking ability to
those who need it, and speeding up things for those who don't.


Best regards,
Chí-Thanh Christopher Nguyễn



Re: [gentoo-dev] Manifest2 hashes, take n+1-th

2017-10-20 Thread Chí-Thanh Christopher Nguyễn
Michał Górny schrieb:
> to:
> 
>   manifest-hashes = SHA512 SHA3_512

+1

Just wondering about the performance argument on weak systems:
Does Portage absolutely have to check all of the hashes or can it be
configured by the user to check only a subset of them?


Best regards,
Chí-Thanh Christopher Nguyễn



Re: [gentoo-dev] last rites: app-text/acroread

2017-06-09 Thread Chí-Thanh Christopher Nguyễn

Jason A. Donenfeld schrieb:

RIP acroread.

The only PDF reader on linux that can properly parse PDF Reference XObjects.

Thou shall be missed.



I found the Chrome PDF reader (pdfium) to be a somewhat adequate 
replacement. pdfium recently gained the ability to deal with XFA forms, 
which are unsupported by most other PDF readers on Linux.


Alternatively you can use Wine to run the Windows version.


Best regards,
Chí-Thanh Christopher Nguyễn




Re: [gentoo-dev] [RFC] New global USE flag: unwind

2017-05-18 Thread Chí-Thanh Christopher Nguyễn

As there were no further comments or objections, I added to profiles/use.desc

unwind - Add support for call stack unwinding and function name resolution

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d62064cb2ac36c7443bd9dcd46019b9816c5ef9e


Best regards,
Chí-Thanh Christopher Nguyễn




Re: [gentoo-dev] [RFC] New global USE flag: unwind

2017-05-11 Thread Chí-Thanh Christopher Nguyễn

Michał Górny schrieb:

On czw, 2017-05-11 at 11:29 +0200, Chí-Thanh Christopher Nguyễn wrote:

Suggested description: Add support for stack traces and function name
resolution via sys-libs/libunwind

Maybe skip the library name. Note that there's also llvm-libunwind,
and some packages may be actually happy with libgcc_s.


Ok, then how about:
"Add support for stack trace unwinding and function name resolution"


I understand that dev-cpp/glog uses the unwind flag differently from the
other packages. If that is an issue that package's flag could be renamed
to "libunwind" as sys-libs/libcxx et al. currently use.


Yeah, that makes sense.



Reported:
https://bugs.gentoo.org/show_bug.cgi?id=618190


Best regards,
Chí-Thanh Christopher Nguyễn



[gentoo-dev] [RFC] New global USE flag: unwind

2017-05-11 Thread Chí-Thanh Christopher Nguyễn
Suggested description: Add support for stack traces and function name 
resolution via sys-libs/libunwind


That description is a little unwieldy though, better suggestions are 
welcome.


Currently in use by the following packages:

dev-cpp/glog:unwind - Use sys-libs/libunwind for stack unwinding instead 
of glibc/gcc (may be more reliable on x86_64)

dev-libs/efl:unwind - Enable debug support via sys-libs/libunwind
dev-libs/weston:unwind - Enable libunwind usage for backtraces
dev-util/ltrace:unwind - Use sys-libs/libunwind for frame unwinding support
dev-util/perf:unwind - Use sys-libs/libunwind for frame unwinding support.
dev-util/strace:unwind - Enable stack backtraces (-k flag) via 
sys-libs/libunwind
media-libs/gstreamer:unwind - Enable sys-libs/libunwind usage for better 
backtrace support in leaks tracer module
www-apache/mod_backtrace:unwind - Use sys-libs/libunwind to provide 
better resolution of function names.
x11-apps/intel-gpu-tools:unwind - Provide automatic stack traces on test 
failures

x11-base/xorg-server:unwind - Enable libunwind usage for backtraces

I understand that dev-cpp/glog uses the unwind flag differently from the 
other packages. If that is an issue that package's flag could be renamed 
to "libunwind" as sys-libs/libcxx et al. currently use.


Best regards,
Chí-Thanh Christopher Nguyễn





Re: [gentoo-dev] [RFC] News item: GCC 6 defaults to USE="pie ssp"

2017-05-10 Thread Chí-Thanh Christopher Nguyễn

Mike Gilbert schrieb:

I disagree. We might want to default the "pie" USE flag differently
depending on the profile, but there's no need to force it.


I think we should force the pie USE flag on/off depending on the profile.

My proposal:
For all profiles except hardened, introduce a pie/nopie variant.
Deprecate the nopie profiles once enough packages build successfully 
(maybe request a tinderbox run?)
In the profile depreciation message, point to a document how to migrate 
to pie.


Setting pie default depending on GCC version is not a good idea IMO.

Best regards,
Chí-Thanh Christopher Nguyễn




Re: [gentoo-dev] Bugzilla package list editing

2017-05-02 Thread Chí-Thanh Christopher Nguyễn

Paweł Hajdan, Jr. schrieb:


Please stop editing package lists when you are not the maintainer and
arches are already CCed.

+1

Please stop it.
And yes that's also true for arch team members.

Package list is maintainer territory.

Curious, what are the reasons and what changes people make that they
shouldn't?

I'm wondering if there's some solution to these issues (maybe better
documentation, or an alternative way of accomplishing what these people
try to do).


As dilfridge pur jer in CC, I guess that some of jer's changes to bugs 
were not welcomed by maintainers.


One recent example of non-maintainer activity in the package list field 
is bug 613104, where he just removed the entire package list (and then 
marked the bug WONTFIX).
Also very common is that he changes fully qualified package names (which 
is the correct syntax per [1]) into fully qualified package atoms (which 
is the legacy syntax). Bug 616260 is one such example.



Best regards,
Chí-Thanh Christopher Nguyễn

[1] https://bugs.gentoo.org/page.cgi?id=fields.html



Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc

2017-04-26 Thread Chí-Thanh Christopher Nguyễn

Michał Górny schrieb:

The most important goal of having the packages masked is that it would
cause Portage to verbosely complain whenever the users have it
installed. With appropriate comment (displayed by Portage), we could
clearly inform users that they need to upgrade gcc and switch to a new
version to ensure that majority of packages work.


Portage already tells users to run --depclean after each @world update, 
which will remove old gcc versions (except if stuff like gcj-jdk is 
installed).
What your proposal does is to remind users who don't act on the first 
message, or who never do world updates, do I get this right?



Best regards,
Chí-Thanh Christopher Nguyễn




Re: [gentoo-dev] [RFC] New Manifest hashes and how to enable them

2017-04-04 Thread Chí-Thanh Christopher Nguyễn

Michał Górny schrieb:

I think the first reasonable change would be to deprecate SHA256. It is
pretty much the same algorithm as SHA512, except for different
parameters. It is weaker than SHA512, and SHA512 is supported on all
existing platforms anyway.


I think there is nothing wrong or insecure with continuing to use 
SHA256, even though it is technically weaker than SHA512. If it is 
already included in all Manifests then keeping it as standard is 
preferable I think.


Some people consider having a second dissimilar algorithm at hand a good 
idea. I suggest SHA3 in that case.


manifest-hashes = SHA256 SHA3-256


Best regards,
Chí-Thanh Christopher Nguyễn




Re: [gentoo-dev] questions about small fixes/cleanups

2016-09-19 Thread Chí-Thanh Christopher Nguyễn

Kristian Fiskerstrand schrieb:

Why are those ebuilds not live? If upstream doesn't do real releases and
can't even be bothered to tag the commit that marks a release, then why
are you (or someone else) doing all this work? The snapshot scripts
could be replaced by a live ebuild and upstream can handle bugs as they
come since they can't be bothered to version their software.


I would expect because live ebuilds can't be keyworded, so snapshot is
the correct way to do it.


I think the rule of not keywording live ebuilds originally applied only to 
those who fetch git/svn/cvs head.
If a live ebuild fetches a particular revision, then the disadvantage is 
still that it can't be mirrored (hence a snapshot is preferable from user 
POV), but other than that it can be tested fine.



Best regards,
Chí-Thanh Christopher Nguyễn




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Lastrites: x11-misc/ardesia, app-benchmarks/phoronix-test-suite, www-apache/mod_fastcgi, x11-plugins/prpltwtr, net-misc/bopm, app-admin/389-ds-console,net-nds/389-admin,app-admin/389-

2016-08-30 Thread Chí-Thanh Christopher Nguyễn

Pacho Ramos schrieb:

# Pacho Ramos <pa...@gentoo.org> (21 Aug 2016)
# Unmaintained, broken in several ways, try to use linux-firmware, bug
# #508848. Removal in a month.
media-tv/linuxtv-dvb-firmware


It should be noted that linux-firmware is not a replacement for 
linuxtv-dvb-firmware. Only one firmware file is present in both packages. 
Users might better be pointed to the perl script

/usr/src/linux/Documentation/dvb/get_dvb_firmware
instead.


Best regards,
Chí-Thanh Christopher Nguyễn




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] versionator.eclass: Add tests for parameter counts

2016-07-24 Thread Chí-Thanh Christopher Nguyễn

Chí-Thanh Christopher Nguyễn schrieb:

I don't say it is a correct use of versionator.eclass. I just say it has
become (unintentionally) part of the API, and therefore is subject to the
rules about changing APIs in eclasses.


Actually, after reading those rules[1] again, it would be enough to fix all 
ebuilds in the tree and wait 30 days to be in compliance with eclass policy.


So from my side I will no longer object to your proposed change, provided 
these conditions are met.



Best regards,
Chí-Thanh Christopher Nguyễn

[1] https://devmanual.gentoo.org/eclass-writing/




Re: [gentoo-dev] [PATCH] versionator.eclass: Add tests for parameter counts

2016-07-24 Thread Chí-Thanh Christopher Nguyễn

Michał Górny schrieb:

You are changing the API of versionator.eclass, even if it was unintentional 
API.


There is no such thing as 'unintentional API'. API is what's described.
If you rely on internals, random undefined behaviors or whatever, it's
not a part of the API.


Well there is the API according to the docs, and then there is the API 
according to the implementation...



Then ebuilds will fail just the same


No. Before, ebuilds would maybe display an upgrading message when they
shouldn't, or vice versa. Now the eclass dies on them.


So what's the alternative? Design another eclass where ebuilds will
fail just the same because people will ignore the more explicit
requirement just the same as they do ignore the API?


I don't know what is your problem here. The eclass needs not be designed 
again from the ground up.
All ebuilds which are unaffected by bug 589444 can be switched to the new 
eclass/functions immediately. The others after they are changed no longer 
make the implicit assumption that REPLACING_VERSIONS contains only a single 
version.



The problem is not 'there is a valid case to pass useless parameters
to the function'. The problem is 'I make an invalid assumption about
what will happen based on my limited knowledge which I believe is
more correct than people who wrote package managers'.


I don't say it is a correct use of versionator.eclass. I just say it has 
become (unintentionally) part of the API, and therefore is subject to the 
rules about changing APIs in eclasses. I agree that relying on unintentional 
or undocumented API is bad and needs to be addressed.



Best regards,
Chí-Thanh Christopher Nguyễn




Re: [gentoo-dev] [PATCH] versionator.eclass: Add tests for parameter counts

2016-07-24 Thread Chí-Thanh Christopher Nguyễn

Ciaran McCreesh schrieb:

On Sun, 24 Jul 2016 10:17:24 +0200
Chí-Thanh Christopher Nguyễn <chith...@gentoo.org> wrote:

Then ebuilds will fail just the same


No. Before, ebuilds would maybe display an upgrading message when
they shouldn't, or vice versa. Now the eclass dies on them.


This attitude that invisible failures (which don't get fixed, and which
lead to occasional weirdness) are better than visible failures (which
must be fixed) is an odd one... Postel has a lot to answer for.


I would agree with you when it comes to upstreams' -Werror but I do realize 
that I am in the minority there.


My point here is that this change will affect the behaviour of ebuilds using 
this eclass.



Best regards,
Chí-Thanh Christopher Nguyễn




Re: [gentoo-dev] [PATCH] versionator.eclass: Add tests for parameter counts

2016-07-24 Thread Chí-Thanh Christopher Nguyễn

Michał Górny schrieb:

So, to summarize we shouldn't fix existing code because people did
assume accepting invalid parameters was fine.


You are changing the API of versionator.eclass, even if it was unintentional 
API.


Then ebuilds will fail just the same


No. Before, ebuilds would maybe display an upgrading message when they 
shouldn't, or vice versa. Now the eclass dies on them.



Best regards,
Chí-Thanh Christopher Nguyễn




Re: [gentoo-dev] [PATCH] versionator.eclass: Add tests for parameter counts

2016-07-23 Thread Chí-Thanh Christopher Nguyễn

Michał Górny schrieb:

Ensure that proper number of parameters is passed to each versionator
function; die otherwise. This prevents the functions from proceeding
with undefined behavior when mis-called.


You are making what versionator.eclass accepts stricter. That it used to work 
when passed multiple versions may be unintentional, but I think you need to 
introduce a new eclass or new function names in this case.



Best regards,
Chí-Thanh Christopher Nguyễn




Re: [gentoo-dev] Signed push & clock drift rejection

2016-07-19 Thread Chí-Thanh Christopher Nguyễn

waltd...@waltdnes.org schrieb:

And even if the system is behind time, it can cause problems. cronjobs
running unexpectedly close to each other (or missed cronjobs in extreme
cases). User sessions expiring early, etc.

And even if there is only one second, and that is known well ahead
(e.g. leap seconds): Unless you know that there isn't going to be
a problem, a great deal of care needs to go into handling that.

   In that case, the dev machine should be a separate machine from the
server.  They don't even have to be separate physical machines.  Do the
dev work in a VM, and set the time in the VM just before doing the push.


I am not talking about bircoph's dev machine, I am explaining why ntpd 
works the way it does. Which usually doesn't lead to problems as the 
drift will be corrected sooner or later. So there was never a problem 
nor reason for action in either case, until it was decided that 5 
seconds is the maximum drift for a push to gentoo.git.



Best regards,
Chí-Thanh Christopher Nguyễn




Re: [gentoo-dev] Signed push & clock drift rejection

2016-07-19 Thread Chí-Thanh Christopher Nguyễn

Kent Fredric schrieb:

On Mon, 18 Jul 2016 22:21:22 -0400
waltd...@waltdnes.org wrote:


   I'm amazed that "robust linux servers" are deathly afraid of simply
setting the time, and being done with it.


There's problems at the software level everywhere that are not so
simply solved.

A more obvious example is in the event your system time gets *ahead* of
real-time.


And even if the system is behind time, it can cause problems. cronjobs 
running unexpectedly close to each other (or missed cronjobs in extreme 
cases). User sessions expiring early, etc.


And even if there is only one second, and that is known well ahead (e.g. leap 
seconds): Unless you know that there isn't going to be a problem, a great 
deal of care needs to go into handling that.



Best regards,
Chí-Thanh Christopher Nguyễn




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] the graveyard overlay

2016-07-08 Thread Chí-Thanh Christopher Nguyễn

Rich Freeman schrieb:

On Fri, Jul 8, 2016 at 2:22 PM, Chí-Thanh Christopher Nguyễn
<chith...@gentoo.org> wrote:

I think the point of a graveyard repository is that discovering and
extracting deleted ebuilds from git is more cumbersome than from CVS attic.

It would be even better if the graveyard repository preserved the commit
history, but I don't see any easy solution for that.



Like I said.  If the only use case is helping people who don't know
how to use git find deleted ebuilds, then just create a directory tree
with everything that was ever in the Gentoo repo.  That would be
pretty easy to script.  QA doesn't need to have anything to do with
it.


I'm sorry for harping on that topic again, but if we had used grobian's 
initial proposal for git migration[0] - one repository per package, and the 
portage tree would be an aggregation of those - then we could have such a 
thing basically for free now.


But that's how it is now. Getting ebuilds from CVS attic could be done via 
the sources.g.o web interface even, no local checkout needed.



Best regards,
Chí-Thanh Christopher Nguyễn

[0] 
https://archives.gentoo.org/gentoo-dev/message/753620a99ab88b9525a253590617db3c




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] the graveyard overlay

2016-07-08 Thread Chí-Thanh Christopher Nguyễn

Rich Freeman schrieb:

You say that there are no bugs in those packages. How do you know? You
don't know unless you test it, and no maintainer means nobody is known
to test it regularly. The package can be pretty much completely broken
and we'll not know unless someone tests it.



This sounds like a tree falling in the forest with nobody around...

If a package is in the tree, and it has no known bugs, and no users,
who cares?

If somebody tries to use it, and it doesn't work, then they can file a
bug, and then we can treeclean it.


One might add here that toralf is doing a great job at building all packages 
and reporting those that fail. So at least we see build failures.



Having a graveyard that ONLY contains broken stuff as an overlay just
doesn't make sense to me.  Why would you install packages directly
from it without fixing them first?  Certainly for build failures you'd
be forced to do this.  I guess for security issues you could decide
that you don't care, or that your host is in a locked room with no
network access or something.  However, these seem like such minor use
cases that somebody could just stick the ebuilds in their own overlay
if they needed them.


I think the point of a graveyard repository is that discovering and 
extracting deleted ebuilds from git is more cumbersome than from CVS attic.


It would be even better if the graveyard repository preserved the commit 
history, but I don't see any easy solution for that.



Best regards,
Chí-Thanh Christopher Nguyễn




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC: BCP 47 for L10N?

2016-06-10 Thread Chí-Thanh Christopher Nguyễn

Michał Górny schrieb:

On the other hand, there will be some cost:
- If BCP 47 tags containing a script or a variant should be used to
  generate LINGUAS, they will require explicit mapping. (OTOH, such
  mapping will also be needed if we stick to Gettext syntax but unify
  variants like "sr@latin" and "sr@Latn".)
- Different syntax for LINGUAS and L10N might be confusing to users,
  so additional documentation will be needed.


As pointed out below, users better not mess with LINGUAS anyway. But one 
thing which might still cause confusion is that LANG and L10N use 
different syntax if we decide for BCP 47.




Comments?

I'd say BCP-47.


+1 for BCP-47


The gettext tags aren't 100% defined anyway, so we'd end up having to choose 
between one upstream and another eventually, and map to the other.


Worse, gettext locales, while apparently designed to resemble POSIX 
locales, can change at any time without notice and may be different 
between glibc versions.



Also, when it makes mapping L10N to LINGUAS harder, it will discourage people 
from abusing the latter.



Best regards,
Chí-Thanh Christopher Nguyễn




Re: [gentoo-dev] [RFC] Global USE=gui

2016-06-09 Thread Chí-Thanh Christopher Nguyễn

Michał Górny schrieb:



2. Packages use REQUIRED_USE to force an appropriate choice.


That would be a policy violation. Packages should pick a reasonable
default if flags are conflicting, but not force users to micro-manage
their flags.


Who did establish that *idiotic* policy and why is he still
a developer? The whole *point of USE Flags* is to let people
micro-manage stuff. Picking up a random default makes flags
meaningless, confusing and makes it impossible to establish
appropriate USE dependencies.


I assume "micro-manage" means users maintaining extensive lists of 
per-package flags in package.use, which I agree with ulm is to be avoided.


Setting the USE flags once in make.conf would not qualify as micro-managing 
in my opinion.


There is an exception though, in cases where this breaks reverse USE 
dependencies, it may be allowed and necessary to use REQUIRED_USE[0].



Best regards,
Chí-Thanh Christopher Nguyễn

[0] 
https://devmanual.gentoo.org/general-concepts/use-flags/index.html#conflicting-use-flags




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] The future of the Sunrise project

2016-06-08 Thread Chí-Thanh Christopher Nguyễn

Michał Górny schrieb:

Therefore, I'd like to ask the following question: is it time to
announce the project dead, or do some developers want to revive it?
If the former, could someone try to contact last active contributors
and ask them if they'd like to move their ebuilds to ::gentoo
via proxy-maint?


I agree that the Sunrise repository should be removed from 
repositories.xml. I don't know if there is any way of informing users 
beforehand of this change happening. If not, then a grace period is 
probably pointless.


Moving ebuilds to proxy-maint and ::gentoo is complicated by the fact 
that there is no concept of maintainer in sunrise. (This is also why we 
were stricter than the portage tree, because the original committer 
might not be around when the next person would have to make changes.)
As every package in sunrise has an associated maintainer-wanted bug, it 
would be good to post a message to each such bug to encourage interested 
users to contact proxy-maint.



I should point out that Sunrise has lost a lot of popularity to
proxy-maint, then also to GitHub pull requests (and the two combined).
The developers involved with those provide quite a good review
workflow, with the extra advantage of getting packages straight
into ::gentoo. I don't know how many users would be interested
in keeping them in ::sunrise if they could have them straight
in ::gentoo with similar (if not less...) effort.

Your thoughts?


I do think there is value in having a user repository. There are 
different ways to manage it: curated, non-curated, only trusted users 
get access, everybody gets access, etc. Sunrise is on one end of the 
spectrum and bgo-overlay probably on the other. The Sunrise approach 
ultimately did not scale and hinged on developers doing most of the work 
that proxy-maint would do but ending up in a much less visible repository.


Maybe an approach similar to what grobian initially suggested for the 
portage tree git migration[0] would be a good idea: Have individual 
user-managed repositories for packages, and an automated script that 
merges them. But of course someone needs to step up and make it happen.



[1]:https://wiki.gentoo.org/wiki/Project:Sunrise


Until further steps are decided, I'll add a statement that the project 
is inactive and refer people to proxy-maintainers.



Best regards,
Chí-Thanh Christopher Nguyễn

[0] 
https://archives.gentoo.org/gentoo-dev/message/753620a99ab88b9525a253590617db3c




Re: [gentoo-dev] News item: LINGUAS USE_EXPAND renamed to L10N

2016-06-07 Thread Chí-Thanh Christopher Nguyễn

Ulrich Mueller schrieb:

POSIX.1-2008[2] as you mentioned defines a slightly different format
for locales



language[_territory][.codeset]



Only LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_NUMERIC, and
LC_TIME additionally accept specification of a modifier.



[language[_territory][.codeset][@modifier]]



Where territory is implementation defined and the modifier
"select[s] a specific instance of localization data within a single
category". Which I think does not match what we want with "valencia"
variant of the "ca" language.


As I understand it:

1. Gettext documentation says that locale names can be LL_CC or
LL_CC@VARIANT. The natural mapping to the (implementation defined)
format mentioned by POSIX seems to be that LL, CC, and VARIANT
correspond to language, territory, and modifier, respectively.

2. Language codes are taken from ISO 639, namely the two-letter code
if one exists, otherwise the three-letter code.


Yes.


3. Territory codes are taken from ISO 3166-1, usually the two-letter
country codes.


Yes.


4. According to Gettext documentation, "'@VARIANT' can denote any kind
of characteristics that is not already implied by the language LL and
the country CC." (So IIUC the BCP-47 variant "valencia" would become
"@valencia".)


This I think is wrong and collides with POSIX.
POSIX modifiers are not allowed for LANG or LC_ALL in POSIX.1-2008[1]
Section 8.2 says you can have at most one modifier field to "select a 
specific instance of localization data within a single category", which I 
don't think applies because it is its own locale, not an instance of an 
existing one. Furthermore (but that doesn't apply in our use case), POSIX 
spec lists the example

LC_COLLATE=De_DE@dict
So what if you want Catalan Valencian with dictionary order? Or if someone 
hypothetically came up with a different script?



Hence I think POSIX locale cannot handle Catalan Valencian, unless
territory is made accept ISO3166-2 region subdivisions.


I haven't found any mention or usage of ISO 3166-2 region subdivisions
in the context of locale. Can you provide any references for this?


As I wrote before, it is not used. But I think it is the only spec-compliant 
way to marry POSIX locales with Catalan Valencian. BCP-47 does it in a more 
natural way.



Best regards,
Chí-Thanh Christopher Nguyễn

[1] 
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_02




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] News item: LINGUAS USE_EXPAND renamed to L10N

2016-06-06 Thread Chí-Thanh Christopher Nguyễn

Ulrich Mueller schrieb:

On Mon, 6 Jun 2016, Chí-Thanh Christopher Nguyễn wrote:

Ulrich Mueller schrieb:

Question related to this, do we take the opportunity to standardise
the values? Looks like the vast majority follows
language[_territory][@modifier] specified by POSIX [1] but some
don't.

What do we do with locales that don't fit into this scheme? Catalan
Valencian is one such locale.
Packages currently use modifiers (ca@valencia) or ISO 3166-1
reserved area (ca_XV) or something entirely different (ca_valencia).

According to [1], "valencia" is a valid variant subtag, therefore
ca@valencia should be fine.


ISO 3166-1:ES defines ES-VC as region code, so maybe ca_ES-VC would
be best. Though a quick Google search didn't find any major usage of
that either.

Neither XV nor ES-VC are registered as a subtag though, so presumably
these should be avoided.


I'm not totally convinced yet.
Following the BCP-47 spec the format is

Language-Tag  = langtag ; normal language tags
langtag   = language
 ["-" script]
 ["-" region]
 *("-" variant)
 *("-" extension)
 ["-" privateuse]

So using the language ca, region es, and variant valencia, the BCP-47 
language tag is ca-es-valencia (or ca-valencia if you omit the region).


POSIX.1-2008[2] as you mentioned defines a slightly different format for 
locales


language[_territory][.codeset]

Only LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_NUMERIC, and 
LC_TIME additionally accept specification of a modifier.


[language[_territory][.codeset][@modifier]]

Where territory is implementation defined and the modifier "select[s] a 
specific instance of localization data within a single category". Which 
I think does not match what we want with "valencia" variant of the "ca" 
language.


Hence I think POSIX locale cannot handle Catalan Valencian, unless 
territory is made accept ISO3166-2 region subdivisions.



Best regards,
Chí-Thanh Christopher Nguyễn

[1] https://tools.ietf.org/rfc/bcp/bcp47.txt
[2] 
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_02





Re: [gentoo-dev] News item: LINGUAS USE_EXPAND renamed to L10N

2016-06-06 Thread Chí-Thanh Christopher Nguyễn

Ulrich Mueller schrieb:

On Mon, 06 Jun 2016, Mart Raudsepp wrote:



Usually only two letter language codes suffice, but can be limited with
country codes with a 'll_CC' formatting, where 'll' is the language code
and 'CC' is the country code, e.g en_GB. Some rare languages also have
three letter language codes.


s/country code/territory code/g

Question related to this, do we take the opportunity to standardise
the values? Looks like the vast majority follows
language[_territory][@modifier] specified by POSIX [1] but some don't.


What do we do with locales that don't fit into this scheme? Catalan Valencian 
is one such locale.
Packages currently use modifiers (ca@valencia) or ISO 3166-1 reserved area 
(ca_XV) or something entirely different (ca_valencia).
ISO 3166-1:ES defines ES-VC as region code, so maybe ca_ES-VC would be best. 
Though a quick Google search didn't find any major usage of that either.



Best regards,
Chí-Thanh Christopher Nguyễn




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] New global USE flag: webp

2016-06-04 Thread Chí-Thanh Christopher Nguyễn

Kristian Fiskerstrand schrieb:

Personally I'da thought an ewarning would be sufficient based on the old
flag, and perhaps a news item if considered important enough?!



as long as it is sufficient time and it notifies ahead of time, and the
new use flag can be added to package.use immediately, indeed, although I
believe an elog is more appropriate than ewarn in that case.


I vaguely remember that this can be done automatically, through 
config_protect to create/update a package.use entry.


Don't ask me on any details though. ;)


Best regards,
Chí-Thanh Christopher Nguyễn



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [RFC] New global USE flag: webp

2016-06-04 Thread Chí-Thanh Christopher Nguyễn

Suggested description: Add support for the WebP image format
Currently in use by the following packages:

app-text/tesseract:webp - Enable support for webp image format.
dev-games/aseprite:webp - Enable webp image format support
dev-libs/DirectFB:webp - build WebP image provider
dev-libs/efl:webp - Enable WebP image loader
dev-python/pillow:webp - Enable support for webp image format.
dev-qt/qtwebkit:webp - Add support for WebP image format
media-gfx/darktable:webp - Enable WebP export support
media-gfx/fbida:webp - Enable support for the WebP image format
media-gfx/graphicsmagick:webp - Enable support for webp image format
media-gfx/gthumb:webp - Enable support for webp image format
media-gfx/imagemagick:webp - Enable webp image format support using 
media-libs/libwebp

media-gfx/imageworsener:webp - enable webp image format support
media-gfx/nomacs:webp - Build support for WEBP image format
media-gfx/qiviewer:webp - Build support for WEBP image format
media-libs/gd:webp - Enable support for the webp format
media-libs/gegl:webp - Enable support for media-libs/libwebp
media-libs/jbig2enc:webp - Add support for WEBP image format
media-libs/leptonica:webp - Adds support for the WebP image format
media-libs/opencv:webp - Enable support for webp image format
media-libs/sdl-image:webp - support loading WEBP images
media-libs/sdl2-image:webp - support loading WEBP images
media-video/ffmpeg:webp - Enables WebP encoding with media-libs/libwebp.
media-video/libav:webp - Enable WebP encoding with media-libs/libwebp.
www-client/netsurf:webp - WebP image support (media-libs/libwebp)
x11-wm/windowmaker:webp - Enables WebP image format support using 
media-libs/libwebp

x11-wm/xpra:webp - Enable webp image format support



Best regards,
Chí-Thanh Christopher Nguyễn



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Masterplan for solving LINGUAS problems

2016-05-31 Thread Chí-Thanh Christopher Nguyễn

Michał Górny schrieb:

Request changing LINGUAS to L10N
in make.conf, and make LINGUAS considered an 'advanced variable' for
implicit localization control (i.e. passed through to build systems).
Recommend clean INSTALL_MASK solution instead.


Can we have this change happen (semi-)automatically, via config_protect?
Also, will there be a transition period where users need to have both 
variables set?



Best regards,
Chí-Thanh Christopher Nguyễn




Re: [gentoo-dev] [PATCH 07/17] profiles: Remove unused INPUT_DEVICES

2016-05-26 Thread Chí-Thanh Christopher Nguyễn

Michał Górny schrieb:

-none - INPUT_DEVICES setting to build no drivers (useful when using binary 
drivers)


Not sure about this one, I think it was never used nor intended to be ever 
used. Same for VIDEO_CARDS.

Otherwise looks fine to me.


Best regards,
Chí-Thanh Christopher Nguyễn



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

2016-05-14 Thread Chí-Thanh Christopher Nguyễn

Gordon Pettey schrieb:


So, it's perfectly okay to make direct commits of obviously broken code that
has no chance of working, because community something mumble...


You may have missed some sarcasm in the post which you replied to.
Plus, I don't think anybody said or implied that committing broken things is ok.


Best regards,
Chí-Thanh Christopher Nguyễn



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Changing order of default virtual/udev provider

2016-02-17 Thread Chí-Thanh Christopher Nguyễn

Michał Górny schrieb:

systemd and udev share the same codebase. You can no longer build udev
without systemd. udev is only a sub-project of systemd now, hence the
name "systemd-udevd".


Of course, sure. But since you seem not to be able to understand
basics: this *does not* mean Lennart is the only person having
influence on how udev progresses. Sharing the same repository
and utility libraries is not the same as being the same thing.


Ok, apparently I am too dense to understand that the someone who is the lead 
developer and visionary of a project naturally has the same say as someone 
who is only bickering from the sidelines. Maybe if you had pointed out a 
systemd developer who disagreed with Lennart's words I could have seen the 
light earlier.


Also I am obviously unable to understand that when the kernel folks 
complained about the "new maintainers" of udev breaking things, they would of 
course never suspect that these "new maintainers" have anything to do with 
systemd at all.


http://thread.gmane.org/gmane.linux.kernel/1368617

Seriously. You gave good reasons why udev should remain the default over 
eudev, I acknowledged as much already. But do not continue the path of 
labelling your opponents as stupid and their arguments as FUD, because this 
is clearly not the case. It really doesn't help your argument, it just makes 
you look bad.




Best regards,
Chí-Thanh Christopher Nguyễn




Re: [gentoo-dev] Changing order of default virtual/udev provider

2016-02-17 Thread Chí-Thanh Christopher Nguyễn

Michał Górny schrieb:

With the exception that Lennart Poettering is the lead developer of
systemd/udev, while such a thing cannot be said about you and eudev.

He's lead developer of *systemd*. udev is a split part of systemd
codebase which has specific maintainers.


systemd and udev share the same codebase. You can no longer build udev 
without systemd. udev is only a sub-project of systemd now, hence the 
name "systemd-udevd".



Best regards,
Chí-Thanh Christopher Nguyễn




Re: [gentoo-dev] Changing order of default virtual/udev provider

2016-02-17 Thread Chí-Thanh Christopher Nguyễn

Michał Górny schrieb:

In a follow-up, upstream wrote about how you should only run udev together
with systemd, and if you don't want to do that (spelling as in original):

"we will not support the udev-on-netlink case anymore. I see three options:
a) fork things, b) live with systemd, c) if hate systemd that much, but
love udev so much, then implement an alternative userspace for kdbus to
do initialiuzation/policy/activation."
https://lists.freedesktop.org/archives/systemd-devel/2014-May/019664.html

So it seems a bit more than only initialization is needed.

You're missing the third option which is a sane option, and jump
straight to pitchforks.


Are you serious? The quoted line directly above your comment shows 
clearly that I have read and understood the third option.



If Lennart's single statement from 2014 is a reason to use eudev
instead of systemd-udevd, my statement from today is a more important
reason not to use eudev.


With the exception that Lennart Poettering is the lead developer of 
systemd/udev, while such a thing cannot be said about you and eudev.



Best regards,
Chí-Thanh Christopher Nguyễn




Re: [gentoo-dev] Changing order of default virtual/udev provider

2016-02-16 Thread Chí-Thanh Christopher Nguyễn

Alexis Ballier schrieb:

If it's just that, it's not limited to udev, but anything using
kdbus/bus1, and would mean openrc/${favorite init system} will have
to do the same thing anyway. But again, almost 2 years is extremely
old considering all the flux that has been around kbus.


OpenRC itself can for now just ignore kdbus, bus1, or whatever kernel
IPC system comes next.


Well, as Lennart wrote it, kbus would have needed some initialisation.
Just like we have a dbus init script, openrc would have a kdbus one.


But if upstream udev makes use of the systemd
userspace interface to the kernel IPC system, then OpenRC would have
to implement the same interface in order to have working udev.


As I understand it, a kernel IPC doesn't need systemd to work. udev
might use wrappers from libsystemd, or libbus1, just like we have
programs using libv4l or libbluetooth currently.


In a follow-up, upstream wrote about how you should only run udev together 
with systemd, and if you don't want to do that (spelling as in original):


"we will not support the udev-on-netlink case anymore. I see three options:
a) fork things, b) live with systemd, c) if hate systemd that much, but
love udev so much, then implement an alternative userspace for kdbus to
do initialiuzation/policy/activation."
https://lists.freedesktop.org/archives/systemd-devel/2014-May/019664.html

So it seems a bit more than only initialization is needed.


Also given the close relationship between systemd and udev, there is
no guarantee that supporting other users of kdbus/bus1 will make udev
automagically work. As these two are released together, there is no
reason to have a stable, public API between them.


Yes, which would mean systemd requires matching udev, not the other way
around. I'm a bit clueless here: Do you have any pointers on the recent
trends on this side ?


I have only upstream's statements from 2014. They talk about a kdbus 
userspace that systemd will provide to udev, which will be necessary for udev 
to function.
If and when upstream comes forward with statements about whether udev will 
only use public and stable API, these concerns could be either dispelled or 
confirmed.



Best regards,
Chí-Thanh Christopher Nguyễn




Re: [gentoo-dev] Changing order of default virtual/udev provider

2016-02-16 Thread Chí-Thanh Christopher Nguyễn

Brian Dolbec schrieb:

Thank you for bringing this information to the forefront of this debate.

So, is it not better for us Gentoo-er's that wish to not install
systemd, to set the default non-systemd udev to eudev.


Note that I am not advocating for or against this move. I was just pointing 
out what I consider bad arguments.


This includes labeling valid concerns as "pure FUD", and calling a move 
"definitely premature" when it was only circumstances beyond udev upstream's 
control which prevented it from becoming a necessity.


I do feel that the eudev critics are correct in pointing out that both the 
real-world exposure of eudev so far and the size of its development team are 
too small. Whether it is a good idea to attempt to increase them by making 
eudev the Gentoo default I don't think I am qualified to answer.



Best regards,
Chí-Thanh Christopher Nguyễn




Re: [gentoo-dev] Changing order of default virtual/udev provider

2016-02-16 Thread Chí-Thanh Christopher Nguyễn

Alexis Ballier schrieb:

I also fail to see how udev using a new linux ipc would make it require
systemd. Quoting Lennart:
"You need the userspace code to set up the bus and its policy and handle
activation. That's not a trivial task. For us, that's what sytemd does
in PID 1. You'd need to come up with an alternative for that."

If it's just that, it's not limited to udev, but anything using
kdbus/bus1, and would mean openrc/${favorite init system} will have to
do the same thing anyway. But again, almost 2 years is extremely
old considering all the flux that has been around kbus.


OpenRC itself can for now just ignore kdbus, bus1, or whatever kernel 
IPC system comes next. But if upstream udev makes use of the systemd 
userspace interface to the kernel IPC system, then OpenRC would have to 
implement the same interface in order to have working udev.


Also given the close relationship between systemd and udev, there is no 
guarantee that supporting other users of kdbus/bus1 will make udev 
automagically work. As these two are released together, there is no 
reason to have a stable, public API between them.



Best regards,
Chí-Thanh Christopher Nguyễn




Re: [gentoo-dev] Changing order of default virtual/udev provider

2016-02-16 Thread Chí-Thanh Christopher Nguyễn
Sorry about the messed up quoting, somehow enigmail and format=flowed do 
not work well together.




Re: [gentoo-dev] Changing order of default virtual/udev provider

2016-02-16 Thread Chí-Thanh Christopher Nguyễn

Alexis Ballier schrieb:

It would probably generate controversy indeed, but my comment was more
to understand what is the root of the f34R of udev being absorbed by
systemd: "it is supposedly unsupported upstream and might not work at
some point".
Well, as far as I can see, you are maintaining sys-fs/udev standalone
and don't intend to drop it. Even if you did, we could still pkgmove it
to systemd. My conclusion is that this claim of udev being a dead end
is pure FUD.


This claim was made by upstream, no less. And it refers to *running* 
udev without systemd as opposed to building (which upstream already made 
impossible).


Here is the exact wording:
"Unless the systemd-haters prepare another
kdbus userspace until then this will effectively also mean that we will
not support non-systemd systems with udev anymore starting at that
point. Gentoo folks, this is your wakeup call."
https://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html

Not sure what about this is FUD.


Best regards,
Chí-Thanh Christopher Nguyễn





boot loader in @system, was Re: [gentoo-dev] Changing order of default virtual/udev provider

2016-02-09 Thread Chí-Thanh Christopher Nguyễn

William Hubbs schrieb:

A boot loader is also needed for a working system, but we do not > have one in 
@system. Instead, we direct the user to choose one.


Actually it is not strictly necessary to install a separate boot
loader. On EFI systems (arm and x86, not ia64 though), the kernel's
EFI stub will function as boot loader.


Best regards,
Chí-Thanh Christopher Nguyễn






Re: [gentoo-dev] Gentoostats

2016-01-24 Thread Chí-Thanh Christopher Nguyễn

Andreas K. Hüttel schrieb:

And it would be extremely useful how many of our maintainer-needed
packages are actually still compiled once per year. (Or if any one
single person even uses KDE on ppc64.)

Gentoostats is a typical stillbirth of the Gentoo Google Summer of
Soon- Obsolete Code. Would I be happy if someone were to revive and
actually deploy it (the last point is important!)? YES!


Actually there is something in use already which would allow you to find
out which packages are compiled when. It is a community website called GenTwoo:

http://gentwoo.elisp.net/

There is not all information visible, and there could be some improvements
of course, but it exists.

Best regards,
Chí-Thanh Christopher Nguyễn




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: [gentoo-dev-announce] Goodbye Java on ppc32?

2016-01-10 Thread Chí-Thanh Christopher Nguyễn

James Le Cuirot schrieb:
At the end of the day, it's not the JVM that's the biggest time  > sink but testing the various Java packages on yet another > 

architecture.
[...]
So please let me know if you have been using Java on this platform.  > I did wonder whether we had any users at all but one has spoken up > 

in #gentoo-powerpc.

I have been building and experimenting with Java stuff on my PowerBook
G4, but more out of curiosity than out of need.
If testing is the obstacle that prevents continued support then I can
volunteer to help out with that.

But I don't need it, and if it makes life easier for you, I think
dropping it is fine. Maybe also post an announcement in the forums.


Best regards,
Chí-Thanh Christopher Nguyễn






[gentoo-dev] New project: Radio

2016-01-01 Thread Chí-Thanh Christopher Nguyễn

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi!

I would like to announce the Radio project.
Its purpose is maintaining the packages which are currently in the radio herd.

https://wiki.gentoo.org/wiki/Project:Radio

Best regards,
Chí-Thanh Christopher Nguyễn
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlaHBrIACgkQ+gvH2voEPRDOiwCfRMG/W9ukwbe/OkJLO2arze8x
sicAn0o/zwfEIG2oDCEfkjZMYpp61pfV
=klvD
-END PGP SIGNATURE-



Re: [gentoo-dev] Need clear semantics for packages with binary entities

2015-12-30 Thread Chí-Thanh Christopher Nguyễn

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

trupa...@gmail.com schrieb:
| I’m suffering from the fact that users can distinguish packages
| containing binaries just by eye. There is no mechanism to allow/ignore
| such packages.

| 7. to be continued... I guess
7. fonts which come precompiled instead of being built from source (e.g.
through fontforge)
8. artwork which is pre-rendered to bitmap formats but originally sourced
from vector graphics (e.g. KDE icons)
9. packages which download additional binary things later (Android SDK,
hplip depending on your printer)
10. documentation which is downloaded as PDF but not as DocBook/TeX/... sources
11. ... (I'm sure there are more)

| I wonder if Gentoo’s devs can do something with the problem. I think
| it’s problem in source-based Linux distribution.

I believe that Debian uses the term "preferred form for modification" to
describe/categorize their builds in that regard.


Best regards,
Chí-Thanh Christopher Nguyễn

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlaEc1UACgkQ+gvH2voEPRCi6QCeNFoY/NWU0zXqf8B/F2tm1ZaB
y7QAni7MdYwoOQHn/1xQd8x2lsB5zc4n
=yQrF
-END PGP SIGNATURE-



Re: [gentoo-dev] ChangeLog

2015-11-04 Thread Chí-Thanh Christopher Nguyễn

hasufell schrieb:


If you want to improve the situation, go talk to git upstream
and send patches.


Or do what Andrew suggested should happen.


Best regards,
Chí-Thanh Christopher Nguyễn




Re: [gentoo-dev] ChangeLog

2015-11-04 Thread Chí-Thanh Christopher Nguyễn

hasufell schrieb:

On 11/04/2015 09:56 AM, Andrew Savchenko wrote:

No, it is not. The whole git tree is insecure and no better than
rsync or CVS in terms of data security because SHA1 is vulnerable.


Another one who is confusing _any_ collision with _preimage attack_ ;)


While Andrew's view is very pessimistic here, yours is decidedly optimistic.

There is no known computationally feasible preimage attack against MD5, 
still that hash function is broken in serious ways with attacks already 
having real-world consequences.


It would be quite naïve to assume that SHA1 will remain secure until a 
preimage attack is found.



Best regards,
Chí-Thanh Christopher Nguyễn





Re: [gentoo-dev] Re: ChangeLog

2015-11-03 Thread Chí-Thanh Christopher Nguyễn

Matt Turner schrieb:
The git transition had been 9 years in the making and has massively 
improved Gentoo development. Look at the graph of contributions per 
month: https://www.openhub.net/p/gentoo


I'd like to point out that some stuff that has previously been done in a 
single commit is now several commits (e.g. bump + removal of old 
version). How much of the rise in commit activity is attributable to 
actual development increase is not clear to me.



Best regards,
Chí-Thanh Christopher Nguyễn




Re: [gentoo-dev] Depending on a range of slots

2015-11-02 Thread Chí-Thanh Christopher Nguyễn
hasufell schrieb:
>>>> Followup question, which of these is less dumb?
>>>>
>>>> Option 1: berkdb? ( >=sys-libs/db-4:*  >>
>>> This doesn't mean what you think it means. A user who has db-3 and db-7
>>> installed satisfies that dependency.
>>>
>>
>> Indeed, thanks.
>>
> 
> That's an interesting pitfall. I am pretty sure we have this kind of
> syntax a lot in the tree. Might make sense to document it.

It's ok and works as expected as long as you depend on only one slot.


Best regards,
Chí-Thanh Christopher Nguyễn




Re: [gentoo-dev] Re: ChangeLog

2015-11-01 Thread Chí-Thanh Christopher Nguyễn
Мисбах-Соловьёв Вадим schrieb:
>>> git clone --depth=1 
>> Now how can this user display the ChangeLog for
>> a certain package?
> ```
> git log -- pkg-category/pkg-name/

I think his point was that shallow clones don't have the full log.


Best regards,
Chí-Thanh Christopher Nguyễn




Re: [gentoo-dev] ssl vs openssl vs libressl vs gnutls USE flag foo

2015-10-29 Thread Chí-Thanh Christopher Nguyễn

hasufell schrieb:

I've seen a lot of ebuilds lately that use 'openssl' USE flag for the
purpose of enabling ssl features. I think this should be discouraged
since it introduces inconsistency and is especially confusing for
packages like media-video/ffmpeg, where'd you expect to get ssl support
by having the global ssl USE flag enabled.

Furthermore, some packages have started to do things like
REQUIRED_USE="^^ ( openssl libressl )"
which is even more inconsistent now and will make it very hard for
people to switch to libressl without figuring out a lot of blockers,
since we have conflicting meanings of 'openssl' now. One uses it as a
feature flag, the other as a provider flag.


It has been discussed before how to map this to USE flags[1], but that 
turned out to be quite difficult. Especially if you want to express 
something like "this package must use the same crypto library as its 
dependency".


REQUIRED_USE="^^ ( openssl libressl )" is one way to make things easy 
for the ebuild developer, but nasty for the user.


For the users, the easiest way would be to set USE="openssl libressl" 
(or some USE_EXPAND) if they are fine with any of these, but this makes 
depending on a package which must be built e.g. against libressl and not 
openssl hard.


Best regards,
Chí-Thanh Christopher Nguyễn


[1] 
https://archives.gentoo.org/gentoo-dev/message/3fd9df7fdd7ac976b87e4e15587bfa63





Re: [gentoo-dev] News Item: Changes in default VIDEO_CARDS

2015-10-29 Thread Chí-Thanh Christopher Nguyễn

Ciaran McCreesh schrieb:

On Thu, 29 Oct 2015 16:22:40 +0100
Chí-Thanh Christopher Nguyễn <chith...@gentoo.org> wrote:

The previous time I wanted to post a news item with USE dependencies,
this was not possible because the Display-If-Installed dependency
atom had to conform to EAPI 0. But now that all profiles are EAPI 5
this is ok I hope.

It's not really clear what the EAPI for the news directory is...


I guess you are right, but as all package managers must now understand 
EAPI 5 dependency atoms, it is not likely that any will choke on it.
Besides, existing news items already use Display-If-Profile: to point to 
EAPI 5 profiles.

But I can ask the Council for clarification on the issue.


Best regards,
Chí-Thanh Christopher Nguyễn




[gentoo-dev] News Item: Changes in default VIDEO_CARDS

2015-10-29 Thread Chí-Thanh Christopher Nguyễn
x11 team plans to change the default VIDEO_CARDS on amd64/x86 per bug 
#561850.
Due to the USE dependencies of Display-If-Installed, this item will only 
be displayed on amd64 and x86 systems that have not overridden 
VIDEO_CARDS in make.conf. Other architectures will retain their 
VIDEO_CARDS and we will leave it to the respective arch teams to adjust 
this as desired.


The previous time I wanted to post a news item with USE dependencies, 
this was not possible because the Display-If-Installed dependency atom 
had to conform to EAPI 0. But now that all profiles are EAPI 5 this is 
ok I hope.


Title: Changes in default VIDEO_CARDS
Author: Chí-Thanh Christopher Nguyễn <chith...@gentoo.org>
Content-Type: text/plain
Posted: 2015-10-30
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: 
x11-base/xorg-drivers[video_cards_dummy,video_cards_fbdev,video_cards_glint,video_cards_intel,video_cards_mach64,video_cards_mga,video_cards_nouveau,video_cards_nv,video_cards_r128,video_cards_radeon,video_cards_savage,video_cards_tdfx,video_cards_trident,video_cards_v4l,video_cards_vesa,video_cards_via,video_cards_vmware]


In order to better reflect the graphics chipsets present on modern
systems, the default VIDEO_CARDS setting has been changed to
"amdgpu fbdev intel nouveau radeon radeonsi vesa"

If your graphics chipset requires a different driver, and you have not set
VIDEO_CARDS in make.conf, it is advisable to do that now.




Re: [gentoo-dev] News Item: Changes in default VIDEO_CARDS

2015-10-29 Thread Chí-Thanh Christopher Nguyễn

Ulrich Mueller schrieb:

On Thu, 29 Oct 2015, Ciaran McCreesh wrote:

[...] but the trouble is that news items slightly predate PMS and
EAPIs.

We could update GLEP 42 for a News-Item-Format 1.1 and allow EAPI 5
dependency specifications there.

Ulrich


New-Item-Format 1.1 implies that it is backwards compatible if I read 
correctly?
If so, we would have to use some other identifier than 
"Display-If-Installed" because EAPI 5 dependency atoms are not a subset 
of EAPI 0 ones.


Maybe

News-Item-Format: 1.1
EAPI: 5
Display-If-Has_version: ...

where Display-If-Has_version is a dependency specification according to 
the given EAPI, and the package manager must ignore it if the EAPI is 
unsupported (thus will display the news item always, which will also 
happen with package managers that only support News-Item-Format 1.0).



Best regards,
Chí-Thanh Christopher Nguyễn




[gentoo-dev] News Item: Changes in default VIDEO_CARDS (v2)

2015-10-29 Thread Chí-Thanh Christopher Nguyễn

I changed the EAPI 5 dependency atom to EAPI 0 ones.

Title: Changes in default VIDEO_CARDS
Author: Chí-Thanh Christopher Nguyễn <chith...@gentoo.org>
Content-Type: text/plain
Posted: 2015-10-30
Revision: 1
News-Item-Format: 1.0
Display-If-Keyword: amd64
Display-If-Keyword: x86
Display-If-Installed: x11-drivers/xf86-video-dummy
Display-If-Installed: x11-drivers/xf86-video-glint
Display-If-Installed: x11-drivers/xf86-video-mach64
Display-If-Installed: x11-drivers/xf86-video-mga
Display-If-Installed: x11-drivers/xf86-video-nv
Display-If-Installed: x11-drivers/xf86-video-r128
Display-If-Installed: x11-drivers/xf86-video-savage
Display-If-Installed: x11-drivers/xf86-video-tdfx
Display-If-Installed: x11-drivers/xf86-video-trident
Display-If-Installed: x11-drivers/xf86-video-v4l
Display-If-Installed: x11-drivers/xf86-video-via
Display-If-Installed: x11-drivers/xf86-video-vmware

In order to better reflect the graphics chipsets present on modern
systems, the default VIDEO_CARDS setting has been changed to
"amdgpu fbdev intel nouveau radeon radeonsi vesa"

If your graphics chipset requires a different driver, and you have not set
VIDEO_CARDS in make.conf, it is advisable to do that now.




Re: [gentoo-dev] newsitem: openrc localmount and netmount changes (third iteration)

2015-10-02 Thread Chí-Thanh Christopher Nguyễn


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

William Hubbs schrieb:
| Display-If-Installed: <=sys-fs/openrc-0.18

That should be sys-apps/openrc, no?

Best regards,
Chí-Thanh Christopher Nguy?n

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJWDs8vXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1RDFCODdDQUUxMkUwNkJCNjUyMDMxOEIy
MzI0RTdCNTY2REYyNjExAAoJECMk57Vm3yYRbOcP/A3q45a15hh0KSerzclO8Gz9
cUToHto7jOrS4X3pU2atgwHydERr+d80z5OgBdP8c1t/bnhmsKGxScdIDPzzlVJe
OWT1iI32+yNg/b4O6qFgt5jyknsroizqMD3hRlaqys1j3SjpG0R+Ej4ycrQUCL1k
5WvtvI3nUC55Tj+Vv1nSoDUg5aHmG9zOoDkEozhAq4/YAKALMRGLPxU62JERipp6
Q2DaNxQPa7vf/mggS4yLIZFWWdJfeU3PDWuONurMsxKSPp0cmxHkfl9mczTCzdfn
Dm3zYEooar5vxigpzV+QwZ7PNkWs3GGqEbmSou0+xiZnf1/gAFakbggLeOtHXysL
CHRm7kdNpKLI19hZ+SV3qZQqvGTmJSasBMRwmU0F7MCVcTSdZvKMQrzGrR3ZnogX
LNjSUkM5zA1+JX4AbeGGGAhAWsaLgzRxjAxIEY6RkOn6hdRhSWcbh4hLLXCNhnCR
EYYT5HI+AplTvzXD/d2YrD/bahknIwdhZh2kG/0W1M73MxzXejz6146y5YY/zID1
Ce7t0f6PHI9XbErmXDhh/UJrErYdFWN6AwGJ++FFu3/vo+WZ1Ic+/UP5lsfkS1gs
PFGyR+WQIAK9z90upIqTIC/L2eEZbdwISg3A/jSYRaX0gqE5Uyxve8QLBvLLz8vH
X1DA0ujXsNMCZvXWQwAW
=JIOC
-END PGP SIGNATURE-




Re: [gentoo-dev] RFI: A better workflow for github pull requests

2015-09-13 Thread Chí-Thanh Christopher Nguyễn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michał Górny schrieb:
> I don't know if you didn't read the proposal, or if you are unable to 
> understand it. You are seriously *offending* me and the few other 
> developers who are trying *really hard*.
> 
> So let me make this clear: I am trying to make it possible for the 
> community to contribute in any way it finds *convenient* while not 
> forcing anyone to use any external (proprietary or non-proprietary) 
> platform.

TBH I don't see any reason to be offended here.
What Andrew is pointing out is that this path can be a slippery slope into
dependency on GitHub infrastructure.

>> It is a pain for me to see that several developers under disguise of 
>> "community" and "integration" are trying hard to make that happen, 
>> step by step.
> 
> And it is a pain for us to read such unfounded accusations. This is 
> incorrect, and very offensive. If this is really your belief, please 
> keep it to yourself. By writing this you are only causing unnecessary 
> anger and frustration which are not helping anyone.

That remark may have been unwarranted. FWIW I don't agree with it.
But I don't think it lowers the anger-and-frustration standards of this
discussion following:
"Thank you for your insightful comment. That's very helpful. Really,
thank you a lot. Gentoo would be much worse without such helpful
comments. Why do we need community at all, when one developer with his
helpful comments can provide all there is ever needed by the distro."


Best regards,
Chí-Thanh Christopher Nguyễn

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlX2B1MACgkQ+gvH2voEPRBP/QCaA3LtZHHhk7qjeUIXHIRm6eD1
90MAn3mmeFk1RmlqNbuSSflyMvx19c9x
=6kAH
-END PGP SIGNATURE-



[gentoo-dev] Re: Better way to direct upstream bugs upstream?

2015-08-30 Thread Chí-Thanh Christopher Nguyễn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matt Turner schrieb:
 Worse, users sometimes file bugs in our bugzilla that we don't have time
 to respond to for a while during which time they're waiting on people
 without the ability to help them.
 
 Is there a better way of directing reporters to file bugs upstream? Of 
 course it's not always clear whether a bug is an ebuild bug or something
 easily patched in Gentoo vs a driver bug that requires an upstream
 developer...

I think such bug reports are still useful. They can point to patches once
the issue has been resolved upstream, for consideration in a new ebuild
revision.

Whether they are kept open or resolved UPSTREAM while an upstream fix is
unavailable I have no strong opinion about.


Best regards,
Chí-Thanh Christopher Nguyễn
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlXjRHgACgkQ+gvH2voEPRCiLwCeNOZAIpEsXwCIsSV2ZzMwXxO4
gUkAnR+5nwYhL8ty5YR2QoISDe4y+B8Y
=U/e0
-END PGP SIGNATURE-



Re: [gentoo-dev] Re: Referencing bug reports in git

2015-08-12 Thread Chí-Thanh Christopher Nguyễn

Michał Górny schrieb:
Bug: https://bugs.gentoo.org/show_bug.cgi?id=333531 format, with the 
https://bugs.gentoo.org/show_bug.cgi?id=; optional for Gentoo 
Bugzilla, would be a compromise I can accept. I would not like having 
to redundantly give the bug number when I already gave the URL. 

Can we make it clear whether we are allowed/supposed to use the short
form:

   https://bugs.gentoo.org/333531

?



As that redirects to the longer form I don't see a problem with allowing 
that.


Note that the short form does not allow for referencing individual 
comments, because

https://bugs.gentoo.org/333531#c4
redirects to
https://bugs.gentoo.org/show_bug.cgi?id=333531
and not
https://bugs.gentoo.org/show_bug.cgi?id=333531#c4


Best regards,
Chí-Thanh Christopher Nguyễn



  1   2   3   4   >