[gentoo-portage-dev] [PATCH] Escape percent-signs in filename when fetching from mirrors
Bug: https://bugs.gentoo.org/719810
Signed-off-by: Mike Gilbert
---
lib/portage/package/ebuild/fetch.py | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/lib/portage/package/ebuild/fetch.py
b/lib/portage/package/ebuild/fetch.py
index 28e7caf53..47c3ad28f 100644
--- a/lib/portage/package/ebuild/fetch.py
+++ b/lib/portage/package/ebuild/fetch.py
@@ -26,6 +26,11 @@ try:
except ImportError:
from urlparse import urlparse
+try:
+ from urllib.parse import quote as urlquote
+except ImportError:
+ from urllib import quote as urlquote
+
import portage
portage.proxy.lazyimport.lazyimport(globals(),
'portage.package.ebuild.config:check_config_instance,config',
@@ -351,7 +356,7 @@ _size_suffix_map = {
class FlatLayout(object):
def get_path(self, filename):
- return filename
+ return urlquote(filename)
def get_filenames(self, distdir):
for dirpath, dirnames, filenames in os.walk(distdir,
@@ -382,7 +387,7 @@ class FilenameHashLayout(object):
c = c // 4
ret += fnhash[:c] + '/'
fnhash = fnhash[c:]
- return ret + filename
+ return ret + urlquote(filename)
def get_filenames(self, distdir):
pattern = ''
--
2.27.0.rc2
Re: [gentoo-dev] Gentoo/OpenBSD current status
Aisha Tammy writes: > I've been trying to play around with the prefix and reading the > code. Basically trying to get it to work for my system. I've not > managed to get even a small headstart and am quite lost to say the > least. I was wondering if the openbsd prefix support is something > that is still garnering any interest from gentoo? There is still interest in Gentoo. But no one seems to have energy to take care of it. Your contribution is welcomed. > Would love to know if it could be possible in anyway. Benda signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo Council Election 2020 - Call For Election Officials
On 2020.05.30 13:14, Rich Freeman wrote: > On Sat, May 30, 2020 at 6:09 AM Roy Bamford > wrote: > > > > We sill need more volunteers. > > > > Not going to be running, so I'm happy to pitch in. > > -- > Rich > > > Rich, Thank you. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgps3MQbFCaNk.pgp Description: PGP signature
[gentoo-dev] Gentoo/OpenBSD current status
Hi maksbotan and other devs, I've been trying to play around with the prefix and reading the code. Basically trying to get it to work for my system. I've not managed to get even a small headstart and am quite lost to say the least. I was wondering if the openbsd prefix support is something that is still garnering any interest from gentoo? Would love to know if it could be possible in anyway. Aisha signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] kernel-2.eclass: use $(CC) as HOSTCC, bug #725878
Also see https://bugs.chromium.org/p/chromium/issues/detail?id=1088210 on
Chrome OS.
Verified that this fixes the linux-headers build issue when gcc links are
not installed.
Thanks,
Manoj
On Sat, May 30, 2020 at 5:24 AM Sergei Trofimovich
wrote:
> Before the change HOSTCC always used gcc. This was
> detected by Agostino on linux-headers package.
>
> After the change HOSTCC uses user-specified CC
> (or BUILD_CC). Tested on native linux-headers
> and on cross-*/linux-headers.
>
> CC: ker...@gentoo.org
> Reported-by: Agostino Sarubbo
> https://bugs.gentoo.org/725878
> Signed-off-by: Sergei Trofimovich
> ---
> eclass/kernel-2.eclass | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> index 930bcf22e29..04edee33930 100644
> --- a/eclass/kernel-2.eclass
> +++ b/eclass/kernel-2.eclass
> @@ -712,6 +712,7 @@ env_setup_xmakeopts() {
> elif type -p ${CHOST}-ar > /dev/null ; then
> xmakeopts="${xmakeopts} CROSS_COMPILE=${CHOST}-"
> fi
> + xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC)"
> export xmakeopts
> }
>
> --
> 2.26.2
>
>
>
[gentoo-dev] Update on Python 3.8 and 3.9 support
Hello,
TL;DR: py3.8 unmasked where possible, py3.9 is ready for package
testing, arch teams need to finally finish pending keywordreqs.
Upstream has recently released Python 3.9.0b1. This means that there
are no further major changes planned and it is now time to start testing
packages for real. For this reason, I have added python3_9 target
and bootstrapped the base package subset that should make it now
possible to start testing other packages without hitting huge dependency
cycles.
Please remember to run tests on Python 3.9 when testing packages.
From my experience, the majority of issues are ImportErrors or
AttributeErrors due to removed stuff (previously deprecated since 3.1
to 3.4). My recommendation is to look into py3.8 reference [1] and find
the deprecated function there, with recommendation how to replace it.
The 'What\'s new' [2] may also be helpful, or full changelog [3].
I would like to remind you that all non-amd64 architectures have had
Python 3.8 target masked due to unresolved ages-old keywordreqs. This
resulted in 3.9 being masked as well. I've attempted to deal with this,
and I've been able to keyword and unmask py3.8+3.9 on ppc, ppc64, sparc
and x86. Sam is working on arm/arm64, and Rolf is working on hppa
(where the situation is horrible AFAICS). This leaves nobody on alpha
and ia64.
Therefore, I would like to ask alpha and ia64 arch teams to finally
start processing Python keywording requests. Given that our package
manager and large part of tooling is in Python, it is kinda important to
have working Python in Gentoo. If we can't manage this, we probably
should remove these arches altogether.
That said, if somebody can give me access to alpha, ia64, hppa, arm,
arm64 hardware (highest priority listed first), I can help. I can also
give you a list of urgent bugs if you wish. The highest priority is to
get depgraph clean after unmasking targets, the final goal is to restore
all lost keywords on Python packages. Please note that some arches
might be missing proper bugs due to the whole mess resulting from delays
(e.g. because arch team keyworded old version and nobody noticed that
keywords were effectively lost again).
To check what needs to be keyworded to unmask targets, remove the mask
from your arch profile and run:
pkgcheck scan -c VisibilityCheck -a
To check all lost keywords:
pkgcheck scan -c DroppedKeywordsCheck -a
One-liner to get ekeyword invocations:
pkgcheck scan -c DroppedKeywordsCheck -a -R FormatReporter \
--format \
'ekeyword {category}/{package}/{package}-{version}.ebuild ~'
Thank you!
[1] https://docs.python.org/3.8/library/index.html
[2] https://docs.python.org/3.9/whatsnew/3.9.html
[3] https://docs.python.org/3.9/whatsnew/changelog.html
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH] kernel-2.eclass: use $(CC) as HOSTCC, bug #725878
Before the change HOSTCC always used gcc. This was
detected by Agostino on linux-headers package.
After the change HOSTCC uses user-specified CC
(or BUILD_CC). Tested on native linux-headers
and on cross-*/linux-headers.
CC: ker...@gentoo.org
Reported-by: Agostino Sarubbo
https://bugs.gentoo.org/725878
Signed-off-by: Sergei Trofimovich
---
eclass/kernel-2.eclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index 930bcf22e29..04edee33930 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -712,6 +712,7 @@ env_setup_xmakeopts() {
elif type -p ${CHOST}-ar > /dev/null ; then
xmakeopts="${xmakeopts} CROSS_COMPILE=${CHOST}-"
fi
+ xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC)"
export xmakeopts
}
--
2.26.2
Re: [gentoo-dev] Gentoo Council Election 2020 - Call For Election Officials
On Sat, May 30, 2020 at 6:09 AM Roy Bamford wrote: > > We sill need more volunteers. > Not going to be running, so I'm happy to pitch in. -- Rich
Re: [gentoo-dev] Gentoo Council Election 2020 - Call For Election Officials
On 2020.05.29 21:10, David Abbott wrote: > On Fri, May 29, 2020 at 4:03 PM Roy Bamford > wrote: > > > > Team, > > > > Our current council will hold their last meeting on 14-Jun-20. > > We therefore need to elect a new council before the July meeting. > > > > To do this, I'm calling for three volunteers to be election > officials and an > > infra member to be the infra contact. > > > ... [snip] > > > > -- > > Regards, > > > > Roy Bamford > > (Neddyseagoon) a member of > > elections > > gentoo-ops > > forum-mods > > arm64 > > Hi Roy, > Count me in. > Regards, > > -- > David Abbott (dabbott) > > David, Thank you. The election page is up now. https://wiki.gentoo.org/wiki/Project:Elections/Council/202006 We sill need more volunteers. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgpfHGn3U4xxH.pgp Description: PGP signature
Re: [gentoo-dev] Value of Continuous integration vs Code Review / Pull Requests
On Fri, 2020-05-29 at 16:34 -0700, Alec Warner wrote: > The pull-based mirroring is a bit sad, as it would be nice to auto-update > some forks, but it's not a killer feature. Exactly. Especially that our push-based mirroring is better, and I think that's how we want to populate it. > I think our new SSO solution > could potentially be a fix for the auth subsystems, but more work there > will be needed. I think SSO should be the primary login to our GitLab, especially for our users. GitHub login is a must. > Another major issue is operating the software. I haven't found anyone to > *run* gitlab; I'm not eager to do it. Today Gentoo is mostly distributed, > bugs are in bugzilla, wiki is on mediawiki, code is on gitolite with N > mirrors, email and lists are separate, etc. In a world where bugs, wiki, > code, ci, containers, PRs, are all on gitlab and it breaks and we can't fix > it; it will be bad news for all of those things. If the bugzilla machine > breaks we lose bugzilla; if gitlab breaks we lose the ability to edit the > wiki, file bugs, commit, run CI, etc. > But who says we want to migrate them all into GitLab? I thought our primary goal was to replace today's GitHub use, i.e. provide an alternative pipeline for pull/merge requests. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
