Re: [arch-general] Heads up: After system update, LUKS fails with certain BIOS versions

[Markus Schaaf via arch-general]

Am 01.05.20 um 16:56 schrieb LuKaRo:

> [...] I tried cryptsetup open, luksOpen, luksDump and isLuks
> ..., all hanging after printing the header checksum.

May I ask if your headers are --type=luks or luks2?

Re: [arch-general] NFS "updates"?

[Markus Schaaf via arch-general]

Am 29.04.20 um 13:44 schrieb Andy Pieters:

> While it is relatively trivial to compile your own kernel with those
> options enabled using Arch's build system, I think you'd better talk to the
> actual people that made the change upstream.
> 
This change might have slipped through unnoticed. It seems idiotic:
_Add_ code to the kernel, to break users systems, with no benefit
whatsoever. It's clearly against Linus' agenda to not break userland.
But to tell the users to discuss this upstream is bad advice. This is a
situation where a distribution should take corrective action by
reverting this configuration. This would add value and remove some
useless code from the kernel.

BR

Re: [arch-general] NFS "updates"?

[Markus Schaaf via arch-general]

Am 27.04.20 um 20:00 schrieb Leonidas Spyropoulos via arch-general:

> It's a kernel configuration which is introduced with 5.6 kernel. In my
> CONFIG_NFS_DISABLE_UDP_SUPPORT=y

Wow! I'd say udp is used a lot with nfsvers=3. That will break many nfs3
deployments.

Re: [arch-general] NFS "updates"?

[Markus Schaaf via arch-general]

Am 27.04.20 um 16:51 schrieb Hauke Fath:

> NFSV4: Unsupported transport protocol udp

Have you tried vers=3 in mount options?

Re: [arch-general] Hibernation Failure

[Markus Schaaf via arch-general]

Am 23.04.20 um 10:14 schrieb Paul Dann via arch-general:

> it down to a kernel update. That being said, I don't hibernate
> regularly, so maybe I've just been lucky :p

Probably. I needed to read some of the code and it hasn't changed lately
AFAIK. My guess is that the problem has something to do with the
integrity journal. I had it disabled, but it's read on cryptsetup open
anyway. After all I didn't like the (inflexible) data layout (which
leads to write amplification), and the journal (and perhaps some of the
code) of dm-integrity, so I've formatted all disks back to aes-xts. :-)

And remember to print your backup keys on paper.

BR

Re: [arch-general] Hibernation Failure

[Markus Schaaf via arch-general]

Am 12.01.20 um 12:19 schrieb Markus Schaaf via arch-general:
> 
> 
> Am 12.01.20 um 01:39 schrieb Paul Dann via arch-general:
>> I'm having trouble getting hibernation to work on my new Dell Inspiron
>> 7590. It seems that the image is stored correctly (onto LUKS+LVM thin-lv),
> 
> I've noticed something similar on a similar setup. It looks like the
> kernel is taking some shortcuts when accessing the (swap-) space during
> hibernation, which are not compatible with dm-crypt. I'm using an AEAD
> cipher and the integrity data is wrong after resume.

I know it is terribly late, but for those curious:

While investigating this I managed to make my laptop unbootable, because
dm-crypt decided that every single sector on my encrypted partition had
a bad AEAD tag and wouldn't let me read a single byte. That was exactly
what had been happening to my swap-partition before, when I tried to
resume from hibernation. But this time it had eaten my root-partition
too. Of course I had backups, encrypted (of course), with a key I had
changed recently ... that I knew I needed to save somewhere else, but
somehow forgot to.

I'm writing this on exactly that laptop, restored completely from the
"unreadable" SSD. But it took me some time to read the relevant kernel
code, develop and run some helpful tools to search and decrypt the data
on said partition.

What I have found: It is unlikely that hibernation is the cause to the
problem I have encountered. It is just the trigger. Somehow dm-integrity
or dm-crypt manages to fuck up it's on-disk meta-data. (Meanwhile the
same happened to my work desktop, which had a similar setup, after
suspend to RAM.) After I had determined the exact encryption algorithm
and layout of my data, I was able to not only read all of it, but the
on-disk integrity-tags matched 100%. Every single sector.

BR

Re: [arch-general] Hibernation Failure

[Markus Schaaf via arch-general]

Am 12.01.20 um 01:39 schrieb Paul Dann via arch-general:
> I'm having trouble getting hibernation to work on my new Dell Inspiron
> 7590. It seems that the image is stored correctly (onto LUKS+LVM thin-lv),

I've noticed something similar on a similar setup. It looks like the
kernel is taking some shortcuts when accessing the (swap-) space during
hibernation, which are not compatible with dm-crypt. I'm using an AEAD
cipher and the integrity data is wrong after resume.

BR

Re: [arch-general] kernel compilation

[Markus Schaaf via arch-general]

Am 28.03.19 um 11:25 schrieb Pascal via arch-general:

> after compilation, if I modify/patch file src/linux-4.19/block/blk-core.c,
> do I have to replace the kernel ? the kernel and all its modules ? or just
> the module concerned by the change (if it concerns a module) ?

