Re: [arch-general] How to have multiple JDKs parallel?

[Carsten Mattner via arch-general]

On 9/19/18, ProgAndy  wrote:

> There are LTS releases planned by AdoptOpenJDK, though. For now, Java 8
> and Java 11 are declared as supported until at least 2022 [1]. These
> versions may be of interest for Arch Linux.

I'm not a Java developer anymore and probably unaware of new stuff,
and what you say makes sense. Though, isn't LTS packaging a niche
feature in Arch and wouldn't Arch follow the current latest JDK.
So JDK-LTS would be an extra package while a hypothetical meta
package like openjdk would track latest stable branch. Make sense?

I don't have a horse in this race, just thinking out loud.

I'm excited OpenJDK is turning into the mainstream source of JDKs,
when it was Oracle and IBM in the past. No more stupid JVM usage
tracking done by Oracle, for one. And no more licensing surprises.

Re: [arch-general] How to have multiple JDKs parallel?

[Carsten Mattner via arch-general]

On 9/17/18, ProgAndy  wrote:
> Am 18.09.18 um 00:23 schrieb Carsten Mattner via arch-general:
>> Hope you don't mind me hijacking the thread to ask if you've ever
>> extracted an adoptopenjdk tarball and were able to use it for running
>> a Swing GUI. The jdk10-openjdk (not bin, didn't try aur) package in arch
>> works, but whatever x86_64 tarball I download from adopopenjdk won't
>> display Swing GUIs. It just throws exceptions about font loading.
>> Do you have relevant experience to share/hint?
>
> There is a similar (the same?) error with MacOS builds:
>
> https://github.com/AdoptOpenJDK/openjdk-build/issues/489

I get these:

java.lang.InternalError: java.lang.reflect.InvocationTargetException
  at sun.font.FontManagerFactory$1.run(
java.desktop@10.0.2-adoptopenjdk/FontManagerFactory.java:86)

Re: [arch-general] How to have multiple JDKs parallel?

[Carsten Mattner via arch-general]

On 9/17/18, Guus Snijders via arch-general  wrote:

> As an alternative : you could just extract (unpack) the pkg file to a
> versioned directory in your $home and use those for testing.

Hope you don't mind me hijacking the thread to ask if you've ever
extracted an adoptopenjdk tarball and were able to use it for running
a Swing GUI. The jdk10-openjdk (not bin, didn't try aur) package in arch
works, but whatever x86_64 tarball I download from adopopenjdk won't
display Swing GUIs. It just throws exceptions about font loading.
Do you have relevant experience to share/hint?

Re: [arch-general] How to have multiple JDKs parallel?

[Carsten Mattner via arch-general]

On 9/17/18, Eli Schwartz via arch-general  wrote:

> So essentially what you really want is a way for pacman to remember your
> choice. That would require pacman modify its configuration which is
> something that goes against the current architecture... What would happen
> instead is pacman.conf could be used to configure this.
>
> I'm not sure if IgnorePkg or HoldPkg would have an effect here...

The way I read it, what's being suggested is something like Debian's
update-alternatives. https://wiki.debian.org/DebianAlternatives

Or a JVM version manager ala pyenv etc. Not sure.

Re: [arch-general] How to have multiple JDKs parallel?

[Carsten Mattner via arch-general]

I have a related question. I tried arch's openjdk packages and those
were successful in displaying Swing UIs.

Then, to check out newer JDKs and IBM's OpenJ9, I grabbed a
build from https://adoptopenjdk.net, and I just couldn't get
any Swing UI to display. It reported many exceptions and that
was it. Tried with different window managers and compositors.

Any idea what's different on Arch or where the adoptopenjdk builds
work?

Re: [arch-general] AppArmor support

[Carsten Mattner via arch-general]

On 9/10/18, Geo Kozey via arch-general  wrote:

> Of course I don't report issues with linux-hardened patch itself upstream.

Correct me if I'm wrong, but does that mean you first try to repro with
vanilla and fall back to reporting to -hardened if it's not present in
Linus' tree?

Re: [arch-general] AppArmor support

[Carsten Mattner via arch-general]

On 9/10/18, Levente Polyak via arch-general  wrote:

> It is quite definitively equally stable as vanilla linux is, there is no
> crazy overly invasive stuff in hardened that would justify claiming
> otherwise.

That hasn't been my experience, and I'm happy to hear I might be an
outlier. I am grateful for the work you put in and hope to see hardened
features be completely included in Linus' tree some day.

> What you most likely encountered, like literally all other "instability"
> issues so far, is that with your setup you triggered a stock vanilla
> linux bug with the difference that hardened immediately shuts itself
> down for security reasons. These bugs are corruption and integrity
> related and shutting down follows "better safe then sorry" for the
> hardened variant.
> There are various kernel configs doing so, to name some:
> CONFIG_BUG_ON_DATA_CORRUPTION, CONFIG_DEBUG_LIST, CONFIG_DEBUG_SG and
> lots more including slab sanitizing/verifying specifically in
> combination with CONFIG_PANIC_ON_OOPS.

That's a possible explanation, and I wasn't complaining, but what I
wrote seems to signal that. I'm sorry it sounded like a complain.
The message I was trying to convey is that proposing linux-hardened
to make use of a feature that's been stable in Linus' tree isn't
a good idea due to stability and reluctant support likelihood when
you run into a problem.

If I have a problem with Fedora, I first ask in Fedora's forums
because they patch their kernel a lot. With Arch, I don't have
to because "linux" only carries a couple backports of fixes,
and all I need to show is config.gz.

With all that being said, I'm genuinely glad to hear that linux-hardened
generally works and I have just been unlucky to hit the right code paths.

> Just a crazy idea but how about contributing back instead of just
> complaining? People on the bug tracker always help guiding how to report
> upstream or finding relevant commits. Yeah, i know it takes a while to
> compile, but it's not that complicated:
> - take a look at the panic in hardened
> - peek the code around it to find out which of the protective config
>   values may have triggered it (if not already obvious from the panic)
> - reproduce on stock/vanilla kernel by building it including the
>   responsible configs
> - report upstream using the gathered information of the vanilla kernel
> - bonus points for git bisecting the commit that broke it
>
> This would not only contribute to make hardened run on your or similar
> setups, all vanilla linux users would benefit by helping to fix a bug
> that can or does result in a corruption.

I did and do. I have open bugs in freedesktop and kernel bugzilla which
are not resolved and in NEW state for months and years. These are usually
regressions in drivers due to the Linux driver packaging model and
insufficient testing on supported hardware configurations. What happens
is that a driver that works flawlessly on hardware rev-1.8 suddenly starts
misbehaving with a newer kernel that has seen improvements, refactorings,
and support for newer hardware. It's most prominent in the graphics stack,
which is complex, hard to test, and easy to break. I don't blame the
developers for having a hard time, I'm discouraged stable drivers for
old hardware get regressions and stop being tested as well as hardware
of years -2/+2 years.

Therefore, I hope you don't mind if my frustration level with the issues
I'm tracking right now is high enough that I'm not in the mood to debug
and track issues I can avoid by using a different stable kernel branch.

Greg, rightfully for the most part, always encourages people to upgrade
to the latest stable branch, but he never talks about preventable
regressions that happen due to speed and unnecessary modifications in
stable drivers for older hardware. What's telling is that it's primarily
hardware drivers, while the general kernel code isn't regressing. If
Linux had a driver ABI..

Re: [arch-general] AppArmor support

[Carsten Mattner via arch-general]

On 9/9/18, Gus  wrote:
> Linux-hardened doesn't support hibernation and i think it's overkill to
> use it on desktop.

Not arguing in anyway for or against AppArmor, just another
data point regarding linux-hardened 4.17 and 4.18:

I tried linux-hardened on two Intel machines, and it was less stable
than "linux". Some of the changes are probably invasive/destabilising,
which makes sense seeing how slowly and carefully the mitigations are
traveling via Kees Cook into Linus' tree. I didn't have stability
issues with the old linux-grsec packages, though to be fair those
were also way older major releases which may matter.

Re: [arch-general] Upgrade to Linux 4.17.2 & xorg-server 1.20.0-8 breaks left-mouse in remote Linux desktops

[Carsten Mattner via arch-general]

Is there a guide to migrate from synaptics to libinput?
I tried and failed to configure Wayland's libinput
to behave like my  xf86-input-synaptics config, and
that has been enough experience to not try
xf86-input-libinput, at least for the moment.

Re: [arch-general] KDE plasma, baloo and UI/video playback freezes

[Carsten Mattner via arch-general]

On 5/29/18, Francesco Porro via arch-general  wrote:

> You don't need to add my address since I'm subscribed to the mailing
> list :)
>
> (it you do, and I hit reply, Kmail replys only to your email by
> default).

I think there's some confusion. I checked the mail you sent me, and
the only recipient was my address, no list addres in either field.
Therefore I assumed you mailed me directly, off-list, and so I didn't
add back the list in my reply. Usually, when someone does this, it's
considered off-list and meant to be private. It's better to miss the
list than expose a potentially personal email to the public list.

Anyway, let's focus on the topic.

> Btw, today i'm going to try changing the scheduler to BFQ, even if I

Do not expect magical fixes. It may or may not help the I/O load
that's affecting you.

> found a workaround that avoid the baloo scheduler activating every
> 10 seconds: simply I changed the path where to save Konversation's
> logs to his .config dir (baloo doen't indexes dotted files o dirs).

Interesting. That sounds like a performance bug in the interaction of
Konversation and Baloo. But it's still odd that Debian doesn't have
this. I assume the KDE version tested was the same on the different
distros.

Re: [arch-general] KDE plasma, baloo and UI/video playback freezes

[Carsten Mattner via arch-general]

On 5/27/18, Francesco Porro via arch-general  wrote:
> You mailed me privately. Better replying to mailing list since this could be
>
> useful to others &&  please do not top quote.

Agreed, but I only replied to your direct mail to me. Apologies if
I missed the CC somehow.

Re: [arch-general] Stronger Hashes for PKGBUILDs

[Carsten Mattner via arch-general]

The single most beneficial change would be adoption of
The Update Framework, since it is resilient against
all known issues with remote package management,
regardless of pkg signers coming/going and whether
HTTPS is used or not. It also has a nice protocol
for handling key revocation.

Re: [arch-general] KDE plasma, baloo and UI/video playback freezes

[Carsten Mattner via arch-general]

On 5/8/18, Francesco Porro  wrote:
> In data martedì 8 maggio 2018 21:08:35 CEST, Carsten Mattner ha scritto:
>> Linux block layer's writeback system was supposed to fix this,
>> but I've also noticed that the mechanism isn't perfect and
>> you can still have a "hanging" application when doing the
>> infamous USB-to-USB transfer that kills the VM subsystem.
>>
>> Another way I can reproduce it is when there SSD-to-thumb-drive
>> and you decide to some disk activity, too.
>>
>> https://lwn.net/Articles/682582/
>>
>> The problem is that VM gets pressured a lot and the whole
>> construct fails in a way, while working as designed,
>> manifesting as hanging programs.
>
> Ok, but I'm talking about HDD on Sata bus. No Usb-to-usb transfers
> involved. And, as said before, I've altready tweaked the
> vm.dirty{writeback,background_ratio} to partialy word around this,
> either on Debian or Arch linux.

It's easier to trigger with slow devices but ultimately the
same issue of block layer and vm subsystem getting overwhelmed.

>> First, to confirm, if you manage to run the indexer like
>> you would `ionice -c idle `, and it shows
>> less hangs, you know the issue is unfair I/O queuing.
>
> The indexer's process autostarts and rapidly kills himself in a bunch of
> seconds... its impossible to renice the process, however I saw (by
> Ksysguard) it's always 19 as nice value... meaning high fairness both
> for the CPU, and I think for the IO too.
>
>
>> You can compare the block layer kernel configuration of
>> Debian vs Arch.
>
> Sorry, how to? Which are the keyword for searching?

On both systems there should be /proc/config.gz of the
running kernel. If you have a suspicion which kernel
option is responsible, you can check if it's different
between Arch and Debian.

>> You can try deadline or bfq schedulers. One is dead simple
>> and the other optimizes for desktop responsiveness.
>
> As a last chance, I'll look into these alternatives schedulers. But now,
> either Debian or Arch are using the same one: Cfq. So I don't think this
> is the cause of the problem.

Sounds true. Is it only that one application or others as well
when they cause much I/O?

Re: [arch-general] KDE plasma, baloo and UI/video playback freezes

[Carsten Mattner via arch-general]

On 5/8/18, Francesco Porro via arch-general  wrote:
> Hi,
>
> My problem is: when I'm watching a video, running Konversation in the
> background with logging on disk enabled, the playback of video slows
> down, freezes for a while.
>
> Running iotop and ksysguard I found that baloo_file_extractor is writing
> on disk a big amount of data, filling the write queue; balooct monitor
> shows baloo is indexing Konversation's logs file changes. Peaks of 60-90
> MB/s of data on mechanical hdd are generated and the playback of videos
> (or audio, or other GUI-related tasks) slow down or freeze. Very very
> annoying.
>
> I'm running updated versions of: KDE plasma (5.12.5), kernel (4.16.7),
> baloo (5.45); CFQ I/O scheduler on sda.
>
> On the same machine, the same version of softwares, the same
> configurations (of programs, mounts, IO scheduler) BUT on a Debian sid
> install (home is shared between installs) is NOT showing the same issue.
> On Debian, playback is running smootly even if baloo_file_extractor is
> heavly loading IO writes queue.
>
> On each installation I added this tweaks, to improve Vm management by
> the kernel:
>
> [frapox@tungsteno ~]$ cat /etc/sysctl.d/local.conf
> vm.dirty_background_ratio = 2
> vm.dirty_ratio = 5
> vm.vfs_cache_pressure = 60
>
> I also tried to recompile the Arch kernel with
> CONFIG_PREEMPT_VOLUNTARY=y, to reflect the same default compile setting
> of Debian, but the issue wasn't solved.
>
> So i'm wondering which other config files or settings/tweaks I can look
> into to overcome this issue on Arch linux (I'd really love to keep on
> use Arch as my main OS).

Linux block layer's writeback system was supposed to fix this,
but I've also noticed that the mechanism isn't perfect and
you can still have a "hanging" application when doing the
infamous USB-to-USB transfer that kills the VM subsystem.

Another way I can reproduce it is when there SSD-to-thumb-drive
and you decide to some disk activity, too.

https://lwn.net/Articles/682582/

The problem is that VM gets pressured a lot and the whole
construct fails in a way, while working as designed,
manifesting as hanging programs.

First, to confirm, if you manage to run the indexer like
you would `ionice -c idle `, and it shows
less hangs, you know the issue is unfair I/O queuing.

You can compare the block layer kernel configuration of
Debian vs Arch.

You can try deadline or bfq schedulers. One is dead simple
and the other optimizes for desktop responsiveness.

Re: [arch-general] procps-ng 3.3.13 and its new topdefaultrc

[Carsten Mattner via arch-general]

FWIW and thankfully, we're not all wired the same, and I can
say with certainty that I find htop irritating and confusing,
having used FreeBSD and procps top for decades. There is
a learning curve, I guess, or we're using/missing different
features.

But to return to the important point, does anyone have a
screenshot of modern-top?

And, like David, I'm wondering if I can toggle modern-top
before coming up with full toprc theme.

On 4/11/18, Eli Schwartz via arch-general  wrote:
> On 04/11/2018 04:36 PM, Leonid Isaev via arch-general wrote:
>> It should also be mentioned that ~/.toprc is the most hideous config file
>> on my
>> system :) And FWIW, I don't think that upstream wanted to provoke any
>> learning
>> -- they just made a change for the sake of it (probably following GNOME
>> 3.x :).
>
> I don't disagree on either count, but I'm pretty sure they *claimed*
> that reason.
>
> --
> Eli Schwartz
> Bug Wrangler and Trusted User
>
>

Re: [arch-general] procps-ng 3.3.13 and its new topdefaultrc

[Carsten Mattner via arch-general]

I haven't seen the modern top ui, but it sounds useful and I'd
be in favor of it if it doesn't break things.

But I have to note that terminal emulators and coloring curses
applications is very hard to do in a way that works across
everyone's favorite color scheme. It's bound to result in
invisible elements or missing contrast when you use too much
coloring. It's not a fault of the designer but the ways terminal
emulators work (in other words are limited).

So by all means, if it doesn't break anything, enable modern
top, but use caution with colors.

Re: [arch-general] Re-install of Arch on a larger drive

[Carsten Mattner via arch-general]

On 3/19/18, Paul Gideon Dann via arch-general
 wrote:
> I've moved or cloned my general-use Arch system between disks more times
> than I can count. This is what LVM is for. If you're not using LVM (or
> BTRFS), I recommend you start

