Re: [arch-general] arch health

On Sun, 23 Apr 2017 10:00:23 +0200 (CEST), fnodeuser wrote: >there are a few AL TMs (team members), that wanted to become, >became, and still are AL TMs because they are selfish. > >these TMs are here, because they want to indirectly benefit >financially from this membership, and/or for the

[arch-general] arch health

ITwrx.org, health? AL is not an organism, it is an OS. what you meant to say is problems. yes, it is true. there are a few problems, but these problems were not caused by a lack of funds. these are the reasons there are problems: 1. there are a few AL TMs (team members), that wanted to become,

Re: [arch-general] arch health

i thint it should be easier to let people help mantainers in software packaging. 2017-04-20 2:22 GMT+02:00 Ralf Mardorf : > Hi, > > I would be concerned, if too many security features not everybody needs, > would become default. Why not dropping security features

Re: [arch-general] arch health

On Sat, Apr 22, 2017 at 12:05 AM, Carsten Mattner via arch-general < arch-general@archlinux.org> wrote: > > Yes it's easy to downgrade manually on a single machine, but my > suggestion is about repo maintainers having a mechanism to force > a downgrade via the index. This is less of an issue for

Re: [arch-general] arch health

On Fri, 21 Apr 2017 16:05:01 +, Carsten Mattner wrote: >In the past there have been just crashes or buggy behavior that >only got fixed with the version-next++ and until then arch had >to live with the broken and regressed version as the default >since there wasn't a revoke/downgrade via the

Re: [arch-general] arch health

On Fri, Apr 21, 2017 at 6:05 PM, Carsten Mattner via arch-general wrote: > In the past there have been just crashes or buggy behavior that > only got fixed with the version-next++ and until then arch had > to live with the broken and regressed version as the default >

Re: [arch-general] arch health

On Fri, Apr 21, 2017 at 12:09 PM, Guus Snijders wrote: > > If I may suggest a pain point: arch needs good support for > revoking packages and replacing with the previous version > if regressions are encountered. > > > From a user POV, that is something where Arch really

Re: [arch-general] arch health

Op 20 apr. 2017 19:56 schreef "Carsten Mattner via arch-general" < arch-general@archlinux.org>: If I may suggest a pain point: arch needs good support for revoking packages and replacing with the previous version if regressions are encountered. >From a user POV, that is something where Arch

Re: [arch-general] arch health

On 04/20/17 at 04:18pm, Storm Dragon via arch-general wrote: > Howdy, > I offered once to learn all the stuff needed to become a TU to help out with > package maintenance. The offer still stands, if someone is willing to talk > with, help with training, and finally sponsor me. The offer still

Re: [arch-general] arch health

2017/04/21 午前11:08 "Eli Schwartz via arch-general" < arch-general@archlinux.org>: On 04/20/2017 09:23 PM, Ivy Foster via arch-general wrote: > Francisco Barbee via arch-general wrote: > >> On 20 April 2017 at 10:32:32, Jelle van der Waa wrote: >>> PIE is blocked by

Re: [arch-general] arch health

On 04/20/2017 09:23 PM, Ivy Foster via arch-general wrote: > Francisco Barbee via arch-general wrote: > >> On 20 April 2017 at 10:32:32, Jelle van der Waa wrote: >>> PIE is blocked by upstream because of this bug iirc. [1] >>> [1]

Re: [arch-general] arch health

Francisco Barbee via arch-general wrote: > On 20 April 2017 at 10:32:32, Jelle van der Waa wrote: > > PIE is blocked by upstream because of this bug iirc. [1] > > [1] https://sourceware.org/bugzilla/show_bug.cgi?id=21090 > Plus nobody ever explained why minor bug in

Re: [arch-general] arch health

On 20-04-2017 23:37, Carsten Mattner wrote: > Bug has been reported in Arch's tracker and there's a companion > bug from someone else about ffmpeg2.8. It makes sense to report > in Arch first because arch has published 3.3 in testing and maybe > ffmpeg's version scheme is just convoluted and 3.3

