Discussion:
Tobias Powalowski and his nonsensical maintenance decisions
(too old to reply)
fnodeuser
2017-04-28 12:40:42 UTC
Permalink
Raw Message
Tobias Powalowski,

you continue to place pkgs in the testing repo that do not require any further testing.

for what reasons, exactly, do the linux 4.10.13 and hwids 20170328 pkgs need to be in
testing for 4+ days?

also, you did not replace git:// with git+https:// in the hwids PKGBUILD file. github
has HTTPS enabled for everything.
Florian Pritz via arch-general
2017-04-28 13:21:32 UTC
Permalink
Raw Message
Post by fnodeuser
you continue to place pkgs in the testing repo that do not require any further testing.
Thank you for showing that you do not understand our repository policy.

All [core] packages go to [testing] first to ensure that we do not
completely break anyone's system. This has happened before and funnily
enough it happened with a kernel that did not boot for anyone. Because
of this [testing] has been created. You really managed to come up with
the best example here.
Post by fnodeuser
for what reasons, exactly, do the linux 4.10.13 and hwids 20170328 pkgs need to be in
testing for 4+ days?
I am not sure on which planet you live and how many hours a day has for
you, but on Earth those packages have been in testing for roughly 7
hours (2017-04-28 07:57 UTC and 2017-04-28 08:17 UTC).

As for the reasoning, see above.
Post by fnodeuser
also, you did not replace git:// with git+https:// in the hwids PKGBUILD file. github
has HTTPS enabled for everything.
While this specific suggestion is correct, the way it has been presented
here and in the past is not. Context matters, and if you annoy people
they will stop listening to you.

I have put you on moderation. If you continue annoying us like this
there will be further consequences. Consider this your final warning.
There will not be another.

Florian
Genes Lists via arch-general
2017-04-28 13:41:56 UTC
Permalink
Raw Message
   1) Tobias: Thank you for doing a terrific and diligent job packaging
and testing kernels and, which come into testing in short order.

   2) Florian: Thank you for your comments - agree completely.

   3) Adding to what Florian said - Testing also allows Arch users to
signoff after performing their own testing which strengthens the program by adding broader testing across different systems.
--
Gene
***@sapience.com
Martin Kühne via arch-general
2017-04-28 15:13:50 UTC
Permalink
Raw Message
Today is the 28th, and the date reported by pacman is the 27th.
Suggestion to OP:

# ntpdate your.favorite.mirror.ntp.org

Because to me it just looks like he might be a few multiples of 86400
seconds off.

On a similar note, I wonder why you didn't complain that the new ELF
binary was apparently built on Thu Jan 1 01:00:00 1970 :)

cheers!
mar77i
Eli Schwartz via arch-general
2017-04-30 01:58:32 UTC
Permalink
Raw Message
Post by Florian Pritz via arch-general
I have put you on moderation. If you continue annoying us like this
there will be further consequences. Consider this your final warning.
There will not be another.
Florian,

Well, as you can see from
https://lists.archlinux.org/pipermail/arch-general/2017-April/043634.html
that didn't work so well...


This is an ongoing problem with this person and that website, see for
example:
https://lists.archlinux.org/pipermail/arch-general/2016-December/042780.html
https://lists.archlinux.org/pipermail/arch-general/2016-December/042791.html

Every time he posts stuff to the mailing lists, he uses disposable email
addresses from binkmail.com, one of Mailinator's alternate domains (for
places that have sensibly blacklisted mailinator.com) which is a sign of
incredible ill faith in addition to willfully breaking thread flow.

If you want to moderate him, you will have to block the whole domain (as
I have requested multiple times before). This is a reasonable thing to
do and is no loss whatsoever, because again, binkmail.com is nothing but
an alternate domain for a *disposable email address* service.
--
Eli Schwartz
Carsten Mattner via arch-general
2017-04-28 16:29:53 UTC
Permalink
Raw Message
Post by fnodeuser
Tobias Powalowski,
you continue to place pkgs in the testing repo that do not require any further testing.
for what reasons, exactly, do the linux 4.10.13 and hwids 20170328
pkgs need to be in testing for 4+ days?
also, you did not replace git:// with git+https:// in the hwids
PKGBUILD file. github has HTTPS enabled for everything.
I have to get this off my chest, since the so called stable and lts
kernel branches have failed to deliver what their name may promise.