Which aspect is easier/improved with LVM?

Re: [arch-general] bz [was gcc broken]

[Carsten Mattner via arch-general]

On 3/16/18, Jelle van der Waa <je...@vdwaa.nl> wrote:
> On 03/15/18 at 09:29pm, Carsten Mattner via arch-general wrote:
>> On 3/15/18, Eli Schwartz via arch-general <arch-general@archlinux.org>
>> wrote:
>>
>> > Good news, I guess, is that we will almost certainly switch to bugzilla
>> > as soon as Harmony brings stable psgi support (Soon™).
>>
>> Harmony?
>> PSGI?
>>
>> I like Bugzilla's features, and I don't use arch's tracker enough to have
>> a voice, or maintain it to have a say, but I would still like to provide
>> an opinion. It's just an opinion. Having used large bugzilla
>> installations
>> like mozilla.org, kernel.org, freedesktop.org, it doesn't look like
>> Bugzilla
>> can be fast. I've found Mantis and to some extend Redmine to be fast and
>> lean trackers. These may or may not suit Arch's needs, and I still have
>> hope Bugzilla will at some point become snappy.
>>
>> Just an opinion based on experience, the arch admins/devs will know why
>> bugzilla is the right choice. I trust them.
>
> Please don't de-rail the thread. (Obviously the Arch devs also want a
> performing bugtracker, but Flyspray has to go either way)

Sorry about that. I let my pain of disappointing bugzilla performance
speak in the wrong context.

Are the Arch devs looking for input on this in some ticket/forum? Like
I said, I don't use it enough to care deeply, but I'm happy to provide
experience report if needed.

Re: [arch-general] gcc broken - Arch specific, applying optimization incorrectly - may explain unexplained problems

[Carsten Mattner via arch-general]

I should note that Jira takes the position of being the slowest bugtracker.
Nobody would use git if it was slow like Jira or Bugzilla.

Re: [arch-general] gcc broken - Arch specific, applying optimization incorrectly - may explain unexplained problems

[Carsten Mattner via arch-general]

On 3/15/18, Eli Schwartz via arch-general  wrote:

> Good news, I guess, is that we will almost certainly switch to bugzilla
> as soon as Harmony brings stable psgi support (Soon™).

Harmony?
PSGI?

I like Bugzilla's features, and I don't use arch's tracker enough to have
a voice, or maintain it to have a say, but I would still like to provide
an opinion. It's just an opinion. Having used large bugzilla installations
like mozilla.org, kernel.org, freedesktop.org, it doesn't look like Bugzilla
can be fast. I've found Mantis and to some extend Redmine to be fast and
lean trackers. These may or may not suit Arch's needs, and I still have
hope Bugzilla will at some point become snappy.

Just an opinion based on experience, the arch admins/devs will know why
bugzilla is the right choice. I trust them.

Re: [arch-general] Xorg crashes

[Carsten Mattner via arch-general]

On 3/14/18, Thomas Dreher  wrote:
> Am Mittwoch, 14. März 2018, 01:50:51 CET schrieb Jagannathan Tiruvallur
> Eachambadi via arch-general:
>> On Tuesday 13 March 2018 12:53:10 PM CET Thomas Dreher wrote:
>> > Libinput is broken. Downgrading to 1.10.1-1 works.
>>
>> Can you link any bug report regarding this. I am running into the same
>> issue and it has irritating to see even X crash since it has been
>> stable for a long time.
>
> I don't think there already is one. Couldn't find one.