You just need to replace the affected binaries, if kernel version and
all configuration stays the same. Of course it would be better to make a
proper package. You may package out-of-tree modules separately, but you
need a full kernel package for in-tree modules. Have a look at the
PKGBUILDs in the repositories. There are examples for both.

KR

Re: [arch-general] Revisiting the SELinux/audit question: Disabling audit on the kernel command line

[Tobias Markus]

Hi,

On Sun, 2017-02-12 at 20:53 +0100, SET wrote:
> Le dimanche 12 février 2017 18:43:22 CET Tobias Markus a écrit :
> > I would be glad if Arch Linux's official kernel could support SELinux
> > again this way!
> > https://lists.archlinux.org/pipermail/arch-general/2014-March/035679.html
> 
> Thank you for the link you posted. I went through most of the discussion.
> This 
> quote is what strikes me most :
> https://lists.archlinux.org/pipermail/arch-general/2014-March/035658.html
> 
> > That they are disabled at runtime does not mean that they have no impact
> > at runtime. At best, it's "only" a performance impact and at worst, it
> > even causes problems.

The performance reasoning in that threat never really talked about hard metrics,
it was mostly looking at kernel code and guessing what performance impact it
would have. While I do think that there is no such thing as a free lunch, to my
knowledge there are no recent benchmarks comparing syscall performance with and
without the SELinux/audit config options.

> 
> Everything has already been discussed. The global conclusions seem to be :
> 
> Most users don't need SELinux/AppArmor or anything that protects them from 
> themselves;
> Implementing these features in the kernel may lead to more trouble than ease;
> Arch kernel's devs and other devs are not ready for the tremendous tasks 
> following such a decision;

I'm not quite sure which tremendous task you mean? Enabling the audit/SELinux
config option in itself is not really a maintenance burden.

> These features can be compiled in personal kernels if required;

Yes, of course - but wouldn't you agree that the Wiki page asking you to compile
your own kernel first somewhat hinders users interested in trying out SELinux?
Furthermore, I don't think that the theoretical next step in Arch Linux SELinux
support, i.e. userspace tools in [community]/[extra], could ever be reasonably
done if the actual kernel does not support SELinux.

> Arch devs do that on a voluntary basis and can't respond to all requests.
> 
> For me, I'm happy with Arch as it is, I'm happy the previous discussion led
> to 
> the 'no need' conclusion, and I just want to voice I wish it goes on this way.
> 
> Regards.

Greetings
Tobias

Re: [arch-general] Revisiting the SELinux/audit question: Disabling audit on the kernel command line

[Tobias Markus]

