[gentoo-dev] Last rites: media-sound/tapestrea
# Sam James (2021-07-26) # Fails to build with GCC 11. No activity upstream. # Removal on 2021-08-26. bug #740536, bug #624746. media-sound/tapestrea signature.asc Description: Message signed with OpenPGP
[gentoo-dev] Last rites: net-im/minbif
# Sam James (2021-07-26) # Fails to build with GCC 11. # Removal on 2021-08-26. bug #788577. net-im/minbif signature.asc Description: Message signed with OpenPGP
[gentoo-dev] Last rites: sci-misc/tango
# Sam James (2021-07-26) # Rather out of date, several open bugs, fails to build with GCC 11. # Removal in 2021-08-26. # bug #793020, bug #692976, bug #741600, bug #703948, bug #674334. sci-misc/tango signature.asc Description: Message signed with OpenPGP
[gentoo-dev] Last rites: dev-cpp/libxsd-frontend
# Sam James (2021-07-26) # No activity upstream. No reverse dependencies (library). # Fails to build with GCC 11. # Removal on 2021-08-26. bug #787113, bug #735714, bug #657510. dev-cpp/libxsd-frontend signature.asc Description: Message signed with OpenPGP
[gentoo-dev] Last rites: media-libs/ctl, media-libs/openexr_ctl
# Sam James (2021-07-25) # No activity upstream since 2014. Fails to build with GCC 11. # Only one reverse dependency (media-libs/openexr_ctl) which # is uninstallable. # Removal on 2021-08-25. bug #789792, bug #715298. media-libs/ctl media-libs/openexr_ctl signature.asc Description: Message signed with OpenPGP
[gentoo-dev] Last rites: app-portage/{deltup,getdelta}
# John Helmert III (2021-07-26) # Open security bug, service backing it seems to be dead, making these # packages useless. Old EAPIs. Removal on 2021-08-26. Bug #630814 app-portage/getdelta app-portage/deltup signature.asc Description: PGP signature
[gentoo-dev] Last rites: app-text/lout
# John Helmert III (2021-07-26) # Maintained needed, open security bug, uninterested upstream. # No revdeps. Removal on 2021-08-26. Bug #752408. app-text/lout signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
Sam James wrote: > > https://www.fsfla.org/pipermail/linux-libre/2020-August/003404.html > > > > it seems that it may be possible to need only very simple tools for the > > deblob program(s). > > Instead of linking to a huge release announcement, could you summarise it? Fair enough - though the relevant part is the short commentary preceding the perhaps mechanical release announcement. The deblob program(s) previously used sed and awk instead of python or perl and seem to have switched more because of performance than because of any features in either python or perl. A quick look into the source code seems to confirm that there's no strong tie to Python. //Peter
Re: [gentoo-dev] Packages up for grab
On Fri, 2021-07-23 at 01:11 +, Peter Stuge wrote: > Marco Scardovi wrote: > > mail-filter/bogofilter > > I'd like to proxy-maintain this. > > > //Peter > We tend to prefer people contribute fixes before adopting. Furthermore, given that you were retired for inactivity (#633142), and I don't see any activity (bar a drive-by fix for app-office/magicpoint) even for the packages you maintained up until that point, I'm disinclined to let you proxy maintain this. If you want to discuss this further, you can email me personally, and we'll then discuss this within proxy-maint.
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
> On 22 Jul 2021, at 16:00, Alice wrote:
>
>
> Signed-off-by: Alice Ferrazzi
> ---
> eclass/kernel-2.eclass | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
Alice, thanks for taking the initiative to get this done and drop Python 2.7
here.
It's much appreciated!
>
> diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> index f94dd9c..05f8161 100644
> --- a/eclass/kernel-2.eclass
> +++ b/eclass/kernel-2.eclass
> @@ -605,7 +605,7 @@ if [[ ${ETYPE} == sources ]]; then
>kernel_is le 2 6 ${DEBLOB_MAX_VERSION} && \
>K_DEBLOB_AVAILABLE=1
>if [[ ${K_DEBLOB_AVAILABLE} == 1 ]]; then
> - PYTHON_COMPAT=( python2_7 )
> + PYTHON_COMPAT=( python3_{7..10} )
I think others already said this, but Python 3.7 is a noop (eclasses ignore
it), so just drop it.
>
>inherit python-any-r1
>
> @@ -1489,9 +1489,14 @@ kernel-2_src_compile() {
>[[ ${ETYPE} == headers ]] && compile_headers
>
>if [[ ${K_DEBLOB_AVAILABLE} == 1 ]] && use deblob; then
> - einfo ">>> Running deblob script ..."
> - python_setup
> - sh "${T}/${DEBLOB_A}" --force || die "Deblob script failed to
> run!!!"
> + # deblob less than 5.10 require python 2.7
> + if kernel_is lt 5 10; then
> + ewarn "we don't support deblob for kernel less then
> 5.10"
> + else
> + einfo ">>> Running deblob script ..."
> + python_setup
> + sh "${T}/${DEBLOB_A}" --force || die "Deblob script
> failed to run!!!"
> + fi
>fi
> }
>
I'd still prefer it if we just didn't provide the USE flag on irrelevant
kernels (it's too confusing) but if you plan on removing this
message at some point, I guess we can keep it?
best,
sam
signature.asc
Description: Message signed with OpenPGP
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
> On 25 Jul 2021, at 23:10, Peter Stuge wrote:
>
> Alice wrote:
>> +++ b/eclass/kernel-2.eclass
> ..
>> - PYTHON_COMPAT=( python2_7 )
>> + PYTHON_COMPAT=( python3_{7..10} )
>
> From
>
> https://www.fsfla.org/pipermail/linux-libre/2020-August/003404.html
>
> it seems that it may be possible to need only very simple tools for the
> deblob program(s). I think that would be a worthwhile improvement and it
> would probably also simplify integration of deblob not only in Gentoo.
Instead of linking to a huge release announcement, could you summarise it?
Better yet, if there's nothing to add, email threads tend to be easier to read
with fewer interventions.
This one has got rather noisy in particular.
>
> That said, if python2_7 is not a thing in Gentoo anymore then the patch
> makes sense to me.
>
It's not been a thing for quite some time other than build-time only
dependencies
which we're only keeping for (now older) Chromium and Firefox/SpiderMonkey.
signature.asc
Description: Message signed with OpenPGP
[gentoo-dev] Last rites: sci-electronics/drawtiming
# David Seifert (2021-07-26) # Fails to build with GCC 11, terrible codebase, tests fail with # modern ImageMagick, last release over 12 years ago. # Bug #725436, #786915, removal in 30 days. sci-electronics/drawtiming signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
Alice wrote:
> +++ b/eclass/kernel-2.eclass
..
> - PYTHON_COMPAT=( python2_7 )
> + PYTHON_COMPAT=( python3_{7..10} )
From
https://www.fsfla.org/pipermail/linux-libre/2020-August/003404.html
it seems that it may be possible to need only very simple tools for the
deblob program(s). I think that would be a worthwhile improvement and it
would probably also simplify integration of deblob not only in Gentoo.
That said, if python2_7 is not a thing in Gentoo anymore then the patch
makes sense to me.
I think the discussion on merits concluded well - kernel maintainers who
want can support it. Everyone who considers it pointless can ignore it.
All good.
Kind regards
//Peter
Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests
On Sun, Jul 25, 2021 at 11:23 AM Ulrich Mueller wrote: > > We can reiterate when there are indications that SHA512 would be broken. > (Then again, the same applies to BLAKE2B.) Unless both are broken at the same time you'd also have the advantage of not having to try to scramble to figure out whether anything was compromised. I get that typically hash functions are first broken in a way that makes them very difficult to exploit, but that isn't some sort of guarantee. In the very unlikely event that somebody comes up with a preimage attack against one of the functions, it would be even more unlikely that an attack would be devised against both. Sure, we're talking about low risks here, but we're also talking about low cost and security. When security is this cheap, why not have it? I mean, if people didn't care about this stuff they wouldn't bother migrating off of md5, and you'd have critical software like source code control using broken hashes like sha1. -- Rich
Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests
> On Sun, 25 Jul 2021, Roy Bamford wrote: > I'm in the "if it's not broken don't fix it" school. +1 I don't see a strong argument to remove SHA512, so leave things as they are for now. We can reiterate when there are indications that SHA512 would be broken. (Then again, the same applies to BLAKE2B.) Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests
On 24/07/21 17:16, Michał Górny wrote: > Hi, everyone. > > I've been asked to repost the idea of removing SHA512 hash from > Manifests, effectively limiting them to BLAKE2B. > > The 'old' set of Gentoo hashes including SHA512 went live in July 2012. > In November 2017, we have decided to remove the two other hashes and add > BLAKE2B in their stead. Today, all Gentoo packages are using BLAKE2B > and SHA512 hashes. > > To all extent, this is purely a cosmetic change. The benefit from > removing the additional hash is negligible, both from space perspective > and hashing speed perspective. The benefit from keeping two hashes is > also negligible. > > Back during the 2017 discussion, Infra came to the conclusion that we're > going to keep SHA512 for a transition period, then remove it, and stay > with a single hash algorithm. In my opinion, we have kept it long > enough. > > WDYT? > I'd remove it once we have a second hash to add and/or BLAKE2B is widespread enough on upstream. lu
Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests
Am Samstag, 24. Juli 2021, 17:16:23 CEST schrieb Michał Górny: > Hi, everyone. > > I've been asked to repost the idea of removing SHA512 hash from > Manifests, effectively limiting them to BLAKE2B. Just keep things as they are for now. Even reading this bike^H^H^H^Hthread is more effort than the potential gain. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice)
[gentoo-dev] Racket-Overlay & dev-scheme/racket fixes
Hello! I created a Gentoo overlay [1] with auto-generated ebuilds from the Racket packages catalog [2], using a tool I wrote - collector2 [3]. But most importantly I added, to the overlay, a ebuild with some fixes for dev-scheme/racket [4] and documented [5] the changes (see section "Racket’s ebuild changes"). It would be very nice if the changes (or a part of them) I made to the Racket ebuild would be merged into ::gentoo. In the past I did a PR [6] to add some fixes (at the time without the most important fix - not overwriting changed racket pkg database) but there was no discussion or resolution of that PR. Could some developer look into the changes I made? Thanks in advance. [1] https://gitlab.com/src_prepare/racket/racket-overlay [2] https://pkgs.racket-lang.org/ [3] https://gitlab.com/src_prepare/racket/collector2 [4] https://gitlab.com/src_prepare/racket/racket-overlay/-/blob/master/dev-scheme/racket/racket-8.2.ebuild [5] https://src_prepare.gitlab.io/racket/racket-overlay/racket-overlay-install.html [6] https://github.com/gentoo/gentoo/pull/20668 -- Have a great day! ~ Maciej XGQT Barć
Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests
On 2021.07.25 00:12, Thomas Deutschmann wrote: > Hi, > > I don't understand. Isn't it the same motion we put down just 2 months > > ago [1]? Or is this something new? > > If this isn't something new, what has changed since May [2]? > > To remember: Currently we have two different hashes for every > distfile. > If we are going to throw this data away, we should really have good > reasons to do that. Like said during that council meeting, BLAKE2B and > > SHA512 are competing hashes. What's wrong with having a backup plan > even > for a very unlikely scenario, that BLAKE2B will get broken? > > It's not like SHA512 is requiring any additional deps which are > unmaintained or something like that. SHA has even hardware > acceleration > support in modern systems. > > In addition it is even more likely that you will find SHA checksum > files > with upstream release tarballs than BLAKE2B files. > > Remember that verify-sig.eclass I criticized last year? Of course some > > scenarios I outlined were very unlikely and I never expected that I > can > run around in near future saying "I told you". But in January 2021, > CVE-2021-3345 happened in libgcrypt... > > So again: Why should we throw the data we currently have away and put > Gentoo unnecessarily at risk that we will end up without hashes > because > the only hash algorithm we used became broken and given that we will > be > unable to re-hash every file in a timely manner (remember how long it > took to get a BLAKE2B hash for every file)? > > > > See also: > = > [1] https://bugs.gentoo.org/784710 > > [2] https://projects.gentoo.org/council/meeting-logs/20210509.txt > > > -- > Regards, > Thomas Deutschmann / Gentoo Linux Developer > fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 > > I'm in the "if it's not broken don't fix it" school. The original proposal uses the word 'negligible' twice when describing the the benefits, which makes it sound like busywork. However, it's not me doing the work, so my opinion count for very little. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgp3G7Gf0Tace.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests
Hi, Back during the 2017 discussion, Infra came to the conclusion that we're going to keep SHA512 for a transition period, then remove it, and stay with a single hash algorithm. In my opinion, we have kept it long enough. WDYT? As far I remember we agreed to keep two different hashes. The idea is, that if one hash is no longer safe to use, we still have a short period for migration. If we use only one hash, gentoo is vulnarable to "sudden problems". The everyday news show us, that broken implementations are possible and that this scenario is likely to happen over the years. The benefit of removing the second hash is negligible. So we should keep two different hashes. -- Best, Jonas
Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests
On 24/07/2021 16:16, Michał Górny wrote: Hi, everyone. I've been asked to repost the idea of removing SHA512 hash from Manifests, effectively limiting them to BLAKE2B. The 'old' set of Gentoo hashes including SHA512 went live in July 2012. In November 2017, we have decided to remove the two other hashes and add BLAKE2B in their stead. Today, all Gentoo packages are using BLAKE2B and SHA512 hashes. To all extent, this is purely a cosmetic change. The benefit from removing the additional hash is negligible, both from space perspective and hashing speed perspective. The benefit from keeping two hashes is also negligible. Back during the 2017 discussion, Infra came to the conclusion that we're going to keep SHA512 for a transition period, then remove it, and stay with a single hash algorithm. In my opinion, we have kept it long enough. WDYT? I use Gentoo heavily in my work but not a developer, so only offering a user perspective. I find SHA512 hashes in Manifests, of upstream provided tarballs (i.e. DIST entries) only, very useful when manually comparing with hashes provided by upstream sources. BLAKE2B may be better than SHA512 in certain respects but adoption elsewhere by comparison is extremely low. Granted SHA512 hashes of upstream files are certainly not plentiful (and it is shocking how many project still use MD5) but at least some projects provide them. I've personally never seen any project provide a BLAKE2B hash for a sources tarball. Additionally, as stated by someone else already, there is SHA512 hardware acceleration support on many systems. This can save precious time in certain scenarios when doing manual checks on large files. If there is little benefit to removing SHA512 it seems to me that there are significant benefits to keeping it. I for one would be quite disappointed to see it go.
[gentoo-dev] Last rites: dev-python/xdg
# Michał Górny (2021-07-25) # Conflicts with dev-python/pyxdg. Upstream is unwilling to resolve # this. The only revdep has been patched to use pyxdg. # Removal on 2021-08-24. Bug #804127. dev-python/xdg -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests
On 7/24/21 5:16 PM, Michał Górny wrote: Back during the 2017 discussion, Infra came to the conclusion that we're going to keep SHA512 for a transition period, then remove it, and stay with a single hash algorithm. I'm just curious if Infra in 2021 still wants only 1 hash algo? In my opinion, we have kept it long enough. Indeed, if nothing changed Infras opinion, then it is time to kick if off. -- Toralf PGP 23217DA7 9B888F45 OpenPGP_signature Description: OpenPGP digital signature