I dread the day I must use libinput. It support stuff impossible
before but it lost features we have with the old system and I
still haven't figured out how to make my mice accelerate and
move around the same speed whenever I try to configure libinput
in Wayland compositors. I'm glad I can avoid it in X. It screams
second system syndrome.

Re: [arch-general] Keyboard issue with kernel 4.15.5 (possible Arch issue?)

[Carsten Mattner via arch-general]

On 3/14/18, Ralf Mardorf  wrote:
> As a real-time audio user, too, be sure, I'm as well using a PS/2
> keyboard. A PS/2 keyboard should work. However, from time to time it

I'm so glad to hear there are other PS/2 keyboard proponents.

USB kinda, sorta works but the bus nature of it, and having
more than two devices connected, it means there's intermittent
bus resets and ports disabled by kernel until reboot if it's
those kind of days.

> could happen, that the keyboard's lock LEDs start blinking during
> startup and startup doesn't finish, but the messages don't show a
> kernel panic or something keyboard related. If this happens, I just
> need to reset the computer, a second startup always worked for me.
> assuming your keyboard should be broken, they still sell brand new
> native PS/2 keyboards in all price ranges. Due to the USB keyboard
> issues PS/2 keyboards are seemingly much more important to gamers, than
> for real-time audio users.

Is it still native when connected with a USB-to-PS/2 adapter?

I'm asking because it's very limiting when you shop around
for a keyboard with a "pure" PS/2 connector. It's already hard
to find an ergonomic keyboard that has mechanical switches,
and insisting on non-USB shrinks the list, leaving not much
of a selection.

> Btw. "core" provides 4.15.8. I already upgraded to 4.15.8 early Monday
> morning and FWIW I skipped 4.15.5 and upgraded from 4.15.4-1 to
> 4.15.6-1, so I don't know if something is fishy with 4.15.5.

What was wrong with 4.15.5? I missed the news.

Re: [arch-general] Keyboard issue with kernel 4.15.5 (possible Arch issue?)

[Carsten Mattner via arch-general]

On 3/13/18, Jeanette C. via arch-general  wrote:
> Hey hey,
> I updated yesterday, from some;thing like a 4.13 or 4.14 kernel to version
> 4.15.5 and couldn't use my PS/2 keyboard. I saw the LEDs flashing when the
> system started, but couldn't get any response from the keyboard upon login.
>
> I've managed to get the system going with a USB keyboard.
>
> My PS/2 keyboard is rather old. Is it more likely that the keyboard is
> broken, or is there a chance of a kernel configuration breaking usage of
> the PS/2 keyboard?

Does the keyboard function in BIOS?

Does it work if boot another distro's live usb or cd?

You said 4.13/4.14 before so I don't think you're affected by the
initramfs changes in 2014:

https://www.archlinux.org/news/linux-313-warning-ps2-keyboard-support-is-now-modular/

Re: [arch-general] Update to 4.15.8 on dual quad-core box locked on ( 3/16) Install DKMS modules, need help resurecting

[Carsten Mattner via arch-general]

On 3/13/18, Eli Schwartz via arch-general  wrote:

> Like I said, this can be done from any system which has pacman and
> mkinitcpio available. That means:
>
> 1) Arch Linux
> 2) Gentoo, which has a pacman package and IIRC also provides mkinitcpio
>as an option alongside dracut.
> 3) Any Linux distribution if you have chrooted into the bootstrap image
> 4) Windows (or any operating system, really), by using a virtual machine
>
> Certainly, anything is *possible* if you put in enough work. But making
> something annoyingly difficult to do is, as I said, hardly a generic
> solution.

True and Alpine Linux supports (3.5) ZFS on install which I didn't confirm
because, like I said, I don't use ZFS on Linux. I mean that if Arch
ZFS developers want to, they can leverage work from other distros.
I guess it's a good thing Arch has no installer or otherwise there
might be a heated debate whether ZFS should be an option :).

Re: [arch-general] gcc broken - Arch specific, applying optimization incorrectly - may explain unexplained problems

[Carsten Mattner via arch-general]

On 3/13/18, PkmX via arch-general  wrote:
> Hi,
>
> AFAIK this is the exact case of gcc bugzilla #84607:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84607
>
> As this is an upstream bug this should affect all distributions, maybe
> the commenter on Debian is using 7.3.1 so he can't reproduce the
> issue?

Let's not forget that Debian is patch happy (as is Ubuntu, logically),
especially for gcc. Mostly for good reason but quite a bit is too
many diffs:

https://sources.debian.org/src/gcc-7/7.3.0-11/debian/patches/

It's quite possible that the snapshot plus diffs fixes/hides the bug
on Debian. Fedora is another distro that is very happy to carry
many diffs for some packages. Thinks of the version string like
git-gc-7.3.1+dirty in mainstream distros. It's like a downstream
branch.

Re: [arch-general] High CPU on one core, but unable to find process responsible

[Carsten Mattner via arch-general]

On 3/13/18, David Rosenstrauch <dar...@darose.net> wrote:
>
>
> On 03/12/2018 09:56 PM, Carsten Mattner via arch-general wrote:
>> Any BIOS updates or kernel updates recently (4.15.8)?
>>
>> Try with 3.16 or 4.9 or another old lts kernel from archive.archlinux.org
>> just for testing (not production).
>>
>> It's more likely that the kernel regressed rather than IRQ issues popping
>> up suddenly. It's possible but less likely.
>
> No BIOS updates.  As far as kernel updates, I do those all the time, so
> not sure that would be the cause.
>
> After doing some digging, though, I did "cat /proc/interrupts", and this
> line stood out, for having an astronomically high number:
>
> CPU0   CPU1   CPU2   CPU3
> ...
>   16: 2424156658  0  0  0   IO-APIC  16-fasteoi
>   uhci_hcd:usb5, parport1
>
>
> I have an old PCI card in the machine that's powers an old parallel port
> printer I used to use with it.  Perhaps that's failing.  I don't need
> the card anymore, so I might as well try taking it out and see if that
> makes things better.  If not, I'll be back.  :-)

Let us know in either case. Please tell me it's a huge plotter
you use to make construction plans for your rocket ships.

Re: [arch-general] High CPU on one core, but unable to find process responsible

[Carsten Mattner via arch-general]

On 3/13/18, David Rosenstrauch  wrote:

> So if this issue is irq-based, I guess that means some piece of hardware
> is faulty or failing.  Any idea how I might go about pinning down which
> one?  Would there be info in the kernel log about this?  Or something
> that I can look at in /proc?

Any BIOS updates or kernel updates recently (4.15.8)?

Try with 3.16 or 4.9 or another old lts kernel from archive.archlinux.org
just for testing (not production).

It's more likely that the kernel regressed rather than IRQ issues popping
up suddenly. It's possible but less likely.

Re: [arch-general] Update to 4.15.8 on dual quad-core box locked on ( 3/16) Install DKMS modules, need help resurecting

[Carsten Mattner via arch-general]

Sorry for letting gmail butcher wrapping/breaks. Someone at Google
needs to be demoted for that anti-feature. I should remember to never
edit in gmail's text box but use my normal editor as usual.

Re: [arch-general] Update to 4.15.8 on dual quad-core box locked on ( 3/16) Install DKMS modules, need help resurecting

[Carsten Mattner via arch-general]

It almost looks like filesystem development doesn't fit Linux kernel
development style
of iterating constantly and evolving with time. btrfs has had the same
time as zfs
had in-house at Oracle before it was declared publicly stable, and
there are still
buggy/unfinished corners.

If you look at past successful Linux filesystems it's either an existing design
that was generally amenable to certain extensions and has evolved in-tree or
came designed and implemented from a different platform (JFS, XFS, quite a few
more). EXT4 is the reliable workhorse if inodes aren't a problem and you don't
mind time to allocate and upper bounds thereof. It evolved step by step from
EXT2 to EXT3 to EXT4, all the while having stable core features and experimental
features. btrfs is busy implementing features promised 10 years ago and there
are bugs in regular use if you're not careful.

Developing a filesystem is hard and there's no room for mistakes. Most
productive
filesystem development is happening in XFS and EXT4 teams with the former being
in a nice stable maintenance mode. If you haven't tried XFS in the last 3 years,
give it a test run. The old issues of being optimized for certain workloads have
been fixed years ago. It's a good replacement for EXT4 if you need its features
and tools.

Re: [arch-general] Update to 4.15.8 on dual quad-core box locked on ( 3/16) Install DKMS modules, need help resurecting

[Carsten Mattner via arch-general]

On 3/12/18, Leonid Isaev via arch-general <arch-general@archlinux.org> wrote:
> On Mon, Mar 12, 2018 at 10:24:37PM +, Carsten Mattner via arch-general
> wrote:
>> On 3/12/18, Eli Schwartz via arch-general <arch-general@archlinux.org>
>> wrote:
>> > On 03/11/2018 10:00 PM, Carsten Mattner via arch-general wrote:
>> >> I'm happy to hear that. My rationale is based on past observations
>> >> of needlessly heated arguments and ZFS, due to its license splitting
>> >> the Linux community in half, appearing to be perfect fuel for such
>> >> a thread.
>> >>
>> >> Thanks for the wiki links. Never used ZFS on Linux because I avoid
>> >> out of kernel patches. Maybe I will give it a try on Linux as well.
>> >
>> > Well yes, the main reason people get heated about it I think is because
>> > it is out-of-tree kernel modules and as such are less reliably stable
>> > or
>> > some such.
>> >
>> > Based on how well archzfs keeps their binary repos up to date, I'm not
>> > 100% convinced on the stability. Moreso consider that it's difficult to
>> > bootstrap a system without zfs available, and if their binary repo does
>> > not match the current archiso...
>>
>> I'll stay away from it, thanks. I saw that Alpine Linux has good ZFS
>> support, but I didn't do anything serious with it. When it comes to
>> filesystems, I'm conservative, EXT4 and XFS on Linux. It's a pity
>> there's no modern filesystem to share volumes between FOSS kernels.
>> It's all some compromise that you might or might not accept.
>
> What's wrong with btrfs? Yeah, I know it is not marked "stable", but this
> is just a label. And people shying away from it doesn't help in advancing
> its stability either.