fnodeuser, I understand why you'd want kernel stable and lts updates
to be pushed to core quicker, but the reality is that the criteria for
what patches land in stable and even lts branches is lax. Like Florian
said, stuff breaks in stable in lts kernel releases regularly. I
myself don't understand why it's called stable or lts stable queue
when it isn't strictly critical fixes, but I'm not the maintainer of
the branches and may be missing the point.

<A small rant>

If you want a more stable kernel you can choose to use older lts
branches like 4.1 or 3.16. Those get fewer updates.

I mean, it doesn't help that Greg KH always appends the note

All users of the 4.10 kernel series must upgrade

while a stable kernel release adds regressions and random
refactorings, not just critical fixes. It doesn't make sense to me,
but the developers surely have their reasoning and customers to prove
it makes sense.

The constant churn of refactorings and whatnot makes it impossible for
all the hardware that say i915 supports to actually work reliably
across kernel releases. What used to work flawlessly in 4.1 can be
broken in 4.4 because the devs do not test with Intel GPUs older than
Gen7 for example, all the while claiming it's supported in the now
refactored but practically untested code.

It's not surprising that places with many Linux workstations run
CentOS (Pixar) or Scientific Linux (CERN) or Ubuntu oldest LTS (Google).

The main cause for the breakage is the linux kernel's desire to be
monolithic and carry all drivers in-tree as much as possible for
easier refactoring, which makes sense for developers but pushes users
in need of stability to CentOS. The problem with a system like CentOS
is that you can hope that a service pack release backports important
new features, but you cannot pick and choose. In an OS like FreeBSD or
Windows or a microkernel based system it's much easier and common to
have core pieces that change annually or less often at best and have
few modules that link against a stable ABI and can be fresh with new
features. Think nVidia's drivers on FreeBSD or Windows. Windows has
hopped onto the update often and break often train with version 10 but
they still have a stable ABI like FreeBSD.

The reality is that your hardware that worked in 4.10.3 can be broken
in 4.10.8. I regularly look at the diffs of stable releases and fail
to understand the selection process.

</A small rant>
Eric Blau
2017-04-28 17:11:37 UTC
Permalink
Raw Message
On Fri, Apr 28, 2017 at 12:29 PM, Carsten Mattner via arch-general
Post by Carsten Mattner via arch-general
The constant churn of refactorings and whatnot makes it impossible for
all the hardware that say i915 supports to actually work reliably
across kernel releases. What used to work flawlessly in 4.1 can be
broken in 4.4 because the devs do not test with Intel GPUs older than
Gen7 for example, all the while claiming it's supported in the now
refactored but practically untested code.
Carsten,

I agree with you about i915. I've been hitting this kernel panic
regularly, about once per day, freezing my entire machine:

Bug 99295 - [Regression BDW] kernel panic in Intel i915 module,
complete system freeze in 4.10-rc2
https://bugs.freedesktop.org/show_bug.cgi?id=99295

There's a fix that's been submitted to the tip, but no effort has been
made to patch the bug in the 4.10.x stable series. It seems the devs
don't care about having a stable kernel to use, only about moving
forward the tip and staying on the bleeding edge. Shouldn't at least
showstopper kernel panics be patched to the "stable" release?

I requested a fix on the tip to be patched in the 4.9.x stable series
a couple months ago because I tested the fix myself and verified it
"worked for me" but it was subsequently reverted. I'm sure I don't
know enough about the i915 driver to be able to make these types of
decisions about what should or should not be patched other than to
help with testing, but it would be nice if the i915 dev team made an
effort to propagate fixes to stable as well.

