[gentoo-dev] last-rite: many openstack packages
https://bugs.gentoo.org/793800 Maintenance burden is a bit too high with the mismatch of what the python team wants to support for python-impls and what upstream supports and the various support lifecycles not matching (enterprise vs rolling release). Some openstack clients and utilities will be kept around though. to be removed follows app-admin/glance dev-python/aodhclient dev-python/automaton dev-python/castellan dev-python/cursive dev-python/futurist dev-python/glance_store dev-python/keystonemiddleware dev-python/ldappool dev-python/microversion-parse dev-python/neutron-lib dev-python/os-brick dev-python/os-ken dev-python/oslo-cache dev-python/oslo-concurrency dev-python/oslo-db dev-python/oslo-messaging dev-python/oslo-middleware dev-python/oslo-policy dev-python/oslo-privsep dev-python/oslo-reports dev-python/oslo-rootwrap dev-python/oslo-service dev-python/oslo-upgradecheck dev-python/oslo-versionedobjects dev-python/oslo-vmware dev-python/osprofiler dev-python/os-resource-classes dev-python/os-traits dev-python/os-vif dev-python/os-win dev-python/os-xenapi dev-python/ovsdbapp dev-python/pycadf dev-python/pypowervm dev-python/pysaml2 dev-python/python-barbicanclient dev-python/python-blazarclient dev-python/python-designateclient dev-python/python-heatclient dev-python/python-magnumclient dev-python/python-manilaclient dev-python/python-mistralclient dev-python/python-monascaclient dev-python/python-octaviaclient dev-python/python-saharaclient dev-python/python-senlinclient dev-python/python-troveclient dev-python/python-vitrageclient dev-python/python-zaqarclient dev-python/python-zunclient dev-python/ryu dev-python/taskflow dev-python/tinyrpc dev-python/tooz dev-python/WSME dev-python/XenAPI dev-python/yaql dev-python/zVMCloudConnector sys-auth/keystone sys-cluster/cinder sys-cluster/heat sys-cluster/neutron sys-cluster/nova sys-cluster/openstack-meta sys-cluster/placement sys-cluster/swift -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 5/6] dist-kernel-utils.eclass: Support dracut's uefi=yes option
On 21-01-13 15:35:15, Michał Górny wrote:
> Support dracut's uefi=yes configuration option that creates a combined
> UEFI stub, kernel and initramfs in a single UEFI executable. If such
> an output is detected, install it in place of the actual kernel image
> and stub out the duplicate initrd to save space.
>
> Signed-off-by: Michał Górny
> ---
> eclass/dist-kernel-utils.eclass | 31 ++-
> 1 file changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/eclass/dist-kernel-utils.eclass b/eclass/dist-kernel-utils.eclass
> index d65dc0924b40..50ad15f8b1fd 100644
> --- a/eclass/dist-kernel-utils.eclass
> +++ b/eclass/dist-kernel-utils.eclass
> @@ -41,8 +41,20 @@ dist-kernel_build_initramfs() {
> local output=${1}
> local version=${2}
>
> + local rel_image_path=$(dist-kernel_get_image_path)
> + local image=${output%/*}/${rel_image_path##*/}
> +
> + local args=(
> + --force
> + # if uefi=yes is used, dracut needs to locate the kernel image
> + --kernel-image "${image}"
> +
> + # positional arguments
> + "${output}" "${version}"
> + )
> +
> ebegin "Building initramfs via dracut"
> - dracut --force "${output}" "${version}"
> + dracut "${args[@]}"
> eend ${?} || die -n "Building initramfs failed"
> }
>
> @@ -85,6 +97,23 @@ dist-kernel_install_kernel() {
> local image=${2}
> local map=${3}
>
> + # if dracut is used in eufi=yes mode, initrd will actually
> + # be a combined kernel+initramfs UEFI executable. we can easily
> + # recognize it by PE magic (vs cpio for a regular initramfs)
> + local initrd=${image%/*}/initrd
> + local magic
> + [[ -s ${initrd} ]] && read -n 2 magic < "${initrd}"
> + if [[ ${magic} == MZ ]]; then
This magic header is matched by both the kernel and the new uefi
executible. I think a better check would be...
if file "${image_path}" | grep -q 'EFI application'; then
> + einfo "Combined UEFI kernel+initramfs executable found"
> + # install the combined executable in place of kernel
> + image=${initrd}.uefi
> + mv "${initrd}" "${image}" || die
> + # put an empty file in place of initrd. installing a duplicate
> + # file would waste disk space, and removing it entirely provokes
> + # kernel-install to regenerate it via dracut.
> + > "${initrd}"
> + fi
> +
> ebegin "Installing the kernel via installkernel"
> # note: .config is taken relatively to System.map;
> # initrd relatively to bzImage
> --
> 2.30.0
I want to make sure you are not overwriting the original kernel image,
if you do then subsiquent --config runs will include the kernel image,
making the final image grow.
In order to avoid that I did some file juggling, but it looks like it's
cleaner here.
https://gist.github.com/prometheanfire/aeffa1c3f92d3d2af312b3b6915051fb
'worked' but was kinda unclean.
--
Matthew Thode (prometheanfire)
signature.asc
Description: PGP signature
Re: [gentoo-dev] Last rites: net-vpn/networkmanager-wireguard
On 21-01-01 19:51:19, Conrad Kostecki wrote: > # Conrad Kostecki (2021-01-01) > # NetworkManager has buildin support for WireGuard, > # this plugin is old and unmaintained, so let's drop it. > # Removal in 30 days. > net-vpn/networkmanager-wireguard > > nmtui can't use the built-in wireguard functionality (I don't think it shows 'virtual' connections, of which wireguard is one). previously, with the masked package, wireguard showed up as a vpn type connection. nmcli can manage the connection though (and nm-connection-editor from nm-applet can edit connections for those wanting a gui). That said, now that I'm on a roll I'm going to complain that nm-applet has no native wayland version still :P -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Standard build environment variables
On 20-06-28 08:18:23, Michael Orlitzky wrote:
> As many of you probably know, ago@ has been expanding the scope of our
> CFLAGS/CC support to include some other common build variables:
>
> * CC
> * CXX
> * AR
> * CPP
> * NM
> * RANLIB
> * AS
> * LD
>
> Some of those are POSIX standards[0],
>
> * CC
> * AR
>
> Others are de-facto GNU make standards[1],
>
> * CXX
> * CPP
> * AS
>
> and a few are de-facto GNU libtool standards[2]:
>
> * NM
> * RANLIB
> * LD
>
> If we expect them all to work properly in Gentoo, we have to agree on
> what they mean, and thus how they should be injected into build systems.
> For example, we had a problem with sci-mathematics/pari, whose upstream
> is using the LD environment variable for something other than what GNU
> libtool uses it for. With LD set to something libtooly in the
> environment, the pari build fails. We can solve that by unsetting LD in
> the ebuild, but for that to be The Right Thing To Do, we should be
> expecting LD to contain something libtooly, and thus something
> inappropriate to be passed to the pari build.
>
> To avoid these issues, I suggest creating a list of "Gentoo environment
> variables" in the devmanual with descriptions of how they should be used
> and pointers to the references (for why we chose that meaning). That way
> a user can export LD, for example, and know that it will be used how he
> thinks it will be used.
>
>
> [0] https://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html
>
> [1]
> https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html
>
> [2] https://www.gnu.org/software/libtool/manual/libtool.html
>
I'd like to suggest allowing only approved variables in the build
environment, having portage unset all variables and setting only what is
needed (or configured).
I'd like to see some variable like this used in make.conf (or maybe one
exists that I don't know about...).
# set the default bash array if GENTOO_EMERGE_ENV is not defined as an array
if ! declare -p GENTOO_EMERGE_ENV 2> /dev/null | grep -q '^declare \-a'; then
declare -a GENTOO_EMERGE_ENV
GENTOO_EMERGE_ENV+=("USE=\"-build\"")
GENTOO_EMERGE_ENV+=("FEATURES=\"binpkg-multi-instance buildpkg
parallel-fetch parallel-install\"")
GENTOO_EMERGE_ENV+=("PKGDIR=\"/tmp/portage-pkgdir\"")
GENTOO_EMERGE_ENV+=("DISTDIR=\"/tmp/portage-distdir\"")
GENTOO_EMERGE_ENV+=("PORTDIR=\"/tmp/portage-portdir\"")
export GENTOO_EMERGE_ENV
fi
# itterate over the array, exporting each 'line'
for (( i=0; i<${#GENTOO_EMERGE_ENV[@]}; i++ )); do
eval export "${GENTOO_EMERGE_ENV[i]}"
done
--
Matthew Thode (prometheanfire)
signature.asc
Description: PGP signature
[gentoo-dev] Last rites: dev-python/cliff-tablib
# Matthew Thode (2020-03-13) # masked for removal in 14 days. Bug #712310 dev-python/cliff-tablib https://bugs.gentoo.org/712310 -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Packages up for grabs: app-dicts/verbiste, app-emulation/virt-what, dev-libs/libdaemon, media-libs/libiptcdata, media-video/isight-firmware-tools, net-wireless/broadcom-sta
On 19-11-30 12:22:37, Michał Górny wrote: > Hello, > > Due to eva having little time for Gentoo, the following packages could > use a new maintainer: > > [ v] app-dicts/verbiste > [*v] app-emulation/virt-what > [b ] dev-libs/libdaemon > [ v] media-libs/libiptcdata > [ ] media-video/isight-firmware-tools > [b ] net-wireless/broadcom-sta > > Legend: > v - version bump needed > b - open bugs > * - eva requested being kept as co-maintainer there > I'll take virt-what, useful for my openstack work and my puppet work (though facter) -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Proposal: change to default policy of doing changes to packages that are maintained by other developers
On 19-10-21 19:37:28, Piotr Karbowski wrote: > Hi, > > I'd like to bring the topic of defining default policy to do changes to > packages within ::gentoo that one does not maintain. > > This topic goes back from time to time on #gentoo-dev, and as I was > told, it was originally sent to gentoo-dev mailing list by robbat2 (I > failed to find this in archive, so if anyone have copy of it, please share). > > Current policy is to never touch ebuild that one did not claim as > maintainer unless maintainer of said package allowed you to do so. > > This is a bit unhealthy, especially when some developers that maintain > packages are out of reach, or the patches to update ebuild just rot on > the bugzilla and are not taken in by maintainers. > > What I'd like to end with would be to set a policy that allows any > developer with write access to ebuilds tree do changes that are small in > scope, like a minor bug fixes, adding missing flags, version bumps, > anything, that does not require complete overhaul of ebuild, with the > option to set in metadata.xml that policy for specified package is to > deny anyone but maintainers from doing changes. > > The packages that would require a flag to prohibit non-maintainers from > doing changes would of course be those of toolchain, or other big in > user base packages that are in very good shape, as in gnome packages, > kde packages, X11 packages and so on. > > Of course, the policy would also define, that if there are any bug > introduced by changes that non-maintainer made, it's responsibility of > those who did the change in first place to fix it and clean any mess > that it has created. > > I personally am fine with others doing changes to packages I own, as > long as they won't break anything and I do know from the discussion on > #gentoo-dev, that there are others who have similar opinion about it. > > Those who feel territorial and those who believe only maintainers should > maintain specified packages can just set the flag in metadata.xml and > continue with the current state of things for their packages. > > The reason why I would like to get default policy to allow-all is that I > do not believe most of developers would want to go around all the > packages they own and set it manually to allow others doing changes even > if they're fine with others touching those packages. > > What do you think folks? > > -- Piotr. > I like the idea of setting metadata.xml options so repoman can help enforce things. Not sure if we talked about it earlier but it was an option that popped up in the last couple of weeks in the -dev channel. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
[gentoo-dev] Last rites: app-emulation/openstack-guest-agents-unix
# Matthew Thode (2019-10-20) # defunct upstream, removal in 30 days. Bug #611580 app-emulation/openstack-guest-agents-unix -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo on Discord
On 19-04-30 13:43:31, Rich Freeman wrote: > On Tue, Apr 30, 2019 at 1:22 PM Kristian Fiskerstrand wrote: > > > > It matters if things are perceived as official Gentoo and causing a > > negative reputation as in the article in this thread. One some level > > that actually goes to trademark infringement that should be of interest > > to the foundation, but the issue is broader than that. > > > > While I don't speak for the Foundation, they already have a fairly > decent policy addressing this: > https://www.gentoo.org/inside-gentoo/foundation/name-logo-guidelines.html > > I believe this really only applies to use outside of Gentoo, and not > internal use. Whether a service like a Discord site falls under > internal use probably depends on the degree to which they are > completely subject to Council/Trustees/etc, and the social contract > and code of conduct as enacted by those bodies. > > For non-internal use the name/logo guidelines already have > requirements around reputation and code of conduct. You can't just > call yourself "Gentoo" and do whatever you want (not that I'm implying > that this is what any particular site is doing - I haven't even seen > the discord). > From what I remember the last time this came up we gave them the choice of not using the name/logo in an official sense and using them with the guidelines (CoC, etc). iirc, they chose to follow the CoC. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo on Discord
On 19-04-30 17:36:46, Robin H. Johnson wrote: > On Tue, Apr 30, 2019 at 07:24:45PM +0200, Michał Górny wrote: > > On Tue, 2019-04-30 at 19:20 +0200, Kristian Fiskerstrand wrote: > > > On 4/30/19 7:18 PM, Michał Górny wrote: > > > > On Mon, 2019-04-29 at 22:34 +0200, Dirkjan Ochtman wrote: > > > > > In this article on chat services used for OSS: > > > > > > > > > > https://catfox.life/2019/04/28/keeping-libre-software-accessible-to-all/ > > > > > > > > > > I was surprised to see a mention of Gentoo as a project that uses > > > > > "Discord > > > > > as an official method of communication". When I searched, I indeed > > > > > found > > > > > https://discordapp.com/invite/gentoo. However, I'd never before heard > > > > > we > > > > > were using Discord (and didn't find any mentions of Discord on the > > > > > -dev or > > > > > -project mailing lists). > > > > > > > > > > Is this indeed an official venue? It's not listed on > > > > > https://gentoo.org/support/ (which does mention IRC). > > > > > > > > > I've contacted the author and the author refused to change it. > > > > The claim is that 'PR team runs it', '8 Gentoo developers have admin > > > > rights', 'i.e. it is sanctioned by the project itself'. I was suggested > > > > that if it's not official, we should close it instead. > > > > > > If that is how it is perceived I'd be in favor of outright closing it at > > > least > > > > > I suppose the problem boils down to 'perceived by whom'. > "What's official" is part of the problem. > > The PR wiki page DOES list Discord as one of the official channels, > along with other non-libre Silos. > https://wiki.gentoo.org/wiki/Project:Public_Relations#Social_silos_and_chat > > A better question is: in keeping with social contract, but balancing > that users do want to be on different services, what material should be > on each silo? > - Announcements (copied to multiple locations) > - chat/forum-style support mechanisms for users on those silos > > I disagree with awilfox's assertion that libre software should not > _use_ non-libre silos; I feel a better statement is that libre software > should not DEPEND on non-libre silos where possible, and offer libre > alternatives (IRC, despite it's problems). > I agree with that statement (that we should not depend on non-libre silos). moderation of the discord server is another question (after this discussion I suppose). -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo on Discord
On 19-04-30 19:24:45, Michał Górny wrote: > On Tue, 2019-04-30 at 19:20 +0200, Kristian Fiskerstrand wrote: > > On 4/30/19 7:18 PM, Michał Górny wrote: > > > On Mon, 2019-04-29 at 22:34 +0200, Dirkjan Ochtman wrote: > > > > In this article on chat services used for OSS: > > > > > > > > https://catfox.life/2019/04/28/keeping-libre-software-accessible-to-all/ > > > > > > > > I was surprised to see a mention of Gentoo as a project that uses > > > > "Discord > > > > as an official method of communication". When I searched, I indeed found > > > > https://discordapp.com/invite/gentoo. However, I'd never before heard we > > > > were using Discord (and didn't find any mentions of Discord on the -dev > > > > or > > > > -project mailing lists). > > > > > > > > Is this indeed an official venue? It's not listed on > > > > https://gentoo.org/support/ (which does mention IRC). > > > > > > > I've contacted the author and the author refused to change it. > > > The claim is that 'PR team runs it', '8 Gentoo developers have admin > > > rights', 'i.e. it is sanctioned by the project itself'. I was suggested > > > that if it's not official, we should close it instead. > > > > If that is how it is perceived I'd be in favor of outright closing it at > > least > > > > I suppose the problem boils down to 'perceived by whom'. > Ya, the claim as official came up a while ago, I thought it was dealt with. I'm one of the devs with 'admin' rights it seems, I can change the description and server invite background (both have official in it). I'd change the description to something like the following. Discord server for Gentoo Linux, a free operating system based or Linux or FreeBSD. Though maybe we should use the language we used in the nitrokey announcment for how to descript Gentoo :D It does not look like I have the ability to remove the server entirely, as was suggested elsewhere. I don't think that's a good idea in any case. One thing that may help is to have multiple levels of control defined. Official - as K_F described before, website and email announce lists. Controled - controled / moderated by Gentoo pr / comrel This would be other email lists / aliases / facebook / etc unofficial - not activly moderated by Gentoo pr / comrel -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Looking for members for the openstack project
You (and the other gentoo dev who contacted me privately) feel free to add yourself to the member list in the wiki. https://wiki.gentoo.org/wiki/Project:Openstack I'll be calling an election soon as well. -- Matthew Thode (prometheanfire) On 19-04-16 23:55:39, Geaaru wrote: > Hi Matthew, > > I'm not a Gentoo dev but a maintainer of some package through proxy-maint. > > I have few time for a full support but if you want I could help you for > some specific package. > > In the past I pushed some patches to cinder and I would like to try to play > again with openstack stuff. > > Let me know wdyt. > > Thanks for your work with the ebuilds of Openstack. > > # geaaru > > On Tue, Apr 16, 2019, 21:16 Matthew Thode > > I'm considering disbanding the project and switching to sole > > maintainership of the project. So far I'm the only active maintianer in > > the project that I can see. > > > > I'm looking for others that are interested in helping maintain the > > openstack ebuilds. It's fairly easy as an ongoing thing with two major > > releases a year (which starts an update of 160 or so packages). It's > > python based and I've found maintaining the ebuilds to be very easy > > individually if that helps. > > > > There are other actions that'd be helpful as well. Some arm64 stage > > work to then do some arm64 diskimage-builder work to work on building VM > > images for other arches (openstack or 'vanilla'). > > > > Please respond if you are intrested in joining. > > > > -- > > Matthew Thode (prometheanfire) > > signature.asc Description: PGP signature
[gentoo-dev] Looking for members for the openstack project
I'm considering disbanding the project and switching to sole maintainership of the project. So far I'm the only active maintianer in the project that I can see. I'm looking for others that are interested in helping maintain the openstack ebuilds. It's fairly easy as an ongoing thing with two major releases a year (which starts an update of 160 or so packages). It's python based and I've found maintaining the ebuilds to be very easy individually if that helps. There are other actions that'd be helpful as well. Some arm64 stage work to then do some arm64 diskimage-builder work to work on building VM images for other arches (openstack or 'vanilla'). Please respond if you are intrested in joining. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH][v4] enable user settable gpg keyservers
On 19-02-26 15:33:53, Matthew Thode wrote:
> On 19-02-26 10:52:52, Zac Medico wrote:
> > On 2/26/19 10:48 AM, Zac Medico wrote:
> > > On 2/25/19 1:45 PM, Matthew Thode wrote:
> > >> On 19-02-25 15:41:03, Matthew Thode wrote:
> > >>> On 19-02-25 14:34:46, Matthew Thode wrote:
> > >>>> Allowing users to define which keyservers they update from allows them
> > >>>> to work around buggy keyservers. It is also useful for local mirrors
> > >>>> and / or private keyservers.
> > >>>>
> > >>>> It's likely that I'm setting the default incorrectly and not
> > >>>> alphabetizing right, but the code works at least...
> > >>>>
> > >>>
> > >>> Ok, let's try that again, should be cleaner/better/etc
> > >>>
> > >>
> > >> v3, attached
> > >>
> > >> ---
> > >
> > >> lib/portage/repository/config.py | 6 ++
> > >> lib/portage/sync/syncbase.py | 6 +++---
> > >> 2 files changed, 9 insertions(+), 3 deletions(-)
> > >>
> > >> diff --git a/lib/portage/repository/config.py
> > >> b/lib/portage/repository/config.py
> > >> index 482711c4b..235371ce5 100644
> > >> --- a/lib/portage/repository/config.py
> > >> +++ b/lib/portage/repository/config.py
> > >> @@ -109,6 +109,7 @@ class RepoConfig(object):
> > >> 'sync_allow_hardlinks',
> > >> 'sync_depth',
> > >> 'sync_hooks_only_on_change',
> > >> +'sync_openpgp_keyserver',
> > >> 'sync_openpgp_key_path',
> > >> 'sync_openpgp_key_refresh_retry_count',
> > >> 'sync_openpgp_key_refresh_retry_delay_exp_base',
> > >> @@ -224,6 +225,9 @@ class RepoConfig(object):
> > >> self.sync_allow_hardlinks = repo_opts.get(
> > >> 'sync-allow-hardlinks', 'true').lower() in
> > >> ('true', 'yes')
> > >>
> > >> +self.sync_openpgp_keyserver = repo_opts.get(
> > >> +'sync-openpgp-keyserver',
> > >> 'hkps.pool.sks-keyservers.net').strip.lower()
> > >
> > > It needs to be like this:
> > >
> > > + 'sync-openpgp-keyserver',
> > > 'hkps.pool.sks-keyservers.net').strip().lower() or None
> > >
> > > because gemato handles None but not empty strings.
> >
> > Also let's not provide a default keyserver, let gemato handle that.
> >
> > Also please update man/portage.5.
> >
>
> Ok, that stanza no reads:
>
> self.sync_openpgp_keyserver = repo_opts.get(
> 'sync-openpgp-keyserver').strip.lower() or None
>
> I didn't see a section for the sync-openpgp options though, let me know
> anything else or I'll send the updated patch tonight.
>
v4 patch attached (as said previously, no section in man page for
sync-openpgp options so not added there).
--
Matthew Thode (prometheanfire)
From f87a788f58b4efab07d09947be0920bffa01c66b Mon Sep 17 00:00:00 2001
From: Matthew Thode
Date: Mon, 25 Feb 2019 14:14:20 -0600
Subject: [PATCH] enable user settable gpg keyservers
Allowing users to define which keyservers they update from allows them
to work around buggy keyservers. It is also useful for local mirrors
and / or private keyservers.
Signed-off-by: Matthew Thode
---
lib/portage/repository/config.py | 6 ++
lib/portage/sync/syncbase.py | 6 +++---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/lib/portage/repository/config.py b/lib/portage/repository/config.py
index 482711c4b..e9d5e0a9a 100644
--- a/lib/portage/repository/config.py
+++ b/lib/portage/repository/config.py
@@ -109,6 +109,7 @@ class RepoConfig(object):
'sync_allow_hardlinks',
'sync_depth',
'sync_hooks_only_on_change',
+ 'sync_openpgp_keyserver',
'sync_openpgp_key_path',
'sync_openpgp_key_refresh_retry_count',
'sync_openpgp_key_refresh_retry_delay_exp_base',
@@ -224,6 +225,9 @@ class RepoConfig(object):
self.sync_allow_hardlinks = repo_opts.get(
'sync-allow-hardlinks', 'true').lower() in ('true', 'yes')
+ self.sync_openpgp_keyserver = repo_opts.get(
+ 'sync-openpgp-keyserver').strip.lower() or None
+
self.sync_openpgp_key_path = repo_opts.get(
'sync-openpgp-key-path', None)
@@ -601,6 +605,7 @@ class RepoConfigLoader(object):
'sync_allow_hardlinks',
'sync_depth',
'sync_hooks_only_on_change',
+ 'sync_openpgp_keyserver',
'sync_openpgp_key_pat
Re: [gentoo-portage-dev] [PATCH][v3] enable user settable gpg keyservers (attached)
On 19-02-26 10:52:52, Zac Medico wrote:
> On 2/26/19 10:48 AM, Zac Medico wrote:
> > On 2/25/19 1:45 PM, Matthew Thode wrote:
> >> On 19-02-25 15:41:03, Matthew Thode wrote:
> >>> On 19-02-25 14:34:46, Matthew Thode wrote:
> >>>> Allowing users to define which keyservers they update from allows them
> >>>> to work around buggy keyservers. It is also useful for local mirrors
> >>>> and / or private keyservers.
> >>>>
> >>>> It's likely that I'm setting the default incorrectly and not
> >>>> alphabetizing right, but the code works at least...
> >>>>
> >>>
> >>> Ok, let's try that again, should be cleaner/better/etc
> >>>
> >>
> >> v3, attached
> >>
> >> ---
> >
> >> lib/portage/repository/config.py | 6 ++
> >> lib/portage/sync/syncbase.py | 6 +++---
> >> 2 files changed, 9 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/lib/portage/repository/config.py
> >> b/lib/portage/repository/config.py
> >> index 482711c4b..235371ce5 100644
> >> --- a/lib/portage/repository/config.py
> >> +++ b/lib/portage/repository/config.py
> >> @@ -109,6 +109,7 @@ class RepoConfig(object):
> >>'sync_allow_hardlinks',
> >>'sync_depth',
> >>'sync_hooks_only_on_change',
> >> + 'sync_openpgp_keyserver',
> >>'sync_openpgp_key_path',
> >>'sync_openpgp_key_refresh_retry_count',
> >>'sync_openpgp_key_refresh_retry_delay_exp_base',
> >> @@ -224,6 +225,9 @@ class RepoConfig(object):
> >>self.sync_allow_hardlinks = repo_opts.get(
> >>'sync-allow-hardlinks', 'true').lower() in ('true',
> >> 'yes')
> >>
> >> + self.sync_openpgp_keyserver = repo_opts.get(
> >> + 'sync-openpgp-keyserver',
> >> 'hkps.pool.sks-keyservers.net').strip.lower()
> >
> > It needs to be like this:
> >
> > + 'sync-openpgp-keyserver',
> > 'hkps.pool.sks-keyservers.net').strip().lower() or None
> >
> > because gemato handles None but not empty strings.
>
> Also let's not provide a default keyserver, let gemato handle that.
>
> Also please update man/portage.5.
>
Ok, that stanza no reads:
self.sync_openpgp_keyserver = repo_opts.get(
'sync-openpgp-keyserver').strip.lower() or None
I didn't see a section for the sync-openpgp options though, let me know
anything else or I'll send the updated patch tonight.
--
Matthew Thode (prometheanfire)
signature.asc
Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] enable user settable gpg keyservers
On 19-02-25 14:34:46, Matthew Thode wrote:
> Allowing users to define which keyservers they update from allows them
> to work around buggy keyservers. It is also useful for local mirrors
> and / or private keyservers.
>
> It's likely that I'm setting the default incorrectly and not
> alphabetizing right, but the code works at least...
>
Ok, let's try that again, should be cleaner/better/etc
--
Matthew Thode (prometheanfire)
From 1a44eea8a592e58c8c94b134b5d87bd5d4d26425 Mon Sep 17 00:00:00 2001
From: Matthew Thode
Date: Mon, 25 Feb 2019 14:14:20 -0600
Subject: [PATCH] enable user settable gpg keyservers
Allowing users to define which keyservers they update from allows them
to work around buggy keyservers. It is also useful for local mirrors
and / or private keyservers.
Signed-off-by: Matthew Thode
---
lib/portage/repository/config.py | 8 +++-
lib/portage/sync/syncbase.py | 6 +++---
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/lib/portage/repository/config.py b/lib/portage/repository/config.py
index 482711c4b..4acb36678 100644
--- a/lib/portage/repository/config.py
+++ b/lib/portage/repository/config.py
@@ -109,6 +109,7 @@ class RepoConfig(object):
'sync_allow_hardlinks',
'sync_depth',
'sync_hooks_only_on_change',
+ 'sync_openpgp_keyserver',
'sync_openpgp_key_path',
'sync_openpgp_key_refresh_retry_count',
'sync_openpgp_key_refresh_retry_delay_exp_base',
@@ -224,8 +225,11 @@ class RepoConfig(object):
self.sync_allow_hardlinks = repo_opts.get(
'sync-allow-hardlinks', 'true').lower() in ('true', 'yes')
+ self.sync_openpgp_keyserver = repo_opts.get(
+ 'sync-openpgp-keyserver', 'hkps.pool.sks-keyservers.net').strip.lower()
+
self.sync_openpgp_key_path = repo_opts.get(
- 'sync-openpgp-key-path', None)
+'sync-openpgp-key-path', None)
for k in ('sync_openpgp_key_refresh_retry_count',
'sync_openpgp_key_refresh_retry_delay_exp_base',
@@ -601,6 +605,7 @@ class RepoConfigLoader(object):
'sync_allow_hardlinks',
'sync_depth',
'sync_hooks_only_on_change',
+ 'sync_openpgp_keyserver',
'sync_openpgp_key_path',
'sync_openpgp_key_refresh_retry_count',
'sync_openpgp_key_refresh_retry_delay_exp_base',
@@ -1047,6 +1052,7 @@ class RepoConfigLoader(object):
"main_repo",
"priority",
"sync_depth",
+ "sync_openpgp_keyserver",
"sync_openpgp_key_path",
"sync_openpgp_key_refresh_retry_count",
"sync_openpgp_key_refresh_retry_delay_exp_base",
diff --git a/lib/portage/sync/syncbase.py b/lib/portage/sync/syncbase.py
index 83b35c667..ae9ec938e 100644
--- a/lib/portage/sync/syncbase.py
+++ b/lib/portage/sync/syncbase.py
@@ -252,10 +252,10 @@ class SyncBase(object):
@type openpgp_env: gemato.openpgp.OpenPGPEnvironment
"""
out = portage.output.EOutput(quiet=('--quiet' in self.options['emerge_config'].opts))
- out.ebegin('Refreshing keys from keyserver')
+ out.ebegin('Refreshing keys from keyserver {s}'.format(s=self.repo.sync_openpgp_keyserver))
retry_decorator = self._key_refresh_retry_decorator()
if retry_decorator is None:
- openpgp_env.refresh_keys()
+ openpgp_env.refresh_keys(keyserver=self.repo.sync_openpgp_keyserver)
else:
def noisy_refresh_keys():
"""
@@ -263,7 +263,7 @@ class SyncBase(object):
errors, display errors as soon as they occur.
"""
try:
- openpgp_env.refresh_keys()
+ openpgp_env.refresh_keys(keyserver=self.repo.sync_openpgp_keyserver)
except Exception as e:
writemsg_level("%s\n" % (e,),
level=logging.ERROR, noiselevel=-1)
--
2.19.2
signature.asc
Description: PGP signature
Re: [gentoo-portage-dev] [PATCH][v3] enable user settable gpg keyservers
On 19-02-25 15:41:03, Matthew Thode wrote: > On 19-02-25 14:34:46, Matthew Thode wrote: > > Allowing users to define which keyservers they update from allows them > > to work around buggy keyservers. It is also useful for local mirrors > > and / or private keyservers. > > > > It's likely that I'm setting the default incorrectly and not > > alphabetizing right, but the code works at least... > > > > Ok, let's try that again, should be cleaner/better/etc > v3 -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH][v3] enable user settable gpg keyservers (attached)
On 19-02-25 15:41:03, Matthew Thode wrote:
> On 19-02-25 14:34:46, Matthew Thode wrote:
> > Allowing users to define which keyservers they update from allows them
> > to work around buggy keyservers. It is also useful for local mirrors
> > and / or private keyservers.
> >
> > It's likely that I'm setting the default incorrectly and not
> > alphabetizing right, but the code works at least...
> >
>
> Ok, let's try that again, should be cleaner/better/etc
>
v3, attached
--
Matthew Thode (prometheanfire)
From f85c1b823c4b15cf3164fa5b7b1bd2a4128c8fdd Mon Sep 17 00:00:00 2001
From: Matthew Thode
Date: Mon, 25 Feb 2019 14:14:20 -0600
Subject: [PATCH] enable user settable gpg keyservers
Allowing users to define which keyservers they update from allows them
to work around buggy keyservers. It is also useful for local mirrors
and / or private keyservers.
Signed-off-by: Matthew Thode
---
lib/portage/repository/config.py | 6 ++
lib/portage/sync/syncbase.py | 6 +++---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/lib/portage/repository/config.py b/lib/portage/repository/config.py
index 482711c4b..235371ce5 100644
--- a/lib/portage/repository/config.py
+++ b/lib/portage/repository/config.py
@@ -109,6 +109,7 @@ class RepoConfig(object):
'sync_allow_hardlinks',
'sync_depth',
'sync_hooks_only_on_change',
+ 'sync_openpgp_keyserver',
'sync_openpgp_key_path',
'sync_openpgp_key_refresh_retry_count',
'sync_openpgp_key_refresh_retry_delay_exp_base',
@@ -224,6 +225,9 @@ class RepoConfig(object):
self.sync_allow_hardlinks = repo_opts.get(
'sync-allow-hardlinks', 'true').lower() in ('true', 'yes')
+ self.sync_openpgp_keyserver = repo_opts.get(
+ 'sync-openpgp-keyserver', 'hkps.pool.sks-keyservers.net').strip.lower()
+
self.sync_openpgp_key_path = repo_opts.get(
'sync-openpgp-key-path', None)
@@ -601,6 +605,7 @@ class RepoConfigLoader(object):
'sync_allow_hardlinks',
'sync_depth',
'sync_hooks_only_on_change',
+ 'sync_openpgp_keyserver',
'sync_openpgp_key_path',
'sync_openpgp_key_refresh_retry_count',
'sync_openpgp_key_refresh_retry_delay_exp_base',
@@ -1047,6 +1052,7 @@ class RepoConfigLoader(object):
"main_repo",
"priority",
"sync_depth",
+ "sync_openpgp_keyserver",
"sync_openpgp_key_path",
"sync_openpgp_key_refresh_retry_count",
"sync_openpgp_key_refresh_retry_delay_exp_base",
diff --git a/lib/portage/sync/syncbase.py b/lib/portage/sync/syncbase.py
index 83b35c667..ae9ec938e 100644
--- a/lib/portage/sync/syncbase.py
+++ b/lib/portage/sync/syncbase.py
@@ -252,10 +252,10 @@ class SyncBase(object):
@type openpgp_env: gemato.openpgp.OpenPGPEnvironment
"""
out = portage.output.EOutput(quiet=('--quiet' in self.options['emerge_config'].opts))
- out.ebegin('Refreshing keys from keyserver')
+ out.ebegin('Refreshing keys from keyserver {s}'.format(s=self.repo.sync_openpgp_keyserver))
retry_decorator = self._key_refresh_retry_decorator()
if retry_decorator is None:
- openpgp_env.refresh_keys()
+ openpgp_env.refresh_keys(keyserver=self.repo.sync_openpgp_keyserver)
else:
def noisy_refresh_keys():
"""
@@ -263,7 +263,7 @@ class SyncBase(object):
errors, display errors as soon as they occur.
"""
try:
- openpgp_env.refresh_keys()
+ openpgp_env.refresh_keys(keyserver=self.repo.sync_openpgp_keyserver)
except Exception as e:
writemsg_level("%s\n" % (e,),
level=logging.ERROR, noiselevel=-1)
--
2.19.2
signature.asc
Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] enable user settable gpg keyservers
On 19-02-25 21:59:01, Michał Górny wrote: > On Mon, 2019-02-25 at 14:34 -0600, Matthew Thode wrote: > > Allowing users to define which keyservers they update from allows them > > to work around buggy keyservers. It is also useful for local mirrors > > and / or private keyservers. > > > > It's likely that I'm setting the default incorrectly and not > > alphabetizing right, but the code works at least... > > > > I'm still wondering why you need to use keyservers instead of WKD which > is much more reliable. > That I do not know. The only thing I see it doing is using the keyservers. Give me some way of generating debug output and I will do so. using webrsync if that maters (portage tarballs). -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
[gentoo-portage-dev] [PATCH] enable user settable gpg keyservers
Allowing users to define which keyservers they update from allows them
to work around buggy keyservers. It is also useful for local mirrors
and / or private keyservers.
It's likely that I'm setting the default incorrectly and not
alphabetizing right, but the code works at least...
--
Matthew Thode (prometheanfire)
From fa649aac34f7478685c1999857de00c91a1d76cc Mon Sep 17 00:00:00 2001
From: Matthew Thode
Date: Mon, 25 Feb 2019 14:14:20 -0600
Subject: [PATCH] enable user settable gpg keyservers
Allowing users to define which keyservers they update from allows them
to work around buggy keyservers. It is also useful for local mirrors
and / or private keyservers.
Signed-off-by: Matthew Thode
---
lib/portage/repository/config.py | 12 ++--
lib/portage/sync/syncbase.py | 6 +++---
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/lib/portage/repository/config.py b/lib/portage/repository/config.py
index 482711c4b..47adbaf03 100644
--- a/lib/portage/repository/config.py
+++ b/lib/portage/repository/config.py
@@ -115,6 +115,7 @@ class RepoConfig(object):
'sync_openpgp_key_refresh_retry_delay_max',
'sync_openpgp_key_refresh_retry_delay_mult',
'sync_openpgp_key_refresh_retry_overall_timeout',
+ 'sync_openpgp_keyserver',
'sync_rcu',
'sync_rcu_spare_snapshots',
'sync_rcu_store_dir',
@@ -224,8 +225,13 @@ class RepoConfig(object):
self.sync_allow_hardlinks = repo_opts.get(
'sync-allow-hardlinks', 'true').lower() in ('true', 'yes')
- self.sync_openpgp_key_path = repo_opts.get(
- 'sync-openpgp-key-path', None)
+ sync_openpgp_keyserver = repo_opts.get(
+ 'sync-openpgp-keyserver')
+ if sync_openpgp_keyserver is not None:
+ sync_openpgp_keyserver = sync_openpgp_keyserver.strip().lower()
+ else:
+ sync_openpgp_keyserver = 'hkps.pool.sks-keyservers.net'
+ self.sync_openpgp_keyserver = sync_openpgp_keyserver
for k in ('sync_openpgp_key_refresh_retry_count',
'sync_openpgp_key_refresh_retry_delay_exp_base',
@@ -602,6 +608,7 @@ class RepoConfigLoader(object):
'sync_depth',
'sync_hooks_only_on_change',
'sync_openpgp_key_path',
+ 'sync_openpgp_keyserver',
'sync_openpgp_key_refresh_retry_count',
'sync_openpgp_key_refresh_retry_delay_exp_base',
'sync_openpgp_key_refresh_retry_delay_max',
@@ -1048,6 +1055,7 @@ class RepoConfigLoader(object):
"priority",
"sync_depth",
"sync_openpgp_key_path",
+ "sync_openpgp_keyserver",
"sync_openpgp_key_refresh_retry_count",
"sync_openpgp_key_refresh_retry_delay_exp_base",
"sync_openpgp_key_refresh_retry_delay_max",
diff --git a/lib/portage/sync/syncbase.py b/lib/portage/sync/syncbase.py
index 83b35c667..ae9ec938e 100644
--- a/lib/portage/sync/syncbase.py
+++ b/lib/portage/sync/syncbase.py
@@ -252,10 +252,10 @@ class SyncBase(object):
@type openpgp_env: gemato.openpgp.OpenPGPEnvironment
"""
out = portage.output.EOutput(quiet=('--quiet' in self.options['emerge_config'].opts))
- out.ebegin('Refreshing keys from keyserver')
+ out.ebegin('Refreshing keys from keyserver {s}'.format(s=self.repo.sync_openpgp_keyserver))
retry_decorator = self._key_refresh_retry_decorator()
if retry_decorator is None:
- openpgp_env.refresh_keys()
+ openpgp_env.refresh_keys(keyserver=self.repo.sync_openpgp_keyserver)
else:
def noisy_refresh_keys():
"""
@@ -263,7 +263,7 @@ class SyncBase(object):
errors, display errors as soon as they occur.
"""
try:
- openpgp_env.refresh_keys()
+ openpgp_env.refresh_keys(keyserver=self.repo.sync_openpgp_keyserver)
except Exception as e:
writemsg_level("%s\n" % (e,),
level=logging.ERROR, noiselevel=-1)
--
2.19.2
signature.asc
Description: PGP signature
Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system
On 19-02-23 08:17:18, Michał Górny wrote: > On Fri, 2019-02-22 at 20:58 -0600, Matthew Thode wrote: > > On 19-02-19 22:05:02, Brian Dolbec wrote: > > > On Tue, 19 Feb 2019 23:03:51 -0600 > > > Matthew Thode wrote: > > > > > > > On 19-02-20 00:00:04, Michael Orlitzky wrote: > > > > > On 2/19/19 11:21 PM, Matthew Thode wrote: > > > > > > > > > > > > > > What problem would this solve? (Is adding gentoo-keys to @system > > > > > > > the least bad way to solve it?) > > > > > > > > > > > > > > > > > > > It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify > > > > > > portage tarballs. This is useful for the initial sync (as called > > > > > > out in our manual). Otherwise using emerge-webrsync could be > > > > > > mitm'd or otherwise messed with. > > > > > > > > > > Ok, then I agree with the goal if not the solution. This is a > > > > > portage-specific thing, namely > > > > > > > > > > FEATURES=webrsync-gpg > > > > > > > > > > that should be enabled by default on a stage3. (Making new users go > > > > > out of their way to add basic security is daft.) Portage already has > > > > > USE=rsync-verify, and I think we could either > > > > > > > > > > a) expand the meaning of that flag to include enabling > > > > > webrsync-gpg by default, and to pull in gentoo-keys; or > > > > > > > > > > b) add another (default-on) flag like USE=webrsync-verify to do it > > > > > > > > > > That flag would be enabled by default, so gentoo-keys would be > > > > > pulled in as part of @system without actually being *in* the > > > > > @system. Something along those lines would achieve the same goal in > > > > > a cleaner way. > > > > > > > > > > > > > > > > > > This worksforme (optional, default enabled dep of portage with a > > > > default feature flag change). > > > > > > > > > > As far how we treat deps of @system packages, since this does not > > > > > > have any deps that should help check that box for anyone > > > > > > worried. > > > > > > > > > > I meant the other way around. Once gentoo-keys is in @system, > > > > > packages will (inconsistently) omit gentoo-keys from (R)DEPEND. > > > > > There's no real policy or consensus on the matter, and it makes it > > > > > a real PITA if we ever want to remove things from @system, because > > > > > lots of packages will break in unpredictable ways. > > > > > > > > > > > > > Ah, ya, that makes sense. > > > > > > > > > > One of the things that releng has bantered about the last few years is > > > making a stage4 with these extra non @system pkgs. The stage4 would > > > allow all the extra pkgs needed for new installs without adding to > > > @system. The system set could possibly be trimmed a little more then > > > too. Then knowledgeable users could work with minimal stage3's when it > > > suits their purpose while new users doing installs get the advantage of > > > the additional pre-installed pkgs. > > > > > > > Ok, after setting that up portage wants to update pgp keys, which fail > > because keyservers suck. It doesn't look like we can change the > > keyservers or disable the update entirely but we can set the retries to > > 0 (which better disable it...). Robbat2 had a patch to allow disabling > > the update but it doesn't look like it was applied. > > > > Disabling that means entirely killing the verification as it'd happily > use a revoked key. > > Keyservers were supposed not to suck anymore. Are you sure it's not > misconfigured network? Maybe it's got broken-but-pretended IPv6? > How about we allow a setting for controling which keyserver to refresh from. SKS has had problems, fedora has been better (and a coworker says MIT is ok too). Aparently they have a max key size set or something to work around keyserver 'brokenness'. Something similiar to this would be nice, but for keyservers. https://gist.github.com/robbat2/551fc8ea56408ee48e99909f9c26c13e -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system
On 19-02-23 08:17:18, Michał Górny wrote: > On Fri, 2019-02-22 at 20:58 -0600, Matthew Thode wrote: > > On 19-02-19 22:05:02, Brian Dolbec wrote: > > > On Tue, 19 Feb 2019 23:03:51 -0600 > > > Matthew Thode wrote: > > > > > > > On 19-02-20 00:00:04, Michael Orlitzky wrote: > > > > > On 2/19/19 11:21 PM, Matthew Thode wrote: > > > > > > > > > > > > > > What problem would this solve? (Is adding gentoo-keys to @system > > > > > > > the least bad way to solve it?) > > > > > > > > > > > > > > > > > > > It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify > > > > > > portage tarballs. This is useful for the initial sync (as called > > > > > > out in our manual). Otherwise using emerge-webrsync could be > > > > > > mitm'd or otherwise messed with. > > > > > > > > > > Ok, then I agree with the goal if not the solution. This is a > > > > > portage-specific thing, namely > > > > > > > > > > FEATURES=webrsync-gpg > > > > > > > > > > that should be enabled by default on a stage3. (Making new users go > > > > > out of their way to add basic security is daft.) Portage already has > > > > > USE=rsync-verify, and I think we could either > > > > > > > > > > a) expand the meaning of that flag to include enabling > > > > > webrsync-gpg by default, and to pull in gentoo-keys; or > > > > > > > > > > b) add another (default-on) flag like USE=webrsync-verify to do it > > > > > > > > > > That flag would be enabled by default, so gentoo-keys would be > > > > > pulled in as part of @system without actually being *in* the > > > > > @system. Something along those lines would achieve the same goal in > > > > > a cleaner way. > > > > > > > > > > > > > > > > > > This worksforme (optional, default enabled dep of portage with a > > > > default feature flag change). > > > > > > > > > > As far how we treat deps of @system packages, since this does not > > > > > > have any deps that should help check that box for anyone > > > > > > worried. > > > > > > > > > > I meant the other way around. Once gentoo-keys is in @system, > > > > > packages will (inconsistently) omit gentoo-keys from (R)DEPEND. > > > > > There's no real policy or consensus on the matter, and it makes it > > > > > a real PITA if we ever want to remove things from @system, because > > > > > lots of packages will break in unpredictable ways. > > > > > > > > > > > > > Ah, ya, that makes sense. > > > > > > > > > > One of the things that releng has bantered about the last few years is > > > making a stage4 with these extra non @system pkgs. The stage4 would > > > allow all the extra pkgs needed for new installs without adding to > > > @system. The system set could possibly be trimmed a little more then > > > too. Then knowledgeable users could work with minimal stage3's when it > > > suits their purpose while new users doing installs get the advantage of > > > the additional pre-installed pkgs. > > > > > > > Ok, after setting that up portage wants to update pgp keys, which fail > > because keyservers suck. It doesn't look like we can change the > > keyservers or disable the update entirely but we can set the retries to > > 0 (which better disable it...). Robbat2 had a patch to allow disabling > > the update but it doesn't look like it was applied. > > > > Disabling that means entirely killing the verification as it'd happily > use a revoked key. > > Keyservers were supposed not to suck anymore. Are you sure it's not > misconfigured network? Maybe it's got broken-but-pretended IPv6? > Just telling what I see. I've had working ipv6 for a LONG time, perhaps it's broken on their end (this mail is probably delivered via v6, last one was). If the functionality worked I wouldn't be asking about it here. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system
On 19-02-22 22:19:54, Rich Freeman wrote: > On Fri, Feb 22, 2019 at 9:58 PM Matthew Thode > wrote: > > > > Ok, after setting that up portage wants to update pgp keys, which fail > > because keyservers suck. It doesn't look like we can change the > > keyservers or disable the update entirely but we can set the retries to > > 0 (which better disable it...). Robbat2 had a patch to allow disabling > > the update but it doesn't look like it was applied. > > I assume that it proceeds after some timeout? Or does it completely > bail? IMO failing successful makes more sense though it is less > secure. > > It definitely makes sense to attempt a keyserver update since that is > going to be the mechanism to catch key revocations. It also will make > life easier on users using an older stage3 that happens to have > expired keys. Well, assuming the keyserver works... > Na, times out the build (1.5 hour gate time...). It retried nine times... I agree that updating is best, but nine times? http://logs.openstack.org/02/608102/12/check/openstack-ansible-functional-gentoo-17-0-systemd/f866472/logs/host/lxc-cache-prep-commands.log.txt.gz -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system
On 19-02-19 22:05:02, Brian Dolbec wrote: > On Tue, 19 Feb 2019 23:03:51 -0600 > Matthew Thode wrote: > > > On 19-02-20 00:00:04, Michael Orlitzky wrote: > > > On 2/19/19 11:21 PM, Matthew Thode wrote: > > > >> > > > >> What problem would this solve? (Is adding gentoo-keys to @system > > > >> the least bad way to solve it?) > > > >> > > > > > > > > It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify > > > > portage tarballs. This is useful for the initial sync (as called > > > > out in our manual). Otherwise using emerge-webrsync could be > > > > mitm'd or otherwise messed with. > > > > > > Ok, then I agree with the goal if not the solution. This is a > > > portage-specific thing, namely > > > > > > FEATURES=webrsync-gpg > > > > > > that should be enabled by default on a stage3. (Making new users go > > > out of their way to add basic security is daft.) Portage already has > > > USE=rsync-verify, and I think we could either > > > > > > a) expand the meaning of that flag to include enabling > > > webrsync-gpg by default, and to pull in gentoo-keys; or > > > > > > b) add another (default-on) flag like USE=webrsync-verify to do it > > > > > > That flag would be enabled by default, so gentoo-keys would be > > > pulled in as part of @system without actually being *in* the > > > @system. Something along those lines would achieve the same goal in > > > a cleaner way. > > > > > > > > > > This worksforme (optional, default enabled dep of portage with a > > default feature flag change). > > > > > > As far how we treat deps of @system packages, since this does not > > > > have any deps that should help check that box for anyone > > > > worried. > > > > > > I meant the other way around. Once gentoo-keys is in @system, > > > packages will (inconsistently) omit gentoo-keys from (R)DEPEND. > > > There's no real policy or consensus on the matter, and it makes it > > > a real PITA if we ever want to remove things from @system, because > > > lots of packages will break in unpredictable ways. > > > > > > > Ah, ya, that makes sense. > > > > One of the things that releng has bantered about the last few years is > making a stage4 with these extra non @system pkgs. The stage4 would > allow all the extra pkgs needed for new installs without adding to > @system. The system set could possibly be trimmed a little more then > too. Then knowledgeable users could work with minimal stage3's when it > suits their purpose while new users doing installs get the advantage of > the additional pre-installed pkgs. > Ok, after setting that up portage wants to update pgp keys, which fail because keyservers suck. It doesn't look like we can change the keyservers or disable the update entirely but we can set the retries to 0 (which better disable it...). Robbat2 had a patch to allow disabling the update but it doesn't look like it was applied. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] wayland category
On 19-02-16 18:12:26, Aaron Bauman wrote: > On Sat, Feb 16, 2019 at 06:04:54PM -0500, Aaron Bauman wrote: > > On Sun, Feb 17, 2019 at 12:56:52AM +0200, Mart Raudsepp wrote: > > > Wildcards aren't allowed in category names. Do you mean gui-misc, gui- > > > apps, gui-wm, gui-libs, or what? > > > > > > > > > Mart > > > > Correct, examples would be: > > > > gui-libs/wlroots > > gui-wm/sway > > gui-apps/swaylock > > gui-apps/sway > > > > The last example should read gui-apps/swayidle > These all seem good to me, I'll commit it sometime over the weekend if no one objects (and pkg move it in updates/1Q-2019) -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system
On 19-02-19 21:23:33, Matthew Thode wrote: > As the title says, I think this should be done. > > First sync is impossible to verify without keys (webrsync) > app-crypt/gentoo-keys has no dependencies, which help avoid some bloat > in the base install. > > Let the bikeshedding begin. > Looks like it's a docs problem. https://bugs.gentoo.org/671816 -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system
On 19-02-19 22:05:02, Brian Dolbec wrote: > On Tue, 19 Feb 2019 23:03:51 -0600 > Matthew Thode wrote: > > > On 19-02-20 00:00:04, Michael Orlitzky wrote: > > > On 2/19/19 11:21 PM, Matthew Thode wrote: > > > >> > > > >> What problem would this solve? (Is adding gentoo-keys to @system > > > >> the least bad way to solve it?) > > > >> > > > > > > > > It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify > > > > portage tarballs. This is useful for the initial sync (as called > > > > out in our manual). Otherwise using emerge-webrsync could be > > > > mitm'd or otherwise messed with. > > > > > > Ok, then I agree with the goal if not the solution. This is a > > > portage-specific thing, namely > > > > > > FEATURES=webrsync-gpg > > > > > > that should be enabled by default on a stage3. (Making new users go > > > out of their way to add basic security is daft.) Portage already has > > > USE=rsync-verify, and I think we could either > > > > > > a) expand the meaning of that flag to include enabling > > > webrsync-gpg by default, and to pull in gentoo-keys; or > > > > > > b) add another (default-on) flag like USE=webrsync-verify to do it > > > > > > That flag would be enabled by default, so gentoo-keys would be > > > pulled in as part of @system without actually being *in* the > > > @system. Something along those lines would achieve the same goal in > > > a cleaner way. > > > > > > > > > > This worksforme (optional, default enabled dep of portage with a > > default feature flag change). > > > > > > As far how we treat deps of @system packages, since this does not > > > > have any deps that should help check that box for anyone > > > > worried. > > > > > > I meant the other way around. Once gentoo-keys is in @system, > > > packages will (inconsistently) omit gentoo-keys from (R)DEPEND. > > > There's no real policy or consensus on the matter, and it makes it > > > a real PITA if we ever want to remove things from @system, because > > > lots of packages will break in unpredictable ways. > > > > > > > Ah, ya, that makes sense. > > > > One of the things that releng has bantered about the last few years is > making a stage4 with these extra non @system pkgs. The stage4 would > allow all the extra pkgs needed for new installs without adding to > @system. The system set could possibly be trimmed a little more then > too. Then knowledgeable users could work with minimal stage3's when it > suits their purpose while new users doing installs get the advantage of > the additional pre-installed pkgs. > ya, I'm currently using a systemd stage4 for openstack stuff, will update it (as I made it in the first place) https://review.openstack.org/608102 -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system
On 19-02-20 08:35:10, Michał Górny wrote: > On Tue, 2019-02-19 at 21:23 -0600, Matthew Thode wrote: > > As the title says, I think this should be done. > > > > First sync is impossible to verify without keys (webrsync) > > app-crypt/gentoo-keys has no dependencies, which help avoid some bloat > > in the base install. > > > > This is the wrong place to add it, and the wrong package. > > If Portage (still) needs it for whatever, then it should be a dependency > of Portage. > > However, app-crypt/openpgp-keys-gentoo-release should be entirely > sufficient, and it works without all the voodoo dependencies and 'run > programs as root' logic of gkeys. If there's anything in Portage left > not using it, it should be ported. > FEATURES="webrsync-gpg" emerge-webrsync fails to work with just the file. PORTAGE_GPG_DIR="/var/lib/gentoo/gkeys/keyrings/gentoo/release" FEATURES="webrsync-gpg" emerge-webrsync works PORTAGE_GPG_DIR="/usr/share/openpgp-keys/" FEATURES="webrsync-gpg" emerge-webrsync emerge-webrsync: error: signature verification failed (same for the file). Maybe some of the interior portage stuff should be fixed then? -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system
On 19-02-20 00:00:04, Michael Orlitzky wrote: > On 2/19/19 11:21 PM, Matthew Thode wrote: > >> > >> What problem would this solve? (Is adding gentoo-keys to @system the > >> least bad way to solve it?) > >> > > > > It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify > > portage tarballs. This is useful for the initial sync (as called out in > > our manual). Otherwise using emerge-webrsync could be mitm'd or > > otherwise messed with. > > Ok, then I agree with the goal if not the solution. This is a > portage-specific thing, namely > > FEATURES=webrsync-gpg > > that should be enabled by default on a stage3. (Making new users go out > of their way to add basic security is daft.) Portage already has > USE=rsync-verify, and I think we could either > > a) expand the meaning of that flag to include enabling webrsync-gpg > by default, and to pull in gentoo-keys; or > > b) add another (default-on) flag like USE=webrsync-verify to do it > > That flag would be enabled by default, so gentoo-keys would be pulled in > as part of @system without actually being *in* the @system. Something > along those lines would achieve the same goal in a cleaner way. > > This worksforme (optional, default enabled dep of portage with a default feature flag change). > > As far how we treat deps of @system packages, since this does not have > > any deps that should help check that box for anyone worried. > > I meant the other way around. Once gentoo-keys is in @system, packages > will (inconsistently) omit gentoo-keys from (R)DEPEND. There's no real > policy or consensus on the matter, and it makes it a real PITA if we > ever want to remove things from @system, because lots of packages will > break in unpredictable ways. > Ah, ya, that makes sense. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system
On 19-02-19 23:04:26, Michael Orlitzky wrote: > On 2/19/19 10:23 PM, Matthew Thode wrote: > > As the title says, I think this should be done. > > > > First sync is impossible to verify without keys (webrsync) > > app-crypt/gentoo-keys has no dependencies, which help avoid some bloat > > in the base install. > > > > Let the bikeshedding begin. > > > > I don't have app-crypt/gentoo-keys installed. I seem to be doing okay > without it. > > In any case, on principle, we shouldn't add anything else to @system. No > one agrees on how we should treat @system packages as far as > dependencies go, and the whole idea is a stinky pile of dirty laundry > that we should work to make explicit instead. > > What problem would this solve? (Is adding gentoo-keys to @system the > least bad way to solve it?) > It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify portage tarballs. This is useful for the initial sync (as called out in our manual). Otherwise using emerge-webrsync could be mitm'd or otherwise messed with. As far how we treat deps of @system packages, since this does not have any deps that should help check that box for anyone worried. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
[gentoo-dev] adding app-crypt/gentoo-keys to @system
As the title says, I think this should be done. First sync is impossible to verify without keys (webrsync) app-crypt/gentoo-keys has no dependencies, which help avoid some bloat in the base install. Let the bikeshedding begin. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
[gentoo-dev] wayland category
wayland, weston, sway{,lock,idle}, wl-clipboard, etc would be the start,
I'm sure there are a ton I'm missing but I don't know where to put
things like wl-clipboard, dev-libs doesn't seem right.
--
Matthew Thode (prometheanfire)
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: What means bup?
On 18-09-23 21:39:01, Alec Warner wrote: > On Sun, Sep 23, 2018 at 6:53 PM M. J. Everitt wrote: > > > On 23/09/18 22:27, Kent Fredric wrote: > > > On Sat, 22 Sep 2018 15:36:23 -0500 > > > Matthew Thode wrote: > > >> My hand slipped. What ever happened to assuming the best :( Are you > > >> going to ping the list every time my hand slips up and I mistype > > >> something? Not sure you'll have time for it :P > > > Personally, I would love it if more people tried harder to provide > > > meaningful commit messages. > > > > > > "bup" vs "bump" isn't really achieving much, just one of the two are > > > substantially more egregious. > > > > > > Perhaps, if the commit messages were crafted with clarity as their > > > intent, the consequence of accidental typos would be much more > > > inconsequential. > > > > > > ( I seriously think we could do with a *little* more chiding here than > > > we generally see, but like, I'm typically just biting my tongue every > > > time somebody doesn't invest any more effort than to write the word > > > "bump" in their text editor when committing with repoman, cos I really > > > don't want to be a dick about it. There's room for more than 4 > > > characters and a space in the subject, and infinitely more space in the > > > body, why do we have to choose the least clear of all options? ) > > > > > > Occasional accidents are still gonna happen, but it would be nice if we > > > didn't define accidents and siblings of accidents as the status quo. > > > > > I think Kent has pretty much the point here .. we try to stipulate that > > the commit message describes what the update is, and is clear for *all* > > users of the repository, and not just the relevant maintainer. There is > > also a cronic double-standard for existing or long-standing devs, and > > newer devs, recruits and proxy-maintainers (who get a double-scrutiny > > typically) - and I could easily see how this breeds resentment... > > > > Perhaps it would be simple enough to add a check to repoman for commit > > messages less than 10 characters, and with at least one *additional* > > space, mandating two words in the commit message. It seems draconian, > > but if developers continue to be lazy, what choice does one have?! > > > > > I don't see a problem with 'version bump' as a description. Sometimes you > bump an ebuild because upstream released a new version and you want to > track. I'm fairly against changes describing what was changed (typically > the reader can git show and observe the changes.) The useful information is > *why* the change was made. Sometimes its because "upstream released a new > version." > > Like Matt I'm curious what others expect to see in the description. > That's exactly why I release much of the stuff I do, I get a task in todoist via ifttt monitoring a github atom feed that a new release is out and I package it. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: What means bup?
On 18-09-24 09:27:57, Kent Fredric wrote: > On Sat, 22 Sep 2018 15:36:23 -0500 > Matthew Thode wrote: > > My hand slipped. What ever happened to assuming the best :( Are you > > going to ping the list every time my hand slips up and I mistype > > something? Not sure you'll have time for it :P > > Personally, I would love it if more people tried harder to provide > meaningful commit messages. > > "bup" vs "bump" isn't really achieving much, just one of the two are > substantially more egregious. > > Perhaps, if the commit messages were crafted with clarity as their > intent, the consequence of accidental typos would be much more > inconsequential. > > ( I seriously think we could do with a *little* more chiding here than > we generally see, but like, I'm typically just biting my tongue every > time somebody doesn't invest any more effort than to write the word > "bump" in their text editor when committing with repoman, cos I really > don't want to be a dick about it. There's room for more than 4 > characters and a space in the subject, and infinitely more space in the > body, why do we have to choose the least clear of all options? ) > > Occasional accidents are still gonna happen, but it would be nice if we > didn't define accidents and siblings of accidents as the status quo. > What would you rather see for when a package is bumped (that is, simply copying the ebuild and editing the keywords)? -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: What means bup?
On 18-09-22 16:16:28, Jonas Stein wrote: > >> english is not my mother language, so please clarify what bup means, just > >> seen here: > >> > >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397 > >> Just checked if it was a typo, but can't be: > >> git log --oneline --grep bup | count -l > >> Expected 0 lines, got 1248. > > > It's similiar to a sound you make when you touch something's nose. > > *boop* > > There are again new commits with "bup". > Please do not misuse the commit message for jokes and word games. > My hand slipped. What ever happened to assuming the best :( Are you going to ping the list every time my hand slips up and I mistype something? Not sure you'll have time for it :P -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: What means bup?
On 18-07-18 11:28:16, Mike Gilbert wrote: > On Wed, Jul 18, 2018 at 3:26 AM, Matthew Thode > wrote: > > On 18-07-18 09:16:07, Johannes Huber wrote: > >> Hi all, > >> > >> english is not my mother language, so please clarify what bup means, just > >> seen here: > >> > >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397 > >> > >> Just checked if it was a typo, but can't be: > >> git log --oneline --grep bup | count -l > >> Expected 0 lines, got 1248. > >> > > > > It's similiar to a sound you make when you touch something's nose. > > *boop* > > > > I just prefer bup instead. I generally only use it when doing simple > > bumps of packages (copy ebuilds with only keyword edits). > > My preference is to mention the version being added when committing a > version bump. eg. "cat/pkg: bump to x.y.z". > > Yes, it does take a few more seconds, but I think it is worth the effort. > I think more recently I've been following this format. cat/pkg: x.y.z bup -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
[gentoo-dev] Re: What means bup?
On 18-07-18 09:16:07, Johannes Huber wrote: > Hi all, > > english is not my mother language, so please clarify what bup means, just > seen here: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397 > > Just checked if it was a typo, but can't be: > git log --oneline --grep bup | count -l > Expected 0 lines, got 1248. > It's similiar to a sound you make when you touch something's nose. *boop* I just prefer bup instead. I generally only use it when doing simple bumps of packages (copy ebuilds with only keyword edits). -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2 03/11] glep-0063: Clarify dedicated signing subkey in minimal reqs
On 18-07-04 12:54:50, Michał Górny wrote: > W dniu śro, 04.07.2018 o godzinie 12∶35 +0200, użytkownik Kristian > Fiskerstrand napisał: > > On 07/04/2018 12:23 PM, Michał Górny wrote: > > > -2. Root key and signing subkey of EITHER: > > > +2. Root key and a dedicated signing subkey, both of EITHER: > > > > "dedicated" here might be misread to be gentoo-specific, which doesn't > > really make much sense. > > What alternative do you suggest? We really want to make clear that we > require a separate subkey, and that subkey is not marked for encryption. > I'd suggest something along the lines of 'subkey with signing only capabilitiyies' or 'signing only subkey'. I state this because you are able to have a combined SE subkey which would match the language of dedicated or simply only saying 'signing subkey'. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] gcc-7 going stable now
On 18-06-18 23:58:51, Andreas K. Huettel wrote: > Hi all, > > just to give a general heads up, sys-devel/gcc-7.3.0-r3 is now getting > stabilized on all arches in bug 658444. > > Cheers from the toolchain team, > Andreas > Good to hear, been using that version (and previous revbumps) for the last few months. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Python 3.5 -> 3.6 switch
On 18-05-15 07:38:36, Michał Górny wrote: > Hi, everyone. > > In no less than 30 days, we will be switching the default Python targets > from CPython 3.5 to 3.6. The new values will be: > > PYTHON_TARGETS="python2_7 python3_6" > PYTHON_SINGLE_TARGET="python3_6" > > If you haven't ported your package to Python 3.6, please look into doing > it now. Helpful lists: > > packages missing python3.6 support: > list: https://qa-reports.gentoo.org/output/gpyutils/35-to-36.txt > graph: https://qa-reports.gentoo.org/output/gpyutils/35-to-36.svg > > packages needing stabilization: > l https://qa-reports.gentoo.org/output/gpyutils/35-to-36-stablereq.txt > g https://qa-reports.gentoo.org/output/gpyutils/35-to-36-stablereq.svg > > At the same time, I'd like to remind you that Python 3.4 reaches end-of- > life in March 2019. For more details, see [1]. > > I'll submit a news item for users for review today. The switch will be > postponed to account for its publication. > > [1]:https://devguide.python.org/#status-of-python-branches > lol, when it gets to nova. The state for openstack is that upstream currently only tests on 3.5. They are just starting to test on 3.6 with the stable release with that testing probably going to occur for the 2019.1 release. Until then, most of openstack will be mainly on python 3.6. That said, there are not expected to be any problems with openstack on py36, so moving over sooner may make sense (I was hoping that py36 would be in the rocky release). -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Openstack Summit MeetUp
On 18-05-13 13:11:30, Jack Morgan wrote: > Gentoo, > > I will be attending the Openstack Summit in Vancouver, BC. The > conference is May 21-24th. I would like to organize a Gentoo meetup for > those attending or living in the area. I personally will be there from > May 20th - 26th. > > Please reply if you are interested in meeting and which day(s)/time(s) > you are available. I'm looking forward to it! > This is the ONE summit I'm not going to :( I do plan on attending the PTG in Denver and the Summit in Berlin though. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] multi-backend support for ssl/tls in curl
On 18-04-23 17:00:45, James Le Cuirot wrote: > On Mon, 23 Apr 2018 17:47:27 +0200 > Michał Górny <mgo...@gentoo.org> wrote: > > > W dniu pon, 23.04.2018 o godzinie 02∶57 -0500, użytkownik Gordon > > Pettey napisał: > > > On Mon, Apr 23, 2018 at 1:26 AM, Michał Górny <mgo...@gentoo.org> > > > wrote: > > > > W dniu nie, 22.04.2018 o godzinie 09∶34 -0500, użytkownik Matthew > > > > Thode napisał: > > > > > The short of it is that curl supports having multiple > > > > > backends. I'd like to have that feature enabled so libraries > > > > > and userland can choose the backend they wish to use. > > > > > > > > > > https://bugs.gentoo.org/653076 has the specifics, but I cannot > > > > > see a reason why we are artifically limiting the backed to just > > > > > one. > > > > > > > > How would you solve the problem of packages requiring specific SSL > > > > backend? Currently they enforce it via USE dependency on cURL. > > > > > > Perhaps with exactly the same USE dependencies that already exists, > > > just without the at-most-one limitation on curl itself? > > > > This doesn't guarantee that the required backend will actually be > > used. Well, unless it blocks any other USE flag from being enabled > > but that defeats the purpose. > > Proprietary software that's linked against a specific backend usually > links to libcurl-gnutls.so.4 or whatever specifically as that's what > Debian provides. If it points to just libcurl.so.4 but only works > against a specific backend then we could use chrpath to change it to > the specific name. > The way that curl installs it's libs for multi-backend (I'm currently using the proposed patch) is to still just install a single library. To get something like debian does with libcurl-gnutls we'd need to do separate builds. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] multi-backend support for ssl/tls in curl
On 18-04-23 02:57:50, Gordon Pettey wrote: > On Mon, Apr 23, 2018 at 1:26 AM, Michał Górny <mgo...@gentoo.org> wrote: > > W dniu nie, 22.04.2018 o godzinie 09∶34 -0500, użytkownik Matthew Thode > > napisał: > >> The short of it is that curl supports having multiple backends. I'd > >> like to have that feature enabled so libraries and userland can choose > >> the backend they wish to use. > >> > >> https://bugs.gentoo.org/653076 has the specifics, but I cannot see a > >> reason why we are artifically limiting the backed to just one. > >> > > > > How would you solve the problem of packages requiring specific SSL > > backend? Currently they enforce it via USE dependency on cURL. > > Perhaps with exactly the same USE dependencies that already exists, > just without the at-most-one limitation on curl itself? > Yep, as described in the bug, there if a program requires use of a specific backend it's able to request it. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
[gentoo-dev] multi-backend support for ssl/tls in curl
The short of it is that curl supports having multiple backends. I'd like to have that feature enabled so libraries and userland can choose the backend they wish to use. https://bugs.gentoo.org/653076 has the specifics, but I cannot see a reason why we are artifically limiting the backed to just one. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Mailing list moderation and community openness
On 18-03-20 23:17:52, Michael Palimaka wrote: > I see that in bug #650964[1] Council is pushing forward again with > implementing user whitelisting on this mailing list (ie. anyone that is > not "approved" will have their mail rejected). > > Could someone please explain how this doesn't directly contradict the > core tenets of an open and inclusive community? > > 1: https://bugs.gentoo.org/650964 > While I personally do no agree with mailing list moderation infra has been tasked with moving forward on it. In that vein, this is what we are proposing. Install and configure mailman3/hyperkitty/postorius once they all support python3. Specifically we wish to use docker-mailman for this so we can easilly redeploy this on diferent machines as needed. mailman3 gives us two good things, it has support for moderation (for better or worse) and it handles senders using dmarc. There are still some issues with it infra side (archiving will still have to use the old system) and moving mailing lists is going to be fun, but them the breaks. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] bug queue size over time
On 18-03-19 19:33:11, Paweł Hajdan, Jr. wrote: > Is it possible to get graphs of bugs.g.o bug queue size for certain > query (e.g. by assignee) over time? > I suspect it's up and to the right. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Packages up for grabs
On 18-03-10 15:52:21, Pacho Ramos wrote: > This packages are now up for grabs: > app-text/pspdftool > app-admin/supernova > dev-python/args > dev-python/attrdict > dev-python/behave > dev-python/clint > dev-python/dockerpty > dev-python/doublex-expects > dev-python/doublex > dev-python/expects > dev-python/ghp-import > dev-python/linecache2 > dev-python/livereload > dev-python/mamba > dev-python/mando > dev-python/mkdocs-bootstrap > dev-python/mkdocs > dev-python/monotonic > dev-python/mypy > dev-python/nose2 > dev-python/os-client-config > dev-python/paramunittest > dev-python/parse > dev-python/parse-type > dev-python/pycallgraph > dev-python/pyhamcrest > dev-python/pytest-raisesregexp > dev-python/python-termstyle > dev-python/radon > dev-python/sphinxcontrib-cheeseshop > dev-python/sphinxcontrib-newsfeed > dev-python/sphinxcontrib-spelling > dev-python/stormpath > dev-python/texttable > dev-python/torment > dev-python/traceback2 > dev-python/typing > I took app-admin/supernova and dev-python/os-client-config for openstacky stuff -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: That's all folks. (Re: OT Re: [gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists)
On 17-12-09 16:29:24, Daniel Campbell wrote: > On Fri, Dec 08, 2017 at 09:22:32PM +0100, Andreas K. Huettel wrote: > > Am Donnerstag, 7. Dezember 2017, 19:06:36 CET schrieb William L. Thomson > > Jr.: > > > > > > The day everyone wanted has come, after this message. I will > > > unsubscribe not to return. You all won in 2008, and again in 2017. > > > Though this time I will not be back. I tried more than most anyone else > > > would for a very long time. Gentoo wins I lose, I am fine with that. > > > > > > Please do not contact me off list in IRC or at all. I am done with the > > > Gentoo community! > > > > > > Independent of whether William now unsubscribed or not, he's now enjoying a > > lengthy (1 year until review) vacation from all Gentoo communication > > channels. > > > > > > -- > > Andreas K. Hüttel > > dilfri...@gentoo.org > > Gentoo Linux developer (council, perl, libreoffice) > > So, mgorny threatened to leave if something wasn't done, right? I saw > the IRC conversation about unsubscribing from gentoo-dev, as well. IRC > is not private, for the record. Other developers are required to > subscribe to -dev, and are expected to follow it so they stay informed. > If they missed something covered on the list, they are directed to the > archives and (usually) laughed at. I see no reason for this expectation > to be waived for any single developer. Do I get a free pass if I don't > like what someone says? > > It's not enough to let wltjr leave on his own; you had to create a ban > and add a smug, tongue-in-cheek mail to it to maintain the image of > doing something. Quite hypocritical of comrel's attitude of secrecy to > suddenly announce a ban. It seems to me that secrecy is only adopted > when it suits those who stand to benefit from it. > > Great things coming from Gentoo "leadership" here. What will you do when > mgorny starts targeting developers and pitching tantrums over them, too? > Are we going to stratify developership further, too? It seems rather > clear to me that a few individuals see themselves as the owners of this > distro and bend it to suit their whims, using bureacracy to obscure > their actions and motivations, segment the community, and block those > less experienced. This is precisely why we have unmotivated developers > and a bevy of unmaintained packages; nobody wants to contribute to a > distro that treats its users (and developers) so poorly. > > A distro should never bend its entire social structure to protect the > feelings of one surly developer (or his/her entourage), but naturally > since every council member is friends with mgorny and comrel is afraid > to take any action against him, they'll make exceptions to established > procedures and ignore any complaints about the way he treats others. > > Software cannot fix wetware. Plenty of developers get to deal with > mgorny's aggressive and insulting tone, yet nothing happens. Gee... I > wonder why. Maybe because the upper parts of Gentoo are riddled with > cronyism. > > "Rules for thee, not for me." > > It's clear to anyone with eyeballs that there is preferential treatment > and inconsistent enforcement of rules in this community, and the people > in a position to fix it, won't, because they in fact benefit from this. > > Unfortunately, GLEP 39 does not have a section on recalling or > impeachment... This whole situation highlights why the Council has no > business sticking its head into non-technical matters. It's clearly not > up to the task. It's no surprise, since technical skill does not > guarantee or even imply social skill. (or vice-versa) > > I'm tired of people beating around the bush and the facile attempts of > tact: why do you give special treatment to certain members of this > community? Would you have done anything different if it were me or some > other developer who was proposing this change? > > It wouldn't have made it to the Council agenda if he didn't write it, > period. Everyone else would've been told to suck it up and deal with it. > And knowing how the Council is, in a few days we'll all get to deal with > the churn of mailing lists to protect one person's ego. Sad. > zlg has made comments about mgorny that he as been asked to verify. As there has been no response to the request for more information, the Trustees are retracting the comment and wish to apologize to mgorny for the inconvenience. -- Matthew Thode (prometheanfire) President, Gentoo Foundation signature.asc Description: PGP signature
Re: [gentoo-dev] SAT-based dependency solver: request for test cases
On 18-02-06 11:52:10, Michael Lienhardt wrote: > Dear all, > > With the help of some friends and colleagues, I am working on an SAT-based > dependency solver for portage. > We need your help to test it and possibly improve in the long run the already > great portage toolset. > > To help, you can send us the tar generated by this bash script: > https://raw.githubusercontent.com/HyVar/gentoo_to_mspl/master/benchmarks/get_installation.sh > This bash script extracts your world file, the USE flags and keywords > configuration of your system and the list of installed packages you have (it > should not take more than few seconds). > With this, we will see if our solver is able to recreate your system and how > much time it takes. > > You can send everything to my professional email: mlien...@di.unito.it > > > The goal of this alternative solver is to overcome some of the limitations of > emerge. > Thanks to some users of the forum and the gentoo-user mailing list, I already > tested the solver on 8 systems, and the results for now are: > - emerge is not able to recreate any of these systems (i.e., 'cat > world_of_test_configuration | xargs emerge -vp' on a gentoo osboxes VM does > not succeed, even with the right /etc/portage/package.* files) > - our solver takes 2 minutes in average (with little variation), and gives > either a yes answer (with what to install, which USE flags to set, which > packages to keyword) or a no answer (with the set of conflicting constraints) > for every systems > - we solved one bug in our solver (a behavior of emerge that seems > documented only in the PMS document, not in devmanual nor in the wiki, and > that is visible only in 15 packages), but at least one seems to still be > around. > > I started discussing this on the gentoo-portage-dev and the gentoo-user > mailing lists (sorry for the duplicates), and on the forum with three posts: > - https://forums.gentoo.org/viewtopic-t-1074170.html about the documentation > I collected to implement the solver > - https://forums.gentoo.org/viewtopic-t-1074202.html about the solver and > its motivations > - https://forums.gentoo.org/viewtopic-t-1075286.html about the tests I'm > doing > > > About me: > I'm a researcher in computer science, about formal methods, concurrency and > software engineering. > Friday, I will present my first paper on portage, showing that its packages > and their dependencies constitute what is called a "Multi-Software Product > Line" in software engineering. If you skip the algebraic definition, it > should be readable ^^: http://www.di.unito.it/~mlienhar/vamos.pdf > In 2013, I designed and contributed to the implementation of a dependency > solver for dynamic cloud architecture (currently maintained by Jacopo Mauro > https://bitbucket.org/jacopomauro/zephyrus2/src ) > I'm a gentoo user since 2007, and I'm very happy by this opportunity to > contribute back :). > > This sounds intresting, I wonder how it'd handle things like sys-cluster/openstack-meta which can sometimes require masking a package (gentoo stablizes a package ahead of what openstack has tested support for). -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] reproducible builds
On 18-02-04 19:20:33, Marc Schiffbauer wrote: > * Matt Turner schrieb am 04.02.18 um 19:04 Uhr: > > On Sun, Feb 4, 2018 at 7:25 AM, Samuel Bernardo > > <samuelbernardo.m...@gmail.com> wrote: > > > Hi, > > > > > > I send this email to know the opinion of gentoo developers about > > > registering gentoo profiles in the context of reproducible-builds.org > > > > Reproducible builds makes sense when you're distributing binaries to > > users. > > +1 .. and I just wanted to add that this might be something very > valuable if you want some sort of public binhost like it is the case in > another current thread on this list. > > I would think of a giantic cache. If someone else already has built a > reproducable bin-package of an ebuild with the exact same > profile/USE/binutils/gcc/... combination that I am using too, then this > would be something very useful IMO which saves a lot of buildtime and > energy. > Yes, I think a lot of the same stuff could go into our build system. Simple stuff like using the same date for things for instance. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Personal Gentoo Installer project pre-alpha release
On 18-01-14 13:57:56, Christopher Díaz Riveros wrote: > Good day devs, and users: > > generate: produces a stageX tarball. StageX contains some of > the needed files to install and configure Gentoo linux, right > now these files include: > > /etc/portage/* > /etc/timezone > /etc/locale.gen > /var/lib/portage/world StageX sounds like stage4 :P -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [RFC] First (experimental) 17.1 profiles news item for review (v2)
On 17-12-21 09:10:09, Mike Gilbert wrote: > On Thu, Dec 21, 2017 at 2:44 AM, Matthew Thode > <prometheanf...@gentoo.org> wrote: > > On 17-12-21 08:34:31, Michał Górny wrote: > >> W dniu czw, 21.12.2017 o godzinie 05∶29 +, użytkownik Duncan > >> napisał: > >> > Michał Górny posted on Wed, 20 Dec 2017 14:40:27 +0100 as excerpted: > >> > > >> > In all this I don't see an answer to one question: > >> > > >> > Will this eventually be the only supported choice, or is the > >> > compatibility-symlinked version going to be supported going forward too? > >> > If it's to be only-supported, what's the timeline? > >> > >> The former. We'll make a timeline when the profiles are tested > >> and stable. > >> > > > > What group are the ones making this decision? > > The decision was effectively made by vapier in 2014 (see bug 506276); > mgorny is the one doing most of the work in 2017. There's also a group > of us who have been following the bug and experimenting with our own > systems since then. > > If you disagree with this plan for some reason, please start a new thread. > Nope, just curious :D -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Java 9 on Gentoo
On 17-11-16 15:17:15, William L. Thomson Jr. wrote: > Just as a heads up, pass it along. For anyone interested. It will be > some time before Java 9 is available on Gentoo. It will take > considerable work to get it unmasked and safe for use. > > Once in tree masked, it will likely be very painful for anyone who does > unmask. You have been forewarned!!! > > NOT FUD! > Constructive heads up as to the factual state of things. If > you would like to see them change. Talk to Chewi/James Le Cuirot. He > will need lots of help! Even with others I guestimate a month or more > before it can be unmasked. Once its added to tree... > > -- > William L. Thomson Jr. You seem to know a bit about this, has there been a bug made outlining the troubles we will encounter as you know them? It's nice to have a warning, but sounding alarmist without concrete help doesn't actually help all that much. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: PowerPC Resources at OSU
On 17-09-12 10:44:42, R0b0t1 wrote: > On Mon, Sep 11, 2017 at 11:29 PM, R0b0t1 <r03...@gmail.com> wrote: > > Hello, > > > > (This will be almost a duplicate on the PPC list, but now having more > > information I am sending it to the BSD list as well.) > > > > I apologize in advance if I did anything improper. I misunderstood > > desultory when I asked him what to do earlier. Originally I was > > unwilling to try to associate myself with Gentoo for the purpose of > > this request but I wasn't referred to anyone who could fill out the > > form "for" me. > > > > Having requested OpenPOWER hosting from OSUOSL on Gentoo's behalf, I > > was informed that hosting is already provided to the project. > > Consequently I have two questions: > > > > 1) May I have access to a/the POWER server, or some other suitable > > POWER resource? If not, > > 2) is anyone available to verify that I am associated with the project > > or that I will use the resources for project related work? > > > > > > For any comment to OSU, such as to request closure of the ticket or > > that they go ahead with allocating the VM, please comment and I will > > forward the support ticket to you. > > > > > > My intent is to experiment with the PowerPC architecture, specifically > > features found on newer POWER processors and servers. It is unlikely I > > will ever get to do this on my own as the machines run $10k-$30k. I > > requested services from OSU because GCC was not able to accommodate my > > request for hypervisor access on their system. > > > > However, having finally found the resources I've been looking for this > > whole time, it looks like OSU's nodes are virtualized and won't be > > able to do exactly what I want anyway (i.e. the GCC sysadmin was > > misinformed), so I may have accidentally wasted people's time and > > potentially tarnished Gentoo's reputation. I will make amends as best > > I can. > > > > IBM is willing to fund a node for my use and OSU is willing to deploy > > it pending contact from Gentoo leadership. If there is a machine that > > already exists that I would not disrupt, I would have no problems > > working on existing resources instead if that seems reasonable. The > > GCC server(s) are probably adequate, however I am having lots of > > problems setting up a prefix on those systems because they use CentOS. > > I am trying to fix bugs as best as I am able but it is starting to > > look hopeless. > > > > Excess resources on the donated OSU OpenPOWER machine could be offered > > to other developers or used to run a Tinderbox. It may be a good idea > > to do those things on the already existing machine(s). > > > > Respectfully, > > R0b0t1 > > I am in no great hurry to get things moving and don't mind being told > "no," but at a certain point I feel like I will have to tell OSU that > I couldn't figure out who controls their current donation. > > Respectfully, > R0b0t1 > I have access to it (can spin up servers and whatnot), but it doesn't sound like that's what you are looking for (needing a non-virtualized system). What specific features are you looking for? Are you looking for rack space to put a donated IBM system in or what? I'm not certian what you are looking for. I'm on irc (as prometheanfire) if you want to talk. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] sys-boot/plymouth needs major fixes/maintainer
On 17-07-26 11:56:39, Pacho Ramos wrote: > sys-boot/plymouth is orphan for a long time. Its old 0.8.x versions where > having > important bugs that were fixed in 0.9.x, but 0.9 is also plenty of issues. > Then, > either this is adopted by someone able to handle all that issues or we will > need > to finally treeclean (and drop its support for dependant packages) > > Thanks > I did take sys-boot/plymouth, set up notifications for new releases so packaging will be somewhat automated. Also prodded upstream to release 0.9.3 (which they did) and packaged it. Updated to eapi6 as well, tested booting on systemd, worksforme. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] sys-boot/plymouth needs major fixes/maintainer
On 17-08-04 17:17:05, Mart Raudsepp wrote: > On K, 2017-07-26 at 11:56 +0200, Pacho Ramos wrote: > > sys-boot/plymouth is orphan for a long time. Its old 0.8.x versions > > where having > > important bugs that were fixed in 0.9.x, but 0.9 is also plenty of > > issues. Then, > > either this is adopted by someone able to handle all that issues or > > we will need > > to finally treeclean (and drop its support for dependant packages) > > So despite this thread, this got suddenly p.masked. > > It seems most issues are related to usage with OpenRC, plus some > stopping issue with sddm. > > I can soon look into the systemd aspects, but are there anyone > interested in the openrc use case, to help out there? > > > Mart > I've reverted the p.mask commit and added myself to the metadata for plymouth (not the openrc plugin). I've also poked upstream for a new tag since it's been a while and they are active... -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] New package neomutt
On 17-07-31 09:11:19, Nicolas Bock wrote: > Hi, > > I would like to add neomutt to the tree. This new package is meant > as an alternative and not a replacement of the existing mutt > package. > > Thanks, > > Nick > > -- > Nicolas Bock <nicolasb...@gentoo.org> It was my understanding that neomutt was mainly mutt with a bunch of patches added on, from what I can see, those patches are already handled by use flags in the mutt package itself. https://www.neomutt.org/about.html describes itself as a large set of feature patches and not a fork as well. Are there missing patches that need to be added to the mutt package? -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Package up for grabs
On 17-07-30 14:24:50, Daniel Campbell wrote: > On 07/23/2017 07:13 AM, Manuel Rüger wrote: > > The following packages are up for grabs: > > > > app-admin/gixy > > app-admin/mei-amt-check > > app-admin/ngxtop > > app-admin/passwordsafe > > app-arch/lz5 > > app-crypt/acme > > app-crypt/certbot > > app-crypt/certbot-apache > > app-crypt/certbot-nginx > > app-crypt/easy-rsa > > app-crypt/libmd > > app-crypt/manuale > > app-crypt/pgpdump > > app-emulation/docker-gc > > app-misc/jira-cli > > app-misc/pdfpc > > app-text/blahtexml > > app-text/itex2mml > > app-text/mathtex > > dev-go/cli > > dev-go/delve > > dev-go/go-gitlab-client > > dev-go/glide > > dev-go/toml > > dev-python/parsley > > dev-python/safety > > dev-python/txsocksx > > dev-python/vcversioner > > dev-libs/libgit2 > > dev-lua/luadbi > > dev-lua/luasocket > > dev-lua/lua-zlib > > dev-util/bloaty > > dev-util/cookiecutter > > net-analyzer/linkchecker > > net-libs/libssh2 > > net-misc/kafkacat > > x11-misc/flow-pomodoro > > x11-plugins/pidgin-opensteamworks > > x11-plugins/pidgin-xmpp-receipts > > > > There is another set of packages, which have a backup project > > maintaining it. Please talk to the respective project if you're > > interested in maintaining those: > > > > app-office/texstudio > > dev-python/cookies > > dev-python/freezegun > > dev-python/future > > dev-python/hiro > > dev-python/hvac > > dev-python/parsedatetime > > dev-python/parsley > > dev-python/pyhcl > > dev-python/pykka > > dev-python/pyrfc3339 > > dev-python/pytest-capturelog > > dev-python/pytest-localserver > > dev-python/responses > > dev-python/vcrpy > > dev-python/zope-component > > dev-python/zope-event > > net-firewall/nftables > > net-libs/libnftnl > > > > Best regards, > > Manuel Rüger > > > > > I have a machine using certbot (Rpi 3 Model B) now that I might be > switching to Gentoo in the future. I'd be willing to co-maintain > app-crypt/certbot with other interested developers. The catch is I don't > use Apache or nginx; others would need to maintain certbot-apache and > certbot-nginx. > > Anyone interested? > > -- > Daniel Campbell - Gentoo Developer > OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net > fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 > I could probably help with that (certbot-nginx). I don't use it in particular, but could probably set up one of my test domains with it. I imagine that we'd be co-maintaining certbot and acme then? I'd be intrested in co-maintaining nftables (or may just take it), seems like something we should want to keep around... -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] last rites: app-text/acroread
On 06/08/2017 07:17 PM, Jason A. Donenfeld wrote: > RIP acroread. > > The only PDF reader on linux that can properly parse PDF Reference XObjects. > > Thou shall be missed. > I'm not sure if it works, but qpdfview is the best alternative that I've found so far. -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs
On 03/26/2017 02:50 PM, aide...@gentoo.org wrote: > Hi, > > The following packages are up for grabs: > > app-admin/hddtemp > app-backup/burp > app-crypt/md5deep > dev-python/appdirs > dev-python/husl > dev-python/pyro > dev-python/selectors34 > sys-apps/biosdevname > > These packages are quite easy to maintain, so if someone cares about any of > these, don't hesitate! (-: > > I will reassign to maintainer-needed if noone will take a package in > a while. > > Cheers, > -- Amadeusz Żołnowski > I took dev-python/appdirs as it's used by openstack somewhat. -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Updating the puppet portage package provider
Currently puppet is fairly simple in how it handles portage packages. It doesn't handle package (un)install options, package sets or purging of packages. Also, iirc, uninstallation is fairly limited in what it can handle (can't handle uninstalling a slot iirc). The new version fixes these limitations. I'd appreciate review of the code and possible testing of this change by others using puppet. (and reviews by ruby devs). If people know of other lists to ask for review for this on let me know. https://github.com/puppetlabs/puppet/pull/5498/ -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
[gentoo-dev] packages up for grabs
My mentee has decided to not pursue Gentoo any more and as a result there is one package up for grabs. games-arcade/savagewheels -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Openstack ocata available
First, Openstack Ocata is available as openstack-meta-2017.1. (installs the services from stable branches). Tags for each of the services are available if needed as well. -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Printer drivers and net-print
On 02/20/2017 03:47 PM, Andreas K. Huettel wrote: > Hey all, > > 1) Putting printer drivers into "net-print" is silly. > > Something that converts format a to device-specific format b has absolutely > nothing to do with network. > So, a new category "sys-print", emphasizing that it's hardware drivers, (or > "cups-drv"?) (or maybe "media-print"?) might make sense. > > 2) After introducing that, however, "net-print" becomes nearly empty. > > On a quick glance, the only *network*-specific packages in there are cups and > lprng. Maybe one or two more which I dont recognize. > > So move cups and lprng to "net-misc" and drop "net-print"? > Or move them to new "sys-print" as well? > > What do you think? > > Cheers, > Andreas > Moving stuff around seems sort of like busy work. I can see the reasoning and as mjeveritt mentioned in the other email a full category rename may work just as well (instead of moving a couple of packages and also a rename). The question to me is 'is there a great enough need to go through the pain of this?'. -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Introducing stable profiles for arm64 (aarch64)
On 02/03/2017 11:26 PM, Mart Raudsepp wrote: > Hello, > > I am working towards having a clean deptree for arm64 and afterwards > marking the non-hardened 5 arm64 profiles stable (or 4 - I don't see > value in the developer profile without the desktop specific > subprofiles, until there are mix-ins). > It's good to hear that I'll soon be able to get some of my packages stable on arm64, that'll encourage me even more to switch some of my smaller servers to it (for power/heat reasons). :D -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] About ALLARCHES
On 01/24/2017 07:54 AM, Agostino Sarubbo wrote: > We are working to provide some tools for the stabilization process. > > > > > > Unfortunately, there isn't atm something able to manage the requests > with the ALLARCHES keyword, > > > > So, *everyone* with the commit access can keyword for all after a > stabilization/keyword happened at least for one arch. > > > > Thanks. > So, to be clear, we need to wait for an AT to mark stable for one arch on an ALLARCHES package. Once that is done any dev can mark the rest of the arches stable. -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)
On 01/03/2017 09:10 AM, Kristian Fiskerstrand wrote: > On 01/03/2017 03:57 PM, Michael Mol wrote: >> For security's sake, even mature software needs, at minimum, routine >> auditing. >> Unless someone's doing that work, the package should be considered for >> removal. (Call that reason # π, in honor of TeX.) > > A distinction here likely needs to be made between actively maintained > upstream and actively Gentoo maintained as well. Actively maintained > upstream might not be an issue for a feature complete package, but if it > lacks a Gentoo-maintainer in addition it is worrying. > Agreed, the main thing a package needs is a responsive packager. If the packager finds an issue with a package that they can't fix and upstream is non-responsive then the packager is probably responsible for tree-cleaning themselves. -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)
On 01/03/2017 09:11 AM, Damien LEVAC wrote: > But routine auditing, while being wishful thinking in the open-source > world (even when the projects are alive), are not meant to find those > kind of bugs anyway (and wouldn't be effective at doing so either). > I think it's wishful thinking in every world :P > I would argue that those concerns apply to every packages to different > degree and you might not be safer (on the contrary) with a maintained > but more experimental package... > > Even if just for the sake of stability, shouldn't there be a policy of > inertia? I.e. if it is not broken it does not need fixing, or something > like that? Like you said, this topic comes every once in a while and > every time it is a waste of time. Unless there is an unknown maintaining > cost in having it in the tree unmaintained? -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [rfc] New global USE flag: rbd
On 12/26/2016 02:17 AM, Daniel Campbell wrote: > On 12/25/2016 11:45 PM, Andrew Savchenko wrote: >> Hi all, >> >> 8 packages are using either rbd or rados USE flag for Rados >> Block Device support: >> >> use.local.desc:app-backup/bareos:rados - Enable rados storage backend >> use.local.desc:app-emulation/ganeti:rbd - Enable rados block device support >> via sys-cluster/ceph >> use.local.desc:app-emulation/libvirt:rbd - Enable rados block device support >> via sys-cluster/ceph >> use.local.desc:app-emulation/qemu:rbd - Enable rados block device backend >> support, see http://ceph.newdream.net/wiki/QEMU-RBD >> use.local.desc:net-analyzer/rrdtool:rados - Enable support for librados from >> sys-cluster/ceph >> use.local.desc:net-libs/xrootd:rbd - Enable rados block device support via >> sys-cluster/ceph >> use.local.desc:sys-block/fio:rbd - Enable Rados block device support via >> sys-cluster/ceph >> use.local.desc:sys-block/tgt:rbd - Add support for ceph block devices >> >> Suggested description: >> rbd - Enable rados block device support via sys-cluster/ceph >> >> Best regards, >> Andrew Savchenko >> > > Do we expect the list of packages using RBD to grow? If so then sure, if > for no other reason than to give a consistent description. > I think sys-cluster/cinder and maybe nova/glance could use it. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Please retain authorship of contributed patches
On 11/30/2016 03:23 PM, Andrey Utkin wrote:
> 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 <prometheanf...@gentoo.org>
> 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}"
>
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). I should
have mentioned that bug at the very least though and/or worked with you
on the ebuild.
Generally if committing from the community I will cherry-pick, which
does retain authorship.
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.
--
-- Matthew Thode (prometheanfire)
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On 10/19/2016 07:15 AM, Kristian Fiskerstrand wrote: > On 10/19/2016 02:13 PM, Matthew Thode wrote: >> On 10/19/2016 04:10 AM, Ulrich Mueller wrote: >>> Maybe I have missed something, but why would one use --signoff for >>> a Gentoo commit? >> >> Personally I use it as 'I sign off on the Author's work'. I suppose the >> commit itself is good enough for this but I personally prefer verbosity. >> It also calls out that it wasn't my work. >> > > This sounds more like a reviewed by or acked by? > > Yep, but do either of those have a simple switch I can use (-s)? :P -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On 10/19/2016 04:10 AM, Ulrich Mueller wrote: > Maybe I have missed something, but why would one use --signoff for > a Gentoo commit? Personally I use it as 'I sign off on the Author's work'. I suppose the commit itself is good enough for this but I personally prefer verbosity. It also calls out that it wasn't my work. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On 10/19/2016 01:00 AM, Robin H. Johnson wrote: > One of the downsides both the git-am and cherry-pick workflows are that > they invalidate or otherwise omit commit signatures. > > git-merge on the other hand does preserve the signature as the original > commit is intact, and the merge commit is where the signature of the > gentoo developer is introduced. > > I agree clean history is valuable, but verifiable attribution may in > fact be more important. > Yes, I don't like this aspect of any workflow that breaks history but I personally feel that for the sake of both 'cleanliness' and ease of use that the git am (or cherry-pick) workflow is best. I could possibly see the possibility of tampering with the patch could be a problem (attribution as you say) but in the end a developer still committed it. Authored-by and Committed-by being different fields I feel the main one infra needs to worry about is Committed-by. -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
I've been using the curl into git am method for a while now, it's nice to see it's not just me :D Does pram allow you to pass options to git am (signedoffby for instance)? -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] nftables
On 09/08/2016 07:31 PM, Ian Bloss wrote: > Anyone actively using nftables for their firewall over iptables? > Considering giving it a go as the syntax looks much nicer than iptables. Openstack uses nftables if it's available. So kinda. -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: /etc/hostname on gentoo
On 08/22/2016 10:58 AM, William Hubbs wrote: > All, > > it looks like app-emulation/docker expects /etc/hostname to exist. > > On Gentoo, this file does not exist, so I'm wondering how we can make it > exist? > > I know in OpenRC I can read it and use the value there as the hostname > instead of /etc/conf.d/hostname if it exists,but I'm not sure whether > OpenRC should populate /etc/hostname if it does not exist or whether > something else should do that. > > Thoughts? > > William > Secondarily I'd like /etc/hostname to be seen as a source of truth. Having to write wrapper scripts to fix /etc/hostname issues can suck (cloud-init and glean). -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: /etc/hostname on gentoo
On 08/22/2016 10:58 AM, William Hubbs wrote: > All, > > it looks like app-emulation/docker expects /etc/hostname to exist. > > On Gentoo, this file does not exist, so I'm wondering how we can make it > exist? > > I know in OpenRC I can read it and use the value there as the hostname > instead of /etc/conf.d/hostname if it exists,but I'm not sure whether > OpenRC should populate /etc/hostname if it does not exist or whether > something else should do that. > > Thoughts? > > William > I'd like us to populate the file in some way (symlink to /run or otherwise). Just keep in mind that the format is different than /etc/conf.d/hostname when considering your options. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Package up for grab
On 08/02/2016 04:15 PM, Amy Winston wrote: > net-im/skype > > Anyone interested? > > I feel like this is a trick question :P -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] distutils-r1.eclass: Do not modify the HOME variable
On 05/06/2016 08:25 AM, Mike Gilbert wrote:
> This was only necessary when we ran phases in parallel.
> Also, PMS says this variable should not be modified.
> ---
> eclass/distutils-r1.eclass | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
> index 7965e91..497bed5 100644
> --- a/eclass/distutils-r1.eclass
> +++ b/eclass/distutils-r1.eclass
> @@ -628,12 +628,6 @@ distutils-r1_run_phase() {
> # in the sys.path_importer_cache)
> mkdir -p "${BUILD_DIR}/lib" || die
>
> - # We need separate home for each implementation, for .pydistutils.cfg.
> - if [[ ! ${DISTUTILS_SINGLE_IMPL} ]]; then
> - local -x HOME=${HOME}/${EPYTHON}
> - mkdir -p "${HOME}" || die
> - fi
> -
> # Set up build environment, bug #513664.
> local -x AR=${AR} CC=${CC} CPP=${CPP} CXX=${CXX}
> tc-export AR CC CPP CXX
>
Thanks for this, think I reported it a while ago, can't find the bug though.
--
-- Matthew Thode (prometheanfire)
Re: [gentoo-dev] USE flag proposal: memcached
On 05/14/2016 10:19 AM, Dirkjan Ochtman wrote: > All, > > I want to add a "memcached" USE flag to mail-filters/rmilter. Before > doing so, I looked if there was a global USE flag. There is not, but I > though see usage across 14 packages: > > dev-db/pgpool2[memcached]: Use memcached for query caching > dev-php/pecl-mysqlnd_qc[memcached]: Use > dev-libs/libmemcached as a storage handler > mail-filter/opendkim[memcached]: Add support for using > dev-libs/libmemcached > mail-mta/postfix[memcached]: Add support for using > net-misc/memcached for lookup tables > net-analyzer/graphite-web[memcached]: Enable memcached support > net-analyzer/munin[memcached]: Install the packages required for > memcached monitoring. > net-mail/automx[memcached]: Enable memcached support > sys-auth/keystone[memcached]: Installs dependencies needed for using > memcached as a backend > sys-cluster/cinder[memcached]: Installs the memcached server > sys-cluster/gearmand[memcache]: Support memcache daemon (via > dev-libs/libmemcached) for the queue storage. > sys-cluster/nova[memcached]: Installs the memcached server > sys-cluster/swift[memcached]: adds memcached support > www-servers/lighttpd[memcache]: Enable memcache support for mod_cml > and mod_trigger_b4_dl > > Most of these seem to depend on dev-libs/libmemcached or > net-misc/memcached, with a few packages depending on language-specific > stuff (e.g. dev-perl/Cache-Memcached or dev-python/python-memcached). > > I suppose the description can just be "Enable memcached support". > > Any objections? > > Cheers, > > Dirkjan > +1 from me :D -- -- Matthew Thode (prometheanfire)
Re: [gentoo-dev] Reminder: ALLARCHES
On 04/30/2016 07:53 PM, Daniel Campbell wrote: > On 04/30/2016 02:16 PM, Andreas K. Huettel wrote: >> >> Hi all, >> >> just as a small reminder, to ease the load on all arch teams: >> >> If a stablerequest has the keyword ALLARCHES set, then >> * the first arch that tests successfully and stabilizes >> * can and *should* immediately stabilize for all requested arches! >> >> Whether this keyword is set on a bug is decision of the package maintainer. >> >> For example, Perl team sets ALLARCHES normall for all pure-perl packages >> (i.e., no compilation / gcc involved). >> >> Here's an example how this was used: >> https://bugs.gentoo.org/show_bug.cgi?id=578408 >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=44c2d31dfc61bb3e2aee3709cb5a784b213511fa >> >> Cheers, Andreas >> >> > > A package working on one arch won't necessarily guarantee that it works > correctly on all other arches. Shouldn't we at least make sure we're > testing on the relevant arch? For example, I don't have any hppa > hardware. If I stabilized for amd64, why should I stabilize for hppa? I > can't in good faith claim that it'll work fine for hppa because I've not > tested it. > > As you said, however, it's a choice of the maintainer. Things like Perl > and Python may be less prone to this issue since they're meant to be > portable. > > My apologies if my concern is misplaced. > > ~zlg > Yes, this is mainly for interpreted languages (python/perl/ruby/etc) -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Herd likely up for grabs: net-fs
On 01/18/2016 12:03 AM, Joshua Kinard wrote: > On 01/17/2016 15:03, Michał Górny wrote: >> Hello, everyone. >> >> The current maintainer of net-fs herd so far hasn't replied to our >> queries. If we don't get any reply in a week, we will be disbanding it >> and looking for new maintainers for its packages. >> >> Is anyone interested in keeping the herd as a whole and maintaining all >> of its packages? If nobody replies till 2016-01-24, the herd will be >> automatically disbanded and I will be sending a complete list of >> packages needing maintainers. >> >> Packages currently in herd along with their other maintainers: >> > > [snip] > >> net-fs/ncpfs : > > I'll claim this one. I actually have several old NetWare VMs (3.x, 4.2) that > I > can test this with from time-to-time, both TCP/IP and old IPX. > > >> net-fs/nfs4-acl-tools: >> net-fs/nfs-utils : >> net-nds/rpcbind : >> net-libs/libnfsidmap : > > base-system has portmap already, and given some run nfs as a root filesystem, > I > wonder if base-system shouldn't cover these as well? > > --J > > I'd like to help out as I use nfs as well, but don't think I can do it myself, just a user... -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] newsitem: some dhcpcd hooks are now examples
On 01/07/2016 05:46 PM, William Hubbs wrote: > All, > > this is a newsitem for a significant change for dhcpcd-6.10.0. I have > the standard two day delay on it, but I intend to move faster if there > are no objections; we need to do a fast stable of dhcpcd-6.10.0 for > security [1]. > > So, let me know what you think. > > Thanks, > > William > > [1] https://bugs.gentoo.org/show_bug.cgi?id=571152 > lgtm, another option is for us to copy them back in the package (possibly via use flag). -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] packages to grab
On 01/07/2016 07:50 AM, Justin Lecher (jlec) wrote:
> Dear everyone,
>
> due to changes in real life I need to cut back vastly my day to day
> maintainer work starting in February. So far I have no clue how much
> time I can devote to Gentoo in nearer future.
>
> I will move all packages I maintain [1] to the associated projects if
> possible. All devs are free to take what ever you are interested in. I
> am also happy to proxy contributors if they like to maintain a package.
>
> My plan is to focus more on task which I can handle more flexible.
>
> Regarding the projects I am involved in I have the following ideas:
>
> _Recruiters_
>
> We are again actively looking for someone who is doing the review
> session. The candidate should have solid knowledge about the various
> aspects for Gentoo reaching from packaging to institutional aspects.
> Further, you should be able to work with inexperienced contributors
> and have fun teaching the necessary bits.
>
> Secondly, I would like to work strategically on our recruitment
> process. This includes reworking of the quizzes and a general
> assessment of the process as well as new options. We won't change
> anything over night, but I really think we can do simpler and better.
>
> In case you are interested in either topic, feel free to drop a mail
> to recruit...@gentoo.org.
>
> _Science_
>
> We are understaffed for a long time. So in case you like to join feel
> free to do so. This is also and especially directed to the community.
> I strongly encourage you to contribute via PR to the overlay or the
> main gentoo.git. If you have proven yourself in contributions and
> still nobody encouraged you to become a full dev, don't hesitate to
> express your wish and we will manage your recruitment.
>
> _Council_
>
> My council duties should not be affected.
>
> _Other project_
>
> For the time being, I need to drop most work there.
>
> Cheers,
> Justin
>
> 1)
> http://euscan.gentooexperimental.org/maintainers/jlec%40gentoo.org/
>
gonna take these unless anyone yells at me.
modified: app-admin/ansible/metadata.xml
modified: app-arch/p7zip/metadata.xml
modified: dev-python/ipaddress/metadata.xml
modified: dev-python/lz4/metadata.xml
modified: dev-python/mysqlclient/metadata.xml
modified: net-fs/nfstest/metadata.xml
modified: sys-process/iotop/metadata.xml
--
Matthew Thode
--
-- Matthew Thode (prometheanfire)
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] stabilization commits and atomicity
On 10/19/2015 10:04 AM, hasufell wrote: > On 10/19/2015 04:37 PM, Ian Stakenvicius wrote: >> >> >> >> It may be my lack of coffee this morning, but I think you and >> hasufell are saying the same thing but using "making commits less >> atomic" conversely. >> >> Just so i make sure i'm understanding this right, hasufell's >> suggestion is to, instead of rolling a single "atomic" commit for >> every package being stabilized under a tracker bug, that the whole >> set of packages gets stabilized via one commit. Thus ensuring one >> doesn't get half a kde update, and rollbacks can be done at a single >> commit level, etc. >> >> Do I have this right? >> >> (note, since all of these package changes are for a particular >> single purpose imo it would still be an atomic commit) >> >> > > Well yes. But you could go one step further and argue that we can allow > the same thing when ago's scripts make 300 commits for 300 stabilization > bugs at once (same category or not). > > The question is if stabilization needs to be atomic history-wise. It is > nothing you revert or cherry-pick anyway and you could consider it a > global commit too with the subsystem "stable arch". > while I think that one commit per bug is preferred, having multiple bugs in one commit is ok as well. Some of us already do this sometimes when updating packages (multiple birds with one stone and all that). -- -- Matthew Thode (prometheanfire)
[gentoo-dev] Openstack Tokyo (mitaka) summit
I'm going to be at the summit and it would be nice to meet up with others there. I will be moderating the infrastructure containers session (not gentoo related) so I'm guaranteed to be there. Come, watch me make a fool of myself :P Let me know if you'll be there, it'd be nice to get dinner one night. -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] JFYIOR: A Simple Package Versioning Spec
On 09/18/2015 01:24 PM, konsolebox wrote: > On Fri, Sep 18, 2015 at 11:38 PM, Matthew Thode > <prometheanf...@gentoo.org> wrote: >> Are you stating this is for package epochs? > > I'm sorry but I'm not familiar with the term. If you mean package > versions, yes. > > The current specification I also mentioned is this: > https://projects.gentoo.org/pms/5/pms.html#x1-280003.2 > Nah, I'm talking about epochs. When a package wishes to reversion itself, changing how it does versioning. For instance, nova is going to go from 2015.1.1 to 12.0.0, so 2015.n.x is epoch 1, and 12.y.z is epoch 2. Think of it like super versioning. http://legacy.python.org/dev/peps/pep-0440/#version-epochs has a nice summary. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] JFYIOR: A Simple Package Versioning Spec
eturn 0
> end
>
> def self.parse(*args)
> result = new
>
> args.each do |a|
> case a
> when Integer
> result << a
> when /^[[:digit:]][[:alnum:]]*$/
> a.scan(/[[:digit:]]+|[[:alpha:]]+/).each_with_index.map do |b,
> i|
> if i.even?
> str = b.gsub(/^0+/, '')
> result << (str.empty? ? 0 : Integer(str))
> else
> value = 0
>
> b.downcase.bytes.reverse.each_with_index do |c, i|
> value += 27 ** i * (c - 96) ## a == 1, z == 26,
> and 0 exists but is not used
> end
>
> result << value
> end
> end
> else
> raise ArgumentError.new("Invalid node string: #{a.inspect}")
> end
> end
>
> result
> end
>
> def self.zero
> @zero ||= new(0)
> end
>
> private_class_method :new, :allocate
> end
>
> attr_accessor :base, :stage, :patch, :revision
>
> def initialize(base, stage, patch, revision)
> @base, @stage, @patch, @revision = base, stage, patch, revision
> end
>
> def compare_with(another)
> [self.base, another.base].adaptive_transpose.each do |a, b|
> a ||= Node.zero
> b ||= Node.zero
> r = a.compare_with(b)
> return r unless r == 0
> end
>
> r = self.stage.compare_with(another.stage)
> return r unless r == 0
>
> r = self.patch.compare_with(another.patch)
> return r unless r == 0
>
> r = self.revision.compare_with(another.revision)
> return r unless r == 0
>
> return 0
> end
>
> STAGES = { 'alpha' => -4, 'beta' => -3, 'pre' => -2, 'rc' => -1 }
> REGEX =
> /^([[:digit:]][[:alnum:]]*(?:[.][[:alnum:]]+)*)?(?:_(alpha|beta|pre|rc)([[:digit:]][[:alnum:]]*)?)?(?:_p([[:digit:]][[:alnum:]]*))?(?:-r([[:digit:]]+))?(.+)?$/m
>
> def self.parse(version_string)
> __, base, stage, stage_ver, patch, revision, extra =
> version_string.match(REGEX).to_a
> raise_invalid_version_string(version_string) if extra
>
> begin
> base = base.split('.').map{ |e| Node.parse(e) }
> stage = stage ? stage_ver ? Node.parse(STAGES[stage],
> stage_ver) : Node.parse(STAGES[stage]) : Node.zero
> patch = patch ? Node.parse(patch) : Node.zero
> revision = revision ? Node.parse(revision) : Node.zero
> rescue ArgumentError => e
> raise_invalid_version_string("#{version_string}: #{e}")
> end
>
> new(base, stage, patch, revision)
> end
>
> def self.raise_invalid_version_string(version_string)
> raise ArgumentError.new("Invalid version string: #{version_string}")
> end
>
> private_class_method :new, :allocate, :raise_invalid_version_string
> end
> end
>
> samples = [
> ["0", "0.01"],
> ["0.01", "0.010"],
> ["0.09", "0.090"],
> ["0.10", "0.100"],
> ["0.99", "0.990"],
> ["0.100", "0.1000"],
> ["0.100", "0.100"],
> ["0.1", "0.1.1"],
> ["0.1.1", "0.1a"],
> ["0.1a", "0.2"],
> ["0.2", "1"],
> ["1", "1.0"],
> ["1.0", "1.0_alpha"],
> ["1.0_alpha", "1.0_alpha01"],
> ["1.0_alpha01", "1.0_alpha01-r1"],
> ["1.0_alpha01-r1", "1.0_alpha01_p20150105"],
> ["1.0_alpha01_p20150105", "1.0_alpha01_p20150105-r1"],
> ["1.0_alpha01", "1.0_beta"],
> ["1.0_beta", "1.0_beta01"],
> ["1.0_beta01", "1.0_pre01"],
> ["1.0_pre01", "1.0_rc01"],
> ["1.0_rc01", "1.0"],
> ["1.0", "1.0-r1"],
> ["1.0-r1", "1.0_p20150105"],
> ["1.0_p20150105", "1.0_p20150105-r1"]
> ]
>
> samples.each do |a, b|
> x = Portage::PackageVersion.parse(a)
> y = Portage::PackageVersion.parse(b)
> r = x.compare_with(y)
> r = r < 0 ? '<' : r > 0 ? '>' : '=='
> puts "#{a}#{r}#{b}"
> end
>
> 1.3.2 Concept Code Output
>
> 0<0.01
> 0.01<0.010
> 0.09<0.090
> 0.10<0.100
> 0.99<0.990
> 0.100<0.1000
> 0.100==0.100
> 0.1<0.1.1
> 0.1.1<0.1a
> 0.1a<0.2
> 0.2<1
> 1==1.0
> 1.0>1.0_alpha
> 1.0_alpha<1.0_alpha01
> 1.0_alpha01<1.0_alpha01-r1
> 1.0_alpha01-r1<1.0_alpha01_p20150105
> 1.0_alpha01_p20150105<1.0_alpha01_p20150105-r1
> 1.0_alpha01<1.0_beta
> 1.0_beta<1.0_beta01
> 1.0_beta01<1.0_pre01
> 1.0_pre01<1.0_rc01
> 1.0_rc01<1.0
> 1.0<1.0-r1
> 1.0-r1<1.0_p20150105
> 1.0_p20150105<1.0_p20150105-r1
>
Are you stating this is for package epochs?
--
-- Matthew Thode (prometheanfire)
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Inconsistent and messy layout of team maintainership in Gentoo
On 09/16/2015 04:25 PM, Michał Górny wrote: > Hello, > > Right now we kinda have three layers of team package maintainership > in Gentoo: > > 1. e-mail aliases + bugzilla accounts, > > 2. herds, > > 3. projects. > > Now if we get into the details, it's all very messy. > > > E-mail aliases are pretty much handled by obscure, proprietary > scripts. Formally Gentoo developers can read and modify them, but > willikins also provides read access to most of the aliases. E-mail > aliases specify the de-facto list of people receiving bug mail > and other package inquiries. E-mail aliases are either listed directly > as objects, or indirectly provided through herds. > > It should be noted that Bugzilla allows users to 'watch' particular > e-mail addresses, effectively subscribing users to the bug mail. This > can extend the list of people receiving bug mail for a package. > > Herds are stored in data/api.git repository, as an .xml file. > Additionally, read access is provided through api.gentoo.org site. > Herds specify explicitly the de-facto maintainers of packages maintained > by herds. In the past they could alternatively refer to project pages > but that support was dropped along with project wiki migration. Herds > are also mapped to e-mail aliases (which may list different people). > Herds are listed as objects. > > Projects are stored in the proprietary databases of our Wiki instance. > Projects may specify maintainers of packages where herd is supposed to > map directly to a project (though herds.xml doesn't provide a correct > mapping anymore), and also when the particular project's e-mail address > is listed as maintainer. Projects are usually (though not obligatorily) > mapped to e-mail aliases. There is no explicit listing for projects in > metadata.xml. > > > To summarize, I see the following issues: > > 1. All three layers are totally disjoint, stored in completely > different format in completely different places. > > 2. Only herds and aliases can be cleanly mapped via metadata.xml. > > 3. If an alias is given as maintainer, and the alias maps both to > a herd and a project, it is unclear which of the two it is. > > 4. Herds can no longer refer to projects, so all project members are > duplicated in herds (= increased maintenance burden). > > 5. Projects can't list members who do not have Wiki accounts or are > not Gentoo developers. > > So, what are your thoughts for unmessing this? > Herds are groups of developers that can then be mapped to a package. Aliases are groups of developers and/or others that can be mapped to a package (and more, but at least that). Is there a reason not to do a merge into it all being one or the other (preferably aliases I think, as it's somewhat more explicit with mail). -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] dev-rust category
On 09/05/2015 02:21 PM, Jauhien Piatlicki wrote: > Hi, > > I have plans to split ?/cargo-bin [1] package from the dev-lang/rust-bin > one. We have already dev-rust/cargo package in the rust overlay[2]. > > It would be logical to have dev-rust/cargo-bin package then. But there > is a problem: it will be the only package in this category in the tree > and it is not welcome to have categories with small number of packages. > Other rust stuff will appear, but later (with no estimate), as a number > of problems with packaging source rust packages should be solved before > (afaik upstream also has plans to improve rust packaging). The same > about moving source cargo to the tree. > > So what is better, create dev-util/cargo-bin package and later, when > rust infrastructure grows, move it to the dev-rust category or create > new category now? > > [1] https://crates.io/ > [2] https://github.com/Heather/gentoo-rust > > -- > Jauhien > I think cargo should probably go in dev-util with other rust libraries and programs going into dev-rust as needed, but that's just me :D -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2015-08-30 23:59 UTC
On 09/04/2015 01:51 PM, Michał Górny wrote: > Dnia 2015-09-04, o godz. 19:43:41 > James Le Cuirot <ch...@gentoo.org> napisał(a): > >> On Fri, 4 Sep 2015 13:15:57 -0500 >> Matthew Thode <prometheanf...@gentoo.org> wrote: >> >>> uh, this is wrong btw :P >>> >>> I am both mthode and prometheanfire >> >> Your fault for committing with the wrong e-mail address? :P Perhaps >> they're linked in GitHub but I wouldn't want to use that as a source of >> information. How else would we determine this? > > PGP key matching? > that's what I was expecting -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2015-08-30 23:59 UTC
On 09/04/2015 03:53 AM, malc wrote: > James - you're right - I hadn't paid attention to MTA wrapping... > Patrice - even though it's counter to what James asked, I added short > sha-1s [ i.e. the output of git rev-parse --short > f1cb2b98f62fa9cbf1ef5a0f149dd47fee6964be ] > Now the output looks like below (or attached txt file) > > Removals: > dev-java/antenna 2015-09-03 13:45:07 + monsieurp > b4215f4 > dev-java/jjtraveler2015-09-03 13:46:28 + monsieurp > 0bda332 > www-servers/skunkweb 2015-09-03 13:52:51 + monsieurp > 2dc8314 > x11-drivers/radeon-ucode 2015-09-02 00:17:33 +0200 chithanh > 7b60c95 > > Additions: > dev-python/cachetools 2015-09-03 16:17:35 -0500 mthode > 3dca3ff > dev-python/debtcollector 2015-09-01 10:24:15 -0500 mthode > 8513c3c > dev-python/fasteners 2015-09-02 21:56:24 -0500 prometheanfire > cfc49c9 > dev-python/functools32 2015-09-02 13:01:45 +0200 jlec > 2933703 > dev-python/futurist2015-09-03 16:24:23 -0500 mthode > 4a5f1c0 > > Updated scripts attached. > > malc. > uh, this is wrong btw :P I am both mthode and prometheanfire -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] repoman adding Package-Manager: portage-2.2.20.1 to every single commit
On 08/19/2015 12:48 PM, Mike Gilbert wrote: On Wed, Aug 19, 2015 at 1:38 PM, Matthew Thode prometheanf...@gentoo.org wrote: On 08/19/2015 12:37 PM, Zac Medico wrote: On 08/19/2015 09:33 AM, hasufell wrote: I don't want to start a lot of bikeshed, but I think this information is practically useless. If there has been a problem with a commit, ask the developer about his repoman version (which I believe was the reason for this, unless you want me to add Package-Manager: paludis-2.4.0 to every commit ;). Let's just remove it. The intent is to leave a record of the version of repoman used, which leaves an audit trail in case there's a bug in some some version (or to detect if someone is using an ancient version). It can especially be useful when new repoman checks need to be added for new EAPI features. If repoman supported adding a signedoffby line I'd likely use it more for commits. Still running repoman full before commit though. I do not believe we have an requirement for adding Signed-off-by in the gentoo repository. Why do you feel the need to do that? General completeness is all -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] repoman adding Package-Manager: portage-2.2.20.1 to every single commit
On 08/19/2015 12:37 PM, Zac Medico wrote: On 08/19/2015 09:33 AM, hasufell wrote: I don't want to start a lot of bikeshed, but I think this information is practically useless. If there has been a problem with a commit, ask the developer about his repoman version (which I believe was the reason for this, unless you want me to add Package-Manager: paludis-2.4.0 to every commit ;). Let's just remove it. The intent is to leave a record of the version of repoman used, which leaves an audit trail in case there's a bug in some some version (or to detect if someone is using an ancient version). It can especially be useful when new repoman checks need to be added for new EAPI features. If repoman supported adding a signedoffby line I'd likely use it more for commits. Still running repoman full before commit though. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: www-apps/horizon
# Matthew Thode prometheanf...@gentoo.org (04 Aug 2015) # removing old and never working horizon Bug #556710 www-apps/horizon -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
[gentoo-dev] openstack talks
If any of you can I'd appreciate it if you voted for a talk I submitted for the Tokyo Openstack summit. In it I use Gentoo as an example of packaging done right. Thanks :D https://www.openstack.org/summit/tokyo-2015/vote-for-speakers/presentation/4202 -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
[gentoo-dev] new gentoo openstack images
All of the issues that people reported should be fixed. If you have other issues, let me know. https://github.com/prometheanfire/gentoo-cloud-prep/issues?q=is%3Aissue+is%3Aclosed http://gentoo.osuosl.org/experimental/amd64/openstack/ -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
[gentoo-dev] puppet changes/updates
Puppet upstream is changing to a much more /opt based model, as much as that sucks... app-admin/puppet will eventually go away, replaced by puppet-agent and puppetserver (just added both to the tree). I've also added puppetdb support. puppet-agent includes a few packages so blocks against puppet hiera facter and mcollective. have at it and let me know what I did wrong (I was testing on a systemd box so will test the openrc scripts later tonight). -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
[gentoo-dev] openstack image update
I've updated the openstack images to make them smaller, make them work with dynamic ethernet interface add/delete, and make the disk resize on first boot. I've also made nomultilib and hardened images. They are published here now. http://distfiles.gentoo.org/experimental/amd64/openstack/ -- -- Matthew Thode (prometheanfire)
Re: [gentoo-dev] Openstack image availability
On 06/08/2015 01:10 PM, Daniel wrote: I thought I would point out a few things 1) Did you happen to see this guys step by step instructions for creating a cloud image: http://terrarum.net/blog/creating-a-gentoo-cloud-image.html I basically followed these instructions a year or so ago, and with a few tweaks was able to get Gentoo running on OpenStack. 2) I have extensive knowledge of OpenStack, it's been my profession for the past 2 years, so if you need any assistance, let me know. There are automated platforms such as Fuel by Mirantis that can help people deploy OpenStack on a virtual environment in case anyone wanted to try it out. Also DevStack is another common platform people use to test with. Just throwing my 2 cents into the conversation - Daniel On Mon, Jun 8, 2015 at 12:56 PM, Matthew Thode prometheanf...@gentoo.org mailto:prometheanf...@gentoo.org wrote: On 06/08/2015 01:38 PM, wirel...@tampabay.rr.com mailto:wirel...@tampabay.rr.com wrote: On 06/08/2015 10:30 AM, Matthew Thode wrote: Hi, I've just started generation of Gentoo Openstack images. Right now it is just a basic amd64 image, but I plan on adding nomultilib and hardened variants (for a total of at least 4 images). I plan on generating these images at least weekly. These images are not yet sanctioned by our infra team, but I plan on remedying that (being a member of said team should help). I am currently using the scripts at https://github.com/prometheanfire/gentoo-cloud-prep to generate the images (based on a heavily modified version of Matt Vandermeulen's scripts). If you have any issues please submit bugs there or contact me on irc (prometheanfire on freenode). Here's the link to the images, I'm currently gpg signing them with the same key I use to sign this email (offline master key smartcard setup for security minded folk). http://23.253.251.73/ Let me know if you have questions, OK, So to test the images, just burn a dvd/usbstick and run it like a liveDVD? I did not see instructions or brief guidance; I'm noob with openstack but curious to see how she performs.. Long term, will we get an openstack-meta (testing) out of this in portage, or should I just dedicated an old dual core amd64 box for image testing? I'm building up (from 100% sources) a mesos cluster offering with cephfs, Apache-spark, Apache-storm and tachyon. It'd be great to run some tests of codes on openstack (running on local hardware) and then test the same hardware running Apache-mesos. So any suggestions you have on that (so the comparisons are as similar as possible, including recommended test codes) would be of keen interest to me. James This is an image to deploy on top of Openstack. While you can deploy Openstack on the image, it isn't made for that purpose. Something like this is needed to import it into glance. glance image-create --name gentoo-20150608 --disk-format qcow2 --container-format bare --is-public True --min-disk 5 --min-ram 512 --file gentoo-amd64-multilib_2015-06-08.qcow2 --progress -- Matthew Thode (prometheanfire) Thanks, I did have that link as one of the items in a list of reference material. The reason I went the way I did is so I could integrate into our (Gentoo infra's) image building process. Also, thanks for the offer to help, we are in the #gentoo-openstack channel on freenode. I've been working the last few years on openstack (including the ebuild maintence for it in gentoo) at Rackspace :P. I generally recommend people use the openstack-meta-2015.0. package right now, as it deploys from stable/kilo. -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