btrfs never got on my radar because it's Linux only and its instability
is a blocker. If I have to be careful how I use a filesystem even when
I didn't explicitly enable beta features, I'm too scared to put my files
on it. If I were a Suse Enterprise customer, I might use it, but Red Hat
isn't behind it anymore, so it's like Reiser3 back in the day. Only Suse
was putting their weight behind it. Well Facebook has developers on it,
but Facebook isn't a distro developer and can't be trusted with continued
maintenance, since they might switch on a weekend to some Facebook-FS.
Facebook has too many engineers and is reinventing stuff in-house a lot.

btrfs and zfs suffer from design limitations, but zfs has been stable
and in petabyte production for a long time across many organizations.
btrfs is one of many future Linux filesystems with no clear winner
so far. It looks like XFS will gain full checksums and scrubbing
before btrfs gets reliable and Red Hat's XFS++ work will provide
snapshots. It's like git replacing bitkeeper in 2005. Seems like
XFS++ will do the same with btrfs left to history of experiments.

All I want is a modern filesystem whose volume I can share without
exposing it via a network protocol.

Re: [arch-general] Update to 4.15.8 on dual quad-core box locked on ( 3/16) Install DKMS modules, need help resurecting

[Carsten Mattner via arch-general]

On 3/12/18, Eli Schwartz via arch-general <arch-general@archlinux.org> wrote:
> On 03/11/2018 10:00 PM, Carsten Mattner via arch-general wrote:
>> I'm happy to hear that. My rationale is based on past observations
>> of needlessly heated arguments and ZFS, due to its license splitting
>> the Linux community in half, appearing to be perfect fuel for such
>> a thread.
>>
>> Thanks for the wiki links. Never used ZFS on Linux because I avoid
>> out of kernel patches. Maybe I will give it a try on Linux as well.
>
> Well yes, the main reason people get heated about it I think is because
> it is out-of-tree kernel modules and as such are less reliably stable or
> some such.
>
> Based on how well archzfs keeps their binary repos up to date, I'm not
> 100% convinced on the stability. Moreso consider that it's difficult to
> bootstrap a system without zfs available, and if their binary repo does
> not match the current archiso...

I'll stay away from it, thanks. I saw that Alpine Linux has good ZFS
support, but I didn't do anything serious with it. When it comes to
filesystems, I'm conservative, EXT4 and XFS on Linux. It's a pity
there's no modern filesystem to share volumes between FOSS kernels.
It's all some compromise that you might or might not accept.

My current recommendation if one is looking for ZFS:

(1) FreeBSD good enough, no linux binaries needed? Go with that.
(2) illumos derivative work for you in terms of drivers _and_
you need Linux binaries to run seamlessly? illumos lx branded
zones are your solution then. You can even dtrace a linux zone
from the illumos outer environment. It's like FreeBSD Jails
on steroids without the immaturity and chaos of Linux containers.
Crossbow is nice, too.

Keep in mind both 1 and 2 start off with a desire to use 1st class
native ZFS support. illumos #1 problem is the unneeded distro
fragmentation when the community is so small anyway. But they're
collaborating on the base and core system very well. The main issue
is porting or writing drivers. To this day I wonder why Google for
all of its Java language reliance didn't buy Sun liberate it fully.
Past fights over the language and Apache Java might have led Sun
to block any Google talks.

Re: [arch-general] High CPU on one core, but unable to find process responsible

[Carsten Mattner via arch-general]

