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 'braggi
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,
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 completely and
> instead making r
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 L
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 in
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
> since there wasn't a revoke/d
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 stands out (for me,
> anywa
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 real
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 stand
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 upstream because of this bug i
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] https://sourceware.org/bugzilla/show_bug.cgi?id=21090
>
>> Plus
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 testsuite should be
> a bloc
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 is
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 | grep -A1 epoch
>>
>> For th
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 foll
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 res
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 need
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
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 i
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
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 it's
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 offici
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 con
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 t
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.
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
> ht
> 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 everybo
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,
> 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 ac
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 ad
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
> https://ITwrx.org
> @I
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 not do it?
> >
> no
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 the default? This i
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 ac
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
>issue
You are
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 Ar
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 would not cause an
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 implemented due to de
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 is
39 matches
Mail list logo
