Re: [gentoo-dev] [News item review] V2 Chromium access to Google services
On 3/8/21 5:19 PM, Thomas Deutschmann wrote:
Hi,
On 2021-03-08 20:01, Stephan Hartmann wrote:
Starting March 15th, 2021 Google Chrome Team will restrict access to
Google APIs and services that are reserved for Google use only. This
means that users are no longer able to login into their Google
Accounts which disables access to for example Chrome Sync.
Maybe outline that this will only affect browser functions. You can
still log in into your Google Account when accessing
https://accounts.google.com/.
As a consequence we have to remove Client ID and secret from all
www-client/chromium ebuilds. This change has already been done for
=www-client/chromium-89.0.4389.82. Other versions will be updated
shortly.
My first reaction was: WTF?! Why remove... maybe add a reference to [2]
already or quote
As explained in section above, signing in to Google web is rate
limited if the developer has configured a client ID and client
secret. To avoid hitting this limit in Chromium Derivatives, please
remove the OAuth 2.0 client ID and client secret from your build
configuration.
directly in the news item.
As quantitative feedback helps, I second this! I had the exact same
reaction.
Aisha
That said, I wonder if there's a use case to allow users to bake-in
custom credentials. I know at least one large Gentoo setup distributing
Firefox to its users with custom keys. This is possible via environment
variables set at build time, see
https://gitweb.gentoo.org/repo/gentoo.git/tree/www-client/firefox/firefox-86.0.ebuild?id=dfe26277ee7441d00d88da14691cfc48db85ac8a#n453
If you need one of the Google use only APIs, then you either have to
switch to www-client/google-chrome{-beta,-unstable} or setup your
own keys [1].
Should be
www-client/google-chrome{,-beta,-unstable}
^^^
However, the latter is only intended for development. Documentation
on how to generate and use own keys can be found in [2].
I wouldn't mention that at all. Either there is suitable way to keep
status quo or there isn't.
My suggestion:
announcement>
client_id or client_secret as explained in last paragraph of [2].>
environment variable at runtime (and or build-time if you are going to
support that) or add reference to [2] again.>
Re: [gentoo-dev] Fwd: [Python-Dev] Move support of legacy platforms/architectures outside Python
On 2/21/21 8:01 AM, Michał Górny wrote: Hi, FYI, a few member of Python upstream are continuing their crusade against minor architectures not supported by Rust. This time, they're discussing actively removing support for platforms they don't officially support, and requiring people to maintain external patches forever. ggwp was fun Forwarded Message From: Victor Stinner To: Python Dev Subject: [Python-Dev] Move support of legacy platforms/architectures outside Python Date: Sun, 21 Feb 2021 13:13:45 +0100 Hi, I propose to actively remove support for *legacy* platforms and architectures which are not supported by Python according to PEP 11 rules: hardware no longer sold and end-of-life operating systems. The removal should be discussed on a case by case basis, but I would like to get an agreement on the overall idea first. Hobbyists wanting to support these platforms/archs can continue to support them with patches maintained outside Python. For example, I consider that the 16-bit m68k architecture is legacy, whereas the OpenBSD platform is still actively maintained. I already know that there will be a strike back: "oh no, you must continue to support my architecture" and "their existing code should stay and doesn't cost anything to maintain". Python is maintained by volunteers, the majority is contributing in their free time, so people are free to use their free time as they want. You cannot ask core developers to support your favorite *legacy* platform/architecture if they don't want to. In short, I propose to move maintenance of the legacy platforms/archs outside Python: people are free to continue support them as patches. -- Concrete example: Christian Heimes proposed to drop support for 31-bit s390 Linux: https://bugs.python.org/issue43179 The lack of clear definition on how a platform is supported or not confuses users who consider that their favorite platform/arch is supported, whereas core developers don't want to support it since it would be too much work. In fact, the PEP 11 has clear and explicit rules: https://www.python.org/dev/peps/pep-0011/#supporting-platforms A platform is only considered as supported if the following two conditions are met: 1) a core developer needs to volunteer to maintain platform-specific code 2) a stable buildbot must be provided Last October, I proposed to drop Solaris support (bpo-42173). Jakub Kulik stepped in and proposed some Solaris patches, so I abandoned my idea. But I still don't see any running Solaris buildbot worker, and there is still no core developer volunteer to maintain Solaris support. It's unclear to me if Python has "best effort" support for Solaris, of if Solaris is "not supported". -- Over the years, Python was ported to tons of platforms and CPU architectures. It didn't matter if the platform or the architecture was commonly used or not. 30 years later, Python still has the code for many legacy platforms and architectures. Some hardware is no longer sold but kept alive by hobbyists, especially members of retro computing groups. Some Linux distributions like Gentoo and Debian are trying to support most architectures which are supported by these hobbyist groups, whereas some other distributions like Ubuntu are limited to a few platforms. For example, Ubuntu 20.4.2 LTS server supports 4 architectures: x86-64, AArch64 (ARM), POWER and s390x. I guess that the difference between Debian and Ubuntu is that Ubuntu is a Canonical product, Canonical sells professional support and so cannot support too many architectures. Each architecture support requires to build all packages on it, tests the packages, have experts who fix issues specific to this arch, etc. -- Python has different kinds of platform and architecture supports. In practice, I would say that we have: * (1) Fully supported. Platform/architecture used by core developers and have at least one working buildbot worker: fully supported. Since core developers want to use Python on their machine, they fix issues as soon as they notice them. Examples: x86-64 on Linux, Windows and macOS. * (2) Best effort. Platform/architecture which has a buildbot worker usually not used by core developers. Regressions (buildbot failures) are reported to bugs.python.org, if someone investigates and provides a fix, the fix is merged. But there is usually no "proactive" work to ensure that Python works "perfectly" on these platforms. Example: FreeBSD/x86-64. * (3) Not (officially) supported. We enter the blurry grey area. There is no buildbot worker, no core dev use it, but Python contains code specific to these platforms/architectures. Example: 16-bit m68k and 31-bit s390 architectures, OpenBSD. The Rust programming language has 3 categories of Platform Support, the last one is : "Tier 3 platforms are those which the Rust codebase has support for, but which are not built or tested automatically, and may not work. Official builds are not available."
Re: [gentoo-dev] New project: binhost
Maybe as starter, if some people have any public binhosts available, some volunteers can try using those to build a (test) system to check how it fares? I have two public binhosts available (with very limited set of packages and very specific CPUs and very weak servers, so please don't crash them) https://bsd.ac/gentoo-binpkgs/ivybridge/Packages <--- a bit more up to date https://bsd.ac/gentoo-binpkgs/znver1/Packages <--- not that regularly updated The packages might be about week or two old, am going to setup weekly builds and uploads. Might be better to start making something, and testing things out. If and when things break, we can see how to fix. I'm sure others have more extensive infrastructure and setups than my tiny VPS. If some other people want to give out information about their binhosts, at least some form of trial and error can be started. Thoughts? Aisha On 2/10/21 12:57 PM, Andreas K. Hüttel wrote: Hi all, I'm announcing a new project here - "binhost" "The Gentoo Binhost project aims to provide readily installable, precompiled packages for a subset of configurations, via central binary package hosting. Currently we are still in the conceptual planning stage. " https://wiki.gentoo.org/wiki/Project:Binhost If you're interested in helping out, feel free to add yourself on the wiki page. Note that I see actually *building* the packages not as the central point of the project (that could be e.g. a side effect of a tinderbox). I'm more concerned about * what configurations should we use * what portage features are still needed or need improvements (e.g. binpkg signing and verification) * how should hosting look like * and how we can test this on a limited scale before it goes "into production" * ... Comments, ideas, flamebaits? :D Cheers, Andreas
[gentoo-dev] Make 'man' global USE flag from currently local
Hi all, I am proposing to make the `man` USE flag into a global one. Currently it is used by ~45 packages most of which have the same description 'Build and install man pages': https://packages.gentoo.org/useflags/man Hopefully no objections to this part? Cheers, Aisha
Re: [gentoo-dev] New project: binhost
On 2/10/21 2:11 PM, Rich Freeman wrote: On Wed, Feb 10, 2021 at 12:57 PM Andreas K. Hüttel wrote: * what portage features are still needed or need improvements (e.g. binpkg signing and verification) * how should hosting look like Some ideas for portage enhancements: 1. Ability to fetch binary packages from some kind of repo. 2. Ability to have multiple binary packages co-exist in a repo (local or remote) with different build attributes (arch, USE, CFLAGS, DEPENDS, whatever). 3. Ability to pick the most appropriate binary packages to use based on user preferences (with a mix of hard and soft preferences). One idea I've had around how #2-3 might be implemented is: 1. Binary packages already contain data on how they were built (USE flags, dependencies, etc). Place this in a file using a deterministic sorting/etc order so that two builds with the same settings will have the same results. this is provided by FEATURES="binpkg-multi-instance" (or maybe i misread) 2. Generate a hash of the file contents - this can go in the filename so that the file can co-exist with other files, and be located assuming you have a full matching set of metadata. 3. Start dropping attributes from the file based on a list of priorities and generate additional hashes. Create symlinked files to the original file using these hashes (overwriting or not existing symlinks based on policy). This allows the binary package to be found using either an exact set of attributes or a subset of higher-priority attributes. This is analogous to shared object symlinking. 4. The package manager will look for a binary package first using the user's full config, and then by dropping optional elements of the config (so maybe it does the search without CFLAGs, then without USE flags). Eventually it aborts based on user prefs (maybe the user only wants an exact match, or is willing to accept alternate CFLAGs but not USE flags, or maybe anything for the arch is selected. 5. As always the final selected binary package still gets evaluated like any other binary package to ensure it is usable. Such a system can identify whether a potentially usable file exists using only filename, cutting down on fetching. In the interests of avoiding useless fetches we would only carry step 3 reasonably far - packages would have to match based on architecture and any dynamic linking requirements. So we wouldn't generate hashes that didn't include at least those minimums, and the package manager wouldn't search for them. Obviously you could do more (if you have 5 combinations of use flags, look for the set that matches most closely). That couldn't be done using hashes alone in an efficient way. You could have a small manifest file alongside the binary package that could be fetched separately if the package manager wants to narrow things down and fetch a few of those to narrow it down further. Or you could skip the hash searching and just fetch all the manifests for a particular package/arch and just search all of those, but that is more data to transfer just to do a query. A metadata cache of some kind of might be another solution. Content hashes would probably still be useful just to allow co-existence of alternate builds.
Re: [gentoo-dev] New project: binhost
On 2/10/21 12:57 PM, Andreas K. Hüttel wrote: Hi all, I'm announcing a new project here - "binhost" "The Gentoo Binhost project aims to provide readily installable, precompiled packages for a subset of configurations, via central binary package hosting. Currently we are still in the conceptual planning stage. " https://wiki.gentoo.org/wiki/Project:Binhost If you're interested in helping out, feel free to add yourself on the wiki page. Note that I see actually *building* the packages not as the central point of the project (that could be e.g. a side effect of a tinderbox). I'm more concerned about * what configurations should we use maybe to start with, desktop profiles (gnome/qt/none + systemd/openrc) are a good idea, these are the people who would benefit most. This may not be enough, most people also enable extra flags polkit/elogind/ttf/otf/wayland/pulseaudio We can start with a default and gather feedback as to what new flags should be enabled. * what portage features are still needed or need improvements (e.g. binpkg signing and verification) somehow checking valid CFLAG/etc. compatibility, not sure how. Some packages fail when built with differing flags * how should hosting look like Something like the list of profiles in eselect profile (replace https by protocol of choice): https://binpkg.gentoo.org/amd64/17.1/desktop/ https://binpkg.gentoo.org/amd64/17.1/desktop/gnome/ could potentially also be mirrored on rsync mirrors. Cheers, Aisha * and how we can test this on a limited scale before it goes "into production" * ... Comments, ideas, flamebaits? :D Cheers, Andreas
[gentoo-dev] GTK:2 EOL and incoming migration to GTK:3
Hi all, As most of you might be (or not be) aware, GTK:2 has reached EOL in December 2020, following the announcement of GTK:4. We are now in the process of cleaning up GTK:2 ebuilds and moving the packages to use GTK:3 and drop GTK:2 support. In the coming days, bugs will be opened for all packages which are still using GTK:2. We encourage all maintainers who get a bug to start the migration soon, to ensure a smooth transition. This transition is expected to take a long time so there shouldn't be a worry about sudden changes in packages. We are going to keep some of the more important old GTK:2 ebuilds, such as the CJK ebuilds, around as long as we have GTK:2 in the tree. Newer packages are encouraged to be GTK:3 only. The starting point of the transition are packages which have GTK:3 support and optional GTK:2 support. Most of the bugs of this kind have already been filed[1] and is the safest place to start killing off GTK:2. Best, Aisha [1] https://blog.gtk.org/2020/12/16/gtk-4-0/ [2] https://bugs.gentoo.org/768993
[gentoo-dev] gui-libs/display-manager-init: second review for new news item
Hi all, Here is an updated news item for the display-manager-init changes. Please comment and check. Thanks, Aisha Title: New OpenRC Display Manager Initializer Scripts Author: Aisha Tammy Author: Andreas Sturmlechner Posted: 2021-01-30 Revision: 5 News-Item-Format: 2.0 Display-If-Installed: sys-apps/openrc There has been a refactoring of the old 'xdm' init script into a new script called 'display-manager', provided by a new package that will be introduced by your @world update routine as a dependency of x11-base/xorg-server-1.20.10-r1: gui-libs/display-manager-init The package is now in ~arch and will be available to stable users starting with 2nd March 2021. [1] Its purpose is to provide the same startup mechanism for your chosen display manager (like GDM, SDDM etc. [2]) as xdm did previously, but without depending on x11-base/xorg-server. This is necessary to support new DMs that no longer depend on Xorg. Existing settings from /etc/conf.d/xdm will be migrated to new /etc/conf.d/display-manager config, however after installation it is vital not to forget to run either `etc-update` or `dispatch-conf`. Afterwards check that /etc/conf.d/display-manager contains the desired value for DISPLAYMANAGER. The old 'xdm' init script is no longer supported and henceforth removed from x11-base/xorg-server-1.20.10-r1, so it is imperative that you switch from xdm to display-manager service in default runlevel: # rc-update del xdm default # rc-update add display-manager default The changes are complete and on the next reboot, 'display-manager' will start your chosen DM. To switch to the new script without rebooting, run the following commands in a tty: # rc-service xdm stop # rc-service display-manager start Finally, the following action is necessary *ONLY* if you are running a) a DM (and rest of system) without Xorg b) a DM from an overlay, to make sure display-manager persists # emerge --noreplace gui-libs/display-manager-init [1] To make this change *now*, and proceed with this news item already, stable users would need to add the following entries to /etc/portage/package.accept_keywords [3] and update @world: ~sys-apps/sysvinit-2.98 ~x11-apps/xinit-1.4.1 ~x11-base/xorg-server-1.20.10 ~gui-libs/display-manager-init-1.0 [2] https://wiki.gentoo.org/wiki/Display_manager [3] https://wiki.gentoo.org/wiki//etc/portage/package.accept_keywords
Re: [gentoo-dev] [RFC] Would you join to a new project "Themes"?
On 1/29/21 6:22 PM, Jonas Stein wrote: > Hi, > > x11-themes/* are very similar. > It could make sense to have a project who maintains all x11-themes. > > I never used themes so I am out, but please reply, if you would like to > create/join such a project. > Happy to contribute!! Love messing about with ricing :D Aisha
Re: [gentoo-dev] [News item review v2] Python preference to follow PYTHON_TARGETS
On 1/24/21 7:59 AM, Michał Górny wrote: > Here's v2 with extra 'tl;dr' instructions in first para: > > ``` > Title: Python preference to follow PYTHON_TARGETS > Author: Michał Górny > Posted: 2021-01-24 > Revision: 1 > News-Item-Format: 2.0 > > On 2021-02-01 stable users will switch to a new method of updating > the preferred Python versions that employs the configuration update > mechanism in order to follow PYTHON_TARGETS. We will also deprecate > and stop installing app-eselect/eselect-python by default. If you wish > to use the newest Python version present in your PYTHON_TARGETS, you > only have to accept configuration changes. If you wish need > to customize the behavior, read on. > > Since 2017, /usr/bin/python and the related non-versioned symlinks > are wrapped through dev-lang/python-exec. The list of preferred Python > implementations is stored in /etc/python-exec/python-exec.conf and/or > per-program /etc/python-exec/.conf configuration files. > To preserve backwards compatibility, app-eselect/eselect-python remained > a wrapper that updated this file. > > However, this mechanism alone has proven inconvenient to end users who > had to update python-exec.conf whenever the default PYTHON_TARGETS > changed. Thanks to the fallback logic, this was not a major problem > for software installed via Gentoo packages that always ensure that > a supported implementation is used. However, users have reported that > whenever the preference for /usr/bin/python mismatched their > PYTHON_TARGETS, their custom scripts would break due to unsatisfied > dependencies. This does not follow the principle of least surprise. > > For this reason, we have decided to change the default python-exec > configuration to match PYTHON_TARGETS by default, in the eclass > preference order, that is from the newest CPython version to oldest, > with alternative Python implementations coming afterwards. This change > will be propagated via the configuration protection mechanism whenever > dev-lang/python-exec-conf is installed or rebuilt due to PYTHON_TARGETS > changes. This will permit the users to interactively confirm > the updates. > > If the new default is not correct for you, please use your preferred > configuration update tool to discard or edit the new configuration file. > > Furthermore, dev-lang/python will no longer attempt to automatically > update the Python interpreter preference, or pull in eselect-python > automatically. If you wish to continue using it, please install it > manually to ensure that it is not unmerged. > > ``` > Has this change already been pushed for unstable? I am running an unstable system but I still have eselect-python, so I assume not (unless due to my side error). Thanks, Aisha
Re: [gentoo-dev] Packages up for grabs
On 1/17/21 8:43 AM, m1027 wrote: > mgorny: > >> [bv] www-apps/radicale > > I am actively using radicale on arm, arm64 and amd64 and thus > feel like I should contribute. :-) > > As this was my debut to package maintainment, and I'd need at least > some initial pointers on how to start, what's the least bothering > way for everybody to ask for help and such. > > BTW: There is 2.x in portage but 3.x out, so there is not just a > minor version bump to do. > > Thanks > > Best way is to come ask for help on #gentoo-dev-help and #gentoo-proxy-maint on freenode IRC. Aisha
Re: [gentoo-dev] Getting rid of USE=unicode
On 12/30/20 1:34 PM, Andreas K. Huettel wrote: > Am Mittwoch, 30. Dezember 2020, 19:53:25 EET schrieb Aisha Tammy: >> >> Yes, this sounds nice. >> What about packages which rely on/give unicode support outside of this flag? >> Like the global icu flag, which supposedly needs dev-libs/icu ? >> > > Hmmm... good point. I thought too simple. > > 1) We want to enable unicode unconditionally whereever that is possible > without much impact. > 2) If that pulls in large libraries like icu, a useflag remains useful. > > So maybe instead of any use.forcing we should just go through the ebuilds and > > a) reduce the number of occurences of IUSE=unicode as much as possible > b) switch to IUSE=icu or similar where that makes sense > dilfridge++ Sounds awesome.
Re: [gentoo-dev] Getting rid of USE=unicode
On 12/30/20 12:46 PM, Andreas K. Huettel wrote: > Hi all, > > since utf8 encoding is everywhere by now, and since switching the useflag > unicode off without taking precautions is a way to hose your installation, I > would propose to medium-term get rid of this flag. > > Suggestion: > > 1) use.force unicode now/soon in the default profiles > > 2) step by step, modify ebuilds to enable the functionality unconditionally > (and if necessary fix depstrings) > > 3) at some point the flag is gone > > Opinions? > > Cheers, > Andreas > Yes, this sounds nice. What about packages which rely on/give unicode support outside of this flag? Like the global icu flag, which supposedly needs dev-libs/icu ? Cheers, Aisha
Re: [gentoo-dev] Re: Slotted Lua + revdeps to be unmasked on Christmas Eve
>> >> > > My intention with the suggestion was that the actual library be stored > in /usr/lib64/liblua52.so (or whatever the appropriate name is), but a > symlink used for linking be stored in /usr/lib64/lua5.2/liblua.so. When > you pass "-L /usr/lib64/lua5.2 -llua" to the compiler, it will find the > file /usr/lib64/lua5.2/liblua.so and read the DT_SONAME entry in it. > That will cause the linker to store "liblua52.so" as a DT_NEEDED entry > in the executable. At runtime, the runtime linker ld.so > (/lib64/ld-linux-x86-64.so.2) will read the DT_NEEDED entry, and try to > find the library liblua52.so, which is in /usr/lib64, so it will be > found without any ld.so.conf tricks. This requires no special runtime > support, as the actual name the compiler/linker will end up storing in > the output contains the proper version. This means that if > /usr/bin/binA linked to liblua51.so (via the linker finding > /usr/lib64/lua5.1/liblua.so) and /usr/bin/binB linked to liblua52.so > (likewise), they would both be able to find the correct libraries, as > the DT_SONAMEs are different. > > Jonathan Callen > Yes, this sounds doable and should work! Only problem is that if there is an actual liblua.so with the proper SONAME available in /usr/lib64 (I dunno if Gentoo has any provider of liblua.so with that SONAME, IIRC SLOT=0 currently does that) then it will ignore the wrong SONAMEd even with the -L/usr/lib64/lua5.2/ Aisha
Re: [gentoo-dev] Re: Slotted Lua + revdeps to be unmasked on Christmas Eve
>> >> > > My intention with the suggestion was that the actual library be stored > in /usr/lib64/liblua52.so (or whatever the appropriate name is), but a > symlink used for linking be stored in /usr/lib64/lua5.2/liblua.so. When > you pass "-L /usr/lib64/lua5.2 -llua" to the compiler, it will find the > file /usr/lib64/lua5.2/liblua.so and read the DT_SONAME entry in it. > That will cause the linker to store "liblua52.so" as a DT_NEEDED entry > in the executable. At runtime, the runtime linker ld.so > (/lib64/ld-linux-x86-64.so.2) will read the DT_NEEDED entry, and try to > find the library liblua52.so, which is in /usr/lib64, so it will be > found without any ld.so.conf tricks. This requires no special runtime > support, as the actual name the compiler/linker will end up storing in > the output contains the proper version. This means that if > /usr/bin/binA linked to liblua51.so (via the linker finding > /usr/lib64/lua5.1/liblua.so) and /usr/bin/binB linked to liblua52.so > (likewise), they would both be able to find the correct libraries, as > the DT_SONAMEs are different. > > Jonathan Callen > Yes, this sounds doable and should work! Aisha
Re: [gentoo-dev] Re: Slotted Lua + revdeps to be unmasked on Christmas Eve
On 12/23/20 3:01 PM, Michael Orlitzky wrote: > On 12/23/20 1:14 PM, Aisha Tammy wrote: >> >> I've recently had the same problem for TACC/Lmod which uses >> autotools to get lua versions and lua.cpath and lua.path and did infact >> manage >> to push the horrendously large patch upstream - >> https://github.com/TACC/Lmod/commit/0913bf05dd7e8f478f69d5297e26d744ddb5073a >> >> Maybe something similar can work for your use case? > > Yes, patching the build system works. > Ah, I was unclear. I meant this kind of patch would not be something that upstream will hate, as it is backwards compatible. That's the biggest problem with creating large backwards compatible patches >.< > >> The problem with just using -L/path/to/lua/lib/ -llua would be loading >> library at runtime, unless autotools is smart enough to actually change this >> CFLAGs into a -Wl,-rpath,/path/to/lua/lib -L/path/to/lua/lib -llua. >> I am not sure how intelligent autotools is to be able to do this or not. >> > > We already add entries to /etc/ld.so.conf to make things like slotted LLVM > work. > Hmm, how would that work? I have package A with a binary /usr/bin/binA linked to liblua51.so (which in your suggestion would change to /usr/lib64/lua5.1/liblua.so) and and /usr/bin/binB linked to liblua52.so (or /usr/lib64/lua5.2/liblua.so). I don't see any ordering of /usr/lib64/lua5.1/ and /usr/lib64/lua5.2/ that allows for binA and binB to find their correct lua libraries. (This doesn't need to be for binaries, other shared libraries even) Admittedly, I am not a lua or linker expert... Aisha
Re: [gentoo-dev] Re: Slotted Lua + revdeps to be unmasked on Christmas Eve
On 12/23/20 12:13 PM, Jonathan Callen wrote:
> On 12/23/20 9:10 AM, Michael Orlitzky wrote:
>> On 12/23/20 8:35 AM, Jaco Kroon wrote:
>>> Michael,
>>>
>>> I'm busy disecting what Marek has done for asterisk as I need to make
>>> that work for multiple versions of net-misc/asterisk-16.14.0-r100, not
>>> merely the one he did it for - perhaps that would be helpful for you as
>>> well?
>>>
>>> I don't know lua at all.
>>>
>>> Anyway, I'm on IRC as jkroon if you'd like to exchange notes. I don't
>>> particularly like the patch Marek did as I'll NEVER be able to push that
>>> upstream. The patch will work for us, but as a policy I highly prefer
>>> patches which I can get unstreamed such that we don't need to carry them
>>> more than one or two versions.
>>
>> Agreed. This is more of a system library packaging issue than anything
>> to do with Lua specifically.
>>
>>
>>> I'd prefer to patch upstream to keep it's behaviour of detecting a lua
>>> version, but have a --with-lua(version)? type argument that can take an
>>> optional argument which will then be the version, but --with-* generally
>>> takes a prefix where the include and lib folders can be found ... and
>>> I'd prefer to depend on pkg-config as primary and fallback to the
>>> ./configure mess which tries to guess at things ...
>>>
>>
>> This is exactly what I'm trying to get across. Support for multiple
>> versions of libraries in weird locations is not a new thing. Generally,
>> you can put CPPFLAGS="-I/foo/bar" and LIBS="-L/baz/quux" before running
>> ./configure and everything will just work with your header files and
>> libraries in the non-standard paths /foo/bar and /baz/quux,
>> respectively. Those paths take precedence over the defaults (if used
>> correctly...), so you can use them to override the default version of a
>> library and compile/link against a specific copy if you need to do that.
>> Likewise, one could prepend a path to PKG_CONFIG_PATH to override the
>> version that will be detected via pkg-config.
>>
>> The problem that we've gotten ourselves into is that we've copied Debian
>> by not only relocating the library, but renaming it (and its *.pc file)
>> entirely. There is no good way to tell an autotools build system that
>> you've renamed a library completely, and that it should prefer the
>> renamed version over the standard one if the standard one also exists.
>>
>> If you want to build against the eselected version of Lua on Gentoo,
>> then eselect-lua makes everything OK. It creates symlinks from the
>> standard names to the nonstandard ones, and everything just works. But
>> if you want to build against a specific, not-eselected version of Lua?
>> You have to tell the build system what to do. The eselected version
>> lives in the correct locations (via those symlinks), so the build system
>> is going to want to find that first. If the eselected version is not the
>> one you want to build against, oops. Then, since the version you
>> *do* want to link against has the wrong name, you have to tell the build
>> system to link against it somehow. You can't simply override the
>> PKG_CONFIG_PATH, because our *.pc files have the wrong names. You can't
>> just override the library search path, because our libraries have the
>> wrong names.
>>
>> The work I've done so far for OpenDKIM does nothing to address these
>> larger problems. If lua.pc is on the system, it will get used first,
>> regardless of the version you actually want to build against. AFAIK
>> there's no good way around this without patching.
>>
>> If the libraries (and pkg-config files?) were installed to
>> subdirectories instead, then the standard method of overrides could be
>> used to build against a specific version, rather than requiring every
>> upstream build system to support our weird layout.
>>
>>
>
> One way this could be done without breaking things might be to create a
> subdirectory of /usr/$(get_libdir) for each version of Lua and creating
> a liblua.a and/or liblua.so symlink in that directory pointing to the
> liblua${VERSION}.* file in /usr/$(get_libdir). Then you could simply
> point those build systems at that directory and they would still use the
> correct version. As a hack in an ebuild, you probably could just create
> such a setup in (subdirectories of) ${T}, pointing liblua.a, liblua.so,
> and lua.pc at the appropriately-versioned files.
>
> Jonathan Callen
>
I've recently had the same problem for TACC/Lmod which uses
autotools to get lua versions and lua.cpath and lua.path and did infact manage
to push the horrendously large patch upstream -
https://github.com/TACC/Lmod/commit/0913bf05dd7e8f478f69d5297e26d744ddb5073a
Maybe something similar can work for your use case?
The problem with just using -L/path/to/lua/lib/ -llua would be loading
library at runtime, unless autotools is smart enough to actually change this
CFLAGs into a -Wl,-rpath,/path/to/lua/lib -L/path/to/lua/lib -llua.
I am not sure how intelligent autotools is to
Re: [gentoo-dev] Slotted Lua + revdeps to be unmasked on Christmas Eve
On 12/22/20 6:15 PM, Marek Szuba wrote: > Dear all, > > As of right now, the blocking slotted-lua tracker depends on 5 (FIVE) open > bugs. The still-to-be migrated packages are: > > app-metrics/collectd - ebuild under review of the maintainer > games-strategy/megaglest - no response from maintainers (games@g.o) > mail-filter/opendkim - committed ebuild needs one extra fix > sci-geosciences/osm2pgsql - no response from maintainers (sci-geo@g.o) > www-apps/cgit - to be migrated by bman > > Therefore, the unmasking of slotted Lua + all the ebuilds migrated to Lua > eclasses will take place on Christmas Eve, i.e. this Thursday, around noon > UTC. > > -- > Marecki Congratulations marecki@ ! Thanks for all your work (and also others, conikost, williamh, others who I am forgetting :P). As with any large enough change, lets hope this works in a chirstmas miracle. :D Cheers, Aisha
Re: [gentoo-dev] Last rites: sys-cluster/mvapich2
On 10/24/20 10:52 AM, David Seifert wrote: # David Seifert (2020-10-24) # EAPI 4, doesn't build, outdated, ebuild has multiple QA issues. # Removal in 30 days. Bug #463188, #531104, #613116, #740926. sys-cluster/mvapich2 If someone still wants to use it, it is possible to use this with Spack, which is present in ::science. Spack provides a binary version of this package, which should be useable to some extent (I have not used or tested).
Re: [gentoo-dev] [REVIEW] News Item - 2020-10-17-display-manager-init
On 10/23/20 3:50 AM, Ulrich Mueller wrote: On Thu, 22 Oct 2020, Aisha Tammy wrote: and remove 'xdm' from the default runlevel and add 'display-manager': rc-update del xdm default rc-update add display-manager default So, no automatic upgrade path for users? I am asking again, what is the rationale for renaming? I agree that "display-manager" might be a slightly better name than "xdm", but that's more than outweighted by the trouble that the renaming would impose on users. Ulrich I could run these commands conditionally in postinst to make this an automatic upgrade for people who have 'xdm' currently installed and enabled in the default runlevel. But I really don't think that running these commands is that big an inconvenience.
Re: [gentoo-dev] [REVIEW] News Item - 2020-10-17-display-manager-init
Hi, I've attached the updated news item. It now depends on openrc and the wording has been improved to make it less ambiguous about it being optional. Aisha Title: New OpenRC Display Manager Initializer Scripts Author: Aisha Tammy Posted: 2020-10-22 Revision: 2 News-Item-Format: 2.0 Display-If-Installed: sys-apps/openrc There has been a refactoring of the old 'xdm' init script and its requirements from various packages into an independent package: gui-libs/display-manager-init This package provides the 'display-manager' startup script for handling your chosen display manager, without being dependent on Xorg server. To update to the new DM init scripts, you need to manually add the package in your @world set: emerge -vuDU gui-libs/display-manager-init To start using the new init scripts, change the DISPLAYMANAGER variable in the /etc/conf.d/display-manager to your preferred DM: DISPLAYMANAGER="gdm" and remove 'xdm' from the default runlevel and add 'display-manager': rc-update del xdm default rc-update add display-manager default The changes are complete and on the next reboot, 'display-manager' will start your chosen DM. To switch to the new scripts without rebooting, run the following commands in a tty: rc-service xdm stop rc-service display-manager start
Re: [gentoo-dev] [RFC] Refactor display manager openrc init scripts to independent package
On 10/18/20 8:57 PM, Rich Freeman wrote: On Sun, Oct 18, 2020 at 4:17 AM Andreas Sturmlechner wrote: I'm sure there is a way for the display-manager ebuild to migrate from old xdm configs on users' systems. How much do config and init scripts differ at all? Couldn't you just use a symlink so that either script name works? Then the news item can be about deprecating the old name. There need not be any rush to stop supporting it. It is a possibility but I am opposed to this idea. If more people want this, then I can implement it, its not hard, but it is just delaying the inevitable. I do not see a long term use of this. Aisha
Re: [gentoo-dev] [REVIEW] News Item - 2020-10-17-display-manager-init
On 10/18/20 9:40 AM, Gordon Pettey wrote:
> On Sun, Oct 18, 2020 at 6:02 AM Aisha Tammy wrote:
>
> On 10/18/20 2:29 AM, Joonas Niilola wrote:
> > On 10/18/20 8:48 AM, Michał Górny wrote:
> >> Do you really think a rename for the sake of renaming justifies
> >> requiring all users to rewrite their configuration? While we're
> >> requiring the users to do that, wouldn't it be better to stop using
> >> the awful layout of 'one script to run them all', and switch to
> separate
> >> scripts for every DM?
> >>
> > This is exactly what I proposed in the previous RFC, systemd already
> works this way and is IMHO a lot clearer to use.
> >
> > -- juippis
> >
>
> This would need some more tinkering as OpenRC doesn't have a dedicated
> mechanism to control vt's while systemd controls the vts.
>
>
> Aside from that...
>
> Additionally we would need to able to say that each of them is going to
> conflict
> with the other.
>
>
> What conflict? Each package should have an init script with a matching name.
> The only conflict might arise from
> putting both in the same runlevel (assuming they don't just take the next
> available VT). If a user wants to try out
Making them take the next VT is the crucial point, as OpenRC
doesn't keep track of which VTs are currently used.
You can use openvt from sys-apps/kbd to check if a VT is
free or not (stolen from slashbeast in the PR)
openvt -c ${VT_N:-7} true >/dev/null 2>&1
This has race conditions when being used with openrc parallel
starts as two DMs can check for VT 7 being free and then try
to start on VT 7 in parallel, which is not cool.
This means that we need to make sure to only have ONE of the DM
scripts is enabled in the default runlevel (not a good idea to put
them in other runlevels).
Aisha
> a different DM, it is simpler IMHO to
> /etc/init.d/old-dm stop && /etc/init.d/new-dm start
> than editing xdm.conf. If new-dm crashes the system for whatever reason, no
> need to remember to edit xdm.conf
> to restore your old choice; just reboot and old-dm which was in the default
> runlevel is still your DM.
Re: [gentoo-dev] [REVIEW] News Item - 2020-10-17-display-manager-init
On 10/18/20 8:22 AM, Mikle Kolyada wrote: > > 18.10.2020 01:05, Aisha Tammy пишет: >> Hi, >> I'm attaching the news item for the upcoming display-manager-init changes >> >> Thanks, >> Aisha >> >> --- >> >> Title: New OpenRC Display Manager Initializer Scripts >> Author: Aisha Tammy >> Posted: 2020-10-17 >> Revision: 1 >> News-Item-Format: 2.0 >> >> > > Systemd users have nothing to do with this news item, so please make it > openrc-dependent. > Sounds good.
Re: [gentoo-dev] [REVIEW] News Item - 2020-10-17-display-manager-init
On 10/18/20 2:29 AM, Joonas Niilola wrote: > > > On 10/18/20 8:48 AM, Michał Górny wrote: >> On Sat, 2020-10-17 at 18:05 -0400, Aisha Tammy wrote: >>> This package provides the 'display-manager' startup script for >>> handling your chosen display manager, without being dependent on >>> Xorg server. > being dependent -> depending > >> >> Do you really think a rename for the sake of renaming justifies >> requiring all users to rewrite their configuration? While we're >> requiring the users to do that, wouldn't it be better to stop using >> the awful layout of 'one script to run them all', and switch to separate >> scripts for every DM? >> > This is exactly what I proposed in the previous RFC, systemd already works > this way and is IMHO a lot clearer to use. > > -- juippis > This would need some more tinkering as OpenRC doesn't have a dedicated mechanism to control vt's while systemd controls the vts. IMO systemd is also very centralized, except that it hides it in its internals, as every services that wants to use a tty has to register with it. Nothing wrong with that, its a perfectly good method. I'm curious about why people are averse to a centralized script, it seems to be the simpler and cleaner option, atleast to me, presumably as different scripts for each DM *can* have different working mechanisms, and any fix applied to one of the DMs might have to be applied to others. Also the fact that the packages don't supply an OpenRC script on their own so every package would need an additional file from our end. Additionally we would need to able to say that each of them is going to conflict with the other. Aisha
Re: [gentoo-dev] [REVIEW] News Item - 2020-10-17-display-manager-init
On 10/17/20 6:44 PM, Kent Fredric wrote: > On Sun, 18 Oct 2020 11:41:38 +1300 > Kent Fredric wrote: > >> Uh, do we need a new catagory for this one package? > > Scratch that, my brain is disabled and my eixing failed the first time > and I jumped because it was a category with no recollection of seeing > before. > Lolol, np. > Now I see there is one, I do still think "That's a bit weird", but > whatever, not adding a new category -> no issue. > > Many apologies. > > ( Though I still find the choice of category very odd ) > Hmmm, I thought of this package as just providing the startup scripts and not the actual display-manager themselves, so it feels more like a library (gui-libs) than an app (gui-apps). Am open to suggestions but this feels OK to me. Aisha signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [REVIEW] News Item - 2020-10-17-display-manager-init
On 10/17/20 6:44 PM, Alexey Sokolov wrote: > сб, 17 окт. 2020 г. в 23:05, Aisha Tammy : >> >> Hi, >> I'm attaching the news item for the upcoming display-manager-init changes >> >> Thanks, >> Aisha >> >> --- >> >> Title: New OpenRC Display Manager Initializer Scripts >> Author: Aisha Tammy >> Posted: 2020-10-17 >> Revision: 1 >> News-Item-Format: 2.0 > > This will be shown even if no xdm was installed? Yes, that is true, but there is no xdm package per se (not referring to the display manager XDM, but the init script xdm). This is one of the reasons for the refactoring, because there is no single provider for xdm, parts of the scripts are present in sysvinit, xinit, xorg-server. And the overloading of terms for xdm init script and XDM display manager . This puts them together into one package, while renaming and clearing the confusion. A potential check could be for xorg-server, which should be OK, but I don't see the harm in being a bit more cautious and letting everyone read it. Display-If-Present: x11-base/xorg-server > >> >> There has been a refactoring of the old 'xdm' init script and its >> requirements from various packages into an independent package: >> >> gui-libs/display-manager-init >> >> This package provides the 'display-manager' startup script for >> handling your chosen display manager, without being dependent on >> Xorg server. >> >> To update to the new DM init scripts, you need to manually add the >> package in your @world set: >> >> emerge -vuDU gui-libs/display-manager-init >> >> To start using the new init scripts, change the DISPLAYMANAGER >> variable in the /etc/conf.d/display-manager to your preferred DM: >> >> DISPLAYMANAGER="gdm" >> >> To test the newly installed scripts, you can try to switch to >> 'display-manager' on the running computer. >> Run the following commands in a tty to test your current install: >> >> rc-service xdm stop >> rc-service display-manager start >> >> If the test succeeds, you can remove the old xdm startup script >> and add display-manager to the default runlevel: >> >> rc-update del xdm default >> rc-update add display-manager default >> >> Reboot your computer to perform a final test and check to see >> that your chosen display manager has started. > > What happens if I ignore this news item and do nothing? > If you ignore this news item and upgrade your packages without installing display-manager-init, you will no longer have an 'xdm' init script and you will not get a gui on boot. (Don't ignore news items people :P) Aisha
Re: [gentoo-dev] [REVIEW] News Item - 2020-10-17-display-manager-init
On 10/17/20 6:41 PM, Kent Fredric wrote: > On Sat, 17 Oct 2020 18:05:40 -0400 > Aisha Tammy wrote: > >> gui-libs/display-manager-init > > Uh, do we need a new catagory for this one package? > It's already a category, though a little less known one. signature.asc Description: OpenPGP digital signature
[gentoo-dev] [REVIEW] News Item - 2020-10-17-display-manager-init
Hi, I'm attaching the news item for the upcoming display-manager-init changes Thanks, Aisha --- Title: New OpenRC Display Manager Initializer Scripts Author: Aisha Tammy Posted: 2020-10-17 Revision: 1 News-Item-Format: 2.0 There has been a refactoring of the old 'xdm' init script and its requirements from various packages into an independent package: gui-libs/display-manager-init This package provides the 'display-manager' startup script for handling your chosen display manager, without being dependent on Xorg server. To update to the new DM init scripts, you need to manually add the package in your @world set: emerge -vuDU gui-libs/display-manager-init To start using the new init scripts, change the DISPLAYMANAGER variable in the /etc/conf.d/display-manager to your preferred DM: DISPLAYMANAGER="gdm" To test the newly installed scripts, you can try to switch to 'display-manager' on the running computer. Run the following commands in a tty to test your current install: rc-service xdm stop rc-service display-manager start If the test succeeds, you can remove the old xdm startup script and add display-manager to the default runlevel: rc-update del xdm default rc-update add display-manager default Reboot your computer to perform a final test and check to see that your chosen display manager has started.
Re: [gentoo-dev] [RFC] Refactor display manager openrc init scripts to independent package
On 10/11/20 5:07 AM, Hans Fernhout wrote: > > > On 10/10/20 2:26 PM, Aisha Tammy wrote: >> >>>> - Configuration of display-manager is done similar to xdm by modifying >>>> /etc/conf.d/display-manager >>>> - Add display-manager to default runlevel and it should start working >>> My counter-proposal at this point would be to handle DMs similarily to >>> how it's done with systemd. In other words, every DM would provide their >>> own init and conf files (or, "service" files) and they'd be controlled >> This is quite hard as openrc manages tty handling differently than >> systemd. >> Currently display-managers work by adding an extra run level in openrc >> (see >> https://github.com/gentoo/gentoo/pull/16554/files#diff-6d89a718d595e0c0516c6d6b96bd4cd5R21) >> >> It is not possible to do this independently for each of lightdm/gdm/sddm >> separately, there would be too much redundant copying of code. >> > Would this not be resolved by switching to openrc-init instead of systemv > init? > > Gentoo is about choice and we can't (and don't want to) enforce the fact that people should use openrc-init while we have a compatible solution to work with both. Aisha
Re: [gentoo-dev] [RFC] Refactor display manager openrc init scripts to independent package
On 10/10/20 2:18 PM, Ulrich Mueller wrote: >>>>>> On Sat, 10 Oct 2020, Aisha Tammy wrote: > >> On 10/10/20 8:00 AM, Joonas Niilola wrote: >>>> - xdm init.d is replaced by display-manager init.d script >>> >>> Why this rename? I can't find a reason for that. >>> >> The name change was to make it clear that its separate from xorg-server >> as it no longer has any ties to xdm. >> display-manager can be run without having xdm on your system. > > Still sounds like a rename for the sake of renaming. /etc/init.d/xdm > is already now a generic init script and not tied to any specific > display manager. > > Since this will affect users' systems (and maybe require manual > intervention), I think you'll need a better reason for renaming. > Manual intervention is going to be needed in any case. The display manager inits are independent scripts and need to be installed manually as none of the display managers have a dependency on it. In which case it makes sense to also make it clear what these scripts are for and to not overload the xdm term for both the actual dm and also the init script. > Ulrich > signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Refactor display manager openrc init scripts to independent package
On 10/10/20 8:00 AM, Joonas Niilola wrote: > > On 10/10/20 1:57 PM, Aisha Tammy wrote: >> Hi all, >> This change is for OpenRC init scripts only. >> Currently the way our display managers are started, is by using the >> xdm init script present in the xorg-base/xorg-server package, with its >> script >> dependencies spread across four other packages, without any logical >> separation. >> This makes it so that every display manager needs the whole xorg-server >> package even if just for the init scripts. >> There are bugs open about this for a while to refactor the scripts out >> from >> xorg-server and into their own independent package, to make them easier >> to manage and modify >> - https://bugs.gentoo.org/730644 >> - https://bugs.gentoo.org/356915 >> The change is not just for the sake of closing bugs either. >> Given the recent number of huge additions in wayland, it is now possible >> to have a Xorg-free setup starting from the display manager. >> There are wayland-only display-managers available in gentoo >> - gui-apps/gtkgreet >> - gui-apps/tuigreet >> >> It should now be possible to start these display managers using openrc >> without pulling in Xorg. >> >> The changes are currently being worked on in the PR at >> https://github.com/gentoo/gentoo/pull/16554 > > +1 to separating xdm from xorg-server. > > >> >> Changes >> - xdm init.d is replaced by display-manager init.d script > > Why this rename? I can't find a reason for that. > The name change was to make it clear that its separate from xorg-server as it no longer has any ties to xdm. display-manager can be run without having xdm on your system. > >> - Configuration of display-manager is done similar to xdm by modifying >> /etc/conf.d/display-manager >> - Add display-manager to default runlevel and it should start working > > My counter-proposal at this point would be to handle DMs similarily to > how it's done with systemd. In other words, every DM would provide their > own init and conf files (or, "service" files) and they'd be controlled This is quite hard as openrc manages tty handling differently than systemd. Currently display-managers work by adding an extra run level in openrc (see https://github.com/gentoo/gentoo/pull/16554/files#diff-6d89a718d595e0c0516c6d6b96bd4cd5R21) It is not possible to do this independently for each of lightdm/gdm/sddm separately, there would be too much redundant copying of code. > like that. I really see no point in renaming xdm to display-manager. xdm > to gdm, xdm to lightdm etc causes at least the same amount of confusion > and hassle, but would at least match the other init system. Then > swapping between openrc and systemd would be one step less difficult. > > I have both openrc and systemd systems installed, and find the systemd > way a lot cleaner in this regard. What would other people think? > > -- juippis > > >> >> Other changes, less relevant to everyday users >> - boot parameter nox has been replaced by nogui >> - usage of /etc/.nox has been removed in favor of /run/.nogui as the >> boot >> parameter is a better controller >> >> Cheers, >> Aisha >> > signature.asc Description: OpenPGP digital signature
[gentoo-dev] [RFC] Refactor display manager openrc init scripts to independent package
Hi all, This change is for OpenRC init scripts only. Currently the way our display managers are started, is by using the xdm init script present in the xorg-base/xorg-server package, with its script dependencies spread across four other packages, without any logical separation. This makes it so that every display manager needs the whole xorg-server package even if just for the init scripts. There are bugs open about this for a while to refactor the scripts out from xorg-server and into their own independent package, to make them easier to manage and modify - https://bugs.gentoo.org/730644 - https://bugs.gentoo.org/356915 The change is not just for the sake of closing bugs either. Given the recent number of huge additions in wayland, it is now possible to have a Xorg-free setup starting from the display manager. There are wayland-only display-managers available in gentoo - gui-apps/gtkgreet - gui-apps/tuigreet It should now be possible to start these display managers using openrc without pulling in Xorg. The changes are currently being worked on in the PR at https://github.com/gentoo/gentoo/pull/16554 Changes - xdm init.d is replaced by display-manager init.d script - Configuration of display-manager is done similar to xdm by modifying /etc/conf.d/display-manager - Add display-manager to default runlevel and it should start working Other changes, less relevant to everyday users - boot parameter nox has been replaced by nogui - usage of /etc/.nox has been removed in favor of /run/.nogui as the boot parameter is a better controller Cheers, Aisha
[gentoo-dev] BugDay - October 3rd - Everyone is welcome to join!
# Gentoo BugDay Come join us over at #gentoo-bugday on freenode IRC on the first Saturday of every month to squash bugs and make Gentoo a bit more awesome. You don't need to be a Gentoo developer or even a coder to help us on BugDay. Our next BugDay is on 3rd Oct 2020 and we have started making preparations for selecting and prioritizing bug categories for that day. ## Bug categories Our categories for this bugday include - Adding and improving documentation on the wiki The wiki is a *very* important documentation platform for Gentoo. We exchange our knowledge there and the wiki needs a lot of care in many areas. This is a very nice topic as a lot of people can help us do improvements based on their daily usage of software. Someone who uses awesome or i3-gaps or xmonad surely has some tidbits that they will be able to contribute to their wiki pages. People familiar with virtualization can help us improve our libvirtd, virt-manager and a host of other pages. There are no topics off limit for this and we really would like more people to join in. - Patches for packages failing with -fno-common Given the addition of GCC-10 and LLVM/Clang-10 to our repositories, there has been a whole set of softwares which have been bugging out while compiling. This is not a coincidence and we would love to know from our users which softwares have managed to fix the bugs upstream but we still haven't patched them. For developers who have found workarounds and simple fixes, we would love to get your answers and incorporate them. ## For developers Even if you have never coded for Gentoo you can help us with your knowledge. It's always valuable to have your experience to guide us. Things to help with - Find a related bug that piques your interest. - Look at upstream if this has been reported to them. - If not, make a bug report to the upstream developers. - If they have already seen it, check if they have managed to patch it. - If not, try to gather as much information as you can about the bug so that it may help the developer tackling it. - Alert us at #gentoo-bugday and interact with us to see if this can be squashed. ## For users Users are one of the most important part of Gentoo and this is the occasion for them to talk the developers and make your bugs looked at. Take a look at the categories for BugDay at the poll link and the final BugDay wiki page - Find a related bug that you have experienced and has not been fixed yet - Try to see how it can be reproduced. - The related bug reports have been ignored for months you say? Come poke us about these bugs at #gentoo-bugday on the freenode IRC and we will begin squashing any of those that are pending. ## Whats in it for me? Bragging rights, permanently being listed on the charts of BugDay, sense of entitlement. Any person who helps us solve valid problems will be given the honor of being listed on the page. Even users who help related bugs and find links which make our problem solving easier will be put on a pedestal. ## Contributors Thanks a lot to jstein@ for being the gracious organizer and making sure everything goes smoothly. And special thanks to contributors who have worked on our previous BugDays. Past contributors and bug days: - https://wiki.gentoo.org/wiki/Bugday_2020-06-06 - https://wiki.gentoo.org/wiki/Bugday_2020-07-04 - https://wiki.gentoo.org/wiki/Bugday_2020-08-01 - https://wiki.gentoo.org/wiki/Bugday_2020-09-05
[gentoo-dev] BugDay - August 1st - Everyone is welcome to join!
# Gentoo BugDay Come join us over at #gentoo-bugday on freenode IRC on the first Saturday of every month to squash bugs and make Gentoo a bit more awesome. You don't need to be a Gentoo developer or even a coder to help us on BugDay. Our next BugDay is on 1st Aug 2020 and we have started making preparations for selecting and prioritizing bug categories for that day. ## Bug categories The bug categories should be broad enough that there will be a lot of bugs being targeted. We keep a option poll open to everybody to help us narrow down the categories of bugs to focus. The opinion poll is there to get an input from everyone about how to best tackle the current bug situation and get an understanding of the community and developer priorities. The poll is open at https://dudle.inf.tu-dresden.de/Bugday_2020-08-01/ Be sure to vote in the poll to get your opinion heard. ## For developers Even if you have never coded for Gentoo you can help us with your knowledge. It's always valuable to have your experience to guide us. Things to help with - Find a related bug that piques your interest. - Look at upstream if this has been reported to them. - If not, make a bug report to the upstream developers. - If they have already seen it, check if they have managed to patch it. - If not, try to gather as much information as you can about the bug so that it may help the developer tackling it. - Alert us at #gentoo-bugday and interact with us to see if this can be squashed. ## For users Users are one of the most important part of Gentoo and this is the occasion for them to talk the developers and make your bugs looked at. Take a look at the categories for BugDay at the poll link and the final BugDay wiki page - Find a related bug that you have experienced and has not been fixed yet - Try to see how it can be reproduced. - The related bug reports have been ignored for months you say? Come poke us about these bugs at #gentoo-bugday on the freenode IRC and we will begin squashing any of those that are pending. ## Whats in it for me? Bragging rights, permanently being listed on the charts of BugDay, sense of entitlement. Any person who helps us solve valid problems will be given the honor of being listed on the page. Even users who help related bugs and find links which make our problem solving easier will be put on a pedestal. ## Contributors Thanks a lot to jstein@ for being the gracious organizer and making sure everything goes smoothly. And special thanks to contributors who have worked on our previous BugDays. Past contributors: - https://wiki.gentoo.org/wiki/Bugday_2020-06-06 - https://wiki.gentoo.org/wiki/Bugday_2020-07-04
Re: [gentoo-dev] dev-python/numb-0.40.1.ebuild
On 7/2/20 12:20 PM, Aaron Bauman wrote: > > > On July 2, 2020 9:59:40 AM EDT, "Xianwen Chen (陈贤文)" wrote: >> Honestly, I find it counter productive to remove a package from the >> main >> repository, when there are active efforts to fix the package's >> problems. >> >> >> Xianwen > > These things happen. If it is being ported properly then let's add it back. > > Aisha, please adjust your PR for adding the package back and taking > maintainership. Your work is not lost. > Will do the needful. Thanks Aaron. Aisha
Re: [gentoo-dev] dev-python/numb-0.40.1.ebuild
On 7/2/20 9:16 AM, Joonas Niilola wrote: > > On 7/2/20 4:14 PM, Aisha Tammy wrote: >> On 7/2/20 9:06 AM, Xianwen Chen (陈贤文) wrote: >>> Dear juippis, >>> >>> Thank you. I checked the pull thread out on github.com. >>> >>> Do I get it right that the numba folder is already removed from >>> https://github.com/gentoo/gentoo/tree/master/dev-python? >>> >> Its not removed yet. >> It should be working now but am awaiting feedback. >> >> Aisha >> > It was just removed today. :\ > http://www.nooo.com/ my current feeling: https://imgur.com/gallery/rwpYZr2 (given the work I put into it, I feel I am entitled to posting a few memes) > Next place for numba is science overlay? > Sounds like a plan. Aisha > -- juippis > > signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] dev-python/numb-0.40.1.ebuild
On 7/2/20 9:14 AM, Aisha Tammy wrote: > On 7/2/20 9:06 AM, Xianwen Chen (陈贤文) wrote: >> Dear juippis, >> >> Thank you. I checked the pull thread out on github.com. >> >> Do I get it right that the numba folder is already removed from >> https://github.com/gentoo/gentoo/tree/master/dev-python? >> > Its not removed yet. > It should be working now but am awaiting feedback. Apologies, I should have been more verbose. The PR is updating it to latest and the PR should be in working order. Its not been merged yet due to awaiting feedback. Currently the package is only masked for removal but has not been removed yet. Aisha > > Aisha > >> Yours sincerely, >> >> Xianwen >> >> >> >> >> On 2020-07-01 19:50, Joonas Niilola wrote: >> >>> >>> On 7/1/20 10:37 PM, Xianwen Chen (陈贤文) wrote: >>>> >>>> This ebuild enables Python 3 as one of the Python targets. Otherwise >>>> there is no difference between this ebuild and the latest ebuild in >>>> Portage, which only had Python 2 as the Python target. >>>> >>>> >>> Then it probably doesn't work. Did you try running tests on python3 >>> implementations? >>> >>> There's an ongoing process trying to get it fixed for python3, and I >>> hope the science team will take over now, because this package is ... >>> >>> https://github.com/gentoo/gentoo/pull/15766 >>> >>> Also we have this site called "Bugzilla" where you would've seen any >>> bugs/process related to numba being worked on, and you could've reported >>> the julia issue earlier on: >>> >>> https://bugs.gentoo.org >>> >>> -- juippis >>> >>> > >
Re: [gentoo-dev] dev-python/numb-0.40.1.ebuild
On 7/2/20 9:06 AM, Xianwen Chen (陈贤文) wrote: > Dear juippis, > > Thank you. I checked the pull thread out on github.com. > > Do I get it right that the numba folder is already removed from > https://github.com/gentoo/gentoo/tree/master/dev-python? > Its not removed yet. It should be working now but am awaiting feedback. Aisha > Yours sincerely, > > Xianwen > > > > > On 2020-07-01 19:50, Joonas Niilola wrote: > >> >> On 7/1/20 10:37 PM, Xianwen Chen (陈贤文) wrote: >>> >>> This ebuild enables Python 3 as one of the Python targets. Otherwise >>> there is no difference between this ebuild and the latest ebuild in >>> Portage, which only had Python 2 as the Python target. >>> >>> >> Then it probably doesn't work. Did you try running tests on python3 >> implementations? >> >> There's an ongoing process trying to get it fixed for python3, and I >> hope the science team will take over now, because this package is ... >> >> https://github.com/gentoo/gentoo/pull/15766 >> >> Also we have this site called "Bugzilla" where you would've seen any >> bugs/process related to numba being worked on, and you could've reported >> the julia issue earlier on: >> >> https://bugs.gentoo.org >> >> -- juippis >> >>
Re: [gentoo-dev] Revival of Gentoo BugDay: everyone is welcome to come debug
On 6/12/20 10:54 AM, Jaco Kroon wrote: > Hi Aisha, > > On 2020/06/12 13:44, Aisha Tammy wrote: >> On 6/12/20 6:55 AM, Jaco Kroon wrote: >>> Hi, >>> >>> Can we possibly include the concept of "helping to file bug reports" here? >>> >>> For example, I've got an issue (which hasn't annoyed me just quite >>> enough yet to put effort in) where on bootup after xdm init script >>> starts it takes ~2 minutes before slim login is displayed. But I don't >>> know enough of the workings of that to even understand if this is an >>> Xorg or slim (or dbus) bug ... >>> >> BugDay is not for creating bugs, its for squashing them. >> >> You can create the bugs today and then if it is in one of the top voted >> categories (old bugs, in this case) you might be able to convince interested >> devs to target your specific ones. > > Fair enough. > > In this case I've no idea where to start with filing a sensible bug > though :). So what it really boils down to is that I think we need to > provide a way to help users help us by providing the ability to interact > with people (Yea, #gentoo works up to a point) that can assist with > basic trouble-shooting to point people towards that which could be the > problem to help with filing better bug reports. > > I've been hunting a graphics terminal corruption issue with urxvt now, > and in the man page you get this: > > [Please note that many X servers (and libXft) are buggy with > respect to "-depth 32" > and/or alpha channels, and will cause all sorts of graphical > corruption. This is > harmless, but we can't do anything about this, so watch out] > > So where to from here? Researching that it seems most other similar > reports relate to 4th-gen intel graphics ... heck, this was even > attributed to pango at some point, and some other dock launcher which > name I can't remember now. I've now explicitly set depth to 24 so I'll > know soon enough if this is the issue. To confuse the matter even more, > I've had the same corruption using aterm, and in xterm as well. But it > *only* seems to happen with terminal emulators. > > Then there is the issue I described above. > > Currently I have another two or three *desktop* related issues that > plague me, none of which are easy to point where the bug may actually > be, so to file a bug given this is hard. > > Anyway, count me in on bugday if I can be there at all. This should be > interesting. Without knowing any specifics this looks like it might be either related to font aliasing/ encoding. If there are open bugs for all of them, they would be a good candidate for investigating the X font rendering library (libXft). For people who don't know how to file bugs: You can go on bugs.gentoo.org and look around if these are already filed else open new bugs. > > Looking at the previous bug day there is one thing I don't see: > > How does this approach work? In oher words, the lead-up and > organization seems to be fairly well spelt out - but how does it work on > the day? When does it actually start? Or is this a world-wide rolling > time GMT+12 starts waking up until GMT-12 starts heading to bed? This > is the opportunity to market the event. > Good point! Information dump time - The next bugday is on 4th July (and every first saturday of the month, from then on) It is a world wide event, with a lot of flexibility on timing. Its not constrained to just GMT or a particular time zone. The event will mostly be dependent on when devs and other people start rolling in and ramping up. We will continue going until people get tired and/or a sensible amount of time to be called a "day" has passed, Most of the interaction will be happening on #gentoo-bugday, with devs talking about bugs that they are working on. Users are welcome to come and interact but don't expect us to be trouble shooting for you. Any specific interesting bugs that you can report, the more wide ranging effects of that bug, the more likely it is that somebody will pick it up. How you can help: there are a lot of open bugs on bugzilla but it is hard to pinpoint what the exact reasons for every bug are. It is possible that some bugs get ignore for a long time and become legacy. You can help is find a lot of related bugs that you think can be solved at the same time, because they seem to be sharing the same problem. These kinds of bugs will be very useful to know. Or you can just show up to motivate us and cheer us on, that helps too :) Aisha > Kind Regards, > Jaco > >> >> Aisha >> >>> Guessing #gentoo may also be of help in regards to the above, so this is >>> really just a
Re: [gentoo-dev] Revival of Gentoo BugDay: everyone is welcome to come debug
On 6/12/20 6:55 AM, Jaco Kroon wrote: > Hi, > > Can we possibly include the concept of "helping to file bug reports" here? > > For example, I've got an issue (which hasn't annoyed me just quite > enough yet to put effort in) where on bootup after xdm init script > starts it takes ~2 minutes before slim login is displayed. But I don't > know enough of the workings of that to even understand if this is an > Xorg or slim (or dbus) bug ... > BugDay is not for creating bugs, its for squashing them. You can create the bugs today and then if it is in one of the top voted categories (old bugs, in this case) you might be able to convince interested devs to target your specific ones. Aisha > Guessing #gentoo may also be of help in regards to the above, so this is > really just a suggestion. Yes, it will generate more bugs, but > hopefully the concept will allow for creating targeted bugs rather than > overly generic difficult to trouble-shoot bugs. > > Kind Regards, > Jaco > > On 2020/06/11 14:41, Aisha Tammy wrote: > >> # Gentoo BugDay >> >> >> >> >> Come join us over at #gentoo-bugday on freenode IRC on the first Saturday of >> every month >> >> >> to squash bugs and make Gentoo a bit more awesome. >> >> >> >> >> You don't need to be a Gentoo developer or even a coder to help us on BugDay. >> >> >> Our next BugDay is on 4th July 2020 and we have started making preparations >> for >> selecting and prioritizing bug categories for that day. >> >> >> >> ## Bug categories >> >> >> >> >> The bug categories should be broad enough that there will be a lot of bugs >> being >> >> targeted. >> >> >> >> >> We keep a option poll open to everybody to help us narrow down the >> categories of bugs to focus. >> >> >> The opinion poll is there to get an input from everyone about how to best >> tackle the >> >> >> current bug situation and get an understanding of the community and >> developer priorities. >> >> >> >> >> The poll is open at https://dudle.inf.tu-dresden.de/Bugday_2020-07-04/ >> >> >> Be sure to vote in the poll to get your opinion heard. >> >> >> >> ## For developers >> >> >> >> >> Even if you have never coded for Gentoo you can help us with your experience. >> >> It's always valuable to have your experience to guide us. >> >> >> >> >> Things to help with >> >> >> - Find a related bug that piques your interest. >> >> >> - Look at upstream if this has been reported to them. >> >> >> - If not, make a bug report to the upstream developers. >> >> >> - If they have already seen it, check if they have managed to patch it. >> >> >> - If not, try to gather as much information as you can about the bug so that >> >> >> it may help the developer tackling it. >> >> >> - Alert us at #gentoo-bugday and interact with us to see if this can be >> squashed. >> >> >> >> >> ## For users >> >> >> >> >> Users are one of the most important part of Gentoo and this is the occasion >> for >> >> >> them to talk the developers and make your bugs looked at. >> >> >> >> >> Take a look at the categories for BugDay at the poll link and the final >> BugDay >> >> >> wiki page >> >> >> - Find a related bug that you have experienced and has not been fixed yet >> >> >> - Try to see how it can be reproduced.Gnome not doing proper logins on you >> laptop? >> >> >> - The related bug reports have been ignored for months you say? >> >> >> >> >> Come poke us about these bugs at #gentoo-bugday on the freenode IRC and we >> will >> begin squashing any of >> >> those that are pending. >> >> >> >> >> ## Whats in it for me? >> >> >> >> >> Bragging rights, permanently being listed on the charts of BugDay, sense of >> entitlement. >> >> >> >> Any person who helps us solve valid problems will be given the honor of >> being listed on >> >> the page. >> >> Even users who help related bugs and find links which make our problem >> solving easier >> >> will be put on a pedestal. >> >> >> >> ## Contributors >> >> >> >> >> Thanks a lot to jstein@ for being the gracious organizer and making sure >> everything >> >> >> goes smoothly. >> >> >> >> >> And special thanks to contributors who have worked on our previous BugDays. >> >> Past contributors: >> >> >> - https://wiki.gentoo.org/wiki/Bugday_2020-06-06 >> >
[gentoo-dev] Revival of Gentoo BugDay: everyone is welcome to come debug
# Gentoo BugDay Come join us over at #gentoo-bugday on freenode IRC on the first Saturday of every month to squash bugs and make Gentoo a bit more awesome. You don't need to be a Gentoo developer or even a coder to help us on BugDay. Our next BugDay is on 4th July 2020 and we have started making preparations for selecting and prioritizing bug categories for that day. ## Bug categories The bug categories should be broad enough that there will be a lot of bugs being targeted. We keep a option poll open to everybody to help us narrow down the categories of bugs to focus. The opinion poll is there to get an input from everyone about how to best tackle the current bug situation and get an understanding of the community and developer priorities. The poll is open at https://dudle.inf.tu-dresden.de/Bugday_2020-07-04/ Be sure to vote in the poll to get your opinion heard. ## For developers Even if you have never coded for Gentoo you can help us with your experience. It's always valuable to have your experience to guide us. Things to help with - Find a related bug that piques your interest. - Look at upstream if this has been reported to them. - If not, make a bug report to the upstream developers. - If they have already seen it, check if they have managed to patch it. - If not, try to gather as much information as you can about the bug so that it may help the developer tackling it. - Alert us at #gentoo-bugday and interact with us to see if this can be squashed. ## For users Users are one of the most important part of Gentoo and this is the occasion for them to talk the developers and make your bugs looked at. Take a look at the categories for BugDay at the poll link and the final BugDay wiki page - Find a related bug that you have experienced and has not been fixed yet - Try to see how it can be reproduced.Gnome not doing proper logins on you laptop? - The related bug reports have been ignored for months you say? Come poke us about these bugs at #gentoo-bugday on the freenode IRC and we will begin squashing any of those that are pending. ## Whats in it for me? Bragging rights, permanently being listed on the charts of BugDay, sense of entitlement. Any person who helps us solve valid problems will be given the honor of being listed on the page. Even users who help related bugs and find links which make our problem solving easier will be put on a pedestal. ## Contributors Thanks a lot to jstein@ for being the gracious organizer and making sure everything goes smoothly. And special thanks to contributors who have worked on our previous BugDays. Past contributors: - https://wiki.gentoo.org/wiki/Bugday_2020-06-06
Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]
On 6/7/20 2:28 AM, Joonas Niilola wrote: > > On 6/6/20 10:11 PM, Aisha Tammy wrote: >> On 6/6/20 2:50 PM, Aaron Bauman wrote: >>> All, the graphics project has now been disbanded. >>> >> Is it weird to ask what happened? >> >> It seems like a lot of the packages listed here should be and are >> very popular :O >> >> Aisha >> > Hi, > > floppym's response sums it up. > > https://archives.gentoo.org/gentoo-dev/message/c0b5e5e1ab4e0ed77725d4366a5232be > > jstein started a new thread about this subject, > > https://archives.gentoo.org/gentoo-dev/message/f9fae5f9583e73e6d4dbf4fc521dd559 > Indeed, thanks a lot. I should have anticipated that there would be further discussion on this, before prematurely asking simple question >.< Nonetheless, an interesting situation. I never knew too much about projects. Aisha > -- juippis > > signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]
On 6/6/20 2:50 PM, Aaron Bauman wrote: > All, the graphics project has now been disbanded. > Is it weird to ask what happened? It seems like a lot of the packages listed here should be and are very popular :O Aisha > All packages have been reassigned to maintainer-needed. Bugs will be > reassigned soon. > > Here are a list of the packages that are now up for grabs: > > dev-cpp/pngpp > media-gfx/album > media-gfx/apng2gif > media-gfx/apngasm > media-gfx/apngdis > media-gfx/apngopt > media-gfx/autopano-sift-C > media-gfx/blender > media-gfx/cellwriter > media-gfx/chafa > media-gfx/cptutils > media-gfx/darktable > media-gfx/dcraw > media-gfx/duhdraw > media-gfx/enblend > media-gfx/exact-image > media-gfx/exif > media-gfx/exiv2 > media-gfx/feh > media-gfx/fim > media-gfx/fontypython > media-gfx/fr0st > media-gfx/gif2apng > media-gfx/gif2png > media-gfx/gifsicle > media-gfx/gimageview > media-gfx/gmic > media-gfx/gnofract4d > media-gfx/gphoto2 > media-gfx/gphotofs > media-gfx/gpicview > media-gfx/gqview > media-gfx/graphicsmagick > media-gfx/grub-splashes > media-gfx/gtkam > media-gfx/gtkimageview > media-gfx/hugin > media-gfx/icon-slicer > media-gfx/igal > media-gfx/imagemagick > media-gfx/jhead > media-gfx/jigl > media-gfx/jpeg2ps > media-gfx/jpeginfo > media-gfx/jpegoptim > media-gfx/jpegpixi > media-gfx/jpegtoavi > media-gfx/libimagequant > media-gfx/llgal > media-gfx/luminance-hdr > media-gfx/mandelbulber > media-gfx/mcomix > media-gfx/metapixel > media-gfx/mscgen > media-gfx/nvidia-cg-toolkit > media-gfx/openclipart > media-gfx/panini > media-gfx/pdf2svg > media-gfx/png2ico > media-gfx/pngcheck > media-gfx/pngcrush > media-gfx/pngquant > media-gfx/pngrewrite > media-gfx/pngtools > media-gfx/potrace > media-gfx/povtree > media-gfx/pqiv > media-gfx/pqstego > media-gfx/qiv > media-gfx/qvv > media-gfx/raw-thumbnailer > media-gfx/rawtherapee > media-gfx/rotoscope > media-gfx/scantailor-advanced > media-gfx/scour > media-gfx/scrot > media-gfx/sfftobmp > media-gfx/shotwell > media-gfx/sxiv > media-gfx/tintii > media-gfx/tuxpaint-stamps > media-gfx/tuxpaint > media-gfx/ufraw > media-gfx/uniconvertor > media-gfx/wings > media-gfx/wkhtmltopdf > media-gfx/xli > media-gfx/xloadimage > media-gfx/xsane > media-gfx/xzgv > media-libs/cimg > media-libs/esdl > media-libs/exiftool > media-libs/flickcurl > media-libs/gd > media-libs/giblib > media-libs/giflib > media-libs/icclib > media-libs/imlib > media-libs/jbig2dec > media-libs/jbigkit > media-libs/jpeg > media-libs/lasi > media-libs/lensfun > media-libs/libexif-gtk > media-libs/libexif > media-libs/libfpx > media-libs/libgphoto2 > media-libs/libharu > media-libs/libheif > media-libs/libicns > media-libs/libjpeg-turbo > media-libs/libmng > media-libs/libpano13 > media-libs/libpgf > media-libs/libpqstego > media-libs/libraw > media-libs/libwebp > media-libs/netpbm > media-libs/opencolorio > media-libs/openimageio > media-libs/openjpeg > media-libs/pnglite > media-libs/stimg > media-libs/tiff > media-libs/urt > sci-visualization/grace > virtual/imagemagick-tools > virtual/jpeg-compat > virtual/jpeg > x11-libs/gdk-pixbuf-loader-webp > x11-misc/gromit > x11-misc/shutter > signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo/OpenBSD current status
On 6/1/20 4:19 PM, Peter Stuge wrote: > Benda Xu wrote: >>> I was wondering if the openbsd prefix support is something >>> that is still garnering any interest from gentoo? >> >> There is still interest in Gentoo. But no one seems to have energy to >> take care of it. > > FWIW I have interest in this as well. > > >> Your contribution is welcomed. Unfortunately I don't have any where near the skill set for this :( I can provide moral support and some debugging help as a guinea pig. > > What contributions are known to be needed at the moment? Same question, I am not even sure where to start. Aisha > > > Kind regards > > //Peter > signature.asc Description: OpenPGP digital signature
[gentoo-dev] Gentoo/OpenBSD current status
Hi maksbotan and other devs, I've been trying to play around with the prefix and reading the code. Basically trying to get it to work for my system. I've not managed to get even a small headstart and am quite lost to say the least. I was wondering if the openbsd prefix support is something that is still garnering any interest from gentoo? Would love to know if it could be possible in anyway. Aisha signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] unverifiable GPG keys for @gentoo.org members
On 5/13/20 4:42 PM, Michał Górny wrote: > On Tue, 2020-05-12 at 06:20 -0400, Aisha Tammy wrote: >> On 5/12/20 1:24 AM, Michał Górny wrote: >>> W dniu pon, 11.05.2020 o godzinie 20∶20 -0400, użytkownik Aisha Tammy >>> napisał: >>>> Hi devs@, >>>> Seems like for some reason the gentoo.org does not publish the >>>> gpg public keys of the senders, even though it is signed correctly. >> >> Oh, very sorry if I came out that way. I wasn't being passive aggressive. >> Sometimes I write things the wrong way. I should have definitely written >> it better :( >> > > I'm sorry, it might have been my fault for reading your mail the wrong > way. It really sounded like 'why do you set such high standards for > everyone when you can't get the basics working'. Again, I'm sorry, > I should have knee-jerk reacted on it anyway. > No hard feelings at all :) I'm sure everything is a nice learning experience for everybody involved, we can only do better from now on. I'm still figuring out where my setup has gone wrong but I'm sure I'll get to it in the end :) And I think it is actually really nice that gentoo maintains high standards which is one of the reasons I like contributing to this project. In no way, except direct words, will I want to imply my discomfort with any policy (if ever I have a need). Thanks again to everybody involved and I hope everyone stays safe, Aisha
Re: [gentoo-dev] unverifiable GPG keys for @gentoo.org members
On 5/12/20 1:24 AM, Michał Górny wrote: > W dniu pon, 11.05.2020 o godzinie 20∶20 -0400, użytkownik Aisha Tammy > napisał: >> Hi devs@, >> Seems like for some reason the gentoo.org does not publish the >> gpg public keys of the senders, even though it is signed correctly. > Oh, very sorry if I came out that way. I wasn't being passive aggressive. Sometimes I write things the wrong way. I should have definitely written it better :( >> >> Just wanted to know why the devs are required to use gpg keys, glep63 >> [1] >> but even when the server has the public keys, they aren't published >> properly. >> >> From a proper security perspective, I would have though something >> like WKD[2] would have been implemented on the server side for >> automated >> authentication. > > WKD is implemented and I don't know a single case where it wouldn't > work. If it doesn't work for you, then I dare say it's more likely to > be a problem with your setup. However, if it's a problem on our end, > I'd really appreciate a bug report before calling us retarded. > > In fact, the link you've posted actually lists gentoo.org as one > of the few organizations implementing WKD. > Oh my, now I really feel bad. I definitely don't want to call anyone retarded or any such words. I never like to use very strong words such as those. While I agree I should've worded it better, please don't make it look like I am name calling and insulting everybody, and being a jerk in general. So I would really love it if you don't put those words in my mouth for me. I actually thought that this was the proper channel to ask for these things. Maybe the dev mailing list was not the proper place, I didn't think about it being perceived as accusatory. I mostly thought it would be related to a bug or an oversight. It is 110% possible for my setup to have mistakes. I even said as much. I would love to fix that. Indeed, because the link actually mentioned that gentoo.org has setup WKD that is why I was a bit surprised when some of the keys were not found. >> Why do you claim that? How did you verify it? I am using enigmail + thunderbird which I thought would have should be making proper requests for the WKD keys and it reported that for some of the emails sent from devs they keys were not found on the keyserver. I will be doing a lot more debugging today and will try to see where things went wrong on my end. Now that you say it has been implemented properly, I feel that I should do a lot more work on my side :) >> >> Maybe I am missing something about how to verify the keys of the >> maintainers >> who are sending announcements but it irks me a teensy bit when i have >> signed >> mails and I can't ~~trust~~ verify the signatures. >> >> > > You are missing that WKD does not provide authentication, and if it > were, it would be considered thoroughly insecure. Authentication > in OpenPGP is generally provided via web of trust. For Gentoo > developers, you can also use our Authority Keys [3,4,5]. > This is actually an interesting point. It might be better to discuss that over irc. The web of trust is actually a topic which I have some weird thoughts over. Best, Aisha >> >> [1] >> https://wiki.gentoo.org/wiki/Project:Infrastructure/Generating_GLEP_63_based_OpenPGP_keys >> [2] https://wiki.gnupg.org/WKD > > [3] https://www.gentoo.org/downloads/signatures/ > [4] https://www.gentoo.org/glep/glep-0079.html > [5] https://wiki.gentoo.org/wiki/Project:Infrastructure/Authority_Keys > >
Re: [gentoo-dev] unverifiable GPG keys for @gentoo.org members
On 5/11/20 8:20 PM, Aisha Tammy wrote: > Hi devs@, > Seems like for some reason the gentoo.org does not publish the > gpg public keys of the senders, even though it is signed correctly. > Sorry, I meant **mail signing**, not commit signing. Just saw that wording was confusing. > Just wanted to know why the devs are required to use gpg keys, glep63 [1] > but even when the server has the public keys, they aren't published properly. > > From a proper security perspective, I would have though something > like WKD[2] would have been implemented on the server side for automated > authentication. > > Maybe I am missing something about how to verify the keys of the maintainers > who are sending announcements but it irks me a teensy bit when i have signed > mails and I can't ~~trust~~ verify the signatures. > > This is tots an aside from normal gentoo stuff. > > Hope ya'll are safe, > Aisha > > > > [1] > https://wiki.gentoo.org/wiki/Project:Infrastructure/Generating_GLEP_63_based_OpenPGP_keys > [2] https://wiki.gnupg.org/WKD >
[gentoo-dev] unverifiable GPG keys for @gentoo.org members
Hi devs@, Seems like for some reason the gentoo.org does not publish the gpg public keys of the senders, even though it is signed correctly. Just wanted to know why the devs are required to use gpg keys, glep63 [1] but even when the server has the public keys, they aren't published properly. >From a proper security perspective, I would have though something like WKD[2] would have been implemented on the server side for automated authentication. Maybe I am missing something about how to verify the keys of the maintainers who are sending announcements but it irks me a teensy bit when i have signed mails and I can't ~~trust~~ verify the signatures. This is tots an aside from normal gentoo stuff. Hope ya'll are safe, Aisha [1] https://wiki.gentoo.org/wiki/Project:Infrastructure/Generating_GLEP_63_based_OpenPGP_keys [2] https://wiki.gnupg.org/WKD
Re: [gentoo-dev] dev-python/llvmlite update to 0.32
On 5/11/20 2:35 AM, Michał Górny wrote: > W dniu nie, 10.05.2020 o godzinie 14∶54 -0400, użytkownik Aisha Tammy > napisał: >> On 5/10/20 2:11 PM, Michał Górny wrote: >>> W dniu nie, 10.05.2020 o godzinie 07∶21 -0400, użytkownik Aisha >>> Tammy >>> napisał: >>>> On 5/10/20 2:02 AM, Michał Górny wrote: >>>>> W dniu sob, 09.05.2020 o godzinie 22∶39 -0400, użytkownik Aisha >>>>> Tammy >>>>> napisał: >>>>>> Hey all, >>>>>> I was hoping to upgrade the dev-python/numba jit compiler >>>>>> in >>>>>> proxy- >>>>>> maint but it depends on dev-python/llvmlite >=0.31 >>>>>> Current version of llvmlite is stuck at 0.30 which is >>>>>> preventing >>>>>> the >>>>>> numba package from being upgraded. >>>>>> It is at a risk of last rite retiring because its stuck at >>>>>> 3.6 >>>>> >>>>> It is more likely to be last rited because upstream still >>>>> didn't >>>>> manage >>>>> to port it to LLVM 9. I don't have LLVM 8 anymore, and I don't >>>>> have >>>>> the resources to build 3 different LLVM versions. >>>>> >>>> The following issue tells that LLVM 9 is now supported :) >>>> https://github.com/numba/llvmlite/issues/523 >>>> >>>> They haven't updated their documentation correctly. >>> >>> I suppose this means using the fancy variable to disable LLVM >>> version >>> checks, correct? >>> >> lol, you seem to be experienced with this kind of behaviour :P . >> I won't even ask how many times this may have burned you XD . >> Indeed, they have changed the version checking feature pretty >> recently >> though nothing too coherent has been given out yet. > > Well, I've noticed it when I checked if they finally stopped requiring > 8.*. I presumed they've added it instead of proper support for LLVM 9 > but didn't expect it to actually pass tests (modulo two silly tests, > one checking version and other exact error message). > >> >> Here's to hoping they do it over summer. >> >>>> PS: regarding lack of resources. >>>> I have a spare computer and am willing to use that to do some >>>> testing >>>> for >>>> interesting packages like these. I hope it can help us keep a few >>>> more >>>> packages that would otherwise be killed off. >>> >>> Well, my hardware died two days ago, so I should have more >>> resources >>> mid-next week. Until then, only minimal work that can be done with >>> backup hardware. >>> >> That sucks, hardware failure is the bane of everyones existence T.T >> > > Well, hardware upgrade was long overdue, so there is the bright side. > My plan was to keep the old PC as backup distcc node but I guess it > wouldn't amount to much. It was Athlon64 x2 3800+ (from the times when > they still called it 'Athlon64'). > > In any case, I've just tested the version bump and will push it > shortly. Thanks! > Oh, thanks a lot for your work! Aisha
Re: [gentoo-dev] Packages up for grabs: net-mail/notmuch, dev-python/..., erlang related, ...
On 5/10/20 8:35 PM, Ralph Seichter wrote: > * aide...@gentoo.org: > >> net-mail/muchsync >> net-mail/notmuch > > I can take both. I already maintain these two for MacPorts, and I use > notmuch daily (as in: right now). > awesome, thanks a lot for your work. > -Ralph > I take back my previous request in that case :) Aisha
Re: [gentoo-dev] Packages up for grabs: net-mail/notmuch, dev-python/..., erlang related, ...
On 5/10/20 5:59 PM, aide...@gentoo.org wrote: > Hi, > > The following packages are up for grabs: > > app-misc/tek > app-misc/timew > app-text/dbacl > dev-python/dkimpy > dev-python/potr > dev-python/precis-i18n > dev-python/urwidtrees > dev-util/rebar-bin > net-mail/muchsync > net-mail/notmuch > sys-apps/biosdevname > > due to my retirement. > > I'd like to highlight net-main/notmuch which has a great upstream devs. > > Can I take not-much through proxy-maint? I have another package that needs it. Cheers, Aisha > Cheers, > -- aidecoe >
Re: [gentoo-dev] dev-python/llvmlite update to 0.32
On 5/10/20 2:11 PM, Michał Górny wrote: > W dniu nie, 10.05.2020 o godzinie 07∶21 -0400, użytkownik Aisha Tammy > napisał: >> On 5/10/20 2:02 AM, Michał Górny wrote: >>> W dniu sob, 09.05.2020 o godzinie 22∶39 -0400, użytkownik Aisha >>> Tammy >>> napisał: >>>> Hey all, >>>> I was hoping to upgrade the dev-python/numba jit compiler in >>>> proxy- >>>> maint but it depends on dev-python/llvmlite >=0.31 >>>> Current version of llvmlite is stuck at 0.30 which is preventing >>>> the >>>> numba package from being upgraded. >>>> It is at a risk of last rite retiring because its stuck at 3.6 >>> >>> It is more likely to be last rited because upstream still didn't >>> manage >>> to port it to LLVM 9. I don't have LLVM 8 anymore, and I don't >>> have >>> the resources to build 3 different LLVM versions. >>> >> The following issue tells that LLVM 9 is now supported :) >> https://github.com/numba/llvmlite/issues/523 >> >> They haven't updated their documentation correctly. > > I suppose this means using the fancy variable to disable LLVM version > checks, correct? > lol, you seem to be experienced with this kind of behaviour :P . I won't even ask how many times this may have burned you XD . Indeed, they have changed the version checking feature pretty recently though nothing too coherent has been given out yet. Here's to hoping they do it over summer. >> >> PS: regarding lack of resources. >> I have a spare computer and am willing to use that to do some testing >> for >> interesting packages like these. I hope it can help us keep a few >> more >> packages that would otherwise be killed off. > > Well, my hardware died two days ago, so I should have more resources > mid-next week. Until then, only minimal work that can be done with > backup hardware. > That sucks, hardware failure is the bane of everyones existence T.T Cheers and hope things get better, Aisha
Re: [gentoo-dev] dev-python/llvmlite update to 0.32
On 5/10/20 7:21 AM, Aisha Tammy wrote: > On 5/10/20 2:02 AM, Michał Górny wrote: >> W dniu sob, 09.05.2020 o godzinie 22∶39 -0400, użytkownik Aisha Tammy >> napisał: >>> Hey all, >>> I was hoping to upgrade the dev-python/numba jit compiler in proxy- >>> maint but it depends on dev-python/llvmlite >=0.31 >>> Current version of llvmlite is stuck at 0.30 which is preventing the >>> numba package from being upgraded. >>> It is at a risk of last rite retiring because its stuck at 3.6 >> >> It is more likely to be last rited because upstream still didn't manage >> to port it to LLVM 9. I don't have LLVM 8 anymore, and I don't have >> the resources to build 3 different LLVM versions. >> > The following issue tells that LLVM 9 is now supported :) > https://github.com/numba/llvmlite/issues/523 > another issue which shows that even tests are now working :) https://github.com/easybuilders/easybuild-easyconfigs/pull/10133 Aisha > They haven't updated their documentation correctly. > > PS: regarding lack of resources. > I have a spare computer and am willing to use that to do some testing for > interesting packages like these. I hope it can help us keep a few more > packages that would otherwise be killed off. > > PPS: an aside, but i was always curious where the term last rited came from. > I feel like I am part of the mafia when I use that term XD > > Cheers, > Aisha >
Re: [gentoo-dev] dev-python/llvmlite update to 0.32
On 5/10/20 2:02 AM, Michał Górny wrote: > W dniu sob, 09.05.2020 o godzinie 22∶39 -0400, użytkownik Aisha Tammy > napisał: >> Hey all, >> I was hoping to upgrade the dev-python/numba jit compiler in proxy- >> maint but it depends on dev-python/llvmlite >=0.31 >> Current version of llvmlite is stuck at 0.30 which is preventing the >> numba package from being upgraded. >> It is at a risk of last rite retiring because its stuck at 3.6 > > It is more likely to be last rited because upstream still didn't manage > to port it to LLVM 9. I don't have LLVM 8 anymore, and I don't have > the resources to build 3 different LLVM versions. > The following issue tells that LLVM 9 is now supported :) https://github.com/numba/llvmlite/issues/523 They haven't updated their documentation correctly. PS: regarding lack of resources. I have a spare computer and am willing to use that to do some testing for interesting packages like these. I hope it can help us keep a few more packages that would otherwise be killed off. PPS: an aside, but i was always curious where the term last rited came from. I feel like I am part of the mafia when I use that term XD Cheers, Aisha
[gentoo-dev] dev-python/llvmlite update to 0.32
Hey all, I was hoping to upgrade the dev-python/numba jit compiler in proxy-maint but it depends on dev-python/llvmlite >=0.31 Current version of llvmlite is stuck at 0.30 which is preventing the numba package from being upgraded. It is at a risk of last rite retiring because its stuck at 3.6 Can anyone bump it to 0.32.1? It just came out 2 days ago so might be best to just work with that. additional information: don't use the 0.33.* releases as they are testing releases and prone to breaking. Thanks a lot for the work, Aisha
Re: [gentoo-dev] Cleaning up the installation handbook (Legacy boot / MBR / ...)
On 5/2/20 4:30 PM, Andreas K. Hüttel wrote: > Hey all, > > our installation handbook is right now something of a mess (in particular > regarding partitioning, bootloader, gpt/uefi, ...) > > I'm hereby volunteering to clean things up. Thanks a lot for your work :) But - I'll go the brutal way: > > * Legacy boot and MBR will get kicked out. * > > This is your chance to protest or support. I would like to ask for this to be kept somewhere at least. Is it possible to put it in a separate section or in a page outside the handbook? Having a separate page for it in the wiki might be fine as well. (I don't know if non-devs are allowed to give an opinion, so apologies if I seem presumptuous) Best, Aisha > > Cheers, > Andreas > > signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses
On 3/23/20 2:27 PM, Joonas Niilola wrote: > On 3/23/20 8:23 PM, William Hubbs wrote: >> but we need to >> find a way to notify them when a breaking change is going into a widely >> used eclass and give them time to adjust their ebuilds. >> >> >> Thoughts? >> > Subscribe to this mailing list. > > AFAIK all major changes have been posted here and pushed with some delay. > > -- juippis > > Indeed, that's what I'm doing with my popcorn `kernel`s (and also what most others have advised, even on the irc's). It's quiet enough to not clutter but useful. Aisha signature.asc Description: OpenPGP digital signature
