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 concerned about the "overall health", but you only provide a vague diagnosis. A hiccup seldom is a symptom of sickness, but you even do not clearly describe a hiccup.

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 Arch is very healthy. I doubt that many packages are outdated. Right off the bat a few come to mind, e.g. claws-mail and clawsker but we had Easter holidays and some packages are already in testing. Other packages, such as e.g. ardour are out of date for a long time, but the maintainer explained why he has got no time for a while. Apart from this Ardour is niche software. Each of the outdated packages I noticed still build using ABS or AUR PKGBUILDs by just changing the version and skipping or changing the checksums or they require minimal additional editing, if so I usually drop a note to AUR comments, how to fix the issue. It's hard to find much more packages I consider really outdated. I noticed that some packages from official repositories are flagged out of date, a few minutes after upstream released a new version, so I wouldn't count those packages. In my experiences Arch is a healthy rolling release. There are a few hiccups, but I experience less hiccups using Arch, than I experience serious issues with other distros. Regards, Ralf

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 is a rhetorical question, but actually I would prefer the latter.

In my experiences Arch is very healthy.

I doubt that many packages are outdated.

Right off the bat a few come to mind, e.g.

claws-mail and clawsker

but we had Easter holidays and some packages are already in testing.

Other packages, such as e.g.

ardour

are out of date for a long time, but the maintainer explained why he has got no time for a while. Apart from this Ardour is niche software.

Each of the outdated packages I noticed still build using ABS or AUR PKGBUILDs by just changing the version and skipping or changing the checksums or they require minimal additional editing, if so I usually drop a note to AUR comments, how to fix the issue.

It's hard to find much more packages I consider really outdated. I noticed that some packages from official repositories are flagged out of date, a few minutes after upstream released a new version, so I wouldn't count those packages.

In my experiences Arch is a healthy rolling release. There are a few hiccups, but I experience less hiccups using Arch, than I experience serious issues with other distros.

Regards, Ralf

thanks for your input. i'm not saying Arch isn't great. I use it for everything and it would take a whole lot for that to change. I just want the healthiest Arch possible. I think that Arch could have a few different "build profiles" if it was possible to automate packaging a little or if there were more devs or devs had more time to allocate to Arch because they were getting paid. Or, if the donation system were modernized, Arch could fund it's priorities in that regard and maybe people choose your goals instead of mine. Well, Arcg standard is Keep It Simple, mate.

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 actually I would prefer the latter.

Did you know those security features were extensively tested for performance, with many peoples involved? See: https://github.com/pid1/test-sec-flags/wiki 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 https://aur.archlinux.org/packages/makepkg-optimize2/

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

On 20 April 2017 at 10:43:03, David C. Rankin wrote: Taking the needed time to git it done correctly

Did you know this bug was reported by concerned user because dev hadn't time for it for a half of year? Plus nobody ever explained why minor bug in testsuite should be a blocker here. Also there are more security flags to be enabled, trivial to add and blocked only by lack of time/lack of will, even when other devs explicitly asked for this. 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 addressed than have it called "good enough" in some arbitrary rush that results in more problems and bug reports down the line.

I agree with the above but it's not the case here. Packages doesn't stay in testing for extended period because actual problems are resolved but because everyone who did his/her job has to wait for someone who didn't. See https://www.archlinux.org/todo/openssl-rebuild-take-2/ . Everything is done except one package and nothing changed for weeks. It's not about blaming anyone because I believe everybody do what they can. It's about finding a way to help those who struggle. When some users are asking about how they can help, answering WE DON'T NEED HELP isn't very appropriate. Even if you don't care at all about it please don't try to discourage those who care.

 > On 20 April 2017 at 14:07:54, Ralf Mardorf wrote:

Hi, are you in a hurry?

IMO it's unhealthy to be in a hurry, apart from

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. this seemingly not everybody needs those security features. Some people need them, some don't. You can just ignore this topic instead of writing another post about how much you don't need it.

Arch isn't ill, there seems to be no foreseeable risk that Arch could become ill. If somebody should really experience some illness, then please don't be vague, post a pointer to the illness.

I only claim that I don't experience illness and

OP already mentioned few things. You can look into https://www.archlinux.org/todo/ and https://lists.archlinux.org/listinfo/arch-dev-public to see how many things are need to be done. One example is abs which wasn't maintained for years. that my impression is, that Arch is distinctly healthy. In my experience more healthy, than any other distro I experience/experienced. It's not really about being healthy but being healthier

Imagine everybody who wants something, Arch doesn't provide, would argue with being "a little concerned about arch's overall health", to get it into Arch.

Enabling those flags was already decided by devs regardless how much you hate it. It's lack of execution which is concern here. Maybe bigger issue than Arch health is attitude of some people who're trying hard to water-down any attempt to make things better. If you don't need any help let others help those who need it.

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 this thread, but it's definitely entertaining. I'll quote the original email's contents fragmentally to spare you the whole pain. On Thu, Apr 20, 2017 at 1:29 AM, ITwrx.org wrote:

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?