On 3/12/18, David Rosenstrauch  wrote:
> My server's been exhibiting some very strange behavior lately.  Every
> couple of days I run into a situation where one core (core #0) on the
> quad core CPU starts continuously using around 34% of CPU, but I'm not
> able to see (using htop) any process that's responsible for using all
> that CPU.  Even when I tell htop to show me kernel threads too, I still
> am not able to see the offending process.  Every process remains under
> 1% CPU usage (except for occasional, small, short-lived spikes up) yet
> the CPU usage on that core remains permanently hovering at around 34%.
> The problem goes away when I reboot, but then comes back with a day or
> so.

My gut feeling is that one of the kernel worker threads hangs.
So that would be 25% overall and 100% of the affected core.
But you say there's no load to be found in the kernel threads,
which is odd.

Or if the server is accessible from the Internet, is it possible
it's rooted and someone's running a hidden process? To confirm
this isn't the case, cut off Internet access and let it run for
two days.

I don't think there are any official hidden processes that do not
show up in htop or top since that would make them seem like rootkits.
That means if the guilty process is really invisible, then it's
definitely unusual.

It's scary to consider a rootkit, but if that's the case, then
it's best to be aware as soon as possible. I hope this is not
case for you, wouldn't wish it on your worst enemy.

Another idea. Can you limit the cores to 1 or maybe two and see
if it becomes easier to pinpoint?

This might work in the booted system:
echo 0 > /sys/devices/system/cpu/cpu1/online
echo 0 > /sys/devices/system/cpu/cpu2/online
echo 0 > /sys/devices/system/cpu/cpu3/online

But on the kernel command line maxcpus=1 should work.

Re: [arch-general] Update to 4.15.8 on dual quad-core box locked on ( 3/16) Install DKMS modules, need help resurecting

[Carsten Mattner via arch-general]

On 3/12/18, Celti Burroughs via arch-general <arch-general@archlinux.org> wrote:
> On Mon, 12 Mar 2018 01:04:14 +
> Carsten Mattner via arch-general <arch-general@archlinux.org> wrote:
>
>> Or I actually did post it to the list by accident.
>>
>> Please don't flame me for mention ZFS boot environments as a technique
>> available for FOSS servers.
>>
>> On 3/12/18, Carsten Mattner <carstenmatt...@gmail.com> wrote:
>> > On 3/11/18, David C. Rankin <drankina...@suddenlinkmail.com> wrote:
>> >
>> >> This was a nightmare. It's not a CD problem, it's a problem with
>> >> the system
>> >> seeing the CD Label and/or creating the /dev/disk/by-label
>> >> directory in time for the link to be created.
>> >
>> > Hi David,
>> >
>> > so in the end you were able to boot off usb, right?
>> >
>> > Also, the nightmare you had to work through can be avoided on
>> > servers where you run illumos or FreeBSD by way of ZFS boot
>> > environments (BE). Basically, it's like Windows style snapshots of
>> > core files you can boot, in case stuff goes south.
>> >
>> > I didn't post this to the list, since it mentions ZFS, and that
>> > alone might get some people pissed off.
>
> I don't see why anyone should get pissed off. I mean, ArchZFS[1] is
> definitely a thing that works reasonably well, and the wiki page[2]
> specifically mentions boot environments and beadm.

I'm happy to hear that. My rationale is based on past observations
of needlessly heated arguments and ZFS, due to its license splitting
the Linux community in half, appearing to be perfect fuel for such
a thread.

Thanks for the wiki links. Never used ZFS on Linux because I avoid
out of kernel patches. Maybe I will give it a try on Linux as well.

Re: [arch-general] Update to 4.15.8 on dual quad-core box locked on ( 3/16) Install DKMS modules, need help resurecting

[Carsten Mattner via arch-general]

Or I actually did post it to the list by accident.

Please don't flame me for mention ZFS boot environments as a technique
available for FOSS servers.

On 3/12/18, Carsten Mattner  wrote:
> On 3/11/18, David C. Rankin  wrote:
>
>> This was a nightmare. It's not a CD problem, it's a problem with the
>> system
>> seeing the CD Label and/or creating the /dev/disk/by-label directory in
>> time for the link to be created.
>
> Hi David,
>
> so in the end you were able to boot off usb, right?
>
> Also, the nightmare you had to work through can be avoided on servers
> where you run illumos or FreeBSD by way of ZFS boot environments (BE).
> Basically, it's like Windows style snapshots of core files you can
> boot, in case stuff goes south.
>
> I didn't post this to the list, since it mentions ZFS, and that alone
> might get some people pissed off.
>

Re: [arch-general] Update to 4.15.8 on dual quad-core box locked on ( 3/16) Install DKMS modules, need help resurecting

[Carsten Mattner via arch-general]

On 3/11/18, David C. Rankin  wrote:

> This was a nightmare. It's not a CD problem, it's a problem with the system
> seeing the CD Label and/or creating the /dev/disk/by-label directory in
> time for the link to be created.

Hi David,

so in the end you were able to boot off usb, right?

Also, the nightmare you had to work through can be avoided on servers
where you run illumos or FreeBSD by way of ZFS boot environments (BE).
Basically, it's like Windows style snapshots of core files you can
boot, in case stuff goes south.

I didn't post this to the list, since it mentions ZFS, and that alone
might get some people pissed off.

Re: [arch-general] Why no git --depth=1 option for makepkg?

[Carsten Mattner via arch-general]

On 3/4/18, Eli Schwartz  wrote:
> On 03/04/2018 03:27 PM, Carsten Mattner wrote:
>> Interesting. What does PKGBUILD do with history of more than 10
>> revisions?
>> If we checkout a tag or specific commit (e.g. xf86-video-intel), what
>> does PKGBUILD need prior revisions for? I'm sure you're correct, I'd
>> like to know what it is, if you don't mind explaining.
>
> You cannot clone a tag or commit, you can only clone a branch and check
> out the tag or commit. So you need enough revisions on that branch to
> reach said tag... and you cannot use shallow-exclude as I mentioned in a
> previous email.
>
> This means that PKGBUILDs which checkout a specific revision are
> actually worse than the rest, as you cannot even get the source without
> knowing how many commits you need (rather than failing afterwards in
> pkgver() or something).

Right. I had assumed that git clone -b/--branch did also exist for
tags. Git is like Linux and very evolutionary, with many warts,
only some parts designed before implementation. This means some
features are only implemented partially. I like and use git, but
sometimes it feels like it's a car where there are five doors, but
you're only supposed to use 2.5 of them.

>>> depth=10 will only work for tags that are present in the last ten
>>> commits, which unsurprisingly is exactly the opposite of most projects
>>> (which don't have tags at all and therefore require all history without
>>> exception in order to implement the pkgver() function) or even most
>>> projects with tags (which don't release stable releases on basically
>>> every other commit).
>>
>> Eli, you certainly have more experience, so I'm trusting your word here.
>> However, I don't understand how depth=10 can fail when trying to checkout
>> a specific git tag. Wouldn't the tag be the HEAD in that case?
>
> If that were true, then depth=1 would work. But tags are usually not the
> upstream HEAD commit, because development continues afterwards...
>
> So first you clone a branch, and then you try to checkout a tag (and
> fail, if you used depth=10 and the tag is not attached to one of those
> ten commits).

See above.

>> Checking out with SVN is a speedup trick, and I still think it can make
>> sense if depth limiting git clone is not possible. svn checkout is
>> basically just copying the tree of that revision (or branch/tag path)
>> specified.
>
> I know how SVN works. :p
>
> I also know how svn doesn't work -- you cannot get tag information, for
> example, and svn revision numbers do not necessarily cleanly translate
> to git revisions numbers let alone commit hashes.

svn works differently, whereas git is all about the DAG. But let's
not discuss svn's design. The idea was that when you the ability
to svn checkout a github project or maybe Apache svn repository,
and those have proper tags and branches, then this will be very
quick in comparison. But as you say, this is bound to be problematic
for other reasons.

I believe git devs are working on checking out tags with shallow depth,
not sure how many years it will take.

> Giving users a mysterious svn revision number they don't know how to
> trace, is confusing UI. So I wouldn't recommend this even for projects
> without tags at all.

Let's ignore the possibility of svn, but tracking a revision number
is the same for those projects without tags as it is for git. As
in the xf86-video-intel project.

Re: [arch-general] Why no git --depth=1 option for makepkg?

[Carsten Mattner via arch-general]

On 3/4/18, Eli Schwartz  wrote:
> On 03/04/2018 10:58 AM, Carsten Mattner wrote:
>> At least for GitHub remotes, don't they still support checking out
>> with SVN? If they do, this would be faster and use less space, too,
>> when we just need a certain revision and no history at all.
>>
>> Other than that, I'm "pretty sure" that a git depth of 10 commits
>> will work for most repositories when you clone normally, not
>> shallow. Should also work for tags. However, it's true that git's
>> limited depth clone isn't implemented fully. There are many unhandled
>> cases and surprises.
>>
>> All that being said, I can report that in CI of personal and company
>> projects, I haven't yet run into problems with depth=5. It speeds up
>> checking out the tree, even when it's a fast local network remote.
>
> depth=1 is perfectly okay for most travis cases, as you don't need any
> history at all unless your build system looks for it... this is a
> bizarre comparison.
>
> The point, is that PKGBUILDs do look for history, and make use of it --
> figuring out clever ways to avoid pulling history is completely missing
> the point that we, well, want history.

Interesting. What does PKGBUILD do with history of more than 10 revisions?
If we checkout a tag or specific commit (e.g. xf86-video-intel), what
does PKGBUILD need prior revisions for? I'm sure you're correct, I'd
like to know what it is, if you don't mind explaining.

> depth=10 will only work for tags that are present in the last ten
> commits, which unsurprisingly is exactly the opposite of most projects
> (which don't have tags at all and therefore require all history without
> exception in order to implement the pkgver() function) or even most
> projects with tags (which don't release stable releases on basically
> every other commit).

Eli, you certainly have more experience, so I'm trusting your word here.
However, I don't understand how depth=10 can fail when trying to checkout
a specific git tag. Wouldn't the tag be the HEAD in that case?


Checking out with SVN is a speedup trick, and I still think it can make
sense if depth limiting git clone is not possible. svn checkout is
basically just copying the tree of that revision (or branch/tag path)
specified.

Re: [arch-general] Why no git --depth=1 option for makepkg?

[Carsten Mattner via arch-general]

At least for GitHub remotes, don't they still support checking out
with SVN? If they do, this would be faster and use less space, too,
when we just need a certain revision and no history at all.

Other than that, I'm "pretty sure" that a git depth of 10 commits
will work for most repositories when you clone normally, not
shallow. Should also work for tags. However, it's true that git's
limited depth clone isn't implemented fully. There are many unhandled
cases and surprises.

All that being said, I can report that in CI of personal and company
projects, I haven't yet run into problems with depth=5. It speeds up
checking out the tree, even when it's a fast local network remote.

On 3/4/18, Eli Schwartz via arch-general  wrote:
> On 03/04/2018 10:37 AM, ProgAndy wrote:
>> Maybe a working option would be to implement fragmant variables for some
>> git options like depth, shallow-exclude and shallow-since, but that is
>> likely not trivial.
>>
>> source=("one::git+https://repo.git#branch=master:shallow-exclude=v4.14;
>> "two::git+https://repo.git#branch=master:shallow-since=2017-12-30;)
>
> That would require opt-in support for every package to describe which
> commits it needs, something which the vast majority of maintainers are
> uninterested in and requires successively more query strings for each
> branch you want to cherry-pick from.
>
> Also shallow-exclude would exclude the tag itself, you cannot specify
> "v${pkgver}~1" to shallow-exclude.
>
> As you say, not trivial. ;) I've thought about it too...
>
> --
> Eli Schwartz
> Bug Wrangler and Trusted User
>
>

Re: [arch-general] mouse freezes when switching between X sessions

[Carsten Mattner via arch-general]

Does it also happen if you run one X session and a Wayland session?

On 10/18/17, Robert Arkiletian via arch-general
 wrote:
> If I have two X sessions running on different accounts and I switch
> between them (ctrl-alt-f1  ctrl-alt-f2) a few times. I usually get a
> frozen mouse in one of the two X sessions. I then must shutdown that X
> session and run it again (startx) to get my mouse working again in
> that account.
>
> Any ideas how to diagnose the issue, much appreciated.
>
> Thanks
>

Re: [arch-general] [arch-dev-public] Test repository with gcc7

[Carsten Mattner via arch-general]

On Fri, May 12, 2017 at 1:22 AM, Hao Zhang via arch-general
 wrote:
> On 2017-05-10 20:19, Bartłomiej Piotrowski wrote:
>> I found some time today to make a test build of the latest GCC. I tested
>> some "simple" projects like nginx and libtorrent-rasterbar and they do
>> build, while MariaDB fails on linking for me.
>>
>> Let me know if you encounter any problems, I'd rather not break too much
>> by pushing it to repos.
>
>> [gcc7]
>> SigLevel = Required
>> Server = https://pkgbuild.com/~bpiotrowski/gcc7
>>
>> No i686, embrace the future!
>>
>> Bartłomiej
>
> Hi Bartłomiej,
>
> I found MariaDB fails on linking because /usr/bin/gcc-ar segfaults whenever
> it runs with absolute path. I have filed an upstream bug report:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80717

I'm not testing or complaining, to be clear, but have a simple
question.

I can't find it now but when the new gcc version scheme was
decided I remember that .0 releases were meant to be RC, but
there's one thing I don't remember.

Will 7.1 be the first tested and stable gcc7 release or is
it 7.0.1 under the new scheme?

Re: [arch-general] libx264 changes

[Carsten Mattner via arch-general]

On Mon, May 8, 2017 at 9:15 PM, Eli Schwartz via arch-general
 wrote:
> On 05/08/2017 01:45 PM, Carsten Mattner wrote:
>> Is the idea that I create a machine local repo that has highest prio
>> and overrides arch extra/testing? Otherwise, I don't know how to unbreak
>> the cycle while only building a custom ffmpeg.
>
> Granted that it is a moot point anyway since your initial request was
> answered and the package is now rebuilt with the headers in the lib
> package...
>
> But no, why does a local repo have anything to do with anything? Do you
> feel you need a local repo in order to install a pacman package, or have
> you discovered the magical -U switch yet?

I ask because pacman -U is the usual way I install custom packages.

> Just makepkg your custom PKGBUILD, and then install your custom ffmpeg
> in place of the repo version. Seriously, did you even try it at all?
> Because if you had tried it, it would have worked and you wouldn't be
> having all these strange questions.
>
> In the absolute worst-case scenario imaginable, you would have to
> temporarily have a few wasteful packages installed, including the repo
> ffmpeg, WHICH YOU WOULD THEN UNINSTALL AFTER YOU BUILT YOUR OWN FFMPEG!

I did try and the only way I managed was building ffmpeg after
first building a custom x264 that doesn't depend on x264.
I didn't manage to build and install ffmpeg without installing
the vanilla ffmpeg package first as a dependency of x264.

I'm sure I'm just not seeing the obvious and sorry for my
limited perspective here.

For some reason we seem to be talking past each other and these things
happen in online discussions. Since the header is included in a cycle-free
fashion again, we should end this thread as I'm afraid my failure
to see what you've been suggesting won't be cleared via email.

> Why are you making such a circus out of this???

I'm sorry you think I am, but I don't think I can say anything
to convince you otherwise.

Eli, sorry for asking dumb question that likely stem from
different perspectives and my pacman/makepkg experience.

Re: [arch-general] libx264 changes

[Carsten Mattner via arch-general]

On Sun, May 7, 2017 at 6:37 PM, Eli Schwartz via arch-general
<arch-general@archlinux.org> wrote:
> On 05/07/2017 02:28 PM, Carsten Mattner via arch-general wrote:
>> On Sun, May 7, 2017 at 6:11 PM, Doug Newgard <scim...@archlinux.info> wrote:
>>> And again, the cycle doesn't matter at all if your ffmpeg package is set up
>>> correctly.
>>
>> I don't understand how I can without additionally repacking libx264/x264,
>> but hopefully I will see what you're saying later today or tomorrow.
>
> What Doug is saying is, you should do what 99.999% of all other Arch
> Linux users creating custom packages to replace repo packages do, and
> make your forked ffmpeg package provide "ffmpeg", thereby ensuring that
> libx264/x264 depend on *your* package!

Is the idea that I create a machine local repo that has highest prio
and overrides arch extra/testing? Otherwise, I don't know how to unbreak
the cycle while only building a custom ffmpeg.

Re: [arch-general] libx264 changes

[Carsten Mattner via arch-general]

On Sun, May 7, 2017 at 6:11 PM, Doug Newgard <scim...@archlinux.info> wrote:
> On Sun, 7 May 2017 18:05:16 +
> Carsten Mattner via arch-general <arch-general@archlinux.org> wrote:
>
>> On Sun, May 7, 2017 at 4:45 PM, Doug Newgard <scim...@archlinux.info> wrote:
>> > So what? None of that should cause a problem if your custom
>> > ffmpeg package is done correctly.
>>
>> I have to override/repackage two packages now that x264.h is
>> in a package which leads me into a cycle. Or I repackage
>> ffmpeg, x264, libx264 locally, not just ffmpeg as before.
>>
>
> And again, the cycle doesn't matter at all if your ffmpeg package is set up
> correctly.

I don't understand how I can without additionally repacking libx264/x264,
but hopefully I will see what you're saying later today or tomorrow.

Re: [arch-general] libx264 changes

[Carsten Mattner via arch-general]

On Sun, May 7, 2017 at 4:45 PM, Doug Newgard <scim...@archlinux.info> wrote:
> On Sun, 7 May 2017 16:36:43 +
> Carsten Mattner via arch-general <arch-general@archlinux.org> wrote:
>
>> On Sun, May 7, 2017 at 3:01 PM, Doug Newgard <scim...@archlinux.info> wrote:
>> > On Sun, 7 May 2017 14:51:08 +
>> > Carsten Mattner via arch-general <arch-general@archlinux.org> wrote:
>> >
>> >> For various reasons like missing features and wrong version
>> >> I cannot use arch's ffmpeg package and have to build my own
>> >> package, and this results in a cyclic dependency I cannot
>> >> get out of.
>> >
>> > What, exactly, is the issue here? You need an ffmpeg package that
>> > provides what x264 needs, nothing more.
>>
>> I cannot install libx264's include/x264.h without installing x264
>> which then depends on ffmpeg which itself depends on libx264.
>> This doesn't look like a hard cycle since it seems like only
>> the x264 executable needs libav*.so, but since x264.h was in
>> libx264 (and is in extra still), I've been building a custom
>> ffmpeg package without also having to build a custom configured
>> (lib)x264 too.
>
> So what? None of that should cause a problem if your custom
> ffmpeg package is done correctly.

I have to override/repackage two packages now that x264.h is
in a package which leads me into a cycle. Or I repackage
ffmpeg, x264, libx264 locally, not just ffmpeg as before.

I respect your decision, but I can't find the justification.

(lib)x264 packaging has been problematic due to 8bit/10bit
in the past as well and I'm certain it's not an easy package
to be responsible for. In fact I remember that the header
moved around in the packages once before (maybe 2 years ago).
x264's new feature flag to depend on libav* is recent and
is the source of the cycle.

Re: [arch-general] libx264 changes

[Carsten Mattner via arch-general]

On Sun, May 7, 2017 at 2:57 PM, Lin DasSarma <_...@umbc.edu> wrote:
> Carsten,
>
> What about a custom ffmpeg PKGBUILD instead?

That's what I've been doing which got complicated now that
x264.h is not in libx264 but x264 and x264 depends on ffmpeg
for presumably muxing.

We have more than two x264 packages so a x264-headers could
solve this.

Re: [arch-general] libx264 changes

[Carsten Mattner via arch-general]

On Sun, May 7, 2017 at 3:01 PM, Doug Newgard <scim...@archlinux.info> wrote:
> On Sun, 7 May 2017 14:51:08 +
> Carsten Mattner via arch-general <arch-general@archlinux.org> wrote:
>
>> For various reasons like missing features and wrong version
>> I cannot use arch's ffmpeg package and have to build my own
>> package, and this results in a cyclic dependency I cannot
>> get out of.
>
> What, exactly, is the issue here? You need an ffmpeg package that
> provides what x264 needs, nothing more.

I cannot install libx264's include/x264.h without installing x264
which then depends on ffmpeg which itself depends on libx264.
This doesn't look like a hard cycle since it seems like only
the x264 executable needs libav*.so, but since x264.h was in
libx264 (and is in extra still), I've been building a custom
ffmpeg package without also having to build a custom configured
(lib)x264 too.

[arch-general] libx264 changes

[Carsten Mattner via arch-general]

Since the libx264 package does not include /usr/include
and it's in x264 now, and because x264 depends on ffmpeg,
I cannot use libx264 without also installing ffmpeg.

For various reasons like missing features and wrong version
I cannot use arch's ffmpeg package and have to build my own
package, and this results in a cyclic dependency I cannot
get out of.

(lib)x264 packages have always been cumbersome due to 8bit
vs 10bit and other issues and are uniquely special in arch,
but since there's already so many x264 packages, let's have
a libx264-headers package. Or keep it in libx264 since 8bit
and 10bit cannot be installed in parallel anyway.

Doug, you probably have good reasons for the recent headers
change and see no way to fix it to make my scenario work, but
I'd appreciate if you gave this a thought and shared your
opinion. If you can't fix this, do you mind explaining what
led to the removal of headers from libx264?

I hope I don't have to build libx264 myself as well since my
PKGBUILD would diverge or force me to build libx264 and x264
custom versions.

Re: [arch-general] Tobias Powalowski and his nonsensical maintenance decisions

[Carsten Mattner via arch-general]

On Fri, Apr 28, 2017 at 6:43 PM, Eric Blau <eb...@eblau.com> wrote:
> On Fri, Apr 28, 2017 at 2:19 PM, Carsten Mattner
> <carstenmatt...@gmail.com> wrote:
>> On Fri, Apr 28, 2017 at 5:11 PM, Eric Blau <eb...@eblau.com> wrote:
>>> On Fri, Apr 28, 2017 at 12:29 PM, Carsten Mattner via arch-general
>>> <arch-general@archlinux.org> wrote:
>>>
>>> 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.

>> 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?

>> 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.

>> 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.

>> So when it comes to 

Re: [arch-general] Tobias Powalowski and his nonsensical maintenance decisions

[Carsten Mattner via arch-general]

On Fri, Apr 28, 2017 at 6:34 PM, Eric Blau  wrote:
> On Fri, Apr 28, 2017 at 2:20 PM, Carsten Mattner
>  wrote:
>> 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.

> 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.

Re: [arch-general] Tobias Powalowski and his nonsensical maintenance decisions

[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.

Re: [arch-general] Tobias Powalowski and his nonsensical maintenance decisions

[Carsten Mattner via arch-general]

On Fri, Apr 28, 2017 at 5:11 PM, Eric Blau <eb...@eblau.com> wrote:
> On Fri, Apr 28, 2017 at 12:29 PM, Carsten Mattner via arch-general
> <arch-general@archlinux.org> wrote:
> >
> > 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.

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.

Re: [arch-general] Tobias Powalowski and his nonsensical maintenance decisions

[Carsten Mattner via arch-general]

On Fri, Apr 28, 2017 at 12:40 PM, fnodeuser  wrote:
> 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.



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.

Re: [arch-general] End of official PaX and grsecurity support in Arch Linux

[Carsten Mattner via arch-general]

On Thu, Apr 27, 2017 at 7:12 PM, Carsten Mattner
 wrote:
> Is CopperheadOS using grsec or something derived from it?

Found the technical details, it seems to be select grsec features
ported to AOSP but not a full port of grsec, which together with the
other hardening looks reasonable since it's a whole system/distro approach.

Re: [arch-general] End of official PaX and grsecurity support in Arch Linux

[Carsten Mattner via arch-general]

Is CopperheadOS using grsec or something derived from it?

Re: [arch-general] End of official PaX and grsecurity support in Arch Linux

[Carsten Mattner via arch-general]

This is an undesirable situation for users, but I want to offer a
positive outlook on this. Ever since KSPP started, some of the
dynamics started to shift and I wager that closing off grsec will
motivate more users and developers to consider supporting efforts that
are in mainline linux. Short-term this is a problem and may require
relying and hoping 4.9-lts-grsec will be available and functioning.
When Bitkeeper licensing was revoked from the community, it didn't
take long for git to emerge. I see a similar pattern and high
potential for repetition of the same dynamics here. No grsec will
force people to either subscribe ala RHEL and hope spender is able to
fulfill his end of the contract or supporting KSPP and seamless LSM
integration in major distro packages.

I must admit that spender may have started a process that will result
in arriving quicker at mainline kernel having a comparable set of
protections. Because as long as grsec was there and offered for
relatively recent kernels, there wasn't much motivation or arguments
to make to support a mainline reimplementation.

I believe this will light a fire under KSPP and related community
driven projects.

I faintly remember when there was OpenGrsec because grsec was dead or
zombie but that was at least a decade ago and my memory is probably
incomplete.

I mean some grsec users might consider fleeing to HardenedBSD since
they provide a whole system like Hardened Gentoo, especially those
using grsec on hosting servers where the availability of jails,
capsicum, zfs, dtrace, ports and hardenedbsd may have already looked
enticing.

Re: [arch-general] arch health

[Carsten Mattner via arch-general]

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.

Re: [arch-general] arch health

[Carsten Mattner via arch-general]

On Thu, Apr 20, 2017 at 8:27 PM, Mauro Santos via arch-general
 wrote:
> On 20-04-2017 20:21, Ralf Mardorf wrote:
>>> Have you reported the bug? If yes and the dev decides that it should be
>>> reverted to a previous version there is a way to do it, see:
>>> man pacman | grep -A1 epoch
>>
>> For 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_Arch.3F
>>
>> 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.

Re: [arch-general] arch health

[Carsten Mattner via arch-general]

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.

Re: [arch-general] About linux 4.8 and 4.9...

[Carsten Mattner via arch-general]

On Tue, Jan 10, 2017 at 8:14 PM, Eli Schwartz via arch-general wrote:
> On 01/10/2017 08:53 AM, Carsten Mattner via arch-general wrote:
>> My criticism of the stable patch queue is that they mix fixes
>> with actual feature patches, making it more risky and not
>> upholding a important fixes only policy.
>
> That would depend on whether you understand "stable" to be "LTS" or
> "let's not just pile on all the experimental stuff that may break
> everything".

Since drivers are bundled in the kernel tree, we regularly run into
many driver regressions and that's my primary objection to the
missing quality assurance there. The community is doing an
outstanding amount of testing already but the ranger of supported
hardware is not covered by the testers and constant churn of code
because it's part of a moving amalgamation in linux.git causes more
issues than we would have with drivers targering a kernel ABI.
One thing it would help make abundantly clear is when a driver
maintainer stops supporting an old driver version. Now it's russian
roulette for hardware to break when updating from one stable to
the next supported stable kernel. Like it happened with 4.2 in DRM
or the 4.9 boot problems which seem to be UEFI-exclusive.

> I am pretty sure there is already, in fact, an LTS kernel. You even
> mentioned it yourself.

There are multiple LTS branches with one LTS being Greg's tree.

Re: [arch-general] About linux 4.8 and 4.9...

[Carsten Mattner via arch-general]

FYI, 4.8 has been EOL'd, leaving 4.4-lts, 4.1-lts as options for
arch "default" kernel until 4.10 is released if we assume that
there's a critical fix in the stable patch queue.

My criticism of the stable patch queue is that they mix fixes
with actual feature patches, making it more risky and not
upholding a important fixes only policy.

Re: [arch-general] Getting freeze on early start with linux 4.9-1 kernel.

[Carsten Mattner via arch-general]

On Sat, Dec 24, 2016 at 4:33 PM, Mauro Santos
<registo.maill...@gmail.com> wrote:
> On 24-12-2016 14:14, Carsten Mattner wrote:
>> On Fri, Dec 23, 2016 at 3:17 PM, Mauro Santos via arch-general
>> <arch-general@archlinux.org> wrote:
>>> On 23-12-2016 13:58, Carsten Mattner via arch-general wrote:
>>>> On Fri, Dec 23, 2016 at 1:59 PM, fredbezies via arch-general
>>>> <arch-general@archlinux.org> wrote:
>>>>> Hello.
>>>>>
>>>>> I'm facing an annoying bug with linux 4.9-1 kernel on my 6 or 7 years
>>>>> old Toshiba Laptop. When I try to make it boot on with linux 4.9-1
>>>>> kernel, it freeze right after loading initramfs.
>>>>>
>>>>> 4.8.xx kernel was working flawlessly. My eeePC (nearly 9 years old)
>>>>> and my desktop computer (which is AMD based) are both starting with
>>>>> linux 4.9.
>>>>>
>>>>> I opened a bug : https://bugs.archlinux.org/task/52246
>>>>>
>>>>> Here is my lspci. If someone can help me finding what is happening,
>>>>> I'll be very happy :
>>>>>
>>>>> 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory
>>>>> Controller Hub (rev 07)
>>>>> 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series
>>>>> Chipset Integrated Graphics Controller (rev 07)
>>>>> 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset
>>>>> Integrated Graphics Controller (rev 07)
>>>>> 00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>>>>> UHCI Controller #4 (rev 03)
>>>>> 00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>>>>> UHCI Controller #5 (rev 03)
>>>>> 00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2
>>>>> EHCI Controller #2 (rev 03)
>>>>> 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio
>>>>> Controller (rev 03)
>>>>> 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
>>>>> Port 1 (rev 03)
>>>>> 00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
>>>>> Port 2 (rev 03)
>>>>> 00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
>>>>> Port 5 (rev 03)
>>>>> 00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>>>>> UHCI Controller #1 (rev 03)
>>>>> 00:1d.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>>>>> UHCI Controller #2 (rev 03)
>>>>> 00:1d.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>>>>> UHCI Controller #3 (rev 03)
>>>>> 00:1d.3 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>>>>> UHCI Controller #6 (rev 03)
>>>>> 00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2
>>>>> EHCI Controller #1 (rev 03)
>>>>> 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
>>>>> 00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev 
>>>>> 03)
>>>>> 00:1f.2 SATA controller: Intel Corporation 82801IBM/IEM
>>>>> (ICH9M/ICH9M-E) 4 port SATA Controller [AHCI mode] (rev 03)
>>>>> 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller 
>>>>> (rev 03)
>>>>> 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
>>>>> RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller (rev 02)
>>>>> 03:00.0 Ethernet controller: Qualcomm Atheros AR242x / AR542x Wireless
>>>>> Network Adapter (PCI-Express) (rev 01)
>>>>
>>>> Does the fallback boot entry work?
>>>>
>>>> Have you tried reinstalling the kernel?
>>>>
>>>> I wish arch would (like other distros) keep 2 or three old kernel
>>>> versions around because it doesn't take any space to do so
>>>> and works around boot bugs in new kernels.
>>>>
>>>
>>> Care to explain how "doesn't take any space" works? Last time I checked
>>> files do take up space. There is an LTS kernel in the repos, which you
>>> can have installed exactly for things like this.
>>
>> While writing that I knew somebody would read it in strict interpretation 
>> mode.
>> s/no space/not enough space in \/boot to matter/
>
> The kernel only mig

Re: [arch-general] Getting freeze on early start with linux 4.9-1 kernel.

[Carsten Mattner via arch-general]

On Fri, Dec 23, 2016 at 3:17 PM, Mauro Santos via arch-general
<arch-general@archlinux.org> wrote:
> On 23-12-2016 13:58, Carsten Mattner via arch-general wrote:
>> On Fri, Dec 23, 2016 at 1:59 PM, fredbezies via arch-general
>> <arch-general@archlinux.org> wrote:
>>> Hello.
>>>
>>> I'm facing an annoying bug with linux 4.9-1 kernel on my 6 or 7 years
>>> old Toshiba Laptop. When I try to make it boot on with linux 4.9-1
>>> kernel, it freeze right after loading initramfs.
>>>
>>> 4.8.xx kernel was working flawlessly. My eeePC (nearly 9 years old)
>>> and my desktop computer (which is AMD based) are both starting with
>>> linux 4.9.
>>>
>>> I opened a bug : https://bugs.archlinux.org/task/52246
>>>
>>> Here is my lspci. If someone can help me finding what is happening,
>>> I'll be very happy :
>>>
>>> 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory
>>> Controller Hub (rev 07)
>>> 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series
>>> Chipset Integrated Graphics Controller (rev 07)
>>> 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset
>>> Integrated Graphics Controller (rev 07)
>>> 00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>>> UHCI Controller #4 (rev 03)
>>> 00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>>> UHCI Controller #5 (rev 03)
>>> 00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2
>>> EHCI Controller #2 (rev 03)
>>> 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio
>>> Controller (rev 03)
>>> 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
>>> Port 1 (rev 03)
>>> 00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
>>> Port 2 (rev 03)
>>> 00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
>>> Port 5 (rev 03)
>>> 00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>>> UHCI Controller #1 (rev 03)
>>> 00:1d.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>>> UHCI Controller #2 (rev 03)
>>> 00:1d.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>>> UHCI Controller #3 (rev 03)
>>> 00:1d.3 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>>> UHCI Controller #6 (rev 03)
>>> 00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2
>>> EHCI Controller #1 (rev 03)
>>> 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
>>> 00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev 
>>> 03)
>>> 00:1f.2 SATA controller: Intel Corporation 82801IBM/IEM
>>> (ICH9M/ICH9M-E) 4 port SATA Controller [AHCI mode] (rev 03)
>>> 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 
>>> 03)
>>> 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
>>> RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller (rev 02)
>>> 03:00.0 Ethernet controller: Qualcomm Atheros AR242x / AR542x Wireless
>>> Network Adapter (PCI-Express) (rev 01)
>>
>> Does the fallback boot entry work?
>>
>> Have you tried reinstalling the kernel?
>>
>> I wish arch would (like other distros) keep 2 or three old kernel
>> versions around because it doesn't take any space to do so
>> and works around boot bugs in new kernels.
>>
>
> Care to explain how "doesn't take any space" works? Last time I checked
> files do take up space. There is an LTS kernel in the repos, which you
> can have installed exactly for things like this.

