[gentoo-dev] Last rites: media-fonts/symbola
# 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/
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
# 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
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)
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
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
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
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
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
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
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
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
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
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
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/
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/
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
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] last rites: app-text/acroread
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
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
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
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"
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
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
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
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
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-
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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/
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
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
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
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
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
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
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
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
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
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
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?
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
-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
-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
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
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
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
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
Мисбах-Соловьёв Вадим 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
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
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
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
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)
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)
-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
-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?
-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
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
Re: [gentoo-dev] Re: Referencing bug reports in git
hasufell schrieb: So, I've just tried to count the ++ for different ideas and even if I missed one or two or misread someone's opinion, I think the result is pretty clear: reference the bug only in the summary: 1 don't make any of this mandatory: 1 Gentoo-Bug: 123 or similar short form: 9 Gentoo-Bug: url or similar long form: 2-3 As there was no formal call for a vote, I don't think you can take the number of voiced opinions as an indicator for the support of an option. After all, if someone's opinion is already sufficiently represented by an existing post, that person would not have reason to write to -dev and further clutter the discussion. The only thing you can derive from this counting is that consensus has not been reached. 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. Best regards, Chí-Thanh Christopher Nguyễn