Oh come on. You're making a case against your flawed judgment with such polemic.

[...] I sent a message to SPI's web dev email asking about improvements to project's pages but i haven't heard back.

Would you mind to share the content of these emails? Your argument seems suspicious and can't be verified as long as the content of your scripture is in absence.

[...blah...money...blah...]

Money definitely is an important factor. We're all using arch for the money. cheers! mar77i

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 official revoke and replace in the index instead of manual user intervention.

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 corrupts files. It's not the first instance where I wished for official revoke and replace in the index instead of manual user intervention.

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 -- Mauro Santos

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 responsible for a bug, the problem will not be solved by reporting the bug to Arch developers." - https://wiki.archlinux.org/index.php/Reporting_bug_guidelines#Upstream_or_Ar...

This policy isn't always pleasant ;), but the Arch developers sometimes are willing to balance pros and cons, so sometimes they fix such issues ;).

Maybe I should have been more specific, I was talking about downgrading/reverting an update. That is why the epoch field exists and it has been used before. Ffmpeg does have the mark of shame already so I suppose sometime in the past it has been necessary to do a downgrade. In the case where the bug comes from upstream one should report it upstream, but if it is something "serious" you have to report it in Arch's bug tracker, the maintainer does not have a crystal ball to know some nasty bug reared its head. -- Mauro Santos

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 unstable while 2.8 and 3.2 (even numbers) were stable branches. ffmpeg.org doesn't label 3.3 as a dev branch so I don't blame arch for picking ffmpeg3.3. In fact it says 3.3 is a stable release.

In case of doubt you should ask upstream, doesn't mean it has to be a bug report right away, you can start by asking in a mailing list. If it turns out it really is a nasty bug then opening a bug in arch's bug tracker for the current affected version is the way to go to get the attention of the maintainer. Obviously you should provide links to upstream's bug report or mailing list thread.

The corruption is easy to reproduce and so obvious that I didn't consider reporting it to ffmpeg.org. It looks impossible to slip their tests.

I haven't used ffmpeg directly very much so I don't know if there are any ways to shoot yourself in the foot, but you should consider that what is broken and easy to reproduce for you might just work™ for someone else. If upstream didn't catch it and no one else is complaining you have to consider the problem _could_ be in your setup.

I'm using ffmpeg 2.8.11 now, but since it's dangerous for other users to have their files corrupted, I think an official downgrade to 3.2.4 is in order.

If you've reported the bug both upstream and in arch's bug tracker and it turns out it really is a nasty bug it will most probably either get a downgrade or will be patched quickly (after upstream fixes it). -- Mauro Santos

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, anyway). My procedure was always: #cleanup, keep current versions pacman -Sc #update all pkg's pacman -Syu

And when I run into a buggy package, install the previous version from the cached pkgs. That usually did the trick.

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 LTS distros but important for non-testing users of Arch and other rolling distros. The package maintainer cannot know that 3.3 has a corruption bug and naturally trusts ffmpeg's announcement that 3.3 is a stable release. I did too and was surprised. It's my first ffmpeg surprise and usually ffmpeg is reliable. I bring this up as a good precedent to consider such a mechanism since corruption is the worst kind of regression. A crash is easy to notice and work around but had I not watched the muxed videos myself, I wouldn't have seen the corruption until the number of videos would have been painfully large to queue for remux/re-coding. 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 index. Since you can downgrade manually, the index ought to have mechanism for this too. Hope this makes sense.

On Fri, 21 Apr 2017 16:05:01 +0000, 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 index. Since you can downgrade manually, the index ought to have mechanism for this too. Hope this makes sense.

There already were "local is newer than" packages by official repositories, IOW a new version of a package was provided by an update and later an older version was provided. I don't remember an example, but it definitively already happened. However, those concerns about Arch's health are grotesque. Please open a new thread for the ffmpeg topic and post the links to the upstream bug report and to the Arch bug report. If you want to avoid that others experience the same issue, this is the way to go. On Fri, 21 Apr 2017 00:00:12 +0100, Mauro Santos via arch-general wrote:

If you've reported the bug both upstream and in arch's bug tracker and it turns out it really is a nasty bug it will most probably either get a downgrade or will be patched quickly (after upstream fixes it).

At least upstream would fix it. Bugs are something normal, even bugs that require to restore data from backups, because the original data gets corrupted. Sometimes software upgrades require to convert data for usage with the new software version, so even when downgrading the software, the data needs to be restored from a backup. Hiccups aren't something that serious as Heartbleed was. Even if _one_ bug should be very dangerous, it wouldn't make sense to add a new revoke/downgrade feature, just for a single bug.

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 https://aur.archlinux.org/packages/makepkg-optimize2/

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 to makepkg that does non-deterministic optimisation." 3) PGO that involves makepkg being context-sensitive between two makepkg runs, is not an option; use a wrapper script with multiple makepkg.conf's instead. 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.