-Eric
Carsten Mattner via arch-general
2017-04-28 18:19:39 UTC
Permalink
Raw Message
Post by Eric Blau
On Fri, Apr 28, 2017 at 12:29 PM, Carsten Mattner via arch-general
Post by Carsten Mattner via arch-general
The constant churn of refactorings and whatnot makes it impossible
for all the hardware that say i915 supports to actually work
reliably across kernel releases. What used to work flawlessly in
4.1 can be broken in 4.4 because the devs do not test with Intel
GPUs older than Gen7 for example, all the while claiming it's
supported in the now refactored but practically untested code.
Carsten,
I agree with you about i915. I've been hitting this kernel panic
Bug 99295 - [Regression BDW] kernel panic in Intel i915 module,
complete system freeze in 4.10-rc2
https://bugs.freedesktop.org/show_bug.cgi?id=99295
There's a fix that's been submitted to the tip, but no effort has
been made to patch the bug in the 4.10.x stable series. It seems the
devs don't care about having a stable kernel to use, only about
moving forward the tip and staying on the bleeding edge. Shouldn't
at least showstopper kernel panics be patched to the "stable"
release?
I requested a fix on the tip to be patched in the 4.9.x stable
series a couple months ago because I tested the fix myself and
verified it "worked for me" but it was subsequently reverted. I'm
sure I don't know enough about the i915 driver to be able to make
these types of decisions about what should or should not be patched
other than to help with testing, but it would be nice if the i915
dev team made an effort to propagate fixes to stable as well.
It's possible that the fix causes other issues, but I've also seen
crash fixes take very long until landing in a stable release,
sometimes taking 2 or 3 releases, while refactorings are intertwined
with other fixes in stable releases. It looks odd.

On one machine where XFCE, GNOME3 and Weston work without errors, I've
seen Plasma to misbehave in its compositor so much that I couldn't get
it to open KDE settings for turning off compositing. An earlier
release of Plasma (4.x) used to work, so it's recently regressed. I
attributed all of this to massive amount of churn in applications and
the graphics stack without adequate GPU testing. It's great that we're
now at OpenGL 4.3 levels of support in Mesa for some Intel GPUs, but
when Plasma just doesn't render correctly, it's clear QA failed.

Another bug with i915 and intel gpu stack is that DRI3 was supposed to
solve all tearing issues and together with glamor one was supposed to
use just generic modesetting instead of xf86-video-intel. The reality
is that DRI2 with TearFree and AccelMethod SNA is the only reliable
tear free mode. In DRI3 anytime you start video playback with mpv you
can see how a small rectangle is resized to the final window size.
This doesn't happen with DRI2. Some distros started to use generic
modesetting by default, but I'd wager they didn't test for tearing and
other functionality regressions or are used to and don't care about
it. Since Wayland uses DRI3 by default, I've actually been able to
observe tearing in Sway Wayland compositor, though very seldom.

I wonder how the situation is with AMD and nVidia GPUs with open and
closed driver stacks.

It seems that if you run GNOME3 with GTK3 under Wayland and only GTK3
apps with GDK_BACKEND=wayland and no X app, then it works well, but
that's like forcing everyone to use just Android apps under ChromeOS.

With libweston and libweston-desktop and further fixes in Xwayland,
maybe 2018 we will finally have what Wayland promised very long ago. I
wouldn't blame outsiders if they looked at Linux Desktop and thought
that there's too many variants and too much change with little
stabilization going on.

Then there's outstandingly stable software like GNU Emacs, FVWM, xterm
or XMonad. Your config from a decade or two ago still works and with
minimal to none deprecation disruption.

So when it comes to open source video driver stacks, the best stragey
is running one of the last two generations of GPU (Broadwell and
Skylake) and always stay in thet range since older GPUs lose QA
coverage with new GPUs coming out. If the capabilities of a GPU are
clear and you cannot expect to have newer OpenGL support in a newer
Mesa, then it would make sense to have a stable but old i915 stack for
old GPUs that doesn't change vs new i915 stack for newer GPUs, but
Linux is a monolithic design without driver ABIs for good reasons that
show their disadvantage when QA is insufficient.
Carsten Mattner via arch-general
2017-04-28 18:20:52 UTC
Permalink
Raw Message
Eric, does it also fail in XFCE or GNOME3? Like I wrote, I've found
Plasma's compositor to be buggier.
Eric Blau
2017-04-28 18:34:15 UTC
Permalink
Raw Message
On Fri, Apr 28, 2017 at 2:20 PM, Carsten Mattner
Post by Carsten Mattner via arch-general
Eric, does it also fail in XFCE or GNOME3? Like I wrote, I've found
Plasma's compositor to be buggier.
I use i3 with compton as a compositor. Maybe I would have better luck
running 4.10.x without compton. I haven't tried that yet.

I reverted back to linux-lts which seems to be running fine on my
early 2015 MacBook Pro 12,x with the exception of a failed resume from
hibernate every once and a while.

