Re: [arch-dev-public] Autumn extra cleaning

2020-10-06 Thread Anatol Pomozov via arch-dev-public
Hi On Sun, Oct 4, 2020 at 10:16 PM Sven-Hendrik Haase via arch-dev-public wrote: > > Hey everyone, > > It was suggested as part of this year's spring cleanup of [community] > that we should be have a cleanup in [core]/[extra] and move packages > downwards into [community]. > > This round only

Re: [arch-dev-public] Autumn extra cleaning

2020-10-05 Thread Anatol Pomozov via arch-dev-public
Hi On Sun, Oct 4, 2020 at 11:11 PM Daurnimator via arch-dev-public wrote: > > On Mon, 5 Oct 2020 at 16:16, Sven-Hendrik Haase via arch-dev-public > wrote: > > TUs can notify which packages they are interested to maintain in [community] > > > lua51 > > lua52 > > Sure (though no upstream updates

[arch-dev-public] Anatol is inactive due to situation in Belarus

2020-08-13 Thread Anatol Pomozov via arch-dev-public
Hello folks My name is Anatol Pomozov and I am an Arch Linux developer. I've been quiet for a couple of weeks now and will probably stay away from my Arch Linux/pacman (+bcc:pacman-dev@) duties for a bit more. Please feel free to take care of my packages if it's needed. The reason for this

Re: [arch-dev-public] Use detached package signatures by default

2020-08-10 Thread Anatol Pomozov via arch-dev-public
Hi Giancarlo On Tue, Jul 28, 2020 at 12:35 PM Giancarlo Razzolini wrote: > This could be maintained as a patch on the package, it doesn't necessarily > have to be > on pacman's code itself. Just so we make this transition as painless as > possible to users. Having a seamless transition to the

Re: [arch-dev-public] Use detached package signatures by default

2020-07-28 Thread Anatol Pomozov via arch-dev-public
Hi On Wed, Jul 8, 2020 at 8:22 PM Allan McRae via arch-dev-public wrote: > > On 9/7/20 1:05 pm, Anatol Pomozov wrote: > > Given this information I would like to propose to stop using embedded > > signatures and move to detached signatures by default. This will > > require pacman 6.x or as

Re: [arch-dev-public] Use detached package signatures by default

2020-07-09 Thread Anatol Pomozov via arch-dev-public
Hi Jelle On Thu, Jul 9, 2020 at 2:00 AM Jelle van der Waa wrote: > > On 09/07/2020 05:05, Anatol Pomozov via arch-dev-public wrote: > > TLDR; let’s start using detached package signatures to make system > > updates faster. > > > > Hi folks, > > > > S

[arch-dev-public] Use detached package signatures by default

2020-07-08 Thread Anatol Pomozov via arch-dev-public
TLDR; let’s start using detached package signatures to make system updates faster. Hi folks, Some time ago there was a discussion at IRC where someone (Allan maybe?) proposed to stop using embedded PGP signatures in favor of detached signature files. I would like to bring this idea here and

Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS

2020-04-30 Thread Anatol Pomozov via arch-dev-public
Hi Morten On Sun, Apr 19, 2020 at 3:32 PM Morten Linderud via arch-dev-public wrote: > > Yo! > > After being lazy for a few weeks, I got around to writing the new guidelines > for > Go packages. Currently it's a draft and I'd love if people read through it and > ack/nacked > >

Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS

2020-03-15 Thread Anatol Pomozov via arch-dev-public
Hello On Sun, Mar 15, 2020 at 12:24 PM Morten Linderud via arch-dev-public wrote: > > On Sun, Mar 15, 2020 at 12:09:07PM -0700, Anatol Pomozov via arch-dev-public > wrote: > > > Notice that `-mod=vendor` is also added to `GOFLAGS`. > > > > Most of th

Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS

2020-03-15 Thread Anatol Pomozov via arch-dev-public
Hi On Sun, Mar 15, 2020 at 12:16 PM Christian Rebischke via arch-dev-public wrote: > > On Sun, Mar 15, 2020 at 12:09:07PM -0700, Public mailing list for Arch Linux > development wrote: > > Hello Morten > > > > On Sun, Mar 15, 2020 at 5:38 AM Morten Linderud via arch-dev-public > > wrote: > > >

Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS

2020-03-15 Thread Anatol Pomozov via arch-dev-public
Hello Morten On Sun, Mar 15, 2020 at 5:38 AM Morten Linderud via arch-dev-public wrote: > > > # Introduction > > To enable PIE compilation, we have relied on a patched version of the go > compiler which has been distributed as `go-pie` since around 2017. However, > full > RELRO support for go

Re: [arch-dev-public] Todos for language specific rebuilds

2020-01-11 Thread Anatol Pomozov via arch-dev-public
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On 2020-01-12 at 00:04, arch-dev-public@archlinux.org wrote: > On 1/10/20 4:42 PM, Christian Rebischke via arch-dev-public wrote: > > Hi everybody, > > > > I would like to propose that we create todos for rebuilds of language > > specific

Re: [arch-dev-public] Todos for language specific rebuilds

2020-01-11 Thread Anatol Pomozov via arch-dev-public
Hello On Sat, Jan 11, 2020 at 6:58 AM Dave Reisner wrote: > > On Fri, Jan 10, 2020, 16:43 Christian Rebischke via arch-dev-public < > arch-dev-public@archlinux.org> wrote: > > > Hi everybody, > > > > I would like to propose that we create todos for rebuilds of language > > specific packages. > >

Re: [arch-dev-public] Semi-away till 2019

2019-09-06 Thread Anatol Pomozov via arch-dev-public
Hi On Tue, Sep 3, 2019 at 9:36 AM Bartłomiej Piotrowski via arch-dev-public wrote: > > Hi all, > > As I have free time shortage lately, I think it's fair to officially say > I will be in semi-away mode till 2019. I will try my best to keep up > with uncomplicated pkgver bumps for packages I

Re: [arch-dev-public] Moving gcc7 into [community] for CUDA

2018-05-29 Thread Anatol Pomozov via arch-dev-public
Hi > Agreed, we're moving in a net positive direction. We still have two > versions of gcc, but at least the old version is a *newer* old version. > > (We could name it gcc-cuda if that makes people happier?) gcc-cuda will probably introduce a lot of confusion. Let's use standard naming practice

[arch-dev-public] LLVM 6.0 rebuild

2018-03-16 Thread Anatol Pomozov via arch-dev-public
On Fri, Mar 16, 2018 at 6:20 AM, Arch Website Notification wrote: > The todo list "LLVM 6.0" has had the following packages added to it for which > you are a maintainer: > > > * community/crystal (x86_64) - > https://www.archlinux.org/packages/community/x86_64/crystal/ > >

Re: [arch-dev-public] PSA: third-party gems have been split from 'ruby' package

2018-03-02 Thread Anatol Pomozov via arch-dev-public
Hello There is actually another big third_party component that is currently shipped together with ruby package - rubygems. Rubygems is developed as a project [1] separately from ruby. Once in a while ruby developers check-in rubygems into their source tree [2]. And up until now we used ruby's

Re: [arch-dev-public] PSA: third-party gems have been split from 'ruby' package

2018-01-29 Thread Anatol Pomozov via arch-dev-public
Hi Christian On Mon, Jan 29, 2018 at 9:36 AM, Christian Rebischke wrote: > On Fri, Jan 26, 2018 at 04:36:32PM -0800, Public mailing list for Arch Linux > development wrote: >> Hello folks >> >> There been a packaging issue with 'ruby' package that annoyed me for a

[arch-dev-public] PSA: third-party gems have been split from 'ruby' package

2018-01-26 Thread Anatol Pomozov via arch-dev-public
Hello folks There been a packaging issue with 'ruby' package that annoyed me for a while. The problem comes from the fact that ruby-lang.org source tarballs contain ruby sources itself *and* some third party packages from rubygems.org. The third-party gems shipped by 'ruby' tarball are: minitest,

Re: [arch-dev-public] Stepping back as Arch Linux developer

2017-10-16 Thread Anatol Pomozov via arch-dev-public
Hi Daniel Thank for all the work you've done for Arch! It was please for me to work with you. Have fun with your new interests and offline activities. On Mon, Oct 16, 2017 at 10:17 AM, Daniel Isenmann wrote: > Hi there, > > that wasn't an easy decision, but after months

[arch-dev-public] fuse packages reorganization

2016-12-12 Thread Anatol Pomozov via arch-dev-public
Hi folks I want to give you heads up about fuse packages reorganization. fuse project had a major release recently - fuse v3 is officially out [1]. Following recommendations from the upstream project [1] I renamed package 'fuse' to 'fuse2' and added 'fuse3' package. Common files from these