Did you know this bug was reported by concerned user because dev hadn't time for it for a half of year? Plus nobody ever explained why minor bug in testsuite should be a blocker here. Also there are more security flags to be enabled, trivial to add and blocked only by lack of time/lack of will, even when other devs explicitly asked for this.

Failing testsuites mean that real issues will never be discovered, which means the whole point of running testsuites is nullified. So no, it is not a minor bug.

I agree with the above but it's not the case here. Packages doesn't stay in testing for extended period because actual problems are resolved but because everyone who did his/her job has to wait for someone who didn't. See https://www.archlinux.org/todo/openssl-rebuild-take-2/ . Everything is done except one package and nothing changed for weeks.

I don't know why openssl 1.1 is still in testing. But I do know that merely assuming it is ready to be moved today except for that package, is rather naive. I am going to assume that the Devs have actual reasons for what they do. Also, if your only point is that testing rebuilds get held up, I am not sure what you expect us to do about it. Whatever the reason is, that can only be fixed by the Devs, we have no influence over it in any way. And if they are deliberately ignoring it for the lulz, your bribes won't work; I guess we are just doomed by malice... ... Aside: your emails seem to be wrapped in an over-aggressive manner, why such short lines? -- Eli Schwartz

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 needed. I have a few packages I would move from the AUR, but not a ton, so I could addopt things that are orphaned, and help wherever needed. Of course, I'm just as happy maintaining my stuff in the AUR, but if I can help, I will. Storm -- Happy 4/20! Puff puff give! Powered by Arch Linux! I am registered Linux user number 508465: https://linuxcounter.net/user/508465.html My blog, Thoughts of a Dragon: http://www.stormdragon.tk/ get my public PGP key: gpg --keyserver wwwkeys.pgp.net --recv-key 43DDC193 Twitter and Facebook are so ... yesteryear. Get your 2MB Social account TODAY! http://2mb.social/main/register Need a safe and easy way to backup and share files? Try Dropbox: http://db.tt/jeY50HR "with a trunk big enough to fit three bodies in" Calabrese - Crizila

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 follow the discussion, see: https://lists.archlinux.org/pipermail/pacman-dev/2016-April/021028.html https://bbs.archlinux.org/viewtopic.php?pid=1628371#p1628371

I remember that. A badly-written patch for something far more generic, that Allan agreed he would be potentially willing to merge, but which really needs to be fixed and which anyway does not implement PGO, LTO, or anything similar (since Allan continues to believe that libmakepkg should not do this even if thirdparty libmakepkg extensions do). Maybe Allan would merge the stub for extending buildenv, if someone who actually cared would fix it. In the meantime, once again there are wrapper scripts...

...

Failing testsuites mean that real issues will never be discovered, which means the whole point of running testsuites is nullified. So no, it is not a minor bug.

Sorry, but that's pure speculation. Did you asked upstream if this bug is serious or the actual maintainer ask them? If one Arch user didn't report it it would be never fixed.

It is completely irrelevant whether upstream thinks testsuite failures are serious bugs. What matters is, the Arch maintainer for binutils *absolutely refuses* to enable anything that causes testsuite failures. It *has* been reported upstream. It hasn't been fixed yet, AFAIK.

...

I don't know why openssl 1.1 is still in testing. But I do know that merely assuming it is ready to be moved today except for that package, is rather naive. I am going to assume that the Devs have actual reasons for what they do.

Again you speculate. I've seen to many times maintainers forget about their packages for months until other devs name them explicitly in arch-dev mailinglist.

I am speculating just as much as you are speculating, so how about we compromise and *both of us* shut up? :D

...

Aside: your emails seem to be wrapped in an over-aggressive manner, why such short lines?

I'm very sorry. I was annoyed that discussion is moving out of topic. That was inappropriate

I am not even sure what the text formatting options of your email software has to do with your emotional state of mind regarding this thread. This is a purely software-related matter! Regardless... you are still doing it. Please fix your software or use something that isn't broken, because it is difficult to read what you write when my email software (Thunderbird) renders your email as completely mangled. It appears that whatever you are using, is breaking every line in two. Which is irritating in your replies (because super-short lines are awkward) and downright broken in your quotes, because every other line gets *unquoted*. (I have extensively edited my own quotes, to ensure proper quoting levels and line-wrapping. This is quite tiresome...) -- Eli Schwartz

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 nobody ever explained why minor bug in testsuite should be a blocker here.

Because binutils is a vital system component that it is very, very important to have working. It's one of those programs whose tests you absolutely do not want failing, since you're subsequently using it to link, well, *everything*.

Excuse me, are we or are we not a distro which prides itself on the fact that we live on the bleeding (straight) edge??? Just ask phrik: 10:05:03 PM - eschwartz: archlinux 10:05:05 PM - phrik: Livin' life on the hemorrhaging edge! I've changed my mind -- we should immediately enable PIE. :p :p -- Eli Schwartz

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 @ITwrxorg

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?

Can you please fix your client to reply sanely and not append your own text to the original mail it's confusing and silly. And again don't file bug reports for out of date packages.. -- Jelle van der Waa