On Sun, 2017-02-12 at 23:13 +0100, Nicolas Iooss wrote:
> On Sun, Feb 12, 2017 at 6:43 PM, Tobias Markus  wrote:
> 
> > Hi,
> > 
> > As some of you might know, the question of enabling SELinux support in
> > the official Arch Linux kernel package has been brought up a number of
> > times. The main issue that has been pointed out the previous time was
> > that enabling SELinux depends on CONFIG_AUDIT which is considered
> > unnecessary or even harmful for most desktop users since it generates a
> > flood of kernel log messages.
> > 
> 
> Hi,
> Do you have more information about this unwanted flood of messages? From my
> personal experience on systems with SELinux and audit, the application
> which produces the biggest number of audit events is Chromium, because of
> misconfigured seccomp rules that report in audit log every call to
> set_robust_list(). This has been reported two years ago on Chromium bug
> tracker and the developers seem unwilling to fix it (
> https://bugs.chromium.org/p/chromium/issues/detail?id=456535). If there are
> similar problems which need to be fixed before thinking of enabling audit
> compilation in Arch Linux kernel, where can I find information on them?
> 
> Regards,
> Nicolas

Hi Nicolas,

I have also seen a flood of audit messages arising from Chromium.
However, the configuration I propose would not actually enable audit by default,
i.e. unless you explicitly set "audit=1" in the bootloader's kernel command
line, the audit subsystem will be disabled and thus silent. In other words, if
you don't want to use SELinux/audit, the impact should be minimal.

Since the Chromium bug you mentioned is an application bug, I don't think it
should hinder enabling the audit option, especially since audit would be opt-in.

The reason for Chromium's message floods is that Chromium create quite a lot of
processes and (as written in the bug report you mentioned) set_robust_list is
called during that. So floods of audit messages should be rather atypical.

Greetings
Tobias

Re: [arch-general] Revisiting the SELinux/audit question: Disabling audit on the kernel command line

[Tobias Markus]

On Sun, 2017-02-12 at 14:02 -0700, Leonid Isaev wrote:
> On Sun, Feb 12, 2017 at 06:43:22PM +0100, Tobias Markus wrote:
> > I would be glad if Arch Linux's official kernel could support SELinux
> > again this way!
> 
> AFAIR, coreutils and many other things need to be rebuilt to support selinux.
> 

Hi Leonid,

this really is just about the kernel, not the related userspace tools.

Of course it would be great to have SELinux tools in an official Arch 
repository,
but that is another question entirely. And I guess there will be no tools if
the official kernel doesn't support SELinux.

Greetings
Tobias

[arch-general] Revisiting the SELinux/audit question: Disabling audit on the kernel command line

[Tobias Markus]

Hi,

As some of you might know, the question of enabling SELinux support in
the official Arch Linux kernel package has been brought up a number of
times. The main issue that has been pointed out the previous time was
that enabling SELinux depends on CONFIG_AUDIT which is considered
unnecessary or even harmful for most desktop users since it generates a
flood of kernel log messages.

Citing Thomas Bächler's previous post (in 2014) on the matter [1]:

> And here is my problem: Audit is enabled by default and must be
> explicitly disabled by the admin. This is a showstopper for me! There
> is no kernel option to configure audit to be disabled by default (as
> far as I am aware) so that it can be enabled with 'audit=1' on the
> command line.

Actually, I think there is a perfectly valid and simple way to disable
audit by default: By using the built-in kernel command line. This makes
it possible to specify a number of kernel parameters at build time that
 the kernel prepends to the usual command line it gets from the
bootloader. By specifying

CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE="audit=0"

in the configuration [2], the audit subsystem is disabled by default,
but users intending to use it can do so by manually setting audit=1 on
the bootloader's command line. That in turn would override the audit=0
specified on the built-in command line.

I would be glad if Arch Linux's official kernel could support SELinux
again this way!

Thanks for your comments,
Tobias

[1] https://lists.archlinux.org/pipermail/arch-general/2014-March/03567
9.html
[2] For menuconfig, look at the very end under "Processor type and
features"

Re: [arch-general] lockscreen doesn't work anymore

[Markus Germann]

Maybe not related, but my cinnamon-screensaver also started causing
issues with this update.
Its tasks take 100% CPU usage on several cores, severely slowing down
the PC and cause it to be almost unusable.
I have to kill them by hand to have control again.

Am 09.11.2016 um 01:14 schrieb Apfelkuchen:
> Hey,
> 
> I use cinnamon as my desktop environment. Today I upgraded the packages
> to the newest version:
> 
>> cinnamon 3.2.1-1
>> cinnamon-control-center 3.2.0-1
>> cinnamon-desktop 3.2.0-1
>> cinnamon-menus 3.0.2-1
>> cinnamon-screensaver 3.0.1-2
>> cinnamon-session 3.2.0-1
>> cinnamon-settings-daemon 3.2.0-1
>> cinnamon-translations 3.2.0-1
> 
> After this upgrade, I can't lock my screen anymore. I get this output from
> 
> $ cinnamon-screensaver --debug
> 
>> [gs_debug_init] gs-debug.c:109 (01:11:31):   Debugging enabled
>> [main] cinnamon-screensaver.c:86 (01:11:31): initializing 
>> cinnamon-screensaver 3.0.1
>>
>> (cinnamon-screensaver:15994): GLib-GIO-ERROR **: Settings schema 
>> 'org.cinnamon.desktop.screensaver' does not contain a key named 
>> 'logout-enabled'
>> Trace/Breakpoint ausgelöst (Speicherabzug geschrieben)
> 
> 
> Can anyone help me?
> 
> Thanks and greetings,
> pete
> 

[arch-general] [extra] festival packge (Orphan)

[Tobias Markus]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi list,

I hope this is the right place to post.

The festival package (in [extra]) has been an orphan and out-of-date for a 
while, 2.1 is packaged, 2.4 is available. I fixed some of the errors coming up 
when trying to build festival 2.4 in the festival-patched-hts package (AUR) 
[1], and it works quite well now. The PKGBUILD can be modified for the 
non-HTS-patched version quite easily, only removing the relevant patches, and I 
kept modifications to a necessary minimum (to make it obvious I don't have any 
bad intentions...). Because of this, I wonder if some package maintainer could 
pick the actual festival package up and apply my changes to make it work with 
2.4.

I encountered a build error that is very likely an upstream bug [2], but I 
don't have time to report it right now. A workaround until the issue is 
resolved upstream is included. Aside from that, I changed the MD5 hashes to 
SHA-256 hashes and removed some parts of the some of the compatibility patches 
that were made obselete by upstream changes.

Please do not hestitate to ask me further questions regarding the changes 
involved.

Thank you very much in advance,
Best regards
Tobias

[1] https://aur4.archlinux.org/packages/festival-patched-hts/
[2] festival/src/modules/clustergen/HTS_vocoder_me.cc includes a C file (not a 
header!), namely festival/src/modules/hts_engine/HTS_vocoder.c, causing linkage 
errors (multiple definitions of symbol). Workaround is a header file and some 
uncontroversial non-breaking changes.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlW314IACgkQAO6N0EYmC9b0jgCgugOF+IgM7l7qfzIP+QmEETHA
4+YAmwUwmghQEkSXf3F/0Y4mdC8CBaTk
=wg7q
-END PGP SIGNATURE-

Re: [arch-general] build and test packages automatically

[Markus M. May]

On 22.12.2013 12:51, Guangyu Zhang wrote:

Hello,

I want to build an repository. I need a software to build and test packages
automatically, and to show the status of all packages which is just like
the buildd <http://www.debian.org/devel/buildd/> in Debian. I have been
looking for it via Google, but nothing found.
I have build a specific buildbot configuration, which could be adopted 
to your needs most probably. Right now it uses github as its source for 
changes. Buildbot basically checks for changes in the github repository 
and will then build the packages. Right now there is now way to build 
"dependent" packages, so you have to start the build of each "package" 
automatically.



Can anybody give me some advice? I also wonder what software is used by
official developers to manage the main repository.
I am not an official developer, but thought this could be interesting 
anyways. See https://github.com/pacNAS/pnbuildbot.



Thanks,

Guangyu

R,

Markus

Re: [arch-general] aur down?

[Markus Unterwaditzer]

On 2012-10-26 21:04, Leonidas Spyropoulos wrote:

Is aur server down?


It does seem so to me. "Connection refused" from ISP A1 in Austria, 
with Chromium as well as with wget, both https and http.


-- Markus

Re: [arch-general] "whitebox" on bootup after KMS kicks in

[Markus M. May]

On 28.05.2011 21:41, Rogutės Sparnuotos wrote:

C Anthony Risinger (2011-05-28 00:02):

does anyone else experience?

i've been getting this for sometime -- on intel, nouveau, and radeon
KMS drivers -- and it looks terrible.  after the module loads within
initramfs, the space *within* the old resolution is pure white,
surrounded by normal black.  i'm pretty sure the "whitebox"
corresponds to the size of the previous resolution because it's
different sizes on all my machines, and pretty small on my 1920x1280
laptop (@ 15.5in ... awesome :-)

anyways, long story short it turns back 2 black when written over
(systemd/initscripts output) or cleared, so:

echo -en '\e[H\e[2J'

... takes care of it.  i basically just did a `clear>  out`, looked at
the codes, and made a small initramfs hook from the above.

it works fine as is, but is anyone else seeing this?  it annoys me
because i don't run getty on tty1, so it's there forever unless i
clear right away.  not really a big deal, as it took longer to write
this msg than fix it, but it started happening a few kernels ago IIRC
and i'm wondering if we can just throw something like this into
mkinitcpio (if `quiet`, or before output), because it looks terrible
:-(

i'll open a report unless someone feels like throwing it in there,
it's a pretty simple change.

No white boxes here with radeon KMS (built-in) under 2.6.38.3. Actually, I
can even see the "PCI Device Listing ..." table from the BIOS when I
switch to tty1.
Hm, me is having the same problems, using Grub 2. This problem is only 
seen, if I do use the external Graphic card in the laptop I am using.

No white boxes on another PC with radeon, Arch's kernel26 and initramfs.


R,

Markus

[arch-general] GSoC 2011 - Submission

[Markus M. May]

Hello,

since I haven't heard anything from you, I will submit the AS stuff without any 
attachements to AL.

R,

Markus

[arch-general] GSoC 2011 - Join forces

[Markus M. May]

Hello,

there seem to be some interest in the participation of Arch Linux on GSoC 2011. 
The ArchServer community has decided to participate, but since we are a small 
and quite new project, we do not think to get accepted.

So why not join forces in this effort. I guess we do have similar goals (e.g. 
every Arch Linux based distro will benefit from the extension of pacman).

ArchServer can bring the application to the plate, which will need to get 
adapted to the new structure obviously 
(http://wiki.archserver.org/index.php/GSoC2011_Application). I envision some 
umbrella project for Arch Linux, ArchServer and probably even other Arch Linux 
based distros. Of course we do have a very tough timeframe to get this up.

What do you think?

R,

Markus

Re: [arch-general] Replace dcron once again?

[Markus Trippelsdorf]

Thorsten Töpper wrote:

> On Sun, 7 Nov 2010 21:09:12 +0100
> Heiko Baums  wrote:
>> Am Sun, 7 Nov 2010 13:57:50 -0500
>> schrieb Kaiting Chen :
>> 
>> > I think fcron is kind of heavy for most users. I'd rather we switch
>> > to cronie, which is the descendent of vixie-cron. It's developed by
>> > RedHat, well maintained, supports PAM and SELinux and can be built
>> > with anacron features.
>> 
>> I disagree with Kaiting, because cronie doesn't have anacron features.
>> 
>> If it's compiled with --enable-anacron there is no anacron feature
>> compiled into cronie. Instead there is a separate anacron daemon
>> compiled and that makes it unnecessarily complicated in using and
>> configuring it. And people who need anacron features have to run two
>> daemons and configure two daemons.
>> 
>> With fcron you have all in one and need to run and configure only one
>> daemon. And fcron is by far not bloated and complicated to configure.
>> Instead there are several ways to configure fcron like crontab,
>> scripts in /etc/cron.{daily,weekly,monthly} and in /etc/cron.d. And
>> to use anacron features you only need to prefix a crontab entry with
>> an @.
>> 
>> So I think fcron is much more flexible, much easier to configure and
>> to use than cronie, and has features for rather every use case.
>> 
>> And, please, don't make such a regression again.
>> 
>> Btw., cronie is in AUR since May and still has only 1 vote while fcron
>> is proven to run very well since years.
>> 
>> Heiko
> 
> I agree with Heiko and Florian, I myself am using fcron since spring
> and moved at my machines(including VMs that run more often) one after
> another to fcron and I'm happy with it. It's easy to configure, comes
> with the default jobs (=runs /etc/cron.{daily,weekly,monthly}/*) and
> thus if for a user who doesn't do much with cron nothing to worry
> about, everyone else gets next to the default possibilities several
> features that are really helpful. Furthermore it is well documented,
> so even people who begin to play with cronjobs have a spot where they
> can look for information and get an answer almost for sure.

+1
and don't forget that you can see what job will run when:
 
# fcrondyn -x ls
password for root :
IDUSER   SCHEDULE CMD
14markus 11/07/2010 22:20 /usr/bin/getmail -q
0 systab 11/07/2010 23:01 /usr/sbin/run-cron /etc/cron.hourly
12root   11/07/2010 23:50 /usr/bin/rsnapshot daily
13root   11/08/2010 00:00 /usr/bin/rsnapshot hourly
1 systab 11/08/2010 00:02 /usr/sbin/run-cron /etc/cron.daily
10root   11/08/2010 02:15 /usr/sbin/trim /
11root   11/13/2010 23:40 /usr/bin/rsnapshot weekly
2 systab 11/14/2010 00:22 /usr/sbin/run-cron /etc/cron.weekly
3 systab 12/01/2010 00:42 /usr/sbin/run-cron /etc/cron.monthly

This is very useful for consistency checking.

Re: [arch-general] nvidia and xorg-server 1.9

[Markus Golser]

I'm wondering if there are any known regressions for h264 playback
(vdpau) 64bit nvidia stable

Re: [arch-general] Google-Chrome

[Markus Golser]

> what's wrong with chromium from our repos?
it's old

Re: [arch-general] Script to check monitor blank state

[Markus]

On 25.05.2010 19:17, "Jérôme M. Berger" wrote:
>   Here, "xset q" has a line that says: "Monitor is On". Couldn't you
> use that?
> 
>   Jerome

Yes this seems actually very useful,
i had dpms inactive, but ScreenSaver blanking on.
Maybe someone knows what the difference between these two is all about.
It looks totally equal from the "outside" ;-)

Now that I activated dpms, there is this line indicating the state.

xset q | awk '{if (match($0,"Monitor is On")) {print "notblanked"}}'

I am going to use this little check for my script.

Thank you for your help!

Markus

[arch-general] Script to check monitor blank state

[Markus]

Hello everyone,

i would like to write a little script, that suspends my computer
if a few circumstances are met.

One should be, that my screen should be blanked. I already did a google
search on this, but i only found howtos of getting it to work / disable it.

It looks like xset q does not print the actual state.
Maybe there is a hook for screen blanking?

I know this is not a arch specific question, but maybe someone can help me.

Markus

[arch-general] Battery Monitor Applet (kde4) hangs after s2ram

[Markus Golser]

Hi, after I resume from s2ram my battery monitoring applet does not
refresh anymore.
It shows 100% loaded and plugged in all the time.

I have to kill plasma every time in order to get the current charge.

cat /sys/class/power_supply/BAT0/charge_now <- shows the correct charge.

Maybe someone can help me.


Notebook = Dell Inspiron 9400

[arch-general] [PATCH] automatically mount debugfs

[Markus Trippelsdorf]

Here is a patch for rc.sysinit to automatically mount the kernel's
debugfs, if available.

(I switched from Gentoo to Arch two days ago and first sent this message
to arch-dev-public which turned out to be read-only. Maybe a hint on the
mailman page would be nice, to spare future newbies the same experience?)

--- rc.sysinit_old  2009-10-14 20:08:56.776237753 +0200
+++ rc.sysinit  2009-10-14 20:40:28.227216838 +0200
@@ -19,6 +19,13 @@
 /bin/mount -n -t proc none /proc
 /bin/mount -n -t sysfs none /sys
 
+# mount debugfs, if available
+if [ -d /sys/kernel/debug ]; then
+   if grep -qs debugfs /proc/filesystems; then
+   mount -n -t debugfs -o nodev,noexec,nosuid debugfs 
/sys/kernel/debug
+   fi
+fi
+
 # Copy static device nodes to /dev
 /bin/cp -a /lib/udev/devices/* /dev/
 
@@ -288,7 +295,7 @@
 /bin/mount -o remount,rw /
 # Write /proc, /sys and /dev to /etc/mtab
 if [ -e /proc/mounts ]; then
-   /bin/grep -e "/proc " -e "/sys " -e "/dev " /proc/mounts >> /etc/mtab
+   /bin/grep -e "/proc " -e "/sys " -e "/dev " -e "debugfs" /proc/mounts 
>> /etc/mtab
 fi
 # now mount all the local filesystems
 /bin/mount -a -t $NETFS -O no_netdev
-- 
Markus

[arch-general] Can't compile digikam 0.10 on archlinux.

[Markus Golser]

Hi I try to build digikam 0.10 on archlinux.

I have kdegraphics 4.2.3-1 installed and still can't compile digikam

sudo abs
cp -r /var/abs/extra/digikam/ /tmp
cd /tmp/digikam/
makepkg PKGBUILD

-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Looking for Q_WS_X11
-- Looking for Q_WS_X11 - found
-- Looking for Q_WS_WIN
-- Looking for Q_WS_WIN - not found.
-- Looking for Q_WS_QWS
-- Looking for Q_WS_QWS - not found.
-- Looking for Q_WS_MAC
-- Looking for Q_WS_MAC - not found.
-- Found Qt-Version 4.5.1 (using /usr/bin/qmake)
-- Looking for XOpenDisplay in
/usr/lib/libX11.so;/usr/lib/libXext.so;/usr/lib/libXft.so;/usr/lib/libXau.so;/usr/lib/libXdmcp.so;/usr/lib/libXpm.so
-- Looking for XOpenDisplay in
/usr/lib/libX11.so;/usr/lib/libXext.so;/usr/lib/libXft.so;/usr/lib/libXau.so;/usr/lib/libXdmcp.so;/usr/lib/libXpm.so
- found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Looking for IceConnectionNumber in ICE
-- Looking for IceConnectionNumber in ICE - found
-- Found X11: /usr/lib/libX11.so
-- Looking for include files CMAKE_HAVE_PTHREAD_H
-- Looking for include files CMAKE_HAVE_PTHREAD_H - found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Found Automoc4: /usr/bin/automoc4
-- Found Perl: /usr/bin/perl
-- Performing Test _OFFT_IS_64BIT
-- Performing Test _OFFT_IS_64BIT - Failed
-- Performing Test HAVE_FPIE_SUPPORT
-- Performing Test HAVE_FPIE_SUPPORT - Success
-- Performing Test __KDE_HAVE_W_OVERLOADED_VIRTUAL
-- Performing Test __KDE_HAVE_W_OVERLOADED_VIRTUAL - Success
-- Performing Test __KDE_HAVE_GCC_VISIBILITY
-- Performing Test __KDE_HAVE_GCC_VISIBILITY - Success
-- Phonon Version: 4.3.0
-- Found Phonon: /usr/lib/libphonon.so
-- Found Phonon Includes: /usr/include/KDE;/usr/include
-- Found KDE 4.2 include dir: /usr/include
-- Found KDE 4.2 library dir: /usr/lib
-- Found the KDE4 kconfig_compiler preprocessor:
/usr/bin/kconfig_compiler
-- Found automoc4: /usr/bin/automoc4
-- checking for module 'lcms'
--   found lcms, version 1.18
-- Found lcms version 1.18, /usr/lib/liblcms.so
-- Found JPEG: /usr/lib/libjpeg.so
-- Found ZLIB: /usr/lib/libz.so
-- Found PNG: /usr/lib/libpng.so
-- Found TIFF: /usr/lib/libtiff.so
-- Found Jasper: /usr/lib/libjasper.so
-- Check Kdcraw library in local sub-folder...
-- Check Kdcraw library using pkg-config...
-- WARNING: you are using the obsolete 'PKGCONFIG' macro use
FindPkgConfig
-- PKGCONFIG() indicates that libkdcraw is not installed (install the
package which contains libkdcraw.pc if you want to support this
feature)
-- Check Kexiv2 library in local sub-folder...
-- Check Kexiv2 library using pkg-config...
-- WARNING: you are using the obsolete 'PKGCONFIG' macro use
FindPkgConfig
-- PKGCONFIG() indicates that libkexiv2 is not installed (install the
package which contains libkexiv2.pc if you want to support this
feature)
-- Check Kipi library in local sub-folder...
-- Check Kipi library using pkg-config...
-- WARNING: you are using the obsolete 'PKGCONFIG' macro use
FindPkgConfig
-- Found libkipi release < 0.2.0, too old
-- Found gphoto2: -L/usr/lib -lgphoto2_port;-L/usr/lib -lgphoto2
-lgphoto2_port -lm
-- checking for module 'libkdcraw>=0.4.0'
--   package 'libkdcraw>=0.4.0' not found
-- checking for module 'libkexiv2>=0.5.0'
--   package 'libkexiv2>=0.5.0' not found
-- Found KdepimLibs: /usr/lib/cmake/KdepimLibs-4.2.3/KdepimLibsConfig.cmake
-- WARNING: you are using the obsolete 'PKGCONFIG' macro use FindPkgConfig
-- Found LensFun: /usr/include
--
-- 
--
--  digiKam 0.10.0 dependencies results   
--
--  Qt4 SQL module found YES
--  libjpeg library found... YES
--  libtiff library found... YES
--  libpng library found YES
--  libjasper library found. YES
--  liblcms library found... YES
--  libkipi library found... NO
--
CMake Error at CMakeLists.txt:175 (MESSAGE):
  digiKam needs libkipi library >= 0.2.0. You need to install libkipi first


--  libkipi website is at http://www.digikam.org/sharedlibs
--
--  libkexiv2 library found. NO
--
CMake Error at CMakeLists.txt:185 (MESSAGE):
  digiKam needs libkexiv2 library >= 0.5.0. You need to install 

Re: [arch-general] gran paradiso crashes permanently

[Markus Krell]

Pierre Schmitz wrote:
In most cases the problem is somewhere in your user configuration. Try to move 
~/.mozilla somewhere else in order to see if it still crashes with a clean 
config.


Tried this, but firefox still segfaults after browsing trough a few sites.

Alessandro Doro wrote:
> Try this:
> 
http://www.nabble.com/-Cooker--Acroread-problem-solved-to12261537.html#a12261537


Yes thanks, this command made these obscure failure messages go away, 
but the original problem still exists.


So even with a clean config firefox crashes.

Markus

Re: [arch-general] gran paradiso crashes permanently

[Markus Krell]

Alessandro Doro wrote:

Try to change gtk/gnome theme to something not using the murrine engine.

Tip: next time
$ LANG=C your command


Yes thanks, LANG=C is a good hint.
I changed the theme, but this didnt change anything. Still getting:

Xlib:  extension "RANDR" missing on display ":0.0".
Xlib:  extension "Generic Event Extension" missing on display ":0.0".
Xlib:  extension "Generic Event Extension" missing on display ":0.0".
Xlib:  extension "Generic Event Extension" missing on display ":0.0".
Xlib:  extension "Generic Event Extension" missing on display ":0.0".
Xlib:  extension "Generic Event Extension" missing on display ":0.0".

(firefox:11379): atk-bridge-WARNING **: AT_SPI_REGISTRY was not started 
at session startup.


(firefox:11379): atk-bridge-WARNING **: IOR not set.

(firefox:11379): atk-bridge-WARNING **: Could not locate registry
[1]11379 segmentation fault (core dumped)  LANG=C firefox

I dont know what to do now, hum i will try a firefox directly from 
Mozilla and have a look, if this problem still exists.


Markus

Re: [arch-general] gran paradiso crashes permanently

[Markus Krell]

It's strange, firefox shouldn't detache from the console. Check if there
is any running firefox instance.

And have a look at ~/.xsession-errors.


Ok you were right, firefox does not detach from console. I just caught 
this output.


--
139 mar...@zoidberg ~ % firefox
Xlib:  extension "RANDR" missing on display ":0.0".
Xlib:  extension "Generic Event Extension" missing on display ":0.0".
Xlib:  extension "Generic Event Extension" missing on display ":0.0".
Xlib:  extension "Generic Event Extension" missing on display ":0.0".
Xlib:  extension "Generic Event Extension" missing on display ":0.0".

(firefox:10442): Gtk-WARNING **: Im Modulpfad »murrine« konnte keine 
Themen-Engine gefunden werden,

Xlib:  extension "Generic Event Extension" missing on display ":0.0".

(firefox:10442): atk-bridge-WARNING **: AT_SPI_REGISTRY was not started 
at session startup.


(firefox:10442): atk-bridge-WARNING **: IOR not set.

(firefox:10442): atk-bridge-WARNING **: Could not locate registry
[1]10442 segmentation fault (core dumped)  firefox
--

So firefox segfaults... hum very interesting.

Markus

Re: [arch-general] gran paradiso crashes permanently

[Markus Krell]

Did you try with firefox -safe-mode?


Jep tested it right now, still those crashes after a maximum runtime of 
1 Minute.

[arch-general] gran paradiso crashes permanently

[Markus Krell]

Hi arch users out there,

since a few weeks, my firefox crashes permanently.
I disabled all three Add Ons, i had installed, but still no difference.

Really annoying, so is there any possibility to find out why firefox 
crashes, often a few minutes after starting?
Launched from shell, firefox detaches directly, so i dont know where to 
look first.


Version is up to date: 3.0.7-1

Thx for any answers.

Markus

Re: [arch-general] [arch-dev-public] Linuxtag 2009

[Markus Heuser]

Hey guys,

> > > http://www.linuxtag.org:80/2009/
> > > 24. till 27. June in Berlin.

I'll be there but most time hang at the FSFE-Booth. Since we have no schedule 
yet I can't tell, when exactly I will be there.
So if you guys want have a booth and are short of manpower I can perhaps help 
out a bit.

Last year I had the impression that the LinuxTag becomes more and more 
business-like which is a trend I don't really like.

Greets,
Markus

Re: [arch-general] new here and need some help, please...

[Markus Heuser]

Hey,

Basically ArchLinux Repos are enabled by two lines:

1: [Reponame]
2: Where to find the repo

The second line may be a bit tricky, because it be either a specific server 
(indicated by "Server = http://foo.bar";) or a list of servers resp. mirros 
(indicated by "Include = /foo/bar"). For the official ArchLinux-Repositories 
you 
will find the following entries in your /etc/pacman.conf

> [core]
> Include = /etc/pacman.d/mirrorlist
>  
> [extra]
> Include = /etc/pacman.d/mirrorlist
>
> [community]
> Include = /etc/pacman.d/mirrorlist

(perhaps you have to uncomment their entries, but defaults are safe).

So this means, that pacman will look in your /etc/pacman.d/mirrorlist for 
mirrors for a specific repository. So all you have to do is edit your 
/etc/pacman.d/mirrorlist to have only those mirrors uncommented you whish to 
use (usually they should be located as close as possible to have low latency) 
respectively move them to the top of the file since pacman will try each 
uncommented "Server = ..." - Line beginning in the top until it finds a working 
one.

You can also have a look at 
http://www.archlinux.de/?page=MirrorStatus;orderby=syncdelay;sort=1
(german) which is a nice graphical overview for mirrors.

Have a nice day,
Markus

Re: [arch-general] silent fsck at startup

[Markus Heuser]

Hey Denis,

> There is no information of bugreport or feature request about it, so
> should it be sane to open a feature request to remove this behaviour?

Well, that depends on whether the devs think it's "working as intended".
Personally, I don't think that suppressing the progress bar does much sense, 
especially since it's not _that_ verbose.
I mean, seeing a progress bar every 30 mounts/180 days can't be very annoying 
;)

> Would anyone disagree?

I would definitly second a feature request/bugreport.

Greetings,
Markus

Re: [arch-general] silent fsck at startup

[Markus Heuser]

Hi,

are you using the "quiet" parameter in GRUBs "kernel" line?
This is what caused fsck to be silent in my case.

The problem is that I don't wan't the extremely verbose kerneloutputs when not 
using "quiet". Besides, it also slows down booting since writing so much text 
into framebuffer isn't fast at all.

So if there was a way to have both, the "quiet" parameter and a fsck 
progressbar that would be very neat.

Markus

Re: [arch-general] x264, mplayer, ffmpeg rebuild?

[Markus Heuser]

Hi,

> Making a binary mplayer package is very difficult and the result can't be
> perfect for everybody because you have to make choices about what will be
> enabled in it (and add deps) and what will not (but some users might want
> it). It's the prototype of the package that should stay source-based if
> possible.

Well my main issue wasn't so much about an up-to-date, "bloated" or modified 
mplayer package but a bump of the x264 package wich is like half a year old if 
I interpret the versioning scheme right.

I just wanted to show that there are some showstoppers in the way if we want 
to provide an up to date x264. I'm perfectly fine with the mplayer version from 
the repos but I don't think that the PKGBUILD can be reused for the latest 
available mplayer sources if it is configured with x264 support (as it is the 
case now) because of the rewrite in the mplayer/ffmpeg code.

So I'm not asking for new features and stuff but if future mplayer packages 
should be built against an updated x264 package and provide the same 
functionality as todays version, the configure flags might need to be adapted 
as 
pointed out by the forums thread.

I'm sure that Hugo makes the right coices and would be able to find (better) 
solution for this on his own, but nevertheless giving the forum thread and my 
mail a read could perhaps save a bit of time ;)
If there is a possibility to "recycle" the now used PKGBUILD I definitely won't 
complain about it.

Greets,
Markus

Re: [arch-general] x264, mplayer, ffmpeg rebuild?

[Markus Heuser]

Hi,

> Have you tried mplayer-svn? Mplayer will probably not have a stable
> release ever anyway.

Yeah, I'm using the mplayer-svn package from AUR right now, with some 
adoptions regarding the configure flags (like support for x264 and mencoder of 
course...).

Well, I'm not to familiar with the development procedures of mplayer but what 
I mean by stable is "stable enough to be packaged" ;)

Cheers,
Markus

[arch-general] x264, mplayer, ffmpeg rebuild?

[Markus Heuser]

Hey guys,

Today i wanted to rip one of my dvds with h264enc from AUR [1]. I updated to 
the latest available version (8.6.6) but couldn't get it working together with 
the mencoder from the repos.

I'm not asking for support for an AUR package, but here is what I found out 
and I guess this could be important for other ripping/x264 encoding software 
as well:

The extra/x264 is severely outdated, in fact it lacks support for some
-x264encopts that can be used by mencoder and therefore breaks encoding. This 
seems not to be very common by now but sooner or later encoding tools will use 
these options and we should provide compatible packages :)

So, if one rebuilds x264 either with the $pkgver bumped to the latest 
available snapshot [2] or uses the AUR x264-git Package [3], MPlayer needs a 
rebuild too.

Using the official MPlayer PKGBUILD results in a build error with a possible 
solution posted on the forums [4]. I know that the OP is using an SVN version 
of mplayer but I couldn't get the new x264 working together with the mplayer 
PKGBUILD from the repos (another build error complaining about libavcodec), so 
upgrading to the latest & greatest (tm) version seems to be the next logical 
step to me.

I see that this "solution" involves using ffmpeg and mplayer svn versions which 
is obviously not suitable for the repos. But I'd be very thankful to see a 
rebuild of x264 and mplayer/ffmpeg as soon as the changes in ffmpeg and mplayer 
are in the stable branches and you guys can afford the time to do so :)

Greetings,
Markus

[1] http://aur.archlinux.org/packages.php?ID=12121
[2] ftp://ftp.videolan.org/pub/videolan/x264/snapshots/x264-
snapshot-20081228-2245.tar.bz2
[3] http://aur.archlinux.org/packages.php?ID=15774
[4] http://bbs.archlinux.org/viewtopic.php?id=61858