-Eric
Carsten Mattner via arch-general
2017-04-28 20:00:21 UTC
Permalink
Raw Message
Post by Eric Blau
On Fri, Apr 28, 2017 at 2:20 PM, Carsten Mattner
Post by Carsten Mattner via arch-general
Eric, does it also fail in XFCE or GNOME3? Like I wrote, I've found
Plasma's compositor to be buggier.
I use i3 with compton as a compositor. Maybe I would have better luck
running 4.10.x without compton. I haven't tried that yet.
I use XMonad with compton but GTK3 only works smoothly with Mutter's
compositor or GDK's Wayland backend. Anything else flashes a black
rectangle for any new window. A compositor is supposed to be required
and enough, but compton or xfwm don't cut, though the glitch is less
prevalent under xfwm. Now that Firefox has removed GTK2 support 53,
there's no way around GTK3 anymore.
Post by Eric Blau
I reverted back to linux-lts which seems to be running fine on my
early 2015 MacBook Pro 12,x with the exception of a failed resume from
hibernate every once and a while.
Yeah or systemd requiring a newer kernel sometimes.
Eric Blau
2017-04-28 18:43:47 UTC
Permalink
Raw Message
On Fri, Apr 28, 2017 at 2:19 PM, Carsten Mattner
Post by Carsten Mattner via arch-general
Post by Eric Blau
On Fri, Apr 28, 2017 at 12:29 PM, Carsten Mattner via arch-general
There's a fix that's been submitted to the tip, but no effort has
been made to patch the bug in the 4.10.x stable series. It seems the
devs don't care about having a stable kernel to use, only about
moving forward the tip and staying on the bleeding edge. Shouldn't
at least showstopper kernel panics be patched to the "stable"
release?
I requested a fix on the tip to be patched in the 4.9.x stable
series a couple months ago because I tested the fix myself and
verified it "worked for me" but it was subsequently reverted. I'm
sure I don't know enough about the i915 driver to be able to make
these types of decisions about what should or should not be patched
other than to help with testing, but it would be nice if the i915
dev team made an effort to propagate fixes to stable as well.
It's possible that the fix causes other issues, but I've also seen
crash fixes take very long until landing in a stable release,
sometimes taking 2 or 3 releases, while refactorings are intertwined
with other fixes in stable releases. It looks odd.
Yes, agreed here. The fix I requested to be patched to 4.9.x when it
was the stable release back in the Feb/March timeframe was from
September 2016 but still hadn't made it into a stable release 5 or 6
months later.
Post by Carsten Mattner via arch-general
I wonder how the situation is with AMD and nVidia GPUs with open and
closed driver stacks.
I don't have these problems with a NVIDIA GeForce GTX 970 on my desktop machine.
Post by Carsten Mattner via arch-general
It seems that if you run GNOME3 with GTK3 under Wayland and only GTK3
apps with GDK_BACKEND=wayland and no X app, then it works well, but
that's like forcing everyone to use just Android apps under ChromeOS.
With libweston and libweston-desktop and further fixes in Xwayland,
maybe 2018 we will finally have what Wayland promised very long ago. I
wouldn't blame outsiders if they looked at Linux Desktop and thought
that there's too many variants and too much change with little
stabilization going on.
A big reason why Linux Desktop seems like a lost cause.
Post by Carsten Mattner via arch-general
Then there's outstandingly stable software like GNU Emacs, FVWM, xterm
or XMonad. Your config from a decade or two ago still works and with
minimal to none deprecation disruption.
I prefer stable software that lets me get my job done like i3, vim,
etc. I rarely have problems running the latest versions included in
Arch. The kernel is another story altogether. I frequently have to
switch between linux and linux-lts or build my own kernel with various
patches in order for my machines to run stable.
Post by Carsten Mattner via arch-general
So when it comes to open source video driver stacks, the best stragey
is running one of the last two generations of GPU (Broadwell and
Skylake) and always stay in thet range since older GPUs lose QA
coverage with new GPUs coming out. If the capabilities of a GPU are
clear and you cannot expect to have newer OpenGL support in a newer
Mesa, then it would make sense to have a stable but old i915 stack for
old GPUs that doesn't change vs new i915 stack for newer GPUs, but
Linux is a monolithic design without driver ABIs for good reasons that
show their disadvantage when QA is insufficient.
My 2015 Broadwell-based MacBook Pro is not that old, yet I have i915
issues with it almost kernel release.

