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 also resigning from packaging due to it becoming a chore. Is PIE on the menu of the adopter of those packages?
There are also many official packages that have been out of date for a while. At least one of the devs seems to have too many packages to maintain. Probably because packages were orphaned and someone had to pick up the slack. There are probably many packages in aur that should be moved to official if there were devs who had time to deal with them. There are probably some bugs that need to be fixed too. Maybe we can use some % of donations to pay a dev/devs? Can we modernize the donations system? I sent a message to SPI's web dev email asking about improvements to project's pages but i haven't heard back.
IMHO, a general donate method doesn't cut it. Crowd funding should demonstrate clearly that people will donate much more when they have input and can see goals, progress, etc. Donors and devs should be able to designate goals (devs could have approval/veto power) and/or donors should be able to donate towards approved goals. It would be nice if we could fund developers or maybe just a rewards pool where devs get some appreciation money each month. Crypto currency could be an option. Devs could choose what they want to receive. If nothing else, maybe we could crypto tip individually or to an Arch address. Some way to make arch development more practical for people. I know in the past arch devs have said roughly that "he who does the dev makes the decisions" but maybe us users can buy our way in just enough to influence the speed or goals of the distro's dev? It doesn't seem like the current state of things can keep up with threats, new features, etc. I think i am not alone in being willing to pitch in money, when i can, to make it easier or more worthwhile for devs, new or current. At least we could see what the current funding levels for goals were so we would know if more needs to be done. Some other distros have large corps that can foot the bill to get things done. I'm sure Arch could use some help too, even if we already have donation funds for infrastructure needs.
thanks
2017/04/20 午前8:30 "ITwrx.org" info@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 dev's lack of time. Now said dev is also resigning from packaging due to it becoming a chore. Is PIE on the menu of the adopter of those packages?
There are also many official packages that have been out of date for a while. At least one of the devs seems to have too many packages to maintain. Probably because packages were orphaned and someone had to pick up the slack. There are probably many packages in aur that should be moved to official if there were devs who had time to deal with them. There are probably some bugs that need to be fixed too. Maybe we can use some % of donations to pay a dev/devs? Can we modernize the donations system? I sent a message to SPI's web dev email asking about improvements to project's pages but i haven't heard back.
IMHO, a general donate method doesn't cut it. Crowd funding should demonstrate clearly that people will donate much more when they have input and can see goals, progress, etc. Donors and devs should be able to designate goals (devs could have approval/veto power) and/or donors should be able to donate towards approved goals. It would be nice if we could fund developers or maybe just a rewards pool where devs get some appreciation money each month. Crypto currency could be an option. Devs could choose what they want to receive. If nothing else, maybe we could crypto tip individually or to an Arch address. Some way to make arch development more practical for people. I know in the past arch devs have said roughly that "he who does the dev makes the decisions" but maybe us users can buy our way in just enough to influence the speed or goals of the distro's dev? It doesn't seem like the current state of things can keep up with threats, new features, etc. I think i am not alone in being willing to pitch in money, when i can, to make it easier or more worthwhile for devs, new or current. At least we could see what the current funding levels for goals were so we would know if more needs to be done. Some other distros have large corps that can foot the bill to get things done. I'm sure Arch could use some help too, even if we already have donation funds for infrastructure needs.
thanks
-- 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?
On 04/19/2017 06:32 PM, Dragon ryu via arch-general wrote:
2017/04/20 午前8:30 "ITwrx.org" info@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 dev's lack of time. Now said dev is also resigning from packaging due to it becoming a chore. Is PIE on the menu of the adopter of those packages?
There are also many official packages that have been out of date for a while. At least one of the devs seems to have too many packages to maintain. Probably because packages were orphaned and someone had to pick up the slack. There are probably many packages in aur that should be moved to official if there were devs who had time to deal with them. There are probably some bugs that need to be fixed too. Maybe we can use some % of donations to pay a dev/devs? Can we modernize the donations system? I sent a message to SPI's web dev email asking about improvements to project's pages but i haven't heard back.
IMHO, a general donate method doesn't cut it. Crowd funding should demonstrate clearly that people will donate much more when they have input and can see goals, progress, etc. Donors and devs should be able to designate goals (devs could have approval/veto power) and/or donors should be able to donate towards approved goals. It would be nice if we could fund developers or maybe just a rewards pool where devs get some appreciation money each month. Crypto currency could be an option. Devs could choose what they want to receive. If nothing else, maybe we could crypto tip individually or to an Arch address. Some way to make arch development more practical for people. I know in the past arch devs have said roughly that "he who does the dev makes the decisions" but maybe us users can buy our way in just enough to influence the speed or goals of the distro's dev? It doesn't seem like the current state of things can keep up with threats, new features, etc. I think i am not alone in being willing to pitch in money, when i can, to make it easier or more worthwhile for devs, new or current. At least we could see what the current funding levels for goals were so we would know if more needs to be done. Some other distros have large corps that can foot the bill to get things done. I'm sure Arch could use some help too, even if we already have donation funds for infrastructure needs.
thanks
-- 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?
no, PIE is just one of the examples i listed of symptoms of a larger issue that i thought might could be helped by paying devs and modernizing the donation system. why would i file a bug for an out of date package? i'm sure the developer is notified when a package is flagged? why should i pester them to update it?
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
On Wed, 19 Apr 2017 18:55:05 -0500, ITwrx.org wrote:
2017/04/20 午前8:30 "ITwrx.org" info@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.
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.
2017/04/20 午前9:42 "ITwrx.org" info@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 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" info@itwrx.org:
<snip>
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, PIE is just one of the examples i listed of symptoms of a larger issue that i thought might could be helped by paying devs and modernizing the donation system.
PIE is blocked by upstream because of this bug iirc. [1]
why would i file a bug for an out of date package? i'm sure the developer is notified when a package is flagged? why should i pester them to update it?
You don't and it's counterproductive, just flag it out of date. Currently you might experience packages being updated a lot slower since we have a lot of big invasive rebuilds; OpenSSL 1.1, LLVM 4.0. Especially the OpenSSL rebuild was painful and time consuming.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=21090
On 04/20/17 at 08:32am, Dragon ryu via arch-general wrote:
2017/04/20 午前8:30 "ITwrx.org" info@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..
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 addressed than have it called "good enough" in some arbitrary rush that results in more problems and bug reports down the line.
Since the infighting of systemd and the libc move have been relegated to history, I haven't seen any indication of ill heath since that time. (having to build php56 from AUR is a bit of a pain, but that too is no indication of any ill health in the distro...
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
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.
On 20 April 2017 at 10:43:03, David C. Rankin
wrote:
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 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 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, 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.
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 that my impression is, that Arch is distinctly healthy. In my experience more healthy, than any other distro I experience/experienced.
YMMV!
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.
Regards, Ralf
Regards, Ralf
> 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 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.
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.
I only claim that I don't experience illness and
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.
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?
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. 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
that my impression is, that Arch is distinctly healthy. In my experience more healthy, than any other distro I experience/experienced.
[...]
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.
Hello, this is unrelated, but it appears that your MUA or MTA screws up the formatting of your mails, making it difficult to follow this conversation, as I have to figure out for each line whether it's part of a quote or not.
Also, it's hard to read, like in this example:
On Thu, Apr 20, 2017 at 13:14:08 +0300, Francisco Barbee via arch-general wrote:
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.
Would you mind finding out why that is so, and try to fix that? Thank you in advance!
Best, Tinu
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 info@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
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 concerned about arch's overall health", while there is no causal indication for even a hiccup.
I'm not necessarily against pathos (I'm not using the term "polemic"). Pathos is a very good tool when making art, but it's not good when trying to get something into a distro, that seemingly already was rejected.
Regards, Ralf
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 Thu, 20 Apr 2017 17:56:19 +0000, 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 understandable, that this can't be done that easy as for release model distros with a freeze, since there are dependency chains and Arch tries to follows upstream when ever possible, without patching "stable" releases from upstream. If such a hiccup happens, we could report bugs upstream and temporarily downgrade [1], or if necessary, rebuild packages against new dependencies using PKGBUILDs from ABS [2].
I sometimes build with fixes from upstream, e.g. git commits, that aren't official released as a new version, without adding "-git" or similar to the package, so next time a stable version is released, the upgrade happens automatically. At the moment I'm doing this for jack2 [3].
Until now nobody claimed that Arch Linux is perfect, free from any hiccups. It's just "pathetic" or "polemic" to imply that Arch tends to become less healthy. If an issue happens, we need to establish a differential diagnosis, instead of careless diagnosing a disease.
There are no doubts that hiccups happen from time to time, but the advantage of Arch is, that it does follow upstream as simple and close as possible, so it's much easier to fix an issue temporarily on your own, perhaps with help from the community, than it could be done for most other distros.
The more features Arch developers would add by default, the more prone Arch would become to make fixing it harder, if an issue does arise for your domain/usage.
My domain is real-time audio and I prefer Arch not because it's perfect by default, but because it's perfect to fix issues even for niches. A lot of other distros are optimised for different usages. There are without doubts needs, that require really long term support, where restoring from a backup isn't an option. IMO Arch is good for a specific target group, but maybe not good for all purposes.
Any unreasonable changes won't improve Arch. Until now we only know that somebody guess that too many packages are outdated and some features aren't provided, because it's presumed that Arch developers don't have the time/money to do the work.
I'm not a developer, so I won't judge this claim. However, until now no developer agreed that there is a lack of money and time. At least not by such an amount, that Arch danger threatens.
I don't know, but until not several users confirm that Arch's overall health is fishy, we should assume that Arch is in good shape.
Just my 2 Cents, Ralf
[1] https://aur.archlinux.org/packages/downgrade/ [2] https://www.archlinux.org/packages/extra/x86_64/abs/ [3] [rocketmouse@archlinux ~]$ pacman -Si jack2 | grep Ver Version : 1.9.10-6 [rocketmouse@archlinux ~]$ pacman -Q jack2 jack2 1.9.10.r261.g2d1d3235-1
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
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 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
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 ;).
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:
- CFLAGS+="-flto" should be set in
makepkg.conf, not libmakepkg
- 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.
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
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.
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.
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
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
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.
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...)
On Thu, Apr 20, 2017 at 8:27 PM, Mauro Santos via arch-general arch-general@archlinux.org 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 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.
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.
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'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.
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).
Francisco Barbee via arch-general arch-general@archlinux.org 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*.
if
On 04/20/2017 09:23 PM, Ivy Foster via arch-general wrote:
Francisco Barbee via arch-general arch-general@archlinux.org 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
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 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 --
You can start by going through the bugtracker, there are plenty of bugs which need to be triaged, reported upstream or potential fixes in packaging which in the form of patches can be created and attached to a bug.
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 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.
The important part is to only cleanup right before an upgrade.
Of course, this in itself does nothing for the packages in the repro, but my users can happily keep working :).
The bugged pkg needs a report, of course, but usually someone has already reported it by the time I see it.
Mvg, Guus Snijders (With apologies for the messy HTML)
On Fri, Apr 21, 2017 at 12:09 PM, Guus Snijders gsnijders@gmail.com 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, Apr 21, 2017 at 6:05 PM, Carsten Mattner via arch-general arch-general@archlinux.org 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.
Such a feature would mean all dependencies would be flagged for downgrades too, except when two packages a package depends on have been upgraded. then an intermediate version with package A_old and B_new. That should even be possible in the *usual* case, but we *would* need a plan for when that wasn't possible, which would mean forcing downgrade of package B because A_new cannot be satisfied because package C depends on either being compatible, and we're kind of dissolving the foundations of KISS on which arch is built. See what I mean?
cheers! mar77i
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 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 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.
They do, it's called the epoch (see man PKGBUILD).
i thint it should be easier to let people help mantainers in software packaging.
2017-04-20 2:22 GMT+02:00 Ralf Mardorf silver.bullet@zoho.com:
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
arch-general@lists.archlinux.org