Re: [arch-general] arch health

On Thu, Apr 20, 2017 at 8:27 PM, Mauro Santos via arch-general wrote: > On 20-04-2017 20:21, Ralf Mardorf wrote: >>> Have you reported the bug? If yes and the dev decides that it should be >>> reverted to a previous version there is a way to do it, see: >>> man pacman

Re: [arch-general] arch health

On 04/20/2017 03:51 PM, Francisco Barbee via arch-general wrote: >> Lack of time is not the issue, in fact, Allan has reviewed *lots* >> of pacman/makepkg patches, and merged lots of them, in the time he >> has refused to even consider these. > > That was the beginning but it seems you didn't

Re: [arch-general] arch health

On 20-04-2017 20:21, Ralf Mardorf wrote: >> Have you reported the bug? If yes and the dev decides that it should be >> reverted to a previous version there is a way to do it, see: >> man pacman | grep -A1 epoch > > For the sake of completeness: > > "Upstream or Arch? > [snip] > If Arch is not

Re: [arch-general] arch health

Howdy, I offered once to learn all the stuff needed to become a TU to help out with package maintenance. The offer still stands, if someone is willing to talk with, help with training, and finally sponsor me. The offer still stands. I could work on Arch related stuff several hours per week if

Re: [arch-general] arch health

 On 20 April 2017 at 16:21:21, Eli Schwartz via arch-general wrote: > Actually, Allan said he dislikes that concept entirely and refuses to > merge it at all because: > 1) CFLAGS+="-flto" should be set in makepkg.conf, not libmakepkg > 2) PGO will not be a thing because "I am not adding an option

Re: [arch-general] arch health

On Thu, 20 Apr 2017 20:00:13 +0100, Mauro Santos via arch-general wrote: >On 20-04-2017 18:56, Carsten Mattner via arch-general wrote: >> If I may suggest a pain point: arch needs good support for >> revoking packages and replacing with the previous version >> if regressions are encountered. Case

Re: [arch-general] arch health

On 20-04-2017 18:56, Carsten Mattner via arch-general wrote: > If I may suggest a pain point: arch needs good support for > revoking packages and replacing with the previous version > if regressions are encountered. Case in point ffmpeg 3.3. > 3.2.4 was fine and 2.8.11 is also fine but 3.3's muxer

Re: [arch-general] arch health

On Thu, 20 Apr 2017 17:56:19 +, Carsten Mattner wrote: >If I may suggest a pain point: arch needs good support for >revoking packages and replacing with the previous version >if regressions are encountered. Hi, IIRC a few downgrades happened already, but since it's a rolling release, IMO

Re: [arch-general] arch health

If I may suggest a pain point: arch needs good support for revoking packages and replacing with the previous version if regressions are encountered. Case in point ffmpeg 3.3. 3.2.4 was fine and 2.8.11 is also fine but 3.3's muxer corrupts files. It's not the first instance where I wished for

Re: [arch-general] arch health

On Thu, 20 Apr 2017 16:10:18 +0300, Francisco Barbee wrote: >You can just ignore this topic instead of writing another post >about how much you don't need it. Hi, you completely missed my point. You ignore that in my opinion, in this context, it's not appropriate to argue with being "a little

Re: [arch-general] arch health

Not only could most of the concerns be successfully identified as Other People's Problems™, pepole are still very focused on email ettiquette. I think interpreting these two basic indicators about the health of Arch can left as an exercise for the reader. I'm not exactly sure what OP expected in

Re: [arch-general] arch health

On Thu, Apr 20, 2017 at 16:10:18 +0300, Francisco Barbee via arch-general wrote: > > IMO it's unhealthy to be in a hurry, apart from > this seemingly not everybody needs those security > features. > > [...] > > > Arch isn't ill, there seems to be no foreseeable > risk that Arch could become ill.

Re: [arch-general] arch health

On 04/20/2017 06:14 AM, Francisco Barbee via arch-general wrote: > It's 2017, security doesn't mean unoptimized. There was attempt to > bring in more optimizations already used in Clearlinux project like > pgo and lto to makepkg but it's still on sidelines due to lack of > time from devs. See >