-Eric
Carsten Mattner via arch-general
2017-04-28 20:11:08 UTC
Permalink
Raw Message
Post by Eric Blau
On Fri, Apr 28, 2017 at 2:19 PM, Carsten Mattner
Post by Carsten Mattner via arch-general
Post by Eric Blau
On Fri, Apr 28, 2017 at 12:29 PM, Carsten Mattner via arch-general
There's a fix that's been submitted to the tip, but no effort has
been made to patch the bug in the 4.10.x stable series. It seems the
devs don't care about having a stable kernel to use, only about
moving forward the tip and staying on the bleeding edge. Shouldn't
at least showstopper kernel panics be patched to the "stable"
release?
I requested a fix on the tip to be patched in the 4.9.x stable
series a couple months ago because I tested the fix myself and
verified it "worked for me" but it was subsequently reverted. I'm
sure I don't know enough about the i915 driver to be able to make
these types of decisions about what should or should not be patched
other than to help with testing, but it would be nice if the i915
dev team made an effort to propagate fixes to stable as well.
It's possible that the fix causes other issues, but I've also seen
crash fixes take very long until landing in a stable release,
sometimes taking 2 or 3 releases, while refactorings are intertwined
with other fixes in stable releases. It looks odd.
Yes, agreed here. The fix I requested to be patched to 4.9.x when it
was the stable release back in the Feb/March timeframe was from
September 2016 but still hadn't made it into a stable release 5 or 6
months later.
Wouldn't it be nice if all projects would communicate that a bug
is low priority and may not be fixed anytime soon unless you get
involved with a diff, although that's no guarantee it will be merged.

Some projects have bugs that affect only few users or are hard to fix
and are sitting in OPEN for a decade, but it's common that request
for status info is usually ignored. Other projects just close bugs
after a timeout, implying that it must be irrelevant now.
Post by Eric Blau
Post by Carsten Mattner via arch-general
I wonder how the situation is with AMD and nVidia GPUs with open and
closed driver stacks.
I don't have these problems with a NVIDIA GeForce GTX 970 on my desktop machine.
No tearing, nothing, without a need for special hacks/configs in X?
nVidia binary drivers?
Post by Eric Blau
Post by Carsten Mattner via arch-general
It seems that if you run GNOME3 with GTK3 under Wayland and only GTK3
apps with GDK_BACKEND=wayland and no X app, then it works well, but
that's like forcing everyone to use just Android apps under ChromeOS.
With libweston and libweston-desktop and further fixes in Xwayland,
maybe 2018 we will finally have what Wayland promised very long ago. I
wouldn't blame outsiders if they looked at Linux Desktop and thought
that there's too many variants and too much change with little
stabilization going on.
A big reason why Linux Desktop seems like a lost cause.
Politically it's hard to rectify since there are camps with
NIHism and recurring wheel reinventing without a stable API/ABI
path in many modules.

A Windows application written for Windows 2000 still works the
same, unless it used some borderline stuff, under Windows 10.