While writing that I knew somebody would read it in strict interpretation mode.
s/no space/not enough space in \/boot to matter/

> There is also the matter of automagic bootloader configuration change to
> support that, not to mention people that use efistub to boot their
> system, how do you propose to handle that?

If you have installed archlinux, it's reasonable to expect that one knows
how to configure this.

>> If this is a regression you will have to post dmesg. If you don't see
>> errors/warnings, then kernel developers would usually ask to enable
>> debug flags for printing more information during boot.
>>
>> That said, I have one old machine with a Core2Duo and GM4xx and
>> ever since DRM's atomic modesetting was introduced in 4.2, I can
>> only use 4.1 warning free. Regressions do happen but you had no
>> warnings or errors in 4.8 so yours looks like a different regression.
>>
>
> If you don't report the bugs upstream they don't get fixed, if you have
> reported it and no one got around to take a look at it then fine,
> otherwise don't be lazy and report those bugs and help get them fixed.

I did report it and it's been written off as "why do you care about the new
warning/stacktrace?". Given that I didn't bother trying to convince the
DRM devs of the importance since I don't have a RHEL or SLES support
contract I pay for.

Re: [arch-general] Getting freeze on early start with linux 4.9-1 kernel.

[Carsten Mattner via arch-general]

On Fri, Dec 23, 2016 at 1:59 PM, fredbezies via arch-general
 wrote:
