Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass
On Mon, May 11, 2020 at 4:00 PM William Hubbs wrote: > > On Tue, May 12, 2020 at 01:45:45AM +0300, Andreas K. Hüttel wrote: > > > This patch makes migrating mandatory by forcing ebuilds to die if they > > > have EGO_VENDOR set and are using go-module.eclass. > > > > You can't commit this as long as there is a single such ebuild in the tree. > > Sure, and I'm working on migrating them. I think all the replies to this thread could have been avoided by just saying that in your initial email. :)
Re: [gentoo-dev] unverifiable GPG keys for @gentoo.org members
W dniu pon, 11.05.2020 o godzinie 20∶20 -0400, użytkownik Aisha Tammy napisał: > Hi devs@, > Seems like for some reason the gentoo.org does not publish the > gpg public keys of the senders, even though it is signed correctly. Why do you claim that? How did you verify it? Why are you jumping straight to passive-aggressive accusations without asking nicely first? > > Just wanted to know why the devs are required to use gpg keys, glep63 > [1] > but even when the server has the public keys, they aren't published > properly. > > From a proper security perspective, I would have though something > like WKD[2] would have been implemented on the server side for > automated > authentication. WKD is implemented and I don't know a single case where it wouldn't work. If it doesn't work for you, then I dare say it's more likely to be a problem with your setup. However, if it's a problem on our end, I'd really appreciate a bug report before calling us retarded. In fact, the link you've posted actually lists gentoo.org as one of the few organizations implementing WKD. > > Maybe I am missing something about how to verify the keys of the > maintainers > who are sending announcements but it irks me a teensy bit when i have > signed > mails and I can't ~~trust~~ verify the signatures. > > You are missing that WKD does not provide authentication, and if it were, it would be considered thoroughly insecure. Authentication in OpenPGP is generally provided via web of trust. For Gentoo developers, you can also use our Authority Keys [3,4,5]. > > [1] > https://wiki.gentoo.org/wiki/Project:Infrastructure/Generating_GLEP_63_based_OpenPGP_keys > [2] https://wiki.gnupg.org/WKD [3] https://www.gentoo.org/downloads/signatures/ [4] https://www.gentoo.org/glep/glep-0079.html [5] https://wiki.gentoo.org/wiki/Project:Infrastructure/Authority_Keys -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] unverifiable GPG keys for @gentoo.org members
On 5/11/20 8:20 PM, Aisha Tammy wrote: > Hi devs@, > Seems like for some reason the gentoo.org does not publish the > gpg public keys of the senders, even though it is signed correctly. > Sorry, I meant **mail signing**, not commit signing. Just saw that wording was confusing. > Just wanted to know why the devs are required to use gpg keys, glep63 [1] > but even when the server has the public keys, they aren't published properly. > > From a proper security perspective, I would have though something > like WKD[2] would have been implemented on the server side for automated > authentication. > > Maybe I am missing something about how to verify the keys of the maintainers > who are sending announcements but it irks me a teensy bit when i have signed > mails and I can't ~~trust~~ verify the signatures. > > This is tots an aside from normal gentoo stuff. > > Hope ya'll are safe, > Aisha > > > > [1] > https://wiki.gentoo.org/wiki/Project:Infrastructure/Generating_GLEP_63_based_OpenPGP_keys > [2] https://wiki.gnupg.org/WKD >
[gentoo-dev] unverifiable GPG keys for @gentoo.org members
Hi devs@, Seems like for some reason the gentoo.org does not publish the gpg public keys of the senders, even though it is signed correctly. Just wanted to know why the devs are required to use gpg keys, glep63 [1] but even when the server has the public keys, they aren't published properly. >From a proper security perspective, I would have though something like WKD[2] would have been implemented on the server side for automated authentication. Maybe I am missing something about how to verify the keys of the maintainers who are sending announcements but it irks me a teensy bit when i have signed mails and I can't ~~trust~~ verify the signatures. This is tots an aside from normal gentoo stuff. Hope ya'll are safe, Aisha [1] https://wiki.gentoo.org/wiki/Project:Infrastructure/Generating_GLEP_63_based_OpenPGP_keys [2] https://wiki.gnupg.org/WKD
Re: [gentoo-dev] Package up for grabs: net-im/prosody
[2020-05-11 12:39:05+0200] Tobias Klausmann: > Hi! > > As per subject. I am not running any Jabber infrastructure > anymore. > > Package is in decent shape. Lua 5.2 compatibility is not there, > but I don't see 5.2 happening soon anyway. The rest of the bugs > are nice-to-haves and cosmetic stuff. > > I'll keep myself in the maintainers file for another month or so. > If you want to take over, feel free to drop in and remove me. > > Best, > Tobias Hi, I already have app-editors/vis with a dependency on lua 5.2+ so I can take it if no one else takes it over in let's say two weeks. (I'm open for co-maintainance btw) Only thing is that right now my prosody setup isn't using the ebuild (it's an old setup from before I used gentoo, it builds from the hg tip/trunk). At least it's likely that I'll just keep using prosody so a serious while. Best regards,
[gentoo-dev] last rites: dev-go/go-protobuf
# William Hubbs (2020-05-11) # No reverse dependencies, upstream has superseeded this with the # ggoogle.golang.org/protobuf module. # Removal in 30 days. Bug #722542. dev-go/go-protobuf Thanks, William signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass
On Tue, May 12, 2020 at 01:45:45AM +0300, Andreas K. Hüttel wrote: > > This patch makes migrating mandatory by forcing ebuilds to die if they > > have EGO_VENDOR set and are using go-module.eclass. > > You can't commit this as long as there is a single such ebuild in the tree. Sure, and I'm working on migrating them. William signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass
On Mon, May 11, 2020 at 09:51:45AM -0400, Mike Gilbert wrote: > On Sun, May 10, 2020 at 5:16 PM William Hubbs wrote: > > > > All, > > > > now that go 1.14.2 is stable, I want to remove the EGO_VENDOR support from > > go-module.eclass. > > > > This was kept when the EGO_SUM support was added on 4 Mar, with a qa > > warning advising people to migrate their ebuilds to EGO_SUM. > > > > This patch makes migrating mandatory by forcing ebuilds to die if they > > have EGO_VENDOR set and are using go-module.eclass. > > > > Thoughts? > > It seems like you're being very lazy about this. At a minimum, you > should do the following: I will respond to your points below, but first, I take offense to your accusation of me being lazy especially since it seems pretty obvious you didn't attempt to research my work before you said it. > 1. Search for affected packages. Done. > 2. Contact the maintainers, possibly via bug reports. Already done. If you look at the packages I have been doing this conversion for so far, you would see that most of them are maintained by myself, zac or not maintained at all. > 3. Give them a some time to convert their packages. No one has had issues with me doing the work myself, so that is what has been happening. Also, keep in mind that there was a public announcement made on this list about migrating go packages to the go-module eclass, and no one spoke out then against it. > 4. Mask any packages that do not get updated. There's only one I have masked so far and that was per the maintainer. I did post the lastrites but it looks like I need to forward it to -dev or re-post it, I will take a look again after I respond to this message. William signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass
> This patch makes migrating mandatory by forcing ebuilds to die if they > have EGO_VENDOR set and are using go-module.eclass. You can't commit this as long as there is a single such ebuild in the tree. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: sys-boot/plymouth-openrc-plugin
# Amadeusz Żołnowski (2020-05-11) # Masked for removal in 30 days. Unmaintained upstream. sys-boot/plymouth-openrc-plugin signature.asc Description: PGP signature
Re: [gentoo-dev] dev-python/llvmlite update to 0.32
On 5/11/20 2:35 AM, Michał Górny wrote: > W dniu nie, 10.05.2020 o godzinie 14∶54 -0400, użytkownik Aisha Tammy > napisał: >> On 5/10/20 2:11 PM, Michał Górny wrote: >>> W dniu nie, 10.05.2020 o godzinie 07∶21 -0400, użytkownik Aisha >>> Tammy >>> napisał: On 5/10/20 2:02 AM, Michał Górny wrote: > W dniu sob, 09.05.2020 o godzinie 22∶39 -0400, użytkownik Aisha > Tammy > napisał: >> Hey all, >> I was hoping to upgrade the dev-python/numba jit compiler >> in >> proxy- >> maint but it depends on dev-python/llvmlite >=0.31 >> Current version of llvmlite is stuck at 0.30 which is >> preventing >> the >> numba package from being upgraded. >> It is at a risk of last rite retiring because its stuck at >> 3.6 > > It is more likely to be last rited because upstream still > didn't > manage > to port it to LLVM 9. I don't have LLVM 8 anymore, and I don't > have > the resources to build 3 different LLVM versions. > The following issue tells that LLVM 9 is now supported :) https://github.com/numba/llvmlite/issues/523 They haven't updated their documentation correctly. >>> >>> I suppose this means using the fancy variable to disable LLVM >>> version >>> checks, correct? >>> >> lol, you seem to be experienced with this kind of behaviour :P . >> I won't even ask how many times this may have burned you XD . >> Indeed, they have changed the version checking feature pretty >> recently >> though nothing too coherent has been given out yet. > > Well, I've noticed it when I checked if they finally stopped requiring > 8.*. I presumed they've added it instead of proper support for LLVM 9 > but didn't expect it to actually pass tests (modulo two silly tests, > one checking version and other exact error message). > >> >> Here's to hoping they do it over summer. >> PS: regarding lack of resources. I have a spare computer and am willing to use that to do some testing for interesting packages like these. I hope it can help us keep a few more packages that would otherwise be killed off. >>> >>> Well, my hardware died two days ago, so I should have more >>> resources >>> mid-next week. Until then, only minimal work that can be done with >>> backup hardware. >>> >> That sucks, hardware failure is the bane of everyones existence T.T >> > > Well, hardware upgrade was long overdue, so there is the bright side. > My plan was to keep the old PC as backup distcc node but I guess it > wouldn't amount to much. It was Athlon64 x2 3800+ (from the times when > they still called it 'Athlon64'). > > In any case, I've just tested the version bump and will push it > shortly. Thanks! > Oh, thanks a lot for your work! Aisha
[gentoo-dev] Last rites: acct-group/octoprint, acct-user/octoprint, www-apps/octoprint
# Michał Górny (2020-05-11) # Causes downgrades of multiple Python packages. Not touched since # initial commit, waiting for a bump to the final release. Maintainer # unresponsive. Upstream recommends installing in a virtualenv. # Removal in 30 days. Bug #710406. acct-group/octoprint acct-user/octoprint www-apps/octoprint -- Best regards, Michał Górny
Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass
On Mon, May 11, 2020 at 06:13:19PM +0200, David Seifert wrote: > On Mon, 2020-05-11 at 09:51 -0400, Mike Gilbert wrote: > > On Sun, May 10, 2020 at 5:16 PM William Hubbs > > wrote: > > > All, > > > > > > now that go 1.14.2 is stable, I want to remove the EGO_VENDOR > > > support from > > > go-module.eclass. > > > > > > This was kept when the EGO_SUM support was added on 4 Mar, with a qa > > > warning advising people to migrate their ebuilds to EGO_SUM. > > > > > > This patch makes migrating mandatory by forcing ebuilds to die if > > > they > > > have EGO_VENDOR set and are using go-module.eclass. > > > > > > Thoughts? > > > > It seems like you're being very lazy about this. At a minimum, you > > should do the following: > > > > 1. Search for affected packages. > > 2. Contact the maintainers, possibly via bug reports. > > 3. Give them a some time to convert their packages. > > 4. Mask any packages that do not get updated. > > > > Wow, and python changing one line in its implementation details is > breaking the world, whereas there's still a ton of users of EGO_VENDOR > in the tree? I'm looking at a specific combination at this point. The ebuilds I'm looking at inherit go-module *and* use EGO_VENDOR. Most of these have already been fixed because I have permission from the maintainers to work on them or I am the maintainer. The hard part is going to be the work of migrating ebuilds that inherit golang-* and use EGO_VENDOR over to go-module. That will take work with upstreams in some cases to make it happen. William signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass
On Mon, 2020-05-11 at 09:51 -0400, Mike Gilbert wrote: > On Sun, May 10, 2020 at 5:16 PM William Hubbs > wrote: > > All, > > > > now that go 1.14.2 is stable, I want to remove the EGO_VENDOR > > support from > > go-module.eclass. > > > > This was kept when the EGO_SUM support was added on 4 Mar, with a qa > > warning advising people to migrate their ebuilds to EGO_SUM. > > > > This patch makes migrating mandatory by forcing ebuilds to die if > > they > > have EGO_VENDOR set and are using go-module.eclass. > > > > Thoughts? > > It seems like you're being very lazy about this. At a minimum, you > should do the following: > > 1. Search for affected packages. > 2. Contact the maintainers, possibly via bug reports. > 3. Give them a some time to convert their packages. > 4. Mask any packages that do not get updated. > Wow, and python changing one line in its implementation details is breaking the world, whereas there's still a ton of users of EGO_VENDOR in the tree?
Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass
On Sun, May 10, 2020 at 5:16 PM William Hubbs wrote: > > All, > > now that go 1.14.2 is stable, I want to remove the EGO_VENDOR support from > go-module.eclass. > > This was kept when the EGO_SUM support was added on 4 Mar, with a qa > warning advising people to migrate their ebuilds to EGO_SUM. > > This patch makes migrating mandatory by forcing ebuilds to die if they > have EGO_VENDOR set and are using go-module.eclass. > > Thoughts? It seems like you're being very lazy about this. At a minimum, you should do the following: 1. Search for affected packages. 2. Contact the maintainers, possibly via bug reports. 3. Give them a some time to convert their packages. 4. Mask any packages that do not get updated.
[gentoo-dev] Package up for grabs: net-im/prosody
Hi! As per subject. I am not running any Jabber infrastructure anymore. Package is in decent shape. Lua 5.2 compatibility is not there, but I don't see 5.2 happening soon anyway. The rest of the bugs are nice-to-haves and cosmetic stuff. I'll keep myself in the maintainers file for another month or so. If you want to take over, feel free to drop in and remove me. Best, Tobias -- # Basic IBM dingbats, some of which will never have a purpose clear # to mankind linux-2.4.0/drivers/char/cp437.uni
Re: [gentoo-dev] Packages up for grabs: LXDE
On 5/11/20 10:00 AM, Joonas Niilola wrote: > > And here are packages that were co-maintained by lxqt project, or by > individual devs: > > > media-gfx/gpicview And this by graphics... signature.asc Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs: LXDE
Hey all, since LXDE has no project members, and no one joined for a long time or picked up the packages, let's properly reassign them. Here are packages that were dropped to maintainer-needed: lxde-base/lxde-icon-theme lxde-base/lxtask lxde-base/lxappearance-obconf lxde-base/lxrandr lxde-base/lxsession lxde-base/lxappearance lxde-base/lxpanel lxde-base/lxterminal lxde-base/lxde-common lxde-base/lxde-meta lxde-base/lxinput lxde-base/lxlauncher media-sound/lxmusic x11-misc/pcmanfm And here are packages that were co-maintained by lxqt project, or by individual devs: x11-libs/libfm-extra x11-libs/libfm lxde-base/lxdm lxde-base/menu-cache media-gfx/gpicview I will reassign bugs next. -- juippis signature.asc Description: OpenPGP digital signature