Qt is less affected by this since they have real world embedded
customers and cannot mess around that much like GTK3 with their
GNOME3 is the environment supported policy.
Post by Eric Blau
Post by Carsten Mattner via arch-general
Then there's outstandingly stable software like GNU Emacs, FVWM, xterm
or XMonad. Your config from a decade or two ago still works and with
minimal to none deprecation disruption.
I prefer stable software that lets me get my job done like i3, vim,
etc. I rarely have problems running the latest versions included in
Arch. The kernel is another story altogether. I frequently have to
switch between linux and linux-lts or build my own kernel with various
patches in order for my machines to run stable.
Exactly. I also prefer to have config files that work across generations
of a program and can be customized, transferred around. It's frightening
to see the reinventions and changes in KDE and GNOME config paths and
storage engines. To set GTK3's theme and font settings, you need to provide
it in settings.ini plus dconf binary db or else it will display correctly
either in X11 mode or Wayland mode. Under Wayland GTK3 zooms the widgets
instead of scaling them, which gives you blurred/washed-out windows.
GTK3 is like Windows 10. It fixed core issues for Wayland support, but
broke much functionality on the way.
Post by Eric Blau
Post by Carsten Mattner via arch-general
So when it comes to open source video driver stacks, the best stragey
is running one of the last two generations of GPU (Broadwell and
Skylake) and always stay in thet range since older GPUs lose QA
coverage with new GPUs coming out. If the capabilities of a GPU are
clear and you cannot expect to have newer OpenGL support in a newer
Mesa, then it would make sense to have a stable but old i915 stack for
old GPUs that doesn't change vs new i915 stack for newer GPUs, but
Linux is a monolithic design without driver ABIs for good reasons that
show their disadvantage when QA is insufficient.
My 2015 Broadwell-based MacBook Pro is not that old, yet I have i915
issues with it almost kernel release.
That sounds scary. Though I'm relieved to hear it's not just older
GPUs which go ignored or something like that.
David C. Rankin
2017-04-29 07:32:06 UTC
Permalink
Raw Message
Post by fnodeuser
Tobias Powalowski,
you continue to place pkgs in the testing repo that do not require any further testing.
for what reasons, exactly, do the linux 4.10.13 and hwids 20170328 pkgs need to be in
testing for 4+ days?
also, you did not replace git:// with git+https:// in the hwids PKGBUILD file. github
has HTTPS enabled for everything.
Given the original reply address -- I smell a troll...
--
David C. Rankin, J.D.,P.E.
Dragon ryu via arch-general
2017-04-29 07:55:12 UTC
Permalink
Raw Message
Post by fnodeuser
Tobias Powalowski,
you continue to place pkgs in the testing repo that do not require any further testing.
for what reasons, exactly, do the linux 4.10.13 and hwids 20170328 pkgs need to be in
testing for 4+ days?
also, you did not replace git:// with git+https:// in the hwids PKGBUILD file. github
has HTTPS enabled for everything.
Given the original reply address -- I smell a troll...

--
David C. Rankin, J.D.,P.E.

Uhm. I think topic are necro'd.
... I suggest close this thing, OP.
fnodeuser
2017-04-29 20:58:21 UTC
Permalink
Raw Message
i do not thank you for your conclusion jumping and for the censorship ("I have put you on moderation.").

you have disappointed me Florian.

time to set the record straight.
Florian Pritz,
1. i am not annoying, i am rational.
2. testing the stable minor releases makes no sense. we should be testing the release candidates of 4.11
since its stable release is nearing. that would actually be beneficial to the users. the placing of stable
minor releases in testing is only delaying the distribution of the fixes to the users.
also, AL users are expected to RTFM. AL is for advanced users and for people who are willing to learn how to
administrate their system(s).
3. he has known about it for many months. https://www.archlinux.org/todo/use-gpg-signatures-and-https-sources/
"Your message was deemed inappropriate by the moderator."
i know. it is so 'inappropriate' that Pope Francis would have died if he ever read it.

now, on to the rest.

about the '4+ days' thing. reread my message, carefully, because you have difficulties comprehending what i typed.
hint: it is about delaying things for no good reason.

two more maintenance examples, a recent Antonio Rojas one (once again, he edited today another imperfect PKGBUILD
file and left it imperfect), and a Sébastien Luttringer one (an example of stupidity):

https://git.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=packages/help2man&id=47e0c555b37f059be552a930a5da80130942d5a6
an md5 hash is still used and ftp.gnu.org is HTTPS-enabled. nevertheless, i must say that he has improved.

https://git.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=packages/btrfs-progs&id=c2dab0f16df636bb0ea94e54d7f116d5d1504e60
https://www.kernel.org/pub/linux/kernel/people/kdave/btrfs-progs/sha256sums.asc
he has learning difficulties.

Carsten Mattner,

yes, it is true. sometimes things break, but things can be fixed and there are ways to avoid breakage. RTFM and/or RTFW
is a requirement.[1] also, because of evolution, each one of us possess a brain that can do 'miracles' when it is actually
used. use it, people. i know that there are people for whom the activity of thinking is extremely painful, but we cannot
stop 'rolling' because of them.

in almost all cases it is the AL user's fault.

if one is careless and clueless, bad things can and do happen. that is true almost everywhere, not only in system administration.

-

"They see me rollin', They hatin'!" (AL is a rolling release distro, and we want to (rock and) 'roll' forever)