> Hello.
>
> I'm facing an annoying bug with linux 4.9-1 kernel on my 6 or 7 years
> old Toshiba Laptop. When I try to make it boot on with linux 4.9-1
> kernel, it freeze right after loading initramfs.
>
> 4.8.xx kernel was working flawlessly. My eeePC (nearly 9 years old)
> and my desktop computer (which is AMD based) are both starting with
> linux 4.9.
>
> I opened a bug : https://bugs.archlinux.org/task/52246
>
> Here is my lspci. If someone can help me finding what is happening,
> I'll be very happy :
>
> 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory
> Controller Hub (rev 07)
> 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series
> Chipset Integrated Graphics Controller (rev 07)
> 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset
> Integrated Graphics Controller (rev 07)
> 00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB
> UHCI Controller #4 (rev 03)
> 00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB
> UHCI Controller #5 (rev 03)
> 00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2
> EHCI Controller #2 (rev 03)
> 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio
> Controller (rev 03)
> 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
> Port 1 (rev 03)
> 00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
> Port 2 (rev 03)
> 00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
> Port 5 (rev 03)
> 00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB
> UHCI Controller #1 (rev 03)
> 00:1d.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB
> UHCI Controller #2 (rev 03)
> 00:1d.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB
> UHCI Controller #3 (rev 03)
> 00:1d.3 USB controller: Intel Corporation 82801I (ICH9 Family) USB
> UHCI Controller #6 (rev 03)
> 00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2
> EHCI Controller #1 (rev 03)
> 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
> 00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev 03)
> 00:1f.2 SATA controller: Intel Corporation 82801IBM/IEM
> (ICH9M/ICH9M-E) 4 port SATA Controller [AHCI mode] (rev 03)
> 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 
> 03)
> 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller (rev 02)
> 03:00.0 Ethernet controller: Qualcomm Atheros AR242x / AR542x Wireless
> Network Adapter (PCI-Express) (rev 01)