Re: [arch-general] arch health

 > On 20 April 2017 at 14:07:54, Ralf Mardorf wrote: > Hi, are you in a hurry? Not at all. But I can imagine what feels someone who made effort to make things better by writing patches which are still ignored year after. > IMO it's unhealthy to be in a hurry, apart from this seemingly not

Re: [arch-general] arch health

On Thu, 20 Apr 2017 13:14:08 +0300, Francisco Barbee wrote: >There was attempt to bring in more optimizations >already used in Clearlinux project like pgo and >lto to makepkg but it's still on sidelines due to >lack of time from devs. Hi, are you in a hurry? IMO it's unhealthy to be in a hurry,

Re: [arch-general] arch health

> On 20 April 2017 at 03:23:04, Ralf Mardorf wrote: > I would be concerned, if too many security features not everybody needs, > would become default. Why not dropping security features completely and > instead making real-time optimised features the default? This is a > rhetorical question, but

Re: [arch-general] arch health

On 04/19/2017 07:22 PM, Ralf Mardorf wrote: > In my experiences Arch is very healthy. Taking the needed time to git it done correctly the first time is NOT an indication of poor health -- just the opposite. I would rather have packages stay in testing an additional 30 days and have all problems

Re: [arch-general] arch health

On 04/20/17 at 08:32am, Dragon ryu via arch-general wrote: > 2017/04/20 午前8:30 "ITwrx.org" : > > i'm a little concerned about arch's overall health and i was wondering > if there's anything we can do about it. > > why am i concerned? > > -- > Information Technology Works >

Re: [arch-general] arch health

On 04/19/17 at 06:55pm, ITwrx.org wrote: > On 04/19/2017 06:32 PM, Dragon ryu via arch-general wrote: > > 2017/04/20 午前8:30 "ITwrx.org" : > > > > > > > > Wait, actual question is about PIE? > > If you find that package are outdated in community or extra, file a bug rep. > > Why

Re: [arch-general] arch health

2017/04/20 午前9:42 "ITwrx.org" : On 04/19/2017 07:22 PM, Ralf Mardorf wrote: > Hi, > > I would be concerned, if too many security features not everybody needs, > would become default. Why not dropping security features completely and > instead making real-time optimised features

Re: [arch-general] arch health

On 04/19/2017 07:22 PM, Ralf Mardorf wrote: > Hi, > > I would be concerned, if too many security features not everybody needs, > would become default. Why not dropping security features completely and > instead making real-time optimised features the default? This is a > rhetorical question, but

Re: [arch-general] arch health

On Wed, 19 Apr 2017 18:55:05 -0500, ITwrx.org wrote: >> 2017/04/20 午前8:30 "ITwrx.org" : >> >> i'm a little concerned about arch's overall health and i was >> wondering if there's anything we can do about it. >> >no, PIE is just one of the examples i listed of symptoms of a larger

Re: [arch-general] arch health

Hi, I would be concerned, if too many security features not everybody needs, would become default. Why not dropping security features completely and instead making real-time optimised features the default? This is a rhetorical question, but actually I would prefer the latter. In my experiences

Re: [arch-general] arch health

On 04/19/2017 06:32 PM, Dragon ryu via arch-general wrote: > 2017/04/20 午前8:30 "ITwrx.org" : > > i'm a little concerned about arch's overall health and i was wondering > if there's anything we can do about it. > > why am i concerned? > > Many users tested to demonstrate that PIE

Re: [arch-general] arch health

2017/04/20 午前8:30 "ITwrx.org" : i'm a little concerned about arch's overall health and i was wondering if there's anything we can do about it. why am i concerned? Many users tested to demonstrate that PIE would not cause an undue performance burden but it has still not been

[arch-general] arch health

i'm a little concerned about arch's overall health and i was wondering if there's anything we can do about it. why am i concerned? Many users tested to demonstrate that PIE would not cause an undue performance burden but it has still not been implemented due to dev's lack of time. Now said dev