_
[1] https://wiki.archlinux.org/index.php/Pacman#Skip_package_from_being_upgraded
https://wiki.archlinux.org/index.php/Pacman#Skip_package_group_from_being_upgraded
https://wiki.archlinux.org/index.php/Pacman#Skip_files_from_being_installed_to_system


PS: Florian's censorship necessitated the use of a different address. any complaints about the message being out of the existing
threads are invalid and remarks about my disposable email address are irrelevant.

Florian, remove me immediately from 'moderation' to prove: 1. that you actually want to have an honest discussion about anything
and everything, 2. that you are a decent person.

PPS: whoever you are, you are so cute! port scanning my IP address yesterday, and today registering around with my name.
Dragon ryu via arch-general
2017-04-29 23:08:47 UTC
Permalink
Raw Message
2017/04/30 午前5:58 "fnodeuser" <***@binkmail.com>:

i do not thank you for your conclusion jumping and for the censorship ("I
have put you on moderation.").

you have disappointed me Florian.

time to set the record straight.
Florian Pritz,
1. i am not annoying, i am rational.
2. testing the stable minor releases makes no sense. we should be testing
the release candidates of 4.11
since its stable release is nearing. that would actually be beneficial to
the users. the placing of stable
minor releases in testing is only delaying the distribution of the fixes to the users.
also, AL users are expected to RTFM. AL is for advanced users and for
people who are willing to learn how to
administrate their system(s).
3. he has known about it for many months. https://www.archlinux.org/
todo/use-gpg-signatures-and-https-sources/
"Your message was deemed inappropriate by the moderator."
i know. it is so 'inappropriate' that Pope Francis would have died if he
ever read it.

now, on to the rest.

about the '4+ days' thing. reread my message, carefully, because you have
difficulties comprehending what i typed.
hint: it is about delaying things for no good reason.

two more maintenance examples, a recent Antonio Rojas one (once again, he
edited today another imperfect PKGBUILD
file and left it imperfect), and a Sébastien Luttringer one (an example of
stupidity):

https://git.archlinux.org/svntogit/packages.git/commit/
trunk/PKGBUILD?h=packages/help2man&id=47e0c555b37f059be552a930a5da80
130942d5a6
an md5 hash is still used and ftp.gnu.org is HTTPS-enabled. nevertheless, i
must say that he has improved.

https://git.archlinux.org/svntogit/packages.git/commit/
trunk/PKGBUILD?h=packages/btrfs-progs&id=c2dab0f16df636bb0ea94e54d7f116
d5d1504e60
https://www.kernel.org/pub/linux/kernel/people/kdave/
btrfs-progs/sha256sums.asc
he has learning difficulties.

Carsten Mattner,

yes, it is true. sometimes things break, but things can be fixed and there
are ways to avoid breakage. RTFM and/or RTFW
is a requirement.[1] also, because of evolution, each one of us possess a
brain that can do 'miracles' when it is actually
used. use it, people. i know that there are people for whom the activity of
thinking is extremely painful, but we cannot
stop 'rolling' because of them.

in almost all cases it is the AL user's fault.

if one is careless and clueless, bad things can and do happen. that is true
almost everywhere, not only in system administration.

-

"They see me rollin', They hatin'!" (AL is a rolling release distro, and we
want to (rock and) 'roll' forever)

_
[1] https://wiki.archlinux.org/index.php/Pacman#Skip_package_
from_being_upgraded
https://wiki.archlinux.org/index.php/Pacman#Skip_package_
group_from_being_upgraded
https://wiki.archlinux.org/index.php/Pacman#Skip_files_
from_being_installed_to_system


PS: Florian's censorship necessitated the use of a different address. any
complaints about the message being out of the existing
threads are invalid and remarks about my disposable email address are
irrelevant.

Florian, remove me immediately from 'moderation' to prove: 1. that you
actually want to have an honest discussion about anything
and everything, 2. that you are a decent person.

PPS: whoever you are, you are so cute! port scanning my IP address
yesterday, and today registering around with my name.

Whoa.

Why PKGBUILD need to be perfect?
don't need to... And I think PKGBUILD is only thing in AUR, not in this
Mailing list.

Also, you need to calm down a little bit, think about what you did.

- Chroma/Proj. Chisaki
Loading...