Does the fallback boot entry work?

Have you tried reinstalling the kernel?

I wish arch would (like other distros) keep 2 or three old kernel
versions around because it doesn't take any space to do so
and works around boot bugs in new kernels.

If this is a regression you will have to post dmesg. If you don't see
errors/warnings, then kernel developers would usually ask to enable
debug flags for printing more information during boot.

That said, I have one old machine with a Core2Duo and GM4xx and
ever since DRM's atomic modesetting was introduced in 4.2, I can
only use 4.1 warning free. Regressions do happen but you had no
warnings or errors in 4.8 so yours looks like a different regression.

Re: [arch-general] Stronger Hashes for PKGBUILDs

[Carsten Mattner via arch-general]

On Sat, Dec 3, 2016 at 6:27 AM, fnodeuser  wrote:
> https://lists.archlinux.org/pipermail/arch-dev-public/2016-November/028492.html

I would suggest considering TUF - The Update Framework or stealing their
signing scheme which withstands all kinds of attack scenarios.

Re: [arch-general] On containers. WAS: Re: snapcraft.io ...

[Carsten Mattner via arch-general]

On Sat, Nov 26, 2016 at 3:23 PM, Maarten de Vries 

> To my knowledge, makechrootpkg uses systemd-nspawn, which means it is
> already using a container. Reproducible builds will need quite a bit more
> work than simply using containers though.

I only meant reproducible environment but failed to make that clear.
This is why I was mentioning a clean env with only what's required
to build per recipe and not mistakingly building with stuff that's
in /usr.

Re: [arch-general] On containers. WAS: Re: snapcraft.io ...

[Carsten Mattner via arch-general]

On Sat, Nov 26, 2016 at 3:23 PM, Bennett Piater  wrote:
>> Another very useful case would be using containers as a chroot replacement
>> for having clean (only what's in the recipe), reproducable build environments
>> for building arch packages. It would also allow installing makedeps only in
>> the container/chroot or make cross-compilation easier to manage.
>>
>> Are there plans to support this in makepkg? I believe xbps has this.
>
> Out of curiosity, what's wrong with makechrootpkg?

Thanks I wasn't aware of it.

Re: [arch-general] On containers. WAS: Re: snapcraft.io ...

[Carsten Mattner via arch-general]

On Sat, Nov 26, 2016 at 3:23 PM, Maarten de Vries <maar...@de-vri.es> wrote:
>
>
> On 26 November 2016 at 15:08, Carsten Mattner via arch-general
> <arch-general@archlinux.org> wrote:
>>
>>
>> Another very useful case would be using containers as a chroot replacement
>> for having clean (only what's in the recipe), reproducable build
>> environments
>> for building arch packages. It would also allow installing makedeps only
>> in
>> the container/chroot or make cross-compilation easier to manage.
>>
>> Are there plans to support this in makepkg? I believe xbps has this.
>
>
> To my knowledge, makechrootpkg uses systemd-nspawn, which means it is
> already using a container. Reproducible builds will need quite a bit more
> work than simply using containers though.
>
> And since this whole thread is widely off topic already, there is a totally
> different approach to isolating untrusted apps: cloudabi [1]. Instead of
> making isolated traditional posix environments to run untrusted
> applications, cloudabi makes it impossible to access global resources such
> as the filesystem and network by providing only a subset of system calls.
> For example, there is no `open()` syscall, but there is `open_at()`.
> Resources can be given to the process by leaving open file descriptors when
> it is exec'd, or by sending file descriptors to it over a unix socket.
>
> The biggest drawback is of course that existing software can't simply run
> under cloudabi because there are syscalls and libc functions missing. Also,
> controlling access to network resources is troublesome, but I like the
> general idea: instead of adding complexity of multiple isolated
> environments, cloudabi removes complexity by stripping system calls that can
> access global resources. There is a working patchset for the Linux kernel
> already, though not upstreamed yet. See [1] if you're interested.
>
> [1] https://nuxi.nl/

I know CloudABI from FreeBSD, where it's integrated like Capsicum
and netmap have been for a long time. It's unfortunate Linux suffers
from NIH in this context.

Re: [arch-general] On containers. WAS: Re: snapcraft.io ...

[Carsten Mattner via arch-general]

On Fri, Nov 25, 2016 at 7:01 PM, pelzflorian (Florian Pelz)
 wrote:
> Containers are an attempt to solve multiple issues. One is being a
> replacement for bundles. When people sell and distribute a proprietary
> app/game, they presumably want it to run on as many systems as possible
> with as little effort as possible. Having to rely on volunteer
> maintainers is not good, neither is having to maintain a lot themselves.
> Software bundles with all libraries included are the traditional
> solution to this on all operating systems. Flatpak seems like an even
> easier solution.
>
> The real issue in this discussion is security. Traditional GNU/Linux is
> too monolithic. Having more separation between an application and lower
> system layers adds security just like not using root for running a Web
> server and using separate user accounts for e.g. a Web server and an
> XMPP server does. Well-behaved software uses the self sandboxing you are
> talking about: dropping capabilities, revoking privileges. Two issues
> remain:
>
> Presumably most software (online games in particular) do not properly
> self-sandbox and are not secured very well. It’s safest not to install
> such software on your work PC but you may still wish to somewhat protect
> your gaming PC. Despite not knowing the software that well, we can try
> to constrain its privileges via containers/bubblewrap/firejail.
>
> What’s still missing however is proper filesystem isolation. Not every
> program needs to have access to any file in my home directory. More
> separation here is good for security. I don’t want to create a new user
> account for each app. I do want to use something like the new xdg
> desktop portals. I also want to hide what other software I have
> installed. I planned to do something with many small Arch Linux
> filesystems with inheritance through hardlinks, but maybe embracing Guix
> as an additional per-user package manager is a better approach?
>
> The same missing separation may be a reason to use Mach/Hurd over Linux.
> Of course that is still in its infancy.

I'm no fan of the container (docker) craze right now, but I also agree on
the benefits listed above. Further, some applications or suites like KDE
or GNOME can benefit from being bundled, but it's mostly developers
who want to provide a single bundle for all glibc distros that will benefit
in this regard.

The security aspect is real though since I also don't want all network
clients to have access to all of $HOME. How do you know that Dropbox
doesn't secretly copy your ~/proprietary-work-for-boeing folder?
Whitelisting what networked apps have access to in the filesystem is
very important.

Another very useful case would be using containers as a chroot replacement
for having clean (only what's in the recipe), reproducable build environments
for building arch packages. It would also allow installing makedeps only in
the container/chroot or make cross-compilation easier to manage.

Are there plans to support this in makepkg? I believe xbps has this.

Re: [arch-general] [arch-dev-public] todo list for moving http -> https sources

[Carsten Mattner via arch-general]

When it comes to security of online update mechanisms and that of
an index, TUF has a well designed scheme to be safe regardless of
http and plan for eventual leak/theft of signing keys.

I'd suggest anyone interest to have a look.

Re: [arch-general] Announcing pacpak

[Carsten Mattner via arch-general]

On Tue, Jul 19, 2016 at 8:37 PM, pelzflorian (Florian Pelz)
<pelzflor...@pelzflorian.de> wrote:
> On 07/19/2016 07:03 PM, Carsten Mattner via arch-general wrote:
>> This is a nice and useful project, but I think we could be served
>> better in the short term by having supported firejail profiles
>> for things like Firefox and LibreOffice that are easy to use.
>>
>
> Firejail is a different design with less filesystem isolation. We should
> have both, even in the long term. The more direct competitor to Firejail
> is Bubblewrap, not Flatpak/pacpak.
>
> That said, the documentation on Firejail on the wiki seems to contain
> the most important things. I’m not knowledgable enough about Firejail
> though. Network namespaces are missing in the wiki instructions. I don’t
> know if Firejail can restrict D-Bus access. In the past I could launch
> an unrestricted Nautilus from a Firejail’d Icecat, but apparently that
> no longer works. I don’t know enough about the advantages/disadvantages
> over Bubblewrap; apparently there is some disagreement about the scope,
> e.g. whether how Pulseaudio should be dealt with.

FWIW I couldn't get Firejail's Firefox profile to work.

What's the link for bubblewrap? It's such a generic term that it's
hard to look up.

Re: [arch-general] Announcing pacpak

[Carsten Mattner via arch-general]

This is a nice and useful project, but I think we could be served
better in the short term by having supported firejail profiles
for things like Firefox and LibreOffice that are easy to use.

Re: [arch-general] ocaml package out of date

[Carsten Mattner via arch-general]

On Wed, Jun 1, 2016 at 1:25 AM, phimosis haver via arch-general
 wrote:
> "The most recent version of OCaml is 4.03.0. It was released on 2016-05-25."
>
> https://www.archlinux.org/packages/extra/x86_64/ocaml/ is a super old
> version.

I believe most people use opam to install different OCaml version via
opam switch,
but you're right nonetheless and it should be updated.