Re: [gentoo-dev] News item for uclibc-ng
On Wed, Feb 08, 2017 at 02:37:52PM -0500, Anthony G. Basile wrote: > Hi everyone, > > Attached you'll find a news item for uclibc-ng. I'd like to push it out > in a few days. > > This will make sure all executables link directly against libc.so.0 (as > reported by `readelf -d`) rather than via sym links like libdl.so.0 -> > libc.so.0. Then upgrade from 1.0.19 to 1.0.20 without symlink-combat: > > USE=“-symlink-compat" emerge =sys-libs/uclibc-ng-1.0.20 First quote sign is non-ascii so command doesn't work when copy-pasted to terminal.
Re: [gentoo-dev] [RFC] Addition of a new field to metadata.xml
On Sat, Jun 03, 2017 at 08:19:32PM +1200, Kent Fredric wrote: > On Sat, 03 Jun 2017 09:58:28 +0200 > Michał Górny wrote: > > > and that's a small one. I guess we could avoid this if you restricted > > those remotes to the source package used to build them all. > > I think in the event they're a form of conventional > > foo > foo-dev > foo-dbg > > etc, under the knowledge that those things can't possibly map to other > gentoo packages, we should codify only the first of those, and then have > it placed on the iteroperating code to make logical inferences from > that. > > "foo-dev" in a search query would map to "foo" if no "foo-dev" existed. > > But yeah, lots of complexity there. > > That's why I'd just say those facets shouldn't really be mapped > explicitly. > > The general pattern being: > > "If a debian id can be conjugated from another debian id by guessing > with a generic algorithm, only index the former" It is common for debian package names contain version numbers, besides other ugliness: https://packages.debian.org/search?keywords=libavcodec&searchon=names&suite=stable§ion=all You have searched for packages that names contain libavcodec in suite(s) stable, all sections, and all architectures. Found 4 matching packages. Package libavcodec-dev Package libavcodec-extra Package libavcodec-extra-56 Package libavcodec56 Obviously numbered package name libavcodec56 can be an attribute of exact ebuild, but not of a Gentoo package. With this ugliness of Debian packages naming, I'm afraid the proposed change won't take off.
Re: [gentoo-dev] Packages up for grabs
> sys-power/acpid Taking this one. signature.asc Description: Digital signature
Re: [gentoo-dev] Proliferation of IUSE=static-libs in Gentoo
On Thu, Mar 08, 2018 at 05:57:35PM +0100, Jeroen Roovers wrote: > On Thu, 08 Mar 2018 16:40:44 +0100 > Michał Górny wrote: > > > As part of that we also shouldn't deliver static libraries > > OK, so you want to absolutely kill dead the only current sane way for > developers who use Gentoo to ship static binaries to their users' > target systems? Drive them away to another Linux distro that does > support being the build platform that they need? Or force everyone to > use EXTRA_ECONF"--enable-static" and hope for them that it works for > all packages? All just because static linking *between* ebuilds is bad? This is close to my current case. Trying (in my own time) to build a (hopefully elegant) demo setup of Gentoo & crossdev with static libs enabled, to present as an alternative to CentOS which is currently the build env at my job (and static linkage is the way the product is built now). I run into cross-compilation problems when I enable USE=static-libs to any extent, despite the comment in Gentoo's fake /usr/lib64/*.so files saying "And yes, this works in the cross- compiling scenario as the sysroot-ed linker will prepend the real path". But it's what I'd rather have resolved than have no USE=static-libs at all. signature.asc Description: Digital signature
Re: [gentoo-dev] Packages up for grabs
On Tue, Mar 13, 2018 at 03:11:45PM +0100, Lars Wendler wrote: > On Tue, 13 Mar 2018 12:58:10 +0100 Pacho Ramos wrote: > > >net-wireless/hostapd > > In case nobody else wants to take it I can do. But I'm a mere user of > the package and don't know anything about its internals. So it would be > very basic/low maintenance from me. I can't let this get dropped from the tree :) I'm mere user, too, let's comaintain. Please put us both to metadata.xml (in whichever order you prefer). signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: empty directories in ${D}
On Thu, Mar 29, 2018 at 11:57:06AM -0400, Alec Warner wrote: > On Thu, Mar 29, 2018 at 11:47 AM, Michael Orlitzky wrote: > > > On 03/29/2018 11:28 AM, Alec Warner wrote: > > > > > > Is there any particular reason we need to remove them? > > > > > > > The PMS says that empty directories are undefined, so the portage > > behavior of installing them and leaving them alone leads to > > incompatibilities. Ebuilds rely on the portage behavior, and if another > > PM (within its rights) deletes them, then the package breaks with the > > non-portage PM. > > > > > So we could simply change the PMS to keep the empty directories? > > Why is removing them *better* is my question. Right, I am not aware why PMS has left this explicitly undefined. Have read through https://bugs.gentoo.org/644366 but there's no hint on why, too. I appreciate mjo's proposal. I think it would be good for ebuild maintainer to have a switch "empty dirs are ok by default". The disagreement seems to be based on a prejudice and distrust towards upstreams' build systems. signature.asc Description: Digital signature
Re: [gentoo-dev] [RFC] Personall Gentoo Installer project pre-beta release
Hi, First, my appreciation for your work! I am not going to check it out myself, but I'd enjoy watching a screencast, or at last a series of screenshots, of how it looks and works. signature.asc Description: Digital signature
[gentoo-dev] Please retain authorship of contributed patches
I'm quite sure this angry rant won't be pleasant to read for anybody,
but still I believe this post serves the good of Gentoo and this issue
is technical enough to be discussed on gentoo-dev. Also gentoo-pr list
seems retired anyway.
This is a second time I've got into a situation when a new ebuild
submitted by me gets to mainline with minimal changes but not retaining
my authorship at all.
First time it was here: https://github.com/gentoo/gentoo/pull/361 and my
rant was endorsed by monsieurp and the committer made excuses.
This time the discussion between me and the committer has never
happened.
My PR: https://github.com/gentoo/gentoo/pull/2765
My bugzilla ticket linked to it:
https://bugs.gentoo.org/show_bug.cgi?id=599088
After my pull request from Nov 6, the following commit gets into mainline:
commit e19f46dfca967f4195eedf3f37a7882fbb37b796
Author: Matthew Thode
Date: Tue Nov 15 13:55:17 2016 -0600
dev-python/secretstorage: adding for keyring
Package-Manager: portage-2.3.0
The difference between my submission and final variant by Matthew is big
in number of lines, but is trivial in content as you can see below, so I
don't believe that Matthew has written his variant from scratch on his
own (he hasn't given any note on tickets on bugs.g.o or github), it
seems more like intentional swapping and amending original lines
retaining identical outcome.
Not that authorship of one or two commits is so crucial for me, or that
I'm the most ambitious wannabe-contributor. Hell, there's not much of
code at all in the ebuild - it's trivial; but also not much is needed
here to give credit. I have contributed to quite some FOSS projects, and
have run into theft of my patches a couple of times, and it never was by
pure accident.
I beg affiliated Gentoo developers to stay sane and be thinking not just
about numbers of your commits, but also about community spirit and
relationships. Of course inexperienced contributor gets things not right
first. In such cases, great maintainers fix that and retain original
authorship; good maintainers request for changes and resubmission.
In no way I'm going to drift away from Gentoo because of this issue, no
alternatives around. (I even have a gradually maturing idea to become
Gentoo contributor on regular basis.)
Just for record, a list of projects I've contributed to: FFmpeg, Linux
kernel, VLC, GStreamer, Kamailio, Mcabber, Gajim, v4l-utils.
diff --git a/336a45f661 b/98c5361d66
index 336a45f661..98c5361d66 100644
--- a/336a45f661
+++ b/98c5361d66
@@ -1,19 +1,27 @@
-# Copyright 2016 Gentoo Foundation
+# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$
-EAPI="6"
-PYTHON_COMPAT=( python2_7 python3_{3,4,5} )
+EAPI=6
+PYTHON_COMPAT=( python{2_7,3_4,3_5} )
inherit distutils-r1
-DESCRIPTION="Python bindings to FreeDesktop.org Secret Service API"
-HOMEPAGE="http://pypi.python.org/pypi/SecretStorage";
-SRC_URI="mirror://pypi/${PN:0:1}/${PN}/${P}.tar.gz"
+MY_PN="SecretStorage"
+
+DESCRIPTION="Python bindings to FreeDesktop.org Secret Service API."
+HOMEPAGE="https://github.com/mitya57/secretstorage
https://pypi.python.org/pypi/SecretStorage";
+SRC_URI="mirror://pypi/S/${MY_PN}/${MY_PN}-${PV}.tar.gz"
LICENSE="BSD"
SLOT="0"
-KEYWORDS="~amd64 ~x86"
+KEYWORDS="amd64 ~arm64 x86 ~amd64-linux ~x86-linux"
+IUSE=""
+
+DEPEND="dev-python/setuptools[${PYTHON_USEDEP}]"
+
+RDEPEND="
+ dev-python/cryptography[${PYTHON_USEDEP}]
+ dev-python/dbus-python[${PYTHON_USEDEP}]"
-RDEPEND="dev-python/dbus-python[${PYTHON_USEDEP}]
- dev-python/cryptography[${PYTHON_USEDEP}]"
+S="${WORKDIR}/${MY_PN}-${PV}"
Re: [gentoo-dev] Please retain authorship of contributed patches
On Thu, Dec 01, 2016 at 02:27:17AM +0300, Andrew Savchenko wrote: > One more reason to use merge commits for pull requests: original > author commits with proper authorship will be retained. > > Yes, I know that some people are unhappy with non-linear history, > but this is how git works, so there is nothing wrong with merge > commits for user-contributed changes. Hi Andrew, I don't see this subject as valid reason to prefer merge commits over rebases. Personally I prefer linear history and rebases. I had a commercial project in my practice which was based on Github, and other developers submitted pull requests. My workflow was to rebase the proposed changes onto mainline branch (which of course preserves authorship data), push the updated mainline branch to central repo, and close the PR manually. Not much of work, linear history, git metadata preserved.
Re: [gentoo-dev] Please retain authorship of contributed patches
Hi Matthew, Please take my deepest excuses for unjustly blaming you, now I see that my perception was plain wrong in being so blindly emotional. On Wed, Nov 30, 2016 at 05:43:36PM -0600, Matthew Thode wrote: > While I did see your PR and bug if I remember correctly I didn't > actually use your commit or your ebuild to source it. I added it based > on the bug iirc (which is still waiting on the link it seems). Indeed, the link to PR was never added to bugzilla ticket, which is odd on my side. I guess I could have connectivity issues back then. > I should > have mentioned that bug at the very least though and/or worked with you > on the ebuild. > Again, sorry about not updating the bug or waiting to work with you on > the PR. If there's something else I can do for this let me know. Again sorry for false accusation and not getting in touch with you before starting public discussion.
Re: [gentoo-dev] Please retain authorship of contributed patches
On Thu, Dec 01, 2016 at 12:50:42PM -0800, Daniel Campbell wrote: > I completely agree that we should credit (and thank) contributors. I'm > not sure if I'm doing things correctly, but when I'm dealing with a bug > and users contribute patches or edits to ebuilds, I try to credit them > in my commit message, often asking them which nickname they'd prefer so > I can give credit to the "right" name. Is this a practice you find adequate? As turned out, the problem was lack of communication rather than misprocessing of original contribution. In Git, t's harder to erase the original authorship than to retain it, so I don't see the need to discuss subtleties here. Common practice I see in such projects as FFmpeg and Kernel is to pick the original patch if possible, or, if credit must be given just for mere concept, the contributor is mentioned in "Suggested-by:" line or just informally. > Thanks for bringing this to attention. It's somewhat related to another > discussion we've been having about copyright, and it may be worth > considering protocol for situations like the one you've outlined. Could you please give a link to archives of that discussion?
Re: [gentoo-dev] Help wanted with www-client/chromium
On Tue, Dec 13, 2016 at 06:00:25PM -0500, Mike Gilbert wrote: > Keeping up with the frequent Chromium releases is quite a chore. > Recently, phajdan.jr has been slacking on the masked dev channel > updates due a hardware problem, so I have been spending additional > time on them. > > If there are any developers with relatively fast hardware that could > take on the stable and/or beta channel updates, that would be most > appreciated. This is also something that could be done by a trusted > user. > > Help with the masked dev channel is also welcome -- especially testing > the various USE flags and unbundling libraries. Have reasonably powerful amd64 hardware, can try nightly runs. Not an affiliated gentoo developer. I guess it would be best to make up collectively a tiny git repo with scripts which do exactly what is needed? First of all it could be a set of chromium builds with different use flags (a set of such configurations needs to be defined), saved as binary packages, so that all the builds could be tested at once by unpacking every build, in turn. All build logs must be saved for review, and failures should be reported. Makes sense? Ideas? Comments?
Re: [gentoo-dev] Packages up for grabs
On Sun, Jul 01, 2018 at 10:57:40AM +0200, Pacho Ramos wrote: > net-im/mcabber > net-libs/loudmouth Taking these. signature.asc Description: Digital signature
Re: [gentoo-dev] [pre-GLEP] Gentoo binary package container format
On Wed, Nov 21, 2018 at 11:45:54AM +0100, Fabian Groffen wrote: > We agree it is hackish, and we agree we can do without. You simply > exaggerate the problem, IMO, which mostly isn't there, because it works > fine today. It can also be solved today using shell tools. I am sad that you don't see it as a productivity impediment that the user is required to know the custom tooling to do even such a trivial non-standard action as manual extraction. Maybe I will make myself look bad by admitting this, but I'm not meeting your expectations. I use Gentoo for ~11 years, and for about one year I am using my private binpkgs distributed to all my machines (i.e. I have read binary package guide fair number of times, but I stopped rereading it when I satisfied my needs). When in need, I still reached to trusty tar, and I did not even know what are the names of special tools (a toolchain?) qtbz2 and qxpak. Just few days ago I messed with binpkgs for investigation purpose. I just wanted to extract few to somewhere (definitely not into system root), and read a core dump with GDB asking it to use those extracted files for debug symbols. Of course I used `tar xaf`, because what I know is that it's honest tbz2 just with metadata appended. # tar xaf boost-1.65.0.tbz2 bzip2: (stdin): trailing garbage after EOF ignored Exit code is 0. But the notice is annoying (on subconscious level), because Silence Is Golden - "when a program has nothing interesting or surprising to say, it should shut up". > % head -c `grep -abo 'XPAKPACK' > $EPREFIX/usr/portage/packages/sys-apps/sed-4.5.tbz2 | sed 's/:.*$//'` > $EPREFIX/usr/portage/packages/sys-apps/sed-4.5.tbz2 | tar -jxf - > > results in no warnings/errors from bzip about trailing garbage, possible > thanks to the spec being smart enough about this. Thanks, this is a very concise **custom tool** to handle current binpkg format. > Not having to do this, when under stress and pressure to restore a > system to get it back into production, is a plus. Though, in that > scenario the trailing garbage warning wouldn't have been that bad > either. When understress and pressure, the irrelevant warning is not bad? I am sure it is really bad for operator's attention. signature.asc Description: Digital signature
Re: [gentoo-dev] AUTHORS file for portage repository
On Tue, Nov 27, 2018 at 09:12:26AM -0600, William Hubbs wrote: > All, > > based on the previous thread about copyright attribution clarifications, > I want to add the following AUTHORS file to the top level of the portage > repository if no one objects. > > This is based on the description of the AUTHORS file at Google [1]. > > Everyone is not required to be listed, but there is no reason you can't > add yourself if you have contributed to the tree and want to be listed. > > I hope this will satisfy everyone involved in the discussion. > > Thoughts? It seems to me this will grow huge, and be the source of annoyance for users. There's a plausible opinion that today's Unixes will stay around forever: https://utcc.utoronto.ca/~cks/space/blog/unix/DurableCurrentUnixes And obviously Gentoo is the best flavour of them, so... Are there any long-lived community FOSS projects maintaining such file? FFmpeg had such one (CREDITS file), but eschewed it in 2013 for a short notice "check git log". signature.asc Description: Digital signature
Re: [gentoo-dev] AUTHORS file for portage repository
On Tue, Nov 27, 2018 at 01:50:31PM -0800, Matt Turner wrote: > So let's satisfy everyone and be done with it: Let's put AUTHORS in > Git with a section header that states that these Copyright holders are > not obvious from the git history. This is where Sony would go. We can make it obvious from the git history, can't we? commit Author: Dev on Payroll AuthorDate: Commit: Dev on Payroll CommitDate: commit title commit description Signed-off-by: Dev on Payroll Signed-off-by: Dev on Payroll signature.asc Description: Digital signature
Re: [gentoo-dev] Packages up for grabs due to tetromino's retirement
On Sun, Mar 10, 2019 at 10:52:24AM +0100, Michał Górny wrote: > media-libs/libv4l > media-tv/v4l-utils I have some familiarity with these, I'll take them. (Everybody is welcome to co-maintain if they wish so.) signature.asc Description: Digital signature
Re: [gentoo-dev] Last rites: sys-boot/raspberrypi-firmware
On Fri, Mar 15, 2019 at 03:03:58PM +0100, Conrad Kostecki wrote: > Could we keep this package? I can take it, and make a proper release, if that > would be enough to keep this package? I am using this on my gentoo with my > Rpi3. Hi Conrad, Thank you for being this active! I am also interested in using this and keeping it in Gentoo, so let's team up! signature.asc Description: Digital signature
Re: [gentoo-dev] Introducing global USE=gui flag
On Sun, Apr 21, 2019 at 07:09:12PM +0200, David Seifert wrote: > Dear fellow developers, > as part of our effort in making Gentoo more pleasant to use, I am > suggesting to add the global USE=gui flag. The idea seems sensible to me. What should be the next step? An experimental patchset handling some tricky packages in the proposed way? signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages
On Thu, Jun 20, 2019 at 09:53:46AM -0400, Brian Evans wrote: > What significance will such numbers have when a daemon uses a new > UID/GID and really doesn't care what it is? Why do we have to go > through the effort of assigning fixed IDs at random? One reason not mentioned by mjo: this paves the way to resolution of very old frustrating problem with user/group creation when cross-compiling entire system from scratch. See https://bugs.gentoo.org/541406 signature.asc Description: Digital signature
Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags
I am also against the part of the proposal about maintainer being responsible to prebuild the docs. I'd also like to note that Gentoo users are empowered to locally bump ebuild versions in this insanely easy way, it almost always works, and it is really useful at times. With this policy, this instanely easy way will work with lower probability, because one would need to work around the missing docs package for the new version. Also, I don't see how this would work for proxy-maintained packages and just with external contributions. Proxies team members have to trust the docs prebuilt by non-devs? Or they have to build the docs themselves as part of procedure of acceptance of external contribution? Perhaps what they can do to stay safe is to sidestep external contributions which touch such packages. P.S. Not a great argument, but I just want to say this: source-based nature of Gentoo has ingrained the feeling in me that not only everything is open for studying, but also that, most of time, the result of package installation on user's machine is "sterile", not tainted by any interference from middlemen. I think the currently discussed issue is not critical. Feels odd to reduce the source-based nature because of that. signature.asc Description: Digital signature
[gentoo-dev] [RFC] News Item: sys-boot/raspberrypi-firmware will not install device tree files
Title: sys-boot/raspberrypi-firmware will not install device tree files Author: Andrey Utkin Content-Type: text/plain Posted: 2019-11-25 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: sys-boot/raspberrypi-firmware sys-boot/raspberrypi-firmware up to and including version 1.20190709 installed files /boot/*.dtb and /boot/overlays/*. Newer versions will no longer install these files. These files will be installed by sys-kernel/raspberrypi-image package. If you do not use sys-kernel/raspberrypi-image, you need to install these files according to the method you use to install the kernel. For installation from source, this can be done with such a command: make dtbs_install This change is being made to enable arm64 users and custom kernels users to use sys-boot/raspberrypi-firmware package. See https://bugs.gentoo.org/685412 signature.asc Description: Digital signature
Re: [gentoo-dev] [RFC] Ideas for gentoostats implementation
Since it is going to be opt-in and optional anyway, we seem to be fine with having just partial data. I assume we have logs of distfiles downloads from Gentoo infrastructure, and can negotiate access to relevant logs of our mirrors. That constitutes partial data correlated with users' installation activity, as good as it gets. If we do have some such data, are we using it in any way for the discussed purposes? If we don't, but could get it, would we be able to use that data for these purposes? If no, why? If we can't get the data, why? As an aside, I think the best known way to ensure the availability of important things, from user perspective, is to pay for these important things. Of course I see how this won't fit culturally very well here and that we're not going to switch to commercial model just for this reason. signature.asc Description: Digital signature
[gentoo-dev] Packages up for grabs
I have transitioned to "away" state as I have to reclaim my time for other uses. Here I am trying to reduce the scope of my Gentoo responsibilities to make potential return to activity less dreadful and overwhelming. Call for successors === The following are the packages I do not currently use myself so have the least motivation about. Dropping me from maintainers list is encouraged. WIFI access point service: * net-wireless/hostapd (Co-maintained by zerochaos, still additional attention is encouraged.) Python API for AWS: * dev-python/s3transfer * dev-python/boto3 * dev-python/botocore * dev-python/guzzle_sphinx_theme TUI XMPP clients: * net-im/mcabber * net-im/poezio * net-im/profanity * net-libs/loudmouth * dev-libs/libstrophe * dev-python/slixmpp Somewhat obscure build system: * dev-util/tup V4L: * media-libs/libv4l * media-tv/v4l-utils Call for co-maintainers or successors = For these I have some minor use. You can expect me to have some interest revived. Still, taking responsibility for them in my absence is highly appreciated. GUI XMPP client: * net-im/dino * net-libs/libsignal-protocol-c XMPP server software: * net-im/spectrum2 * net-im/swift Raspberry Pi packages: * media-libs/raspberrypi-userland-bin * sys-boot/raspberrypi-firmware * sys-kernel/raspberrypi-image * sys-kernel/raspberrypi-sources CardDAV CLI tool: * app-misc/khard * dev-python/ruamel-std-pathlib * dev-python/ruamel-yaml-clib * dev-python/ruamel-yaml signature.asc Description: PGP signature
[gentoo-dev] Up for grabs: dev-util/tup, ...
Hi fellows, The following packages are up for grabs: * dev-util/tup Two outstanding issues: https://bugs.gentoo.org/show_bug.cgi?id=711856 https://bugs.gentoo.org/show_bug.cgi?id=704990 * media-gfx/propaganda A collection of graphics. No open bugs. No other package depends on it. * dev-python/guzzle_sphinx_theme No open bugs. A dependency of dev-python/botocore. Maintainers of botocore have been notified directly. signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
I agree with the proposal to sunset LibreSSL. Supporting it benefits very few users due to how non-universal the support of this option is. I see it as entirely sensible choice on apps' upstreams part to not collaborate on libressl support, motivation being focusing on more typical user setups. But I have one loosely related question. About USE=bindist of openssl & openssh. My impression is that when you spin up a new Gentoo setup from stage3, very early on you are typically forced by situations to switch off USE=bindist for openssl and openssh. I conclude that one can't redistribute more elaborate system images and binpkgs because of this. However there's no `bindist` flag and therefore no such situation with libressl package. I never did good research of why this is so, so I am still wondering: what does that mean in practice? Does this mean libressl has some advantage for binary redistributability of elaborate system images and binary packages? signature.asc Description: PGP signature
Re: [gentoo-dev] Packages up for grabs: x11-misc/xscreensaver
On Thu, Mar 11, 2021 at 11:30:44PM +0100, Jonas Stein wrote: > the following packages are up for grabs after dropping > desktop-misc: > > x11-misc/xscreensaver > https://packages.gentoo.org/packages/x11-misc/xscreensaver > > It has 3 open tickets. Hi, Strongly considering picking it up. Please don't remove in the meanwhile. signature.asc Description: